Kernel Shipped With Ubuntu 16.04.1 Cannot Recognize fakeRaid

Bug #1611277 reported by Huang YangWen
24
This bug affects 3 people
Affects Status Importance Assigned to Milestone
dmraid (Ubuntu)
Confirmed
Medium
Stefan Bader
Xenial
Confirmed
Undecided
Unassigned
linux (Ubuntu)
Invalid
Medium
Unassigned
Xenial
Invalid
Undecided
Unassigned

Bug Description

Kernel shipped with Ubuntu 16.04.1 cannot recognize fakeRaid created from Ubuntu 14.04. I've tried three ways but none of them work.

1. Update 14.04.4 to 16.04.1
2. Fresh install 16.04.1
3. Update kernel to linux-images-4.4.0-34-generic only

The result is that the mapper was seperated into /dev/sdb and /dev/sdc and cannot be rebuild with dmraid (said no raid disk) or mdadm (said no superblock).

Something interesting is that when I reinstall Ubuntu 14.04.2 with my old CD, during the installation Ubuntu is able to recognize /dev/mapper/.... But when I do a fresh install in Ubuntu 16.04 with the CD, I get /dev/sdb and /dev/sdc

The motherboard I'm using is Gigabyte X79-UP4

The fakeRaid with Marvell chipset on my motherboard shows the following information with fdisk in Ubuntu 16.04.1.
/dev/sda is where the system is installed. It is a normal hard drive.
/dev/sdb and /dev/sdc are using raid 1.

Disk /dev/sda: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders, total 1953525168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x000b7321

   Device Boot Start End Blocks Id System
/dev/sda1 * 2048 499711 248832 83 Linux
/dev/sda2 501758 1953523711 976510977 5 Extended
Partition 2 does not start on physical sector boundary.
/dev/sda5 501760 1953523711 976510976 8e Linux LVM

Disk /dev/sdb: 2000.4 GB, 2000398934016 bytes
255 heads, 63 sectors/track, 243201 cylinders, total 3907029168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x00000000

Disk /dev/sdb doesn't contain a valid partition table

Disk /dev/sdc: 2000.4 GB, 2000398934016 bytes
255 heads, 63 sectors/track, 243201 cylinders, total 3907029168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x00000000

Disk /dev/sdc doesn't contain a valid partition table

Disk /dev/mapper/ubuntu--vg-root: 982.8 GB, 982805118976 bytes
255 heads, 63 sectors/track, 119485 cylinders, total 1919541248 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x00000000

Disk /dev/mapper/ubuntu--vg-root doesn't contain a valid partition table

Disk /dev/mapper/ubuntu--vg-swap_1: 17.1 GB, 17091788800 bytes
255 heads, 63 sectors/track, 2077 cylinders, total 33382400 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x00000000

Disk /dev/mapper/ubuntu--vg-swap_1 doesn't contain a valid partition table

The fakeRaid with Marvell chipset on my motherboard shows the following information with fdisk in Ubuntu 14.04.4.

Disk /dev/mapper/ddf1_00000000000000004b1b92914b1b92914b0400004b040001: 2000.3 GB, 2000315047936 bytes
255 heads, 63 sectors/track, 243191 cylinders, total 3906865328 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x3b9fee89

                                                         Device Boot Start End Blocks Id System
/dev/mapper/ddf1_00000000000000004b1b92914b1b92914b0400004b040001p1 2048 3906865151 1953431552 83 Linux

Disk /dev/mapper/ddf1_00000000000000004b1b92914b1b92914b0400004b040001p1: 2000.3 GB, 2000313909248 bytes
255 heads, 63 sectors/track, 243190 cylinders, total 3906863104 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x00000000

Disk /dev/mapper/ddf1_00000000000000004b1b92914b1b92914b0400004b040001p1 doesn't contain a valid partition table
---
ApportVersion: 2.14.1-0ubuntu3.21
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC1: bblab 6762 F.... pulseaudio
 /dev/snd/controlC0: bblab 6762 F.... pulseaudio
DistroRelease: Ubuntu 14.04
HibernationDevice: RESUME=UUID=433bcdda-b73d-47e7-abb8-8fab93db4123
InstallationDate: Installed on 2016-07-26 (14 days ago)
InstallationMedia: Ubuntu 14.04.2 LTS "Trusty Tahr" - Release amd64 (20150218.1)
MachineType: Gigabyte Technology Co., Ltd. To be filled by O.E.M.
Package: linux (not installed)
ProcFB: 0 nouveaufb
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.4.0-34-generic root=/dev/mapper/ubuntu--vg-root ro quiet splash vt.handoff=7
ProcVersionSignature: Ubuntu 4.4.0-34.53~14.04.1-generic 4.4.15
RelatedPackageVersions:
 linux-restricted-modules-4.4.0-34-generic N/A
 linux-backports-modules-4.4.0-34-generic N/A
 linux-firmware 1.127.22
RfKill:

Tags: trusty
Uname: Linux 4.4.0-34-generic x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo
_MarkForUpload: True
dmi.bios.date: 12/16/2013
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: F5
dmi.board.asset.tag: To be filled by O.E.M.
dmi.board.name: X79-UP4
dmi.board.vendor: Gigabyte Technology Co., Ltd.
dmi.board.version: To be filled by O.E.M.
dmi.chassis.asset.tag: To Be Filled By O.E.M.
dmi.chassis.type: 3
dmi.chassis.vendor: Gigabyte Technology Co., Ltd.
dmi.chassis.version: To Be Filled By O.E.M.
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrF5:bd12/16/2013:svnGigabyteTechnologyCo.,Ltd.:pnTobefilledbyO.E.M.:pvrTobefilledbyO.E.M.:rvnGigabyteTechnologyCo.,Ltd.:rnX79-UP4:rvrTobefilledbyO.E.M.:cvnGigabyteTechnologyCo.,Ltd.:ct3:cvrToBeFilledByO.E.M.:
dmi.product.name: To be filled by O.E.M.
dmi.product.version: To be filled by O.E.M.
dmi.sys.vendor: Gigabyte Technology Co., Ltd.

description: updated
Revision history for this message
Brad Figg (brad-figg) wrote : Missing required logs.

This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run:

apport-collect 1611277

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

Changed in linux (Ubuntu):
status: New → Incomplete
Revision history for this message
Huang YangWen (yangwen5301) wrote : AlsaInfo.txt

apport information

tags: added: apport-collected trusty
description: updated
Revision history for this message
Huang YangWen (yangwen5301) wrote : BootDmesg.txt

apport information

Revision history for this message
Huang YangWen (yangwen5301) wrote : CRDA.txt

apport information

Revision history for this message
Huang YangWen (yangwen5301) wrote : CurrentDmesg.txt

apport information

Revision history for this message
Huang YangWen (yangwen5301) wrote : IwConfig.txt

apport information

Revision history for this message
Huang YangWen (yangwen5301) wrote : Lspci.txt

apport information

Revision history for this message
Huang YangWen (yangwen5301) wrote : Lsusb.txt

apport information

Revision history for this message
Huang YangWen (yangwen5301) wrote : ProcCpuinfo.txt

apport information

Revision history for this message
Huang YangWen (yangwen5301) wrote : ProcEnviron.txt

apport information

Revision history for this message
Huang YangWen (yangwen5301) wrote : ProcInterrupts.txt

apport information

Revision history for this message
Huang YangWen (yangwen5301) wrote : ProcModules.txt

apport information

Revision history for this message
Huang YangWen (yangwen5301) wrote : PulseList.txt

apport information

Revision history for this message
Huang YangWen (yangwen5301) wrote : UdevDb.txt

apport information

Revision history for this message
Huang YangWen (yangwen5301) wrote : UdevLog.txt

apport information

Revision history for this message
Huang YangWen (yangwen5301) wrote : WifiSyslog.txt

apport information

description: updated
Changed in linux (Ubuntu):
status: Incomplete → Confirmed
Revision history for this message
Joseph Salisbury (jsalisbury) wrote :

Would it be possible for you to test the latest upstream kernel? Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest v4.7 kernel[0].

If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

Once testing of the upstream kernel is complete, please mark this bug as "Confirmed".

Thanks in advance.

[0] http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.8-rc1

Changed in linux (Ubuntu):
importance: Undecided → Medium
tags: added: kernel-da-key needs-bisect
Revision history for this message
Joseph Salisbury (jsalisbury) wrote :

Comment #17 should have said the "latest v4.8 kernel"

Revision history for this message
Huang YangWen (yangwen5301) wrote :

Is testing the upstream kernel able to reverse back to the original state just like I install the 4.4.0-34-generic on Ubuntu 14.04.4?

After the trial, am I able to remove the upstream kernel with apt-get remove and purge? Thanks.

Revision history for this message
Joseph Salisbury (jsalisbury) wrote :

Yes, you can remove the mainline kernel with dpkg --purge

Revision history for this message
Huang YangWen (yangwen5301) wrote :

Sorry, I'm not able to boot my PC with kernel 4.8.0-040800rc1_4.8.0-040800rc1.201608072231.

The error message is as follows:
/scripts/init-top/udev: line 14: can't create /sys/kernel/uevent_helper: permissions failed

Revision history for this message
Huang YangWen (yangwen5301) wrote :

/scripts/init-top/udev: line 14: can't create /sys/kernel/uevent-helper: Permission denied.

Gave up waiting for root device. Common problems:
- Boot args (cat /proc/cmdline)
- Check root delay= (did the system wait long enough?)
- Check root= (did the system wait for the right device?)
- Missing modules (cat /proc/modules, ls /dev)
ALERT! /dev/mapper/ubuntu--vg-root does not exist. Dropping to a shell.
BusyBox v1.12.1 (Ubuntu 1:1.21.0-iubuntu1) built-in shell (ash) Enter 'help'
for a list a built-in commands

(initramfs)

Revision history for this message
Stefan Bader (smb) wrote :

The user-space tool that is responsible to set up fakeraid (except for Intel MSM and DDS style meta-data). Make sure that package is still installed and the dmraid command is still usable.

A rc1 mainline kernel is probably a bit too recent since the first release candidate can always be unstable. A 4.7 final maybe would have been better, though I suspect its less of a kernel issue than a problem with the user-space tool. Maybe related to the kernel because the interface to set up a device-mapper raid1 could have changed.

Not sure if you know how to get back to a working kernel. If not, it should be possible to quickly hit left-shift between BIOS and the hidden grub screen to get to the grub menu (though I am too slow most of the time). From there one would select the alternative option and there has the choice of older kernels.

Revision history for this message
Huang YangWen (yangwen5301) wrote :

Sure, I've rolled back to the working kernel after the boot failed. Thank you!

Is there any thing I can do to fix this bug?

Revision history for this message
Stefan Bader (smb) wrote :

Sure, those BIOS fakeraid boards are getting rare (meaning only you can do tests and provide info). So you can (with the current 16.04.1 kernel) check whether the dmraid package is still installed. If yes, try to run it in various modes (there is one to only show things, but also one that is supposed to create the raid1). I cannot remember the exact command lines but there should be a man page for it. Then please add any results/error messages to this bug.

Revision history for this message
Huang YangWen (yangwen5301) wrote :

Yes, I've already done that. I try to use dmraid with arg "-ay" to scan any possible raid devices when I changed kernel in 14.04.4, and dmraid returns no raid found. fdisk shows /dev/sdb and /dev/sdc as ddf_raid_member.

Revision history for this message
Stefan Bader (smb) wrote :

Oh I think I meant ddf not dds in my previous post. So it could be that this just moved from being handled by dmraid to mdadm. Could you add the output of lsblk and "cat /proc/mdstat", please?

Revision history for this message
Huang YangWen (yangwen5301) wrote :

Ubuntu 14.04.4

lsblk

NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 931.5G 0 disk
├─sda1 8:1 0 243M 0 part /boot
├─sda2 8:2 0 1K 0 part
└─sda5 8:5 0 931.3G 0 part
  ├─ubuntu--vg-root (dm-0) 252:0 0 915.3G 0 lvm /
  └─ubuntu--vg-swap_1 (dm-1) 252:1 0 15.9G 0 lvm [SWAP]
sdb 8:16 0 1.8T 0 disk
└─ddf1_00000000000000004b1b92914b1b92914b0400004b040001 (dm-2) 252:2 0 1.8T 0 dmraid
  └─ddf1_00000000000000004b1b92914b1b92914b0400004b040001p1 (dm-3) 252:3 0 1.8T 0 part /media/Database
sdc 8:32 0 1.8T 0 disk
└─ddf1_00000000000000004b1b92914b1b92914b0400004b040001 (dm-2) 252:2 0 1.8T 0 dmraid
  └─ddf1_00000000000000004b1b92914b1b92914b0400004b040001p1 (dm-3) 252:3 0 1.8T 0 part /media/Database
sdd 8:48 0 1.8T 0 disk
└─sdd1 8:49 0 1.8T 0 part
sr0 11:0 1 1024M 0 rom

Strange that in Ubuntu 14.04.4, I get the following output with cat /proc/mdstat

Personalities :
unused devices: <none>

In Ubuntu 16.04.1

lsblk

NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 931.5G 0 disk
├─sda1 8:1 0 243M 0 part /boot
├─sda2 8:2 0 1K 0 part
└─sda5 8:5 0 931.3G 0 part
  ├─ubuntu--vg-root (dm-0) 252:0 0 915.3G 0 lvm /
  └─ubuntu--vg-swap_1 (dm-1) 252:1 0 15.9G 0 lvm [SWAP]
sdb 8:16 1 1.8T 0 disk
sdc 8:32 1 1.8T 0 disk
sdd 8:48 0 1.8T 0 disk
└─sdd1 8:49 0 1.8T 0 part
sr0 11:0 1 1024M 0 rom

cat /proc/mdstat

Personalities :
unused devices: <none>

Revision history for this message
Huang YangWen (yangwen5301) wrote :

sdd is a usable external hard drive.

Revision history for this message
Stefan Bader (smb) wrote :

The 14.01.x output is not that surprising, dmraid is setting up the raid1 as device-mapper targets. The problem is that dmraid has been abandoned upstream. So the package is unchanged since 14.04 (that could mean it does not even compile anymore).

So there might be some options:
1. Sicne mdadm is supposed to be supporting ddf signatures, the question is was the user-space side actually installed on upgrade (package name mdadm)? If it is installed, then at least in 14.04 there were boot options (either /etc/default/grub or some file in /etc/default/grub.d) that were used to modify handling of ddf signatures. So maybe those need to change, then run update-grub and reboot.

2. The other possibility would be to force a re-compile of dmraid in 16.04 and see whether that works or needs fixing. I could do that but I cannot promise how quickly I get to it.

Revision history for this message
Huang YangWen (yangwen5301) wrote :

So am I able to switch from dmraid to mdadm to control the raid1 without affecting the hard drive in Ubuntu 14.04.4?

Because when I do a fresh install of Ubuntu 16.04.1, which comes with Kernel 4.4.0-34, mdadm (pre-installed in 16.04.1 already) says my raid device does not have recognized superblocks. If I try to load the disk directly, it will give me a unknown type ddf_raid_member.

Revision history for this message
Stefan Bader (smb) wrote :

That sounds more like, despite dmraid using ddf in the name, the BIOS uses some different format which mdadm does not recognize. So that would mean you cannot switch from dmraid to mdadm.

Revision history for this message
Stefan Bader (smb) wrote :

I got some time and did a rebuild of dmraid in Xenial, which completed. So I am not really understanding why running dmraid in 16.04 does claim to find nothing while it does succeed in 14.04. I am attaching the two debs here just in case an actual rebuild produces something different than before.

The dmraid command seems to have verbose and debug options. Maybe those help. Or you could check /var/log/syslog to see whether running dmraid produces some error messages...

Revision history for this message
Stefan Bader (smb) wrote :
Revision history for this message
Huang YangWen (yangwen5301) wrote :

The following commands are executed in Ubuntu 14.04.4 + 4.4.0-34-generic

1. dmraid -d -r

DEBUG: not isw at 17091787776
DEBUG: isw trying hard coded -2115 offset.
DEBUG: not isw at 17090705920
DEBUG: not isw at 982805117952
DEBUG: isw trying hard coded -2115 offset.
DEBUG: not isw at 982804036096
DEBUG: not isw at 2000365288448
DEBUG: isw trying hard coded -2115 offset.
DEBUG: not isw at 2000364206592
DEBUG: not isw at 1000204884992
DEBUG: isw trying hard coded -2115 offset.
DEBUG: not isw at 1000203803136
no raid disks

2. dmraid -V

dmraid version: 1.0.0.rc16 (2009.09.16) shared
dmraid library version: 1.0.0.rc16 (2009.09.16)
device-mapper version: unknown

Option verbose only return "no raid disks"

I've also take a look into the system log. Seems the device-mapper versions of the two kernels are different?

Ubuntu 14.04.4 + 3.16.0-77-generic

Aug 10 20:10:55 bblabcloud kernel: [ 0.625995] device-mapper: uevent: version 1.0.3
Aug 10 20:10:55 bblabcloud kernel: [ 0.626037] device-mapper: ioctl: 4.34.0-ioctl (2015-10-28) initialised: <email address hidden>
.....

Aug 10 11:26:09 bblabcloud kernel: [ 26.001170] device-mapper: multipath: version 1.7.0 loaded

Ubuntu 14.04.4 + 4.4.0-34-generic

Aug 10 20:10:55 bblabcloud kernel: [ 0.625995] device-mapper: uevent: version 1.0.3
Aug 10 20:10:55 bblabcloud kernel: [ 0.626037] device-mapper: ioctl: 4.34.0-ioctl (2015-10-28) initialised: <email address hidden>
......

Aug 10 20:10:55 bblabcloud kernel: [ 9.720613] device-mapper: multipath: version 1.10.0 loaded

Revision history for this message
Huang YangWen (yangwen5301) wrote :

The following commands are executed in Ubuntu 14.04.4 + 3.16.0-77-generic

1. dmraid -d -r

DEBUG: not isw at 2000313908224
DEBUG: isw trying hard coded -2115 offset.
DEBUG: not isw at 2000312826368
DEBUG: not isw at 2000315046912
DEBUG: isw trying hard coded -2115 offset.
DEBUG: not isw at 2000313965056
DEBUG: not isw at 17091787776
DEBUG: isw trying hard coded -2115 offset.
DEBUG: not isw at 17090705920
DEBUG: not isw at 982805117952
DEBUG: isw trying hard coded -2115 offset.
DEBUG: not isw at 982804036096
DEBUG: not isw at 2000365288448
DEBUG: isw trying hard coded -2115 offset.
DEBUG: not isw at 2000364206592
DEBUG: not isw at 2000398932992
DEBUG: isw trying hard coded -2115 offset.
DEBUG: not isw at 2000397851136
DEBUG: not isw at 2000398932992
DEBUG: isw trying hard coded -2115 offset.
DEBUG: not isw at 2000397851136
DEBUG: not isw at 1000204884992
DEBUG: isw trying hard coded -2115 offset.
DEBUG: not isw at 1000203803136
/dev/sdc: ddf1, ".ddf1_disks", GROUP, ok, 3906898096 sectors, data@ 0
/dev/sdb: ddf1, ".ddf1_disks", GROUP, ok, 3906898096 sectors, data@ 0

2. dmraid -V

dmraid version: 1.0.0.rc16 (2009.09.16) shared
dmraid library version: 1.0.0.rc16 (2009.09.16)
device-mapper version: unknown

Revision history for this message
Huang YangWen (yangwen5301) wrote :

I saw this line

Aug 10 11:26:09 bblabcloud kernel: [ 26.001170] device-mapper: multipath: version 1.7.0 loaded

when the system startup.

But when I type multipath in terminal, I was told multipath is not installed. Is the multipath in the terminal is a config tool to config the device-mapper multipath?

Revision history for this message
Stefan Bader (smb) wrote :

What you see (the multipath message) is from a kernel module that gets loaded. That does not necessarily mean it is really used. That is the way that dmraid, lvm, multipath and mdadm work. Only mdadm is different in using different kernel driver modules than the rest.

But in general the commands are responsible for reading meta-data from the devices and detecting whether those contain logical devices they can handle. Then the info is used to create a simpler representation of that which is passed to kernel drivers. And those create the logical disks that you then can use.

The debug data you get unfortunately does not really give a hint why the raid is not detected. Mind, at that stage the kernel is not yet involved. The fact that the device-mapper kernel driver has different versions is not surprising for different kernels. The more important number would be the ioctl-version and that is the same. But still I do not think dmraid is already talking to device-mapper at that stage.

So the only visible difference in the debug is that one is longer than the other (btw, the man page mentions you might get more details when repeating the -d option, like -d -d -d). The only way to guess which disks it looks at might be to compare the offsets to disk size. But that is not very reliable.

Revision history for this message
Stefan Bader (smb) wrote :

So it appears that "dmraid -r -d -d -v -v -v" would produce enough output to at least see whether it is trying the disks which contain the raid.

Revision history for this message
Huang YangWen (yangwen5301) wrote :
Download full text (4.7 KiB)

Ubuntu 14.04.4 + 3.16.0-77-generic

NOTICE: creating directory /var/lock/dmraid
WARN: locking /var/lock/dmraid/.lock
WARN: missing dm serial file for /dev/dm-0
WARN: missing dm serial file for /dev/dm-1
WARN: missing dm serial file for /dev/dm-2
WARN: missing dm serial file for /dev/dm-3
NOTICE: /dev/dm-3: asr discovering
NOTICE: /dev/dm-3: ddf1 discovering
NOTICE: /dev/dm-3: hpt37x discovering
NOTICE: /dev/dm-3: hpt45x discovering
NOTICE: /dev/dm-3: isw discovering
DEBUG: not isw at 2000313908224
DEBUG: isw trying hard coded -2115 offset.
DEBUG: not isw at 2000312826368
NOTICE: /dev/dm-3: jmicron discovering
NOTICE: /dev/dm-3: lsi discovering
NOTICE: /dev/dm-3: nvidia discovering
NOTICE: /dev/dm-3: pdc discovering
NOTICE: /dev/dm-3: sil discovering
NOTICE: /dev/dm-3: via discovering
NOTICE: /dev/dm-2: asr discovering
NOTICE: /dev/dm-2: ddf1 discovering
NOTICE: /dev/dm-2: hpt37x discovering
NOTICE: /dev/dm-2: hpt45x discovering
NOTICE: /dev/dm-2: isw discovering
DEBUG: not isw at 2000315046912
DEBUG: isw trying hard coded -2115 offset.
DEBUG: not isw at 2000313965056
NOTICE: /dev/dm-2: jmicron discovering
NOTICE: /dev/dm-2: lsi discovering
NOTICE: /dev/dm-2: nvidia discovering
NOTICE: /dev/dm-2: pdc discovering
NOTICE: /dev/dm-2: sil discovering
NOTICE: /dev/dm-2: via discovering
NOTICE: /dev/dm-1: asr discovering
NOTICE: /dev/dm-1: ddf1 discovering
NOTICE: /dev/dm-1: hpt37x discovering
NOTICE: /dev/dm-1: hpt45x discovering
NOTICE: /dev/dm-1: isw discovering
DEBUG: not isw at 17091787776
DEBUG: isw trying hard coded -2115 offset.
DEBUG: not isw at 17090705920
NOTICE: /dev/dm-1: jmicron discovering
NOTICE: /dev/dm-1: lsi discovering
NOTICE: /dev/dm-1: nvidia discovering
NOTICE: /dev/dm-1: pdc discovering
NOTICE: /dev/dm-1: sil discovering
NOTICE: /dev/dm-1: via discovering
NOTICE: /dev/dm-0: asr discovering
NOTICE: /dev/dm-0: ddf1 discovering
NOTICE: /dev/dm-0: hpt37x discovering
NOTICE: /dev/dm-0: hpt45x discovering
NOTICE: /dev/dm-0: isw discovering
DEBUG: not isw at 982805117952
DEBUG: isw trying hard coded -2115 offset.
DEBUG: not isw at 982804036096
NOTICE: /dev/dm-0: jmicron discovering
NOTICE: /dev/dm-0: lsi discovering
NOTICE: /dev/dm-0: nvidia discovering
NOTICE: /dev/dm-0: pdc discovering
NOTICE: /dev/dm-0: sil discovering
NOTICE: /dev/dm-0: via discovering
NOTICE: /dev/sdd: asr discovering
NOTICE: /dev/sdd: ddf1 discovering
NOTICE: /dev/sdd: hpt37x discovering
NOTICE: /dev/sdd: hpt45x discovering
NOTICE: /dev/sdd: isw discovering
DEBUG: not isw at 2000365288448
DEBUG: isw trying hard coded -2115 offset.
DEBUG: not isw at 2000364206592
NOTICE: /dev/sdd: jmicron discovering
NOTICE: /dev/sdd: lsi discovering
NOTICE: /dev/sdd: nvidia discovering
NOTICE: /dev/sdd: pdc discovering
NOTICE: /dev/sdd: sil discovering
NOTICE: /dev/sdd: via discovering
NOTICE: /dev/sdc: asr discovering
NOTICE: /dev/sdc: ddf1 discovering
NOTICE: /dev/sdc: ddf1 metadata discovered
NOTICE: /dev/sdc: hpt37x discovering
NOTICE: /dev/sdc: hpt45x discovering
NOTICE: /dev/sdc: isw discovering
DEBUG: not isw ...

Read more...

Revision history for this message
Huang YangWen (yangwen5301) wrote :

Ubuntu 14.04.4 + 4.4.0-34-generic

NOTICE: creating directory /var/lock/dmraid
WARN: locking /var/lock/dmraid/.lock
NOTICE: skipping removable device /dev/sdb
NOTICE: skipping removable device /dev/sdc
WARN: missing dm serial file for /dev/dm-0
WARN: missing dm serial file for /dev/dm-1
NOTICE: /dev/dm-1: asr discovering
NOTICE: /dev/dm-1: ddf1 discovering
NOTICE: /dev/dm-1: hpt37x discovering
NOTICE: /dev/dm-1: hpt45x discovering
NOTICE: /dev/dm-1: isw discovering
DEBUG: not isw at 17091787776
DEBUG: isw trying hard coded -2115 offset.
DEBUG: not isw at 17090705920
NOTICE: /dev/dm-1: jmicron discovering
NOTICE: /dev/dm-1: lsi discovering
NOTICE: /dev/dm-1: nvidia discovering
NOTICE: /dev/dm-1: pdc discovering
NOTICE: /dev/dm-1: sil discovering
NOTICE: /dev/dm-1: via discovering
NOTICE: /dev/dm-0: asr discovering
NOTICE: /dev/dm-0: ddf1 discovering
NOTICE: /dev/dm-0: hpt37x discovering
NOTICE: /dev/dm-0: hpt45x discovering
NOTICE: /dev/dm-0: isw discovering
DEBUG: not isw at 982805117952
DEBUG: isw trying hard coded -2115 offset.
DEBUG: not isw at 982804036096
NOTICE: /dev/dm-0: jmicron discovering
NOTICE: /dev/dm-0: lsi discovering
NOTICE: /dev/dm-0: nvidia discovering
NOTICE: /dev/dm-0: pdc discovering
NOTICE: /dev/dm-0: sil discovering
NOTICE: /dev/dm-0: via discovering
NOTICE: /dev/sdd: asr discovering
NOTICE: /dev/sdd: ddf1 discovering
NOTICE: /dev/sdd: hpt37x discovering
NOTICE: /dev/sdd: hpt45x discovering
NOTICE: /dev/sdd: isw discovering
DEBUG: not isw at 2000365288448
DEBUG: isw trying hard coded -2115 offset.
DEBUG: not isw at 2000364206592
NOTICE: /dev/sdd: jmicron discovering
NOTICE: /dev/sdd: lsi discovering
NOTICE: /dev/sdd: nvidia discovering
NOTICE: /dev/sdd: pdc discovering
NOTICE: /dev/sdd: sil discovering
NOTICE: /dev/sdd: via discovering
NOTICE: /dev/sda: asr discovering
NOTICE: /dev/sda: ddf1 discovering
NOTICE: /dev/sda: hpt37x discovering
NOTICE: /dev/sda: hpt45x discovering
NOTICE: /dev/sda: isw discovering
DEBUG: not isw at 1000204884992
DEBUG: isw trying hard coded -2115 offset.
DEBUG: not isw at 1000203803136
NOTICE: /dev/sda: jmicron discovering
NOTICE: /dev/sda: lsi discovering
NOTICE: /dev/sda: nvidia discovering
NOTICE: /dev/sda: pdc discovering
NOTICE: /dev/sda: sil discovering
NOTICE: /dev/sda: via discovering
no raid disks
WARN: unlocking /var/lock/dmraid/.lock

Revision history for this message
Huang YangWen (yangwen5301) wrote :

I found someone has similar problem using 4.4.0 kernel in arch linux. Are these events related?

dmraid thinks my array devices are removable (they aren't...)
https://bbs.archlinux.org/viewtopic.php?id=208580

[SOLVED] Hard disk partitions showing up as removable devices
https://bbs.archlinux.org/viewtopic.php?id=208514

ATA: All drives are marked as removable, even non-removable (for example, internal SATA HDD or SSD)
https://bugzilla.kernel.org/show_bug.cgi?id=111651

Revision history for this message
Stefan Bader (smb) wrote :

Yes, it sounds like that is the initial trigger. So somewhere between 3.16 and 4.4 the kernel got better in declaring which disk drives could be hot-plugged. And the AHCI and (likely) the fakeraid modes potentially support to hot-plug disks (you could have externally accessible drive bays). Sometimes the BIOS allows to change the hot-plug support but not all). If you had that BIOS option that would be a work-around for you.

But probably dmraid should not care about a drive being removable. It probably was meant to protect against probing USB sticks and/or cdroms. I don't know for sure. As said on some of the threads you link I would rather not think of this as a kernel bug. It rather supports the flag more correctly.

So if something needs to change it probably is dmraid. Unfortunately that change might have odd consequences in other cases. So I would like to be careful there.

Changed in dmraid (Ubuntu):
importance: Undecided → Medium
status: New → Confirmed
Changed in linux (Ubuntu):
status: Confirmed → Invalid
Changed in dmraid (Ubuntu):
assignee: nobody → Stefan Bader (smb)
Changed in linux (Ubuntu Xenial):
status: New → Invalid
Revision history for this message
Huang YangWen (yangwen5301) wrote :

Thanks!

Revision history for this message
Huang YangWen (yangwen5301) wrote :

Hi, is the change log of kernel 4.4.5 a valid upstream commit?

commit a55479ab637cda5ebbfdb9eb7c062bd99c13d5d9
Author: Manuel Lauss <email address hidden>
Date: Sat Feb 27 16:10:05 2016 +0100

    ata: ahci: don't mark HotPlugCapable Ports as external/removable

    commit dc8b4afc4a04fac8ee55a19b59f2356a25e7e778 upstream.

    The HPCP bit is set by bioses for on-board sata ports either because
    they think sata is hotplug capable in general or to allow Windows
    to display a "device eject" icon on ports which are routed to an
    external connector bracket.

    However in Redhat Bugzilla #1310682, users report that with kernel 4.4,
    where this bit test first appeared, a lot of partitions on sata drives
    are now mounted automatically.

    This patch should fix redhat and a lot of other distros which
    unconditionally automount all devices which have the "removable"
    bit set.

    Signed-off-by: Manuel Lauss <email address hidden>
    Signed-off-by: Tejun Heo <email address hidden>
    Fixes: 8a3e33cf92c7 ("ata: ahci: find eSATA ports and flag them as removable" changes userspace behavior)
    Link: http://<email address hidden>
    Signed-off-by: Greg Kroah-Hartman <email address hidden>

From: https://www.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.4.5

Revision history for this message
Huang YangWen (yangwen5301) wrote :

Tried kernel v4.6-yakkety. Not working.

Revision history for this message
Stefan Bader (smb) wrote :

The commit is a legit stable fix and part of the Ubuntu 16.04 kernel since version 4.4.0-18 (your dmesg shows you a re running 4.4.0-34). So unfortunately not helping in your case. I extracted the relevant syslog data below. From that info, the two disks are connected to a Marvell controller in RAID mode.
The change you found was ignoring the HPCP bit. But a drive would still marked as removable if the port had a ESP bit set and the controller had a SXS capability set. I don't think the port bits show up in the log but the controller does have SXS set. So there might be a chance that in your BIOS, there is an option related to the Marvell controller that says "ESP" somewhere. And if you disable that, the drives no longer are removable.

But generally I think dmraid (and fwiw the desktop environment mounting everything removable) uses incorrect assumptions about what removable means. All USB disks are removable but not all removable disks are USB...

06:00.0 RAID bus controller [0104]: Marvell Technology Group Ltd. 88SE9172 SATA III 6Gb/s RAID Controller [1b4b:9192] (rev 12) Subsystem: Gigabyte Technology Co., Ltd Device [1458:b000]

[ 0.693411] ahci 0000:06:00.0: AHCI 0001.0000 32 slots 2 ports 6 Gbps 0x3 impl RAID mode
[ 0.693413] ahci 0000:06:00.0: flags: 64bit ncq sntf led only pmp fbs pio slum part sxs
[ 0.693609] scsi host8: ahci
[ 0.693679] scsi host9: ahci
[ 0.693707] ata9: SATA max UDMA/133 abar m512@0xfb410000 port 0xfb410100 irq 43
[ 0.693710] ata10: SATA max UDMA/133 abar m512@0xfb410000 port 0xfb410180 irq 43
[ 1.184050] ata10: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[ 1.184069] ata9: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[ 1.184636] ata10.00: ATA-9: ST2000DM001-1CH164, CC27, max UDMA/133
[ 1.184638] ata10.00: 3907029168 sectors, multi 0: LBA48 NCQ (depth 31/32), AA
[ 1.184654] ata9.00: ATA-9: ST2000DM001-1CH164, CC27, max UDMA/133
[ 1.184655] ata9.00: 3907029168 sectors, multi 0: LBA48 NCQ (depth 31/32), AA
[ 1.185166] ata10.00: configured for UDMA/133
[ 1.185182] ata9.00: configured for UDMA/133
[ 1.185306] scsi 8:0:0:0: Direct-Access ATA ST2000DM001-1CH1 CC27 PQ: 0 ANSI: 5
[ 1.185443] sd 8:0:0:0: [sdb] 3907029168 512-byte logical blocks: (2.00 TB/1.82 TiB)
[ 1.185445] sd 8:0:0:0: [sdb] 4096-byte physical blocks
[ 1.185451] sd 8:0:0:0: Attached scsi generic sg2 type 0
[ 1.185525] sd 8:0:0:0: [sdb] Write Protect is off
[ 1.185527] sd 8:0:0:0: [sdb] Mode Sense: 00 3a 00 00
[ 1.185553] sd 8:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[ 1.185577] scsi 9:0:0:0: Direct-Access ATA ST2000DM001-1CH1 CC27 PQ: 0 ANSI: 5
[ 1.185711] sd 9:0:0:0: [sdc] 3907029168 512-byte logical blocks: (2.00 TB/1.82 TiB)
[ 1.185713] sd 9:0:0:0: [sdc] 4096-byte physical blocks
[ 1.185725] sd 9:0:0:0: Attached scsi generic sg3 type 0
[ 1.185782] sd 9:0:0:0: [sdc] Write Protect is off
[ 1.185784] sd 9:0:0:0: [sdc] Mode Sense: 00 3a 00 00
[ 1.185807] sd 9:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[ 1.189274] sd 8:0:0:0: [sdb] Attached SCSI removable disk

Revision history for this message
Huang YangWen (yangwen5301) wrote :

Sadly, Marvell SATA controller seems to have its own configuration (I'll try to send a mail to GigaByte support). I've checked the hotplug related options in the BIOS, they are all turned off.

Revision history for this message
Huang YangWen (yangwen5301) wrote :

Sorry to bother you, since dmraid as no update anymore, so is it recommended to use mdadm instead? Is the transfer possible or I'll have to wipe out the whole disk and rebuild it? Thanks.

Revision history for this message
Stefan Bader (smb) wrote :

Sorry, I was distracted by other things. So I will be attaching a proposed update to dmraid and some pre-built package to test. I just cannot promise that change will be accepted.

About converting to mdadm: That would be an option that might be more future proof but only if you do not want to use the RAIDed disks in parallel with Windows. The drivers that come with the motherboard rely on the BIOS signatures and I am not aware (I never had need, so I never searched) of any generic RAID driver for Windows that would recognize the DDF signatures that mdadm creates.

If you only will be using Linux it is a different story. Then moving to mdadm (you can then use even the normal superblock format, no strict need for DDF) would have the additional benefit of being able to replace the motherboard or move the disks to a different computer and have the RAID still working. But of course its a tedious task: you need some place to backup all data, also better make sure the backup has no bits corrupted (maybe rare but happened), erase the RAID signatures (if possible, from the BIOS), either plug the disks to a different controller or switch the current one into SATA/AHCI mode, set up the mdamd RAID and finally copy the backup back (and possibly again check for consistency). A lot of work...

Revision history for this message
Stefan Bader (smb) wrote :
Revision history for this message
Stefan Bader (smb) wrote :
Revision history for this message
Huang YangWen (yangwen5301) wrote :

So now I'll just have to install these two packages and switch to a newer kernel to see if the fix works? Another question is that does dmraid have maximum size limit of the raid devices (something like raid 1 up to 4TB)?

Revision history for this message
Huang YangWen (yangwen5301) wrote :

I'm only using Linux on this PC. But the migration process seems to tired. Maybe I'll just stick to the dmraid if there's not major problems.

tags: added: patch
Revision history for this message
Huang YangWen (yangwen5301) wrote :

It says my libdevmapper (2:1.02.77) is too old, it needs (2:1.02.97) instead. So I should install the patch after I switched the kernel?

Revision history for this message
Stefan Bader (smb) wrote :

Oh, sorry, wait a second. I think I made a mistake and compiled the package against 16.04 user-space.

Revision history for this message
Stefan Bader (smb) wrote :

Those packages are compiled against 14.04 user-space and should need no update for libdevmapper.

Revision history for this message
Stefan Bader (smb) wrote :
Revision history for this message
Stefan Bader (smb) wrote :

About your question about maximum RAID size: I cannot answer that. There possibly are different limits on what dmraid can construct via device-mapper (those are likely higher than 4TB). But then there might be limits that the meta-data which the BIOS uses impose. And I have no clue there.

Revision history for this message
Huang YangWen (yangwen5301) wrote :

Thank you very much! Currently the system works normally with the raid devices loaded.

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in dmraid (Ubuntu Xenial):
status: New → Confirmed
Revision history for this message
Jean-Dominique (ubuntu-delyon) wrote :

On a Dell Dimension 5150:
Does not work with /boot/vmlinuz-4.4.0-34-generic
Works properly with /boot/vmlinuz-3.13.0-93-generic

Two disks / RAID1.

Boot very slow including grub.

syslog shows a deep slow down when activating UUID access.
-> First when activating swap.
-> When fstab is adapted to aim on dmraid disk, instead of triplicated UUID, the problem occurs later at UUID service activation.

Boot on image 3 instead of image 4 is OK.

Not tested new images. Waiting for an automatic upgrade.

Revision history for this message
Johnius (johnius) wrote :

I know this is probably a separate issue, but this is the most recent article I can find on dmraid. I can't get the dmraid to activate on boot. I downloaded and installed the 16.04 packages that are listed in this thread, but it isn't hooking into my boot sequence properly.

To post a comment you must log in.