[Bug 120375] Re: cannot boot raid1 with only one disk

Tapani Rantakokko tapani at rantakokko.net
Mon Feb 2 20:50:04 UTC 2009


Dustin, thank you for your quick answer and tips.

It took me a while to test it, as I have an encrypted RAID 1 array with
LVM, and things are not that straightforward with that setup.

So far I have been using one of the tricks described in this thread
earlier (ie. edit /etc/udev/rules.d/85-mdadm.rules: change the "--no-
degraded" to "-R", after that "sudo update-initramfs -u -k all"). It
allows me to boot with only one drive, but has that annoying side effect
where one of the partitions often starts in degraded mode, even if both
drives are in fact present and working.

I wanted to get rid of that problem, so I did this:
- return 85-mdadm.rules as it used to be, ie. --no-degraded
- sudo update-initramfs -u -k all
- cat /proc/mdstat and check that all drives are online and sync'ed
- upgrade all packages
- re-install grub to both drives

These are my test results:
1. Restart computer with both disks
-> everything works OK

2. Restart computer with only one disk
-> Keeps asking "Enter password to unlock the disk (md1_crypt):" even though I write the correct password

3. Restart computer again with both disks
-> everything works OK

So, first it seemed that the fix does not work at all, as Ubuntu starts
only when both disks are present. Then I made some more tests:

4. Restart computer with only one disk
-> Keeps asking "Enter password to unlock the disk (md1_crypt):" even though I write the correct password
-> Now press CTRL+ALT+F1, and see these messages:
Starting up ...
Loading, please wait...
Setting up cryptographic volume md1_crypt (based on /dev/md1)
cryptsetup: cryptsetup failed, bad password or options?
cryptsetup: cryptsetup failed, bad password or options?
-> After waiting some minutes, I got dropped into the busybox
-> Something seems to be going wrong with encryption

5. Restart computer with only one disk, without "quiet splash" boot parameters in /boot/grub/menu.lst
-> Got these messages:
Command failed: Not a block device
cryptsetup: cryptsetup failed, bad password or options?
... other stuff ...
Command failed: Not a block device
cryptsetup: cryptsetup failed, bad password or options?
Command failed: Not a block device
cryptsetup: cryptsetup failed, bad password or options?
cryptsetup: maximum number of tries exceeded
Done.
Begin: Waiting for root file system... ...
-> After waiting some minutes, I get the question whether I want to start the system with degraded setup. However, it does not matter what I answer, as the system cannot start since the encryption has already given up trying. I don't know what it was trying to read as a password, because I did not type anything.

6. Restart computer with only one disk, with "quiet splash bootdegraded=true" boot parameters in /boot/grub/menu.lst
-> Keeps asking "Enter password to unlock the disk (md1_crypt):" even though I write the correct password
-> Now press CTRL+ALT+F1, and see these messages:
Starting up ...
Loading, please wait...
Setting up cryptographic volume md1_crypt (based on /dev/md1)
cryptsetup: cryptsetup failed, bad password or options?

Summary:
The fix does not seem to work, in case you have encrypted your RAID disks. To be more specific: after a long wait it does ask whether to start in degraded mode, although the question seems to appear only when booted without "quiet splash" parameters. I guess it also starts in degraded mode automatically if "bootdegraded" parameter is set. Nevertheless the system will not start, as this seems to happen too late for encryption has already given up.

Question:
Is this fix tested with encryption at all? Is it suppose to work with it, or not? I think this is important, as if you have a RAID setup you obviously have some important data and in many cases want to encrypt it, too.

-- 
cannot boot raid1 with only one disk
https://bugs.launchpad.net/bugs/120375
You received this bug notification because you are a member of Kernel
Bugs, which is subscribed to initramfs-tools in ubuntu.




More information about the kernel-bugs mailing list