Bugzilla – Bug 723404
encrypted /var not mounted during boot
Last modified: 2011-10-28 11:49:42 UTC
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20100101 Firefox/8.0 When installing system on unencrypted root but with /var on lvm volume inside encrypted PV, initrd does not get built with luks support (and possibly without lvm support too). Rationale for this setup : system partition is on ssd, hdd is composed of encrypted lvm PV. moving /var off to hdd seems a logical thing to do. In result, the installed system does not boot properly. There should be optionally an entire fallback initrd generated at install time (mkinitrd -A) but it also fails; i'll open another bug report for that. Tested on current 11.4 and tumbleweed kernels. Booting with dracut-generated initrd works correctly. Reproducible: Always Steps to Reproduce: 1. install system with /var on encrypted lvm volume, and the main system on classic unencrypted partition 2. reboot after installation 3. recovery shell Actual Results: optional fallback initrd generated at install time could help here (mkinitrd -A type) Expected Results: a normal, functional boot. given how oddball this setup is, i don't consider this critical.
mkinitrd is not supposed to mount /var, this should be handled by the init scripts.
Well, there's an arbitrary number of ways to put partitions in encrypted containers. The hook scripts for mkinitrd currently only consider / automatically. If you add the 'initrd' option to /etc/crypttab for your partition it should be picked up though.
there is still a problem that default install does not boot up properly out of the box on that setup. can i somehow customize my system during installation ? i will retest the /etc/crypttab option.
Hmm, do you use systemd or sysvinit? I can't find any problem with sysvinit. If you have problems with systemd in that setup then it probably misses to trigger an lvm scan after the device gets unlocked.
we don't support systemd on 11.4 nor tumbleweed ;)
well spottet :-) I've cloned the bug for 12.1 as I managed to reproduce using systemd there.
i've resolved the problem by creating /etc/crypttab entry for my luks device, and the running mkinitrd. it generated initrd with lvm2 and luks features and it boots fine now. still, that's something an installer should have done in the first place. i've been using classic init system in relation to this bug report. i had a similar issue on fedora 15 with systemd (relatively early after its release), it was a bit of a different bug, where encrypted lvm PV case was not supported by systemd units. there was a trivial fix for it.
did you actually enable boot.crypto-early? There is no need to mount /var from initrd actually. Normally boot.localfs would mount /var. In case of luks boot.crypto-early needs to unlock the partition first.
i did not do any modifications to system config aside from mentioned above. i'll see what happens when i do. i assume i have to remove the crypttab entry again, right ?
If you've set up the partition using yast boot.crypto-early should be enabled automatically. 'chkconfig boot.crypto-early' should display 'on'.
well, works for me