Bug 755565

Summary:	Systemd asks for LVM password again half-way through boot after lvm is already unlocked
Product:	[openSUSE] openSUSE 12.1	Reporter:	Forgotten User zGf8Rc5x5T <forgotten_zGf8Rc5x5T>
Component:	Basesystem	Assignee:	Frederic Crozat <fcrozat>
Status:	RESOLVED INVALID	QA Contact:	E-mail List <qa-bugs>
Severity:	Normal
Priority:	P5 - None
Version:	Final
Target Milestone:	---
Hardware:	x86-64
OS:	openSUSE 12.1
Whiteboard:
Found By:	---	Services Priority:
Business Priority:		Blocker:	---
Marketing QA Status:	---	IT Deployment:	---
Attachments:	Dmesg after booting with systemd.log_level=debug systemd.log_target=kmsg cat /etc/crypttab cat /etc/fstab /etc/crypttab Dmesg with sysvinit

Description Forgotten User zGf8Rc5x5T 2012-04-03 23:19:11 UTC

Created attachment 484709 [details]
Dmesg after booting with systemd.log_level=debug systemd.log_target=kmsg

User-Agent:       Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/536.6 (KHTML, like Gecko) Chrome/20.0.1090.0 Safari/536.6 SUSE/20.0.1090.0

I updated my Kernel to 3.3.0-17.1 from Tumbleweed* and had to generate my initrd by hand from a chroot, which worked okay in the end. However, since that update, when I start my computer, I get asked for my lvm-password as expected early on, type it, unlock it and everything continues, however, then it seems that systemd is trying to detect and unlock the lvm all over again, despite it being already unlocked. I then have to retype my password, otherwise the boot doesn't continue.

Is there a special way to input "Tumbleweed" or is 12.1 alright, since the base system is still 12.1?

The disk layout is as follows:

/dev/sda1 -> /boot
/dev/sda11 -> luks -> LVM -> /, /home, swap, /tmp, /data

After retyping my password for the second time, everything starts normally. However, I also receive random "password needed" dialogs on the Desktop later on, which seem to have no bearing even if ignored.

Reproducible: Always

Steps to Reproduce:
1. Boot
2. Unlock LVM
3. Boot stalls / asked for LVM password again
Actual Results:  
Having to unlock LVM again

Expected Results:  
After unlocking the LVM initially, normal boot, no further password checks or lvm detection (since it's already detected and mounted?)

I am already using the systemd repository (fcrozat). I also checked additional bug reports, such as https://bugzilla.novell.com/show_bug.cgi?id=725622, https://bugzilla.novell.com/show_bug.cgi?id=740106, https://bugzilla.novell.com/show_bug.cgi?id=724238

None of the fixes or the aforementioned new version fixes the problem for me.

sh-4.2# rpm -q systemd
systemd-37-3.156.1.x86_64

sh-4.2# uname -a
Linux rmk2 3.3.0-17-desktop #1 SMP PREEMPT Mon Apr 2 13:53:06 UTC 2012 (142493d) x86_64 x86_64 x86_64 GNU/Linux

P.S.: This is my first bug report ever, I hope I didn't do anything horribly wrong... :-S

Comment 1 Forgotten User zGf8Rc5x5T 2012-04-03 23:20:42 UTC

Created attachment 484710 [details]
cat /etc/crypttab

Comment 2 Forgotten User zGf8Rc5x5T 2012-04-03 23:21:16 UTC

Created attachment 484711 [details]
cat /etc/fstab

Comment 3 Forgotten User zGf8Rc5x5T 2012-04-03 23:22:34 UTC

Created attachment 484712 [details]
/etc/crypttab

Comment 4 Forgotten User zGf8Rc5x5T 2012-04-03 23:24:37 UTC

Comment on attachment 484712 [details]
/etc/crypttab

>cr_sda11        /dev/disk/by-id/ata-ST9320320AS_5SX2371D-part11 none       none

Comment 5 Forgotten User zGf8Rc5x5T 2012-04-04 00:13:10 UTC

Created attachment 484720 [details]
Dmesg with sysvinit

Mhmm...this is extra weird, the same thing happens with sysvinit, so this doesn't seem to be a specific bug in either systemd or sysvinit...

Apparently, something tries to mount the LVM half-way through the boot process despite the fact that the boot process requires the LVM (with / on it) to be mounted in the first place.

I have no idea what causes the 2nd LVM-search/mounting/password etc...

Comment 6 Forgotten User zGf8Rc5x5T 2012-04-04 00:25:54 UTC

Mhm...it only now dawned on me that having /etc/crypttab was weird. I got rid of the file and the problem went away. This begs the question however what created that file in the first place, since it wasn't there before...

However, this is hereby resolved, I suppose?

This was a somewhat successful and somewhat stupid first bug report, I suppose... :-( Oh well...sorry for wasting somebody's time?

Comment 7 Frederic Crozat 2012-04-16 09:52:09 UTC

let's close as invalid.

no hard feeling ;)