dmraid enabled on install target even if disabled during installation

Bug #311637 reported by Mark Kirkwood
This bug affects 1 person
Affects Status Importance Assigned to Milestone
initramfs-tools (Ubuntu)
Declined for Karmic by Andy Whitcroft

Bug Description

Binary package hint: initramfs-tools

The Ubuntu version is 8.10 Server x86 (no updates, directly from the cd)
The hardware is Supermicro P3TDER with Promise TX4000 fake raid card.

I'm using software (md) raid, so *disable* SATA/fake raid during the install. However on 1st boot of the newly installed system dmraid is enabled - so it steals drives that the md arrays want to use, thus making the system ubootable (/ is on a raid0 array). Note these cards need you to define at least one fake array otherwise the BIOS cannot boot the system (so having no fake arrays is unfortunately not possible).

I worked around this by booting off the cd and choosing "rescue broken system", then removing the dmraid package (possibly a bit clumsy, but it worked).

I think the system should configure the boot ramfs to *not* use dmraid if you have disabled it during the install.

Revision history for this message
Skewray (ubuntu-skewray) wrote :

I just installed dmraid on a 9.04 machine and can't reverse the process. The /boot partition is now hidden by the dmraid, so I cannot remove dmraid from the initrd file. Same problem - the deletion of the "nodmraid" kernel flag has made disabling dmraid impossible.

Revision history for this message
stephen mulcahy (stephen-mulcahy) wrote :

I also got bitten by this (long-winded description of problem and solution at - you can recover from this by booting from the install cd in rescue mode after installation and purging the dmraid package from your installation -- but I'm +1 for *not* installing the dmraid package if you decline SATA/fake raid during installation.

A nodmraid kernel flag might also work.

Revision history for this message
Mark Kirkwood (mark-kirkwood) wrote :

I suspect this bug has aged out of existence now...bit disappointing to see now *actual* updates to reflect progress mind you.

Revision history for this message
Mark Kirkwood (mark-kirkwood) wrote :

...*no* updates was what I meant to say.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers