Bug 723404

Summary:	encrypted /var not mounted during boot
Product:	[openSUSE] openSUSE 11.4	Reporter:	marcin kowalski <yoshi314>
Component:	Basesystem	Assignee:	Ludwig Nussel <lnussel>
Status:	RESOLVED WORKSFORME	QA Contact:	E-mail List <qa-bugs>
Severity:	Normal
Priority:	P5 - None
Version:	Final
Target Milestone:	---
Hardware:	x86-64
OS:	openSUSE 11.4
Whiteboard:
Found By:	---	Services Priority:
Business Priority:		Blocker:	---
Marketing QA Status:	---	IT Deployment:	---

Description marcin kowalski 2011-10-11 19:14:24 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.

Comment 1 Michal Marek 2011-10-12 15:54:42 UTC

mkinitrd is not supposed to mount /var, this should be handled by the init scripts.

Comment 2 Ludwig Nussel 2011-10-13 07:20:25 UTC

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.

Comment 3 marcin kowalski 2011-10-14 09:20:01 UTC

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.

Comment 4 Ludwig Nussel 2011-10-14 14:14:48 UTC

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.

Comment 5 Frederic Crozat 2011-10-14 14:24:16 UTC

we don't support systemd on 11.4 nor tumbleweed ;)

Comment 6 Ludwig Nussel 2011-10-14 14:32:54 UTC

well spottet :-) I've cloned the bug for 12.1 as I managed to reproduce using systemd there.

Comment 7 marcin kowalski 2011-10-14 18:18:05 UTC

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.

Comment 8 Ludwig Nussel 2011-10-17 09:06:53 UTC

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.

Comment 9 marcin kowalski 2011-10-17 12:01:27 UTC

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 ?

Comment 10 Ludwig Nussel 2011-10-17 12:10:23 UTC

If you've set up the partition using yast boot.crypto-early should be enabled automatically. 'chkconfig boot.crypto-early' should display 'on'.

Comment 11 Ludwig Nussel 2011-10-28 11:49:42 UTC

well, works for me