Bug 770890

Adding Frederic, as this might remotely be related to systemd...

I had the same problem, after install from the 64bit DVD (for RC1).

The machine did complete boot, after a long delay.  I believe it was timing out the hidden prompt for the encryption key.

When Yast started up to finalize the install, it mentioned that "/home" was not mounted.  I used CTRL-ALT-F2 to manually setup and mount "/home", and then I resumed Yast (CTRL-ALT-F7).

On a reboot, the same problem.  So I edited "/etc/default/grub" to remove "splash=silent quiet", I added "initrd" to the last column of "/etc/crypttab", then I ran "mkinitrd".

Booting is now noisy, but at least the crypto prompt is where I can respond to it.

I will later be installing in a system with encrypted LVM.  I will report back on whether the same problem occurs there.

This works fine on a system with encrypted LVM.

Where it fails, I have luks encrypted swap and "/home".

On first boot after install, there was no visible prompt for encryption key.

After forcing crypto to "initrd", and disabling plymouth, there was a single prompt for key and both partitions were properly opened.

I switched back to using plymouth, without changing "initrd".  Now there were 3 prompts for keys (for only two partitions).

I removed the "initrd" from the last column of "/etc/crypttab", and ran "mkinitrd".  On the next boot, there was a prompt for the key for swap, but the home partition was never unlocked.

I added back the "initrd" for just the home partition, and ran "mkinitrd".  On the next boot there were 3 prompts for the two partitions.

I disabled plymouth again (removed "splash=silent quiet"), and now all is well though bootup is noisy.

I see this as a show stopper problem, so I have increased the importance rating.

I have the same issue since upgrading to 12.2 RC1.

I have only an encrypted home partition and the system just hangs during startup.

If I boot without the options "splash=silent quiet" I am asked for my pass phrase and able to boot normally.

It looks like Plymouth prevents the boot process from asking for a password.

Bnc#765130 and bnc#765214 seem to be related.

Please let me know the following:

1)  Which version of plymouth is installed ? 
2)  Which plymouth theme is used ? 

Thanks

1) plymouth-0.8.5.1-1.3.1.x86_64
2) the default, the one with the glowing lights flowing around and meeting at the center

My home device is mentioned in /etc/crypttab.

Today I have downloded openSUSE 12.2 RC1, I started VitualBox to install RC1. I got the first screen where you can select 
boot from hard disk ore install. As I selected installation the screen froze and finaly chose install from hard disk. Up to now I can not install RC1.

@Wolfgang Hahnl:  I don't see the relationship with this issue reported with this bug ?  Did you setup a LUKS encrypted partition within Virtualbox ? If not, then we are talking about a different issue and this should be reported in a separate bug.

Just for completeness, I reproduced this on a clean install of RC1 (Build 500) in a Virtual machine:

* use a 10GB disk image file
* boot from openSUSE-NET-Build0050-i586.iso
* select install via HTTP, language "german"
* during partitioning, keep the defaults, "separate home" partition
  * edit the home partition, select "encrypt device"
* during installation, select "XFCE desktop", remove libreoffice, java and
  some of the -lang and manuals packages to save installation time
* second part of installation already comes up (after timeout?) with a
  warning that home is not mounted
  * go into text console, issue "systemctl restart cryptsetup@cr_vda3.service"
    enter passprhase, then switch back to VT 7 to finish installation
* reboot -- no passphrase asked during plymouth boot, need to remove "quiet"
  from boot parameters to get a passphrase

so it looks like this is 100% reproducible.

This is what's in crypttab and fstab:

linux-69ba:~ # cat /etc/crypttab
cr_vda3         /dev/vda3            none       none
linux-69ba:~ # cat /etc/fstab
/dev/vda2           /                 ext4    acl,user_xattr        1 1
/dev/mapper/cr_vda3 /home             ext4    acl,user_xattr,nofail 0 2
/dev/vda1           swap              swap    defaults              0 0
proc                /proc             proc    defaults              0 0
sysfs               /sys              sysfs   noauto                0 0
debugfs             /sys/kernel/debug debugfs noauto                0 0
usbfs               /proc/bus/usb     usbfs   noauto                0 0
devpts              /dev/pts          devpts  mode=0620,gid=5       0 0

installed plymouth packages:
linux-69ba:~ # rpm -qa *ply*
libply2-0.8.5.1-1.3.1.i586
plymouth-branding-openSUSE-0.8.5.1-1.3.1.noarch
libply-splash-graphics2-0.8.5.1-1.3.1.i586
libply-boot-client2-0.8.5.1-1.3.1.i586
plymouth-plugin-label-0.8.5.1-1.3.1.i586
plymouth-scripts-0.8.5.1-1.3.1.noarch
plymouth-plugin-script-0.8.5.1-1.3.1.i586
plymouth-0.8.5.1-1.3.1.i586
libply-splash-core2-0.8.5.1-1.3.1.i586

I can confirm this bug - fresh install 64bit RC1

For the "new install" case, I think this is because the crypto-early and crypto services are masked. At least, this is what I have here when reaching stage2 of the yast installer.

Forget my last comment: Fred tells me that cryptsetup.target is what is used with systemd.

Should be fixed in http://download.opensuse.org/repositories/home:/fcrozat:/branches:/Base:/System/openSUSE_Factory/

please test

Hi Frederic

Awesome - works like a charm and the PW request is embedded into plymouth (which looks great btw - love it).

(Fresh VM installation with your repository as the only change to the system and /home as the only encrypted partition)

Jürgen

Works for me, too. Don't forget to also submit to Factory in addition to 12.2 :-)

That works for me, too.  But with a caveat.

I am using encrypted swap and encrypted "/home", both with the same LUKS key.

Before using your patch, I had removed "splash=silent quiet" from the boot line.  Then I had added "initrd" to the last column of "/etc/crypttab" for the "/home" entry.  That was so that I would only be asked for the encryption key once.

After applying your patch, it hung during boot.  I think that is the same bug that I had earlier reported as 765214.

I disabled splash to get booted.  Then I removed the "initrd" (changed to "none") in the crypttab entry, and ran "mkinitrd".  It then ran perfectly.

In summary - your patches seem to fix the current bug.  There still appears to be an argument between plymouth and other code (probably scripts) running from "initrd" on who should handle the crypto.

I can confirm that it does work and looks great with 12.2.  Thanks for the quick fix.

(In reply to comment #9)
> @Wolfgang Hahnl:  I don't see the relationship with this issue reported with
> this bug ?  Did you setup a LUKS encrypted partition within Virtualbox ? If
> not, then we are talking about a different issue and this should be reported in
> a separate bug.

@Raymond: You are right. The problem is solved. The bug was sitting in front of the desktop: me :-))

pushed as sr 128720, will forward to Factory and 12.2

This is an autogenerated message for OBS integration:
This bug (770890) was mentioned in
https://build.opensuse.org/request/show/128725 Factory / plymouth

Just for the records the issue is still not fixed in 12.2 after a dist upgrade. So please don't forget to forward the fix to 12.2.

sr #129022 done for 12.2

This issue ist still existing in 12.2 RC2.

It is working fine for me now with all updates installed.

Are you sure that you have all updates installed? Or could it be a configuration problem - can you insert the password without the boot parameters "splash=silent quiet"?

A question to Dominik (#24) - Have you seen the report for bug 774400?  Is it possible that this is what you are now experiencing?

Ahh, please ignore my previous post! It is working now for me, too.

It seems that I run into some hardware weirdness. I installed 12.2 RC2 on an SD card, but my notebook (Lenovo x201) hangs during boot, just before the password prompt appears. Booting that SD card on my desktop computer works fine, just as using an USB stick on the Lenovo notebook.

Sorry for my overhasty post.