FakeRAID fails with kernel 2.6.28

I'm having the same problem with kernel 2.6.28-4

I get the same on my NVidia board and dmraid setup. Fortunately, when I performed the upgrade to 9.04, I didn't let it tidy up old packages, so I boot the Intrepid kernel.

When I do that, it doesn't initially setup the array, so I have to do "dmraid -ay" to get that done, then it will boot, albeit on an older kernel.

Got exactly the same issue here as described. Including behaviour described by ViRMiN. In fact, I lost ability to boot with "dmraid -ay" by further updating the system and reinstaling few packages.

Furthermore, installation from alternate disk fails when detecting RAID and in the log is a remark that module dm_mod cannot be loaded. Probably missing in initramfs.

Fortunately, I can still continue to boot the 2.6.27-11 kernel with "dmraid -ay" when it hits the BusyBox console - as I just found when I managed to hang it.

dmraid -ay certainly works with the 2.6.27-11 kernel, big relief there.....

but then how do you boot the system?

I don't have much experience with manually bootstrapping....

nevermind. i typed "exit".

so, temporary solution:

Reboot, select the 2.6.27-11 kernerl
if you get the initramfs prompt:
dmraid -ay
exit

quequotion, what kind of RAID configuration do you have?

There is a workaround for the booting issue, if you have a RAID-5
go to /usr/share/initramfs-tools/hooks/
and edit the file called dmraid.

find the line that writes: force_load dm-raid45
and change it with this: force_load dm-raid4-5
and then update the initramfs and reboot

it seems that the module name has been changed in both the kernel 2.6.27 and 2.6.28

RAID 0 (striped) here

Same issue using Kernel 2.6.26.5. It is not a kernel issue.
I think it is something related to the initramfs - upgraded by the update-initramfs -u.

Found it.

After decompressing my old initrd.img (which works) I just compared the two versions of dmraid.
Looks like Jaunty installation has updated it from version 1.0.0.rc14 to 1.0.0.rc15. After restoring the files to the 1.0.0.rc14 version and generate a new initrd, everything back to work 100% again.

Downgrading dmraid to 1.0.0.rc14 helped - thanks.
But I still have the problem that initram drops me to its shell. "dmraid -ay" works and after "exit" the system boots.
The hint from quequotion (edit /usr/share/initramfs-tools/hooks/dmraid) does not seem to apply for me: There it already writes "dm-raid4-5", which is the correct name of the kernel module here.
When the system is up and running, the output of "lsmod | grep dm" is

dm_crypt 20868 1
dm_raid4_5 73356 0
dm_region_hash 19456 1 dm_raid4_5
dm_mem_cache 12800 1 dm_raid4_5
dm_message 11008 1 dm_raid4_5

Therefore I tried to add "force_load dm-crypt" to /usr/share/initramfs-tools/hooks/dmraid, followed by a "update-initramfs -u". But after reboot there was no improvement.

Same as you Markus, I need to run "dmraid -ay" when it drops into BusyBox for it to create the devices. (Forgot to post the other night after I ready the message re going back to 1.0.0.rc14!)

Markus / ViRMiN

You can try to create a new file called dmraid (or something like that, the name is not important) in /etc/initramfs-tools/scripts/local-top/ containing the following script:

-----------------------------------
#!/bin/sh

PREREQ="udev"

prereqs()
{
        echo "$PREREQ"
}

case $1 in
# get pre-requisites
prereqs)
        prereqs
        exit 0
        ;;
esac

/sbin/udevadm settle --timeout=30
modprobe -Q dm-mod
modprobe -Q dm-mirror

[ -x /sbin/dmraid ] && /sbin/dmraid -ay
------------------------------

Make it executable (sudo chmod +x dmraid) and run update-initramfs -u.

Thanks for the information. Having reverted back to 1.0.0.rc14 I'm at least happy to be running the latest kernel for Jaunty; albeit, with some reversion with the dmraid package.

I've noticed that my raid devices have assumed more human names when checking mount points via runing "mount" with no paramaters, such as /dev/dm-1 rather than things like /dev/mapper/nvidia-ihegheeg1, although that could have been from performing a "clean" install from alpha-3 rather than an upgrade from Intrepid, as I notice references in my /etc/fstab to drives via UUID rather than "names"....

The problem has been found, and a fix will be forthcoming very shortly.

 affects ubuntu/dmraid
 assignee themuso
 status inprogress

 affects ubuntu/dmraid
 status fixreleased

I still have the problem with Alpha 4, so it's good to hear that a fix is on the way.

vinicius.vbf: Your script worked for me. Thank you!

After all of the updates today, my system boots straight through without any intervention required!

I updated today and I still need to do 'dmriad -ay' in initramfs shell to manually activate my array.

My RAID is an nvidia fakeRAID:0.

In the end, I was forced to give up on the distro however.

The workaround I posted was fine until I tried an update-initramfs for unrelated reasons which I don't remember clearly (the terror and rage wiped my memory just like the update wiped my boot options).

After that, all kernels on the system failed to boot from the raid. Luckily, the data on the drive was not significantly damaged and I was able to delete (file by file) the install and reinstall Intrepid from the Live CD.

Again, I can't remember the exact options I set before doing update-initramfs but the result was that ALL kernels failed to boot the same way 2.6.28 does.

Last night I upgraded to the 9.04 beta and after I got everything up and running my dmraid now no longer decides to play nice. When running dmraid -ay here is my output
RAID set "nvidia_iicejhch" already active
ERROR: dos: reading /dev/mapper/nvidia_iicejhch[No such file or directory]
although if you do a ls /dev/mapper you get
control nvidia_iicejhch
so clearly the file does exist
The Raid 5 that I'm trying to get access to is a NTFS partition and I need it to stay that way since I use this partition for both windows and Kubuntu. Thanks in advance for any and all help you can provide with this.

So it appears that the fix for this has not been released yet or something else crazy is going on here.

Open a new bug regarding your issue.
Also try the very latest dmraid from the repos, there were a few bugs in the stock 9.04 beta release.

When posting the new bug post the output of dmraid -ay -vvv -d

I'm still having the problem on
 * Ubuntu Jaunty 9.04:
 * RAID0 on Intel RAID Controller

Boot:
In busybox, must run "dmraid -ay", "exit", only then the system will boot.

sudo lspci | grep Intel | grep RAID
00:1f.2 RAID bus controller: Intel Corporation 82801 SATA RAID Controller (rev 02)

uname -a
Linux 2.6.28-11-server

Here's the output of "dmraid -ay -vvv -d"

http://pastebin.com/f4161b8ec

(Also, based on the previous posts, it seems like a fix was released, and it worked for 1 or 2 people, but the rest say it is still a problem?)

Confirmed.

It does not work for Jaunty x86 and amd64. Tested today fully updated.

I have two disk in raid1. And another alone for the OS. Motherboard only let me select RAID, AHCI and SATA.
So eveything is working with RAID. Even the sparse disk.

The only way to make the system up is to remove the package dmraid and let the system run with without FakeRAid.

Each time I install r15 of dmraid it crash. I don't even have the busybox prompt.

The original bug has been fixed and cleared.
Please start a new bug with relevant info (chipset, debug logs, extra infos).

Jaunty's dmraid works with both my jmicron and intel fakeraid controllers.

Thanks for your reply danwood76.

But, if the original bug was "fixed and cleared", why do some people still report the exact same problem? As I mentioned in my post on 2009-05-05, the symptoms still exist for me with an updated Jaunty, and I had to do the manual hack to fix it.

It doesn't really make sense to report a new bug, when we might be better off to re-open this existing bug report and determine the problem for those who still experience issues, no?

Thanks!

Yes. I can say that's not fixed.

I mean. i cannot use the RAID1 partition because if I try to setup dmraid the whole system stops working. It even does not boot.

So the fixed and cleared it's not really true. Sorry.

I attach some hardware information but I think this is not hardware related.

The controller seems to be a "pdc" (don't know what is exactly).

And the kernel:

Linux azul1 2.6.28-11-generic #42-Ubuntu SMP Fri Apr 17 01:58:03 UTC 2009 x86_64 GNU/Linux

But I tested it with jaunty x86 also and got the same results...

-----

00:00.0 Host bridge: ATI Technologies Inc RD790 Northbridge only dual slot PCI-e_GFX and HT3 K8 part
00:02.0 PCI bridge: ATI Technologies Inc RD790 PCI to PCI bridge (external gfx0 port A)
00:06.0 PCI bridge: ATI Technologies Inc RD790 PCI to PCI bridge (PCI express gpp port C)
00:07.0 PCI bridge: ATI Technologies Inc RD790 PCI to PCI bridge (PCI express gpp port D)
00:11.0 RAID bus controller: ATI Technologies Inc SB700/SB800 SATA Controller [RAID5 mode]
00:12.0 USB Controller: ATI Technologies Inc SB700/SB800 USB OHCI0 Controller
00:12.1 USB Controller: ATI Technologies Inc SB700 USB OHCI1 Controller
00:12.2 USB Controller: ATI Technologies Inc SB700/SB800 USB EHCI Controller
00:13.0 USB Controller: ATI Technologies Inc SB700/SB800 USB OHCI0 Controller
00:13.1 USB Controller: ATI Technologies Inc SB700 USB OHCI1 Controller
00:13.2 USB Controller: ATI Technologies Inc SB700/SB800 USB EHCI Controller
00:14.0 SMBus: ATI Technologies Inc SBx00 SMBus Controller (rev 3a)
00:14.1 IDE interface: ATI Technologies Inc SB700/SB800 IDE Controller
00:14.2 Audio device: ATI Technologies Inc SBx00 Azalia (Intel HDA)
00:14.3 ISA bridge: ATI Technologies Inc SB700/SB800 LPC host controller
00:14.4 PCI bridge: ATI Technologies Inc SBx00 PCI to PCI Bridge
00:14.5 USB Controller: ATI Technologies Inc SB700/SB800 USB OHCI2 Controller
00:18.0 Host bridge: Advanced Micro Devices [AMD] Family 10h [Opteron, Athlon64, Sempron] HyperTransport Configuration
00:18.1 Host bridge: Advanced Micro Devices [AMD] Family 10h [Opteron, Athlon64, Sempron] Address Map
00:18.2 Host bridge: Advanced Micro Devices [AMD] Family 10h [Opteron, Athlon64, Sempron] DRAM Controller
00:18.3 Host bridge: Advanced Micro Devices [AMD] Family 10h [Opteron, Athlon64, Sempron] Miscellaneous Control
00:18.4 Host bridge: Advanced Micro Devices [AMD] Family 10h [Opteron, Athlon64, Sempron] Link Control
02:00.0 FireWire (IEEE 1394): VIA Technologies, Inc. Device 3403
03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 01)
04:00.0 VGA compatible controller: nVidia Corporation GeForce 8800 GT (rev a2)
-------

I must say that system is completly unusable like it's in the central repository. So I suggest this but stay until really resolved.

Thank you very much.

Hi all,

I'm still having *huge* problems. In both, desktop and server machines.
I didn't realized before. But this bug is causing havok in my machines. As I had LVM volumes mounted over the dmraid devices but the dmraid devices are not longer available...

This causes LVM go reading and writing to /dev/sdX devices directly!!!!!

I'm really worried to break the partitions, filesystems etc...

more information about activating the sets:

----------------------------------------------

root@azul3:~# dmraid -ay -vvv -d
WARN: locking /var/lock/dmraid/.lock
NOTICE: /dev/sde: asr discovering
NOTICE: /dev/sde: ddf1 discovering
NOTICE: /dev/sde: hpt37x discovering
NOTICE: /dev/sde: hpt45x discovering
NOTICE: /dev/sde: isw discovering
NOTICE: /dev/sde: jmicron discovering
NOTICE: /dev/sde: lsi discovering
NOTICE: /dev/sde: nvidia discovering
NOTICE: /dev/sde: pdc discovering
NOTICE: /dev/sde: sil discovering
NOTICE: /dev/sde: 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
NOTICE: /dev/sdd: jmicron discovering
NOTICE: /dev/sdd: lsi discovering
NOTICE: /dev/sdd: nvidia discovering
NOTICE: /dev/sdd: pdc discovering
NOTICE: /dev/sdd: pdc metadata discovered
NOTICE: /dev/sdd: sil discovering
NOTICE: sil: areas 1,2,3,4[4] are valid
NOTICE: /dev/sdd: sil metadata discovered
/dev/sdd: "sil" and "pdc" formats discovered (using pdc)!
NOTICE: /dev/sdd: via discovering
NOTICE: /dev/sdc: asr discovering
NOTICE: /dev/sdc: ddf1 discovering
NOTICE: /dev/sdc: hpt37x discovering
NOTICE: /dev/sdc: hpt45x discovering
NOTICE: /dev/sdc: isw discovering
NOTICE: /dev/sdc: jmicron discovering
NOTICE: /dev/sdc: lsi discovering
NOTICE: /dev/sdc: nvidia discovering
NOTICE: /dev/sdc: pdc discovering
NOTICE: /dev/sdc: pdc metadata discovered
NOTICE: /dev/sdc: sil discovering
NOTICE: sil: areas 1,2,3,4[4] are valid
NOTICE: /dev/sdc: sil metadata discovered
/dev/sdc: "sil" and "pdc" formats discovered (using pdc)!
NOTICE: /dev/sdc: via discovering
NOTICE: /dev/sdb: asr discovering
NOTICE: /dev/sdb: ddf1 discovering
NOTICE: /dev/sdb: hpt37x discovering
NOTICE: /dev/sdb: hpt45x discovering
NOTICE: /dev/sdb: isw discovering
NOTICE: /dev/sdb: jmicron discovering
NOTICE: /dev/sdb: lsi discovering
NOTICE: /dev/sdb: nvidia discovering
NOTICE: /dev/sdb: pdc discovering
NOTICE: /dev/sdb: pdc metadata discovered
NOTICE: /dev/sdb: sil discovering
NOTICE: sil: areas 1,2,3,4[4] are valid
NOTICE: /dev/sdb: sil metadata discovered
/dev/sdb: "sil" and "pdc" formats discovered (using pdc)!
NOTICE: /dev/sdb: 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
NOTICE: /dev/sda: jmicron discovering
NOTICE: /dev/sda: lsi discovering
NOTICE: /dev/sda: nvidia discovering
NOTICE: /dev/sda: pdc discovering
NOTICE: /dev/sda: pdc metadata discovered
NOTICE: /dev/sda: sil discoveri...

What's the fix? can we try it?

Still More information...

I changed /usr/share/initramfs-tools/scripts/local-top/dmraid :

for dev in $(dmraid -r -c); do
        dmraid-activate $dev
done

to show

for dev in $(dmraid -r -c); do
        echo "Activating $dev..."
        dmraid-activate $dev
done

And what I got was:

Activating no...
no block devices found
Activating block...
no block devices found
Activating devices...
no block devices found
Activating found...
no block devices found

------

This makes me think that dmraid -r -c response is cleary:
"no block devices found"

But why?!

The original bug was squashed and was due to issues upstream.
If you haven't updated your packages then this will be the problem.

Also you will need to make sure you are using the latest kernel after the package update.

Please start a new bug and provide as much detail as possible as this bug is closed.

But I'm even upgraded to Karmic Alpha to get latest packages and the bug is still there...

I cannot boot...

If you can point me where to look to see if it's fixed then I can check.

> "the symptoms still exist" "the bug is still there"

Guys, please listen to what the man says. This bug, reported by Markus, is fixed. Whatever problem you still have must be something else, per definition. File your own bug reports.

Ok. I belive you. I will try to look to another possible bug.

I will open right now a new bug.

Sorry for any inconvenience.