Red Hat Bugzilla – Bug 441728
rc.sysinit is trying to "cryptsetup create" on a LUKS partition
Last modified: 2014-03-16 23:13:45 EDT
Description of problem: On a newly installed rawhide system I created an encrypted LV /home. On bootup, rc.sysinit tries to initialize this based on the contents of /etc/crypttab, but it is improperly trying to use "cryptsetup create" for a non-LUKS style of encrypted filesystem, rather than "cryptsetup luksOpen". Version-Release number of selected component (if applicable): 8.69-1 How reproducible: always Steps to Reproduce: 1. install and create an encrypted filesystem other than / from anaconda 2. boot system 3. system drops to repair shell since it can't fsck the unopened encrypted volume
Created attachment 301868 [details] screenshot of rc.sysinit running w/set -x I booted with set -x in /etc/rc.sysinit. Here is a screenshot showing the bootup sequence. cryptsetup isLuks is run on /dev/mapper/fedora.data-home, which when I run it manually returns 0 (true) so I'm not sure why it is choosing the "else" clause which runs cryptsetup create. if [ -z "$makeswap" ] && cryptsetup isLuks "$src" 2>/dev/null ; then if key_is_random "$key"; then echo $"$dst: LUKS requires non-random key, skipping" ret=1 continue fi if [ -n "$params" ]; then echo "$dst: options are invalid for LUKS partitions," \ "ignoring them" fi /sbin/cryptsetup ${key:+-d $key} luksOpen "$src" "$dst" <&1 else /sbin/cryptsetup $params ${key:+-d $key} create "$dst" "$src" <&1 2>/dev/null fi
I don't think we're considering non-anaconda applyed crypto setups as release blockers for F9. Moving to target (unless bill disagrees and moves it back).
This isn't non-anaconda applied. Anaconda created all of this, and the system fails to boot properly.
Created attachment 301871 [details] anaconda install.log
Created attachment 301874 [details] anaconda install.log.syslog
Created attachment 301875 [details] anaconda-ks.cfg
Created attachment 301876 [details] fstab after commenting out /home
Created attachment 301877 [details] /etc/crypttab
Created attachment 301879 [details] anaconda.log
Created attachment 301883 [details] [PATCH] fix for rc.sysinit to call init_crypto again after LVM init The problem was that rc.sysinit wasn't handling the case where you have an encrypted LV. Calling init_crypto again after LVM is activated fixes the problem. Since anaconda now supports creating encrypted LV's, can you please apply this fix to rc.sysinit? Thanks.
*** Bug 221304 has been marked as a duplicate of this bug. ***
Added in git, will be in 8.70-1. http://git.fedorahosted.org/git/?p=initscripts.git;a=commit;h=1e610b947935fa07f427c06bb0490d92ab67a0ae