Bug 10805

Summary: Can't boot crypted device after upgrade to Mageia 3 (incl. solution, but no patch)
Product: Mageia Reporter: Hartmut Goebel <h.goebel>
Component: RPM PackagesAssignee: Mageia Bug Squad <bugsquad>
Status: RESOLVED WORKSFORME QA Contact:
Severity: critical    
Priority: Normal CC: davidwhodgins, mageia
Version: 3   
Target Milestone: ---   
Hardware: x86_64   
OS: Linux   
URL: https://forums.mageia.org/en/viewtopic.php?f=8&t=5144
Whiteboard:
Source RPM: dracut CVE:
Status comment:

Description Hartmut Goebel 2013-07-19 19:58:07 CEST
After upgrading from Mageia 2 to Mageia3, I'm no longer able to boot my encrypted system. After some debugging I ended with adding `rdshell rdinitdebug rdbreak=pre-mount` to the kernel command line and at least was able to enter the crypt password.

The command executed (as shown by dracut's debug-output) is

    /bin/plymouth ask-for-password --prompt Password (/dev/sda6) --number-of-tries=5 \
           --command=/sbin/cryptsetup luksOpen -T1 /dev/sda6 crypt_sda6

which looks okay.

After entering the password, I get this error message:

    /dev/mapper/control: open failed: No such device
    Failure to communicate with kernel device-mapper driver.
    Check that device-mapper is available in the kernel.
    Cannot initialize device-mapper. Is dm_mod kernel module loaded?


After entering the password 5 times (see number of tries), drakut continues until it stops with message "sh: 0: can't acess tty; job control turned of".
Now executing

    modprobe dm_mod

yields no error, but running

    /sbin/cryptsetup luksOpen -T1 /dev/sda6 crypt_sda6

still failes with the same error-message. The initrd does not contain `lsmod`, so I can not check whether dm_mod is loaded or not.

Solution:
---------------

I was able to recover from this problem.

As I wrote above, fixing the problem in the dracut shell did not succeed in the first try. So I created a rescue-medium, which took me one step further: I was now able to luksOpen the root-partion when in the dracut shell -- which allowed booting my system. Now running `dracut -f` again gave me a working system. :-)

If you are able to luksOpen the root-partion, you may not need to go via the rescue-medium.

Short description

  - Boot from a rescue-disk, mount your partions, chroot there
  - run `dracut -f`
  - reboot
  - if booting still fails, you should be dropped into the dracut shell. There
      - cryptsetup luksOpen your root-device (here crypt_sda6)
      - ln -sf /dev/mapper/crypt_sda6 /dev/root
      - exit # this should continue booting
      - After booting run `drakut -f` again. Now hopefully your system is booting.

Longer description

   - Prepare some rescue CD/USB-Stick. The dual-arch-CD should be fine.
   - Boot from rescue CD/USB-Stick
   - When the rescue-meu shows up "go to the console"
   - modprobe dm_mod
   - cryptsetup luksOpen ...
   - rescue-gui # go back to the rescue-gui
   - Select "Mount your partitions under /mnt" - this is the easiest way, and this is why we use the rescue-gui
   - "Go to the console" again
   - chroot /mnt/
   - dracut -f
   - exit # leave chroot
   - reboot
   - if booting still fails, you should be dropped into the dracut shell again. Following the details instructions
     from
     https://www.kernel.org/pub/linux/utils/boot/dracut/dracut.html#accessing-the-root-volume-from-the-dracut-shell
     you can continue like this
    
      - Run `blkid` and identify your root-device
      - UUID=$(cryptsetup luksUUID /dev/mapper/linux-root) # replace "linux-root" with the device you identified
      - cryptsetup luksOpen /dev/mapper/linux-root luks-$UUID
      - ln -sf /dev/mapper/luks-$UUID /dev/root
      - exit # this should continue booting
      - This boot may not start the graphics mode (GUI). Press Alt-F2 to get a console to log in.
      - After booting run `drakut -f` again. Now hopefully your system is booting.

Reproducible: 

Steps to Reproduce:
Comment 1 Dave Hodgins 2013-07-19 23:42:29 CEST
Which method did you use to upgrade? I'll try to recreate the problem.

CC: (none) => davidwhodgins

Comment 2 Hartmut Goebel 2013-07-20 08:14:32 CEST
I upgraded using the CLI-variant.
Manuel Hiebel 2013-07-22 20:36:53 CEST

CC: (none) => mageia

Comment 3 Hartmut Goebel 2014-05-11 14:41:44 CEST
Upgrading from Mageia 3 to Mageia 4 worked without any problem in this area. I assume this has been fixed and resolve this bug.

Status: NEW => RESOLVED
Resolution: (none) => WORKSFORME