Kernel Shipped With Ubuntu 16.04.1 Cannot Recognize fakeRaid

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.

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

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

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

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.

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

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

/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)

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.

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?

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.

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.

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?

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>

sdd is a usable external hard drive.

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.

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.

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.

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...

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

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

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?

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.

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.

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 ...

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

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

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.

Thanks!

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

Tried kernel v4.6-yakkety. Not working.

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

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.

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.

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...

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)?

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.

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?

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

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

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.

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

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

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.

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.