| Summary: | Cannot boot with root on encrypted lvm | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | Rémy CLOUARD (shikamaru) <shikamaru> |
| Component: | Installer | Assignee: | Anssi Hannula <anssi.hannula> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | major | ||
| Priority: | Normal | CC: | davidwhodgins, fri, misc, n54, pterjan, thierry.vignaud, tmb, uberscubajim |
| Version: | Cauldron | ||
| Target Milestone: | --- | ||
| Hardware: | i586 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Source RPM: | mkinitrd-6.0.93-21.mga1.src.rpm | CVE: | |
| Status comment: | |||
| Attachments: | output of lsinitrd /boot/initrd.img | ||
Created attachment 148 [details]
output of lsinitrd /boot/initrd.img
I think I found the culprit:
look at line setDeviceEnv LUKSUUID UUID=crypt_sda5
it should be the UUID of my /dev/sda5 partition, ie 1b7b1f1d-913f-4c0f-b3a6-ae295c26d460
I have seen this too without /boot, but didn't found the time to report ( it was the day before the release of alpha1 ) CC:
(none) =>
misc
Rémy CLOUARD (shikamaru)
2011-03-19 14:25:51 CET
CC:
(none) =>
thierry.vignaud
Rémy CLOUARD (shikamaru)
2011-03-19 14:26:11 CET
CC:
(none) =>
pterjan Workaround: 1. boot in rescue mode 2. mount your partitions 3. Create a directory where you will put the files (ie /root/mkinitrd) 4. cd /root/mkinitrd 5. extract old initrd with gzip -dc /boot/initrd.img | cpio -i -d 6. fix the above line in #1 7. reconstruct the initrd with find . | cpio -o -c > /boot/initrd.img.new 8. edit /boot/grub/menu.lst to use the new initrd 9. umount your partitions, reboot Dunno if thereâs a simpler method, but regenerating the initrd with mkinitrd does not seem to fix the problem (I get setDeviceEnv LUKSUUID UUID=vg0) I can confirm this bug and it is very important that it's fixed before Mageia 1 is release. Should be quite simple though.... CC:
(none) =>
uberscubajim
Thierry Vignaud
2011-05-03 20:02:45 CEST
CC:
(none) =>
tmb What are the contents of /etc/crypttab ? I can't tell, it's encrypted! :-) I'll have to try this on the first release and see if it has been fixed. If so then we can close the bug otherwise we have a problem. The problem isn't the contents of /etc/crypttab but /etc/sysinit (I think) calling crypsetup with the wrong arguments, or more accurately giving the wrong UUID. The UUID on that setDeviceEnv command is generated from the contents of /etc/crypttab (2nd field), and if not found, the device name is used instead. Another interesting information would be on what does the system print just before the failure. I.e. the line starting with "Setting up disk encryption". OK, as far as I'm concerned we can mark this bug as closed. The production version of Mageia (Mageia 1) no longer has this bug and it appear to be fixed (at least for me). Can others confirm that it now works for them? My testing was performed inside VirtualBox but I see no reason it would be any different on the bare metal. Minimal installation on a lvm encrypted partition is broken in Mageia 1. Even when I am trying to add packages like for encryption and lvm to the new system it wont start. This must work out-of-box in the installer - even in the minimal system. Status:
NEW =>
REOPENED mga1 64 normal install with KDE4, set up with unencrypted ext 4 /boot, and then / on LVM on luks works for me, on three installs. I used FTP repos to get latest packages during install. CC:
(none) =>
fri I have to say that for my tests I was NOT using LVM. Just plain LUKS on a partition. It's what you get if you just click on the "encrypt" button when installing. None of this fancy LVM for me! If it's working with lvm, but not without, then I think /usr/share/dracut/modules.d/90crypt/cryptroot-ask.sh has to be changed to load dm_mod if /dev/mapper does not exist. CC:
(none) =>
davidwhodgins Just fyi. As part of the qa testing for the Mageia 2 alpha 2 pre-release dvd iso, I just did a clean install, using one real partition for /boot, and one for /, and encrypted the / partition. No LVM. It worked. There was a delay mounting the root partition, which appeared to be caused by a wait for sda4, while the partition was hda4, likely due to different order of kernel module loading order. I'll look into that later. Once it's released, and Jim can confirm it now works, I think this bug can be closed, as resolved/fixed. But its still valid if you use LVM no ? also please(In reply to comment #7) > The UUID on that setDeviceEnv command is generated from the contents of > /etc/crypttab (2nd field), and if not found, the device name is used instead. > > Another interesting information would be on what does the system print just > before the failure. I.e. the line starting with "Setting up disk encryption". there was never an answer. Humm.... I've just tried Mageia 2 alpha 2 install from the live CD and it didn't work. The same "cryptsetup error" as is reported in several other bugs. As I have mentioned before, this works fine in Mageia 1. As mentioned in bug 3749 this works if you attempt installation using the network install image. I can now say that this has been solved in Mageia 2 Beta 2. Well done guys! Close/fixed recommended. thanks for the feedback Status:
REOPENED =>
RESOLVED |
Description of problem: After installing mageia alpha2 with the following setup |- ext2 - boot |- luks | - lvm |- swap |- root Mageia is unable to boot because the command issued to cryptsetup is not valid: Usage: cryptsetup [-?vyrq] [-?|--help] [--usage] [--version] [-v|verbose] [--debug] [-c|--cipher=STRING] [-h|--hash=STRING] [-y|--verify-passphrase] [-d|--key-file=STRING] [--master-key-file=STRING] [--dump-master-key] [-s|--key-size=INT] [-l|--keyfile-size=bytes] [--new-keyfile-size=bytes] [-S|--key-slot=INT] [-b|--size=SECTORS] [-o|--offset=SECTORS] [-p|--skip=SECTORS] [-r|--readonly] [-i|--iter-time=msecs] [-q|--batch-mode] [-t|--timeout=secs] [-T|--tries=INT] [--align-payload=SECTORS] [--header-backup-file=STRING] [--use-random] [--use-urandom] [--uuid=STRING] [OPTION...] <action> <action-specific> cryptsetup: luksOpen: requires <device> <name> as arguments so when someone gets prompted for a password over and over and the luks device never gets opened Version-Release number of selected component (if applicable): 6.0.93-21.mga1 How reproducible: Always Steps to Reproduce: 1. install Mageia with root on encrypted lvm 2. reboot 3. see it asking for password over and over Workaround: boot from another distribution on the same disk and fix initrd manually Reproducible: Steps to Reproduce: