Bug 818673

could you boot with "systemd.log_level=debug" (on kernel command line) and once system is booted, attach full dmesg output to this bug report ?

Thanks.

Created attachment 542113 [details]
Log file from systemd.log_level=debug

could you attach /etc/fstab and /etc/crypttab ? 

it looks like systemd-ask-password-plymouth.service doesn't start properly (or something around that).

Could you try to paste journalctl -b -u systemd-ask-password-plymouth.service ?

Created attachment 542145 [details]
fstab

Created attachment 542146 [details]
crypttab

The command 'journalctl -b -u systemd-ask-password-plymouth.service' (done as root) returns just:
-- Logs begin at Fri, 2013-05-31 12:03:24 CEST, end at Fri, 2013-05-31 16:26:43 CEST. --

(In reply to comment #6)
> The command 'journalctl -b -u systemd-ask-password-plymouth.service' (done as
> root) returns just:
> -- Logs begin at Fri, 2013-05-31 12:03:24 CEST, end at Fri, 2013-05-31 16:26:43
> CEST. --

could you try:
systemctl status systemd-ask-password-plymouth.service ?

quack:/crypted/home/jack # systemctl status systemd-ask-password-plymouth.service
systemd-ask-password-plymouth.service - Forward Password Requests to Plymouth
	  Loaded: loaded (/usr/lib/systemd/system/systemd-ask-password-plymouth.service; static)
	  Active: inactive (dead) since Fri, 2013-05-31 12:03:41 CEST; 4h 42min ago
	 Process: 421 ExecStart=/usr/bin/systemd-tty-ask-password-agent --watch --plymouth (code=exited, status=0/SUCCESS)
	  CGroup: name=systemd:/system/systemd-ask-password-plymouth.service

May 31 12:03:26 quack.suse.cz systemd[1]: Starting Forward Password Requests....
May 31 12:03:26 quack.suse.cz systemd[1]: Started Forward Password Requests ....

hmm, nothing really interesting there :(

Try booting with "plymouth.debug" and attach /var/log/plymouth-debug.log file, to see what is going on with plymouth..

Created attachment 542174 [details]
plymouth-debug.log

*** Bug 818821 has been marked as a duplicate of this bug. ***

I'm a bit perplex why plymouth doesn't switch to the "password" graphics prompt.

Maybe Raymond will have a idea ?

Two observations:
1) With current openSUSE 12.3 + updates the problem doesn't happen always but once in 3-5 boots.
2) I use xfce environment. The problems happens if and only if after I log into the graphical login screen, xfce hangs during startup. This hang magically resolves itself by switching to another console and back.

Ping ... Raymond?  Do you have an idea? Please refer to comment #12

The request for the password is done from the initrd with the help of the script /lib/mkinitrd/scripts/boot-luks.sh.  

This was adjusted in the early days of the plymouth implementation and that one is just doing the following: 

if luks_check_ply; then
        pass=`plymouth ask-for-password --prompt="Enter LUKS Passphrase"`


Back then, this would instruct the running plymouth daemon to show the indicated prompt and a field to enter the password. 

As far as I know, the systemd service systemd-ask-password-plymouth, shouldn't really be necessary as that boot-luks,sh should make the call directly to plymouth itself. 

The user confirms that this is not always happening, so maybe it is a race between plymouth and the systemd service ? 

@Frederic, for what else is the systemd-ask-password-plymouth.service used for ? Or could the user safely disable the service and then see if the problem still occurs ? 

Raymond

(In reply to comment #15)

> @Frederic, for what else is the systemd-ask-password-plymouth.service used for
> ? Or could the user safely disable the service and then see if the problem
> still occurs ? 

the ask-password-plymouth service can also be used for quering passphrase for apache SSL server or openvpn. But that's it.

I just updated to 13.2 and the problem is still there. However now it happens reliably (thinking about it, it was happening reliably with 12.3 lately as well).

The system where this happens is a laptop in a docking station. I have observed that the problem now happens reliably when the laptop is in the docking station and external monitor is attached (which has a different resolution than the internal laptop display). When I boot the laptop without external monitor, the problem doesn't happen and the graphical prompt for the password appears just fine.

The problem still exists in openSUSE Leap 42.1. Can someone please have a look?

(In reply to Jan Kara from comment #17)
> The system where this happens is a laptop in a docking station. I have
> observed that the problem now happens reliably when the laptop is in the
> docking station and external monitor is attached (which has a different
> resolution than the internal laptop display). 

Did you try to enter the password "blindly"? Maybe the password prompt is displayed off-screen thanks to the different resolutions - at least I had that problem with my old laptop + external screen.

(In reply to Jan Kara from comment #17)
> I just updated to 13.2 and the problem is still there. However now it
> happens reliably (thinking about it, it was happening reliably with 12.3
> lately as well).
> 
> The system where this happens is a laptop in a docking station. I have
> observed that the problem now happens reliably when the laptop is in the
> docking station and external monitor is attached (which has a different
> resolution than the internal laptop display)

Which problem exactly ?

According to your initial report, that would be: when your laptop is plugged to your docking station, you can see the splash screen on your external monitor but need to press ESC to see the prompt for the password.

Is this correct otherwise it's probably a different bug.

Here I setup a system with /home encrypted and all seems to work fine: plymouth prompts me for a password at boot and there's no need to press ESC. So your initial bug seems to be fixed by splash or systemd updates.

> When I boot the laptop without
> external monitor, the problem doesn't happen and the graphical prompt for
> the password appears just fine.

So this seems to confirm what I think: your initial bug has been fixed and you're now hit by a new bug.

(In reply to Christian Boltz from comment #19)
> (In reply to Jan Kara from comment #17)
> > The system where this happens is a laptop in a docking station. I have
> > observed that the problem now happens reliably when the laptop is in the
> > docking station and external monitor is attached (which has a different
> > resolution than the internal laptop display). 
> 
> Did you try to enter the password "blindly"? Maybe the password prompt is
> displayed off-screen thanks to the different resolutions - at least I had
> that problem with my old laptop + external screen.

Bingo! Entering password blindly works - i.e., encrypted /home is mounted and boot continues.

(In reply to Franck Bui from comment #20)
> (In reply to Jan Kara from comment #17)
> > I just updated to 13.2 and the problem is still there. However now it
> > happens reliably (thinking about it, it was happening reliably with 12.3
> > lately as well).
> > 
> > The system where this happens is a laptop in a docking station. I have
> > observed that the problem now happens reliably when the laptop is in the
> > docking station and external monitor is attached (which has a different
> > resolution than the internal laptop display)
> 
> Which problem exactly ?
> 
> According to your initial report, that would be: when your laptop is plugged
> to your docking station, you can see the splash screen on your external
> monitor but need to press ESC to see the prompt for the password.
> 
> Is this correct otherwise it's probably a different bug.

Yes, what you describe above is the problem I have.
 
> Here I setup a system with /home encrypted and all seems to work fine:
> plymouth prompts me for a password at boot and there's no need to press ESC.
> So your initial bug seems to be fixed by splash or systemd updates.
>
> > When I boot the laptop without
> > external monitor, the problem doesn't happen and the graphical prompt for
> > the password appears just fine.
> 
> So this seems to confirm what I think: your initial bug has been fixed and
> you're now hit by a new bug.

It has always been this way. Without external monitor connected, everything works as it should. With external monitor connected, only splash is visible both on external monitor and internal laptop display.

(In reply to Jan Kara from comment #22)
> (In reply to Franck Bui from comment #20)
> > (In reply to Jan Kara from comment #17)
> > > I just updated to 13.2 and the problem is still there. However now it
> > > happens reliably (thinking about it, it was happening reliably with 12.3
> > > lately as well).
> > > 
> > > The system where this happens is a laptop in a docking station. I have
> > > observed that the problem now happens reliably when the laptop is in the
> > > docking station and external monitor is attached (which has a different
> > > resolution than the internal laptop display)
> > 
> > Which problem exactly ?
> > 
> > According to your initial report, that would be: when your laptop is plugged
> > to your docking station, you can see the splash screen on your external
> > monitor but need to press ESC to see the prompt for the password.
> > 
> > Is this correct otherwise it's probably a different bug.
> 
> Yes, what you describe above is the problem I have.
>  
> > Here I setup a system with /home encrypted and all seems to work fine:
> > plymouth prompts me for a password at boot and there's no need to press ESC.
> > So your initial bug seems to be fixed by splash or systemd updates.
> >
> > > When I boot the laptop without
> > > external monitor, the problem doesn't happen and the graphical prompt for
> > > the password appears just fine.
> > 
> > So this seems to confirm what I think: your initial bug has been fixed and
> > you're now hit by a new bug.
> 
> It has always been this way.

Not really: your *initial* report (from 2013-05-06 22:34:50 UTC) didn't mention any usage of an external monitor.

You started adding the usage of an external monitor in the picture since comment #17.

> Without external monitor connected, everything
> works as it should. 

Then as I stated previously, the issue is different from the original one (see the summary of your report).

> With external monitor connected, only splash is visible
> both on external monitor and internal laptop display.

Looks like an issue specific to plymouth now where the later doesn't handle external monitor very well. In that case closing this bug and opening a new one describing (in the summary) your specific use case might be a good idea.

(In reply to Franck Bui from comment #23)
> (In reply to Jan Kara from comment #22)
> > (In reply to Franck Bui from comment #20)
> > > (In reply to Jan Kara from comment #17)
> > > > I just updated to 13.2 and the problem is still there. However now it
> > > > happens reliably (thinking about it, it was happening reliably with 12.3
> > > > lately as well).
> > > > 
> > > > The system where this happens is a laptop in a docking station. I have
> > > > observed that the problem now happens reliably when the laptop is in the
> > > > docking station and external monitor is attached (which has a different
> > > > resolution than the internal laptop display)
> > > 
> > > Which problem exactly ?
> > > 
> > > According to your initial report, that would be: when your laptop is plugged
> > > to your docking station, you can see the splash screen on your external
> > > monitor but need to press ESC to see the prompt for the password.
> > > 
> > > Is this correct otherwise it's probably a different bug.
> > 
> > Yes, what you describe above is the problem I have.
> >  
> > > Here I setup a system with /home encrypted and all seems to work fine:
> > > plymouth prompts me for a password at boot and there's no need to press ESC.
> > > So your initial bug seems to be fixed by splash or systemd updates.
> > >
> > > > When I boot the laptop without
> > > > external monitor, the problem doesn't happen and the graphical prompt for
> > > > the password appears just fine.
> > > 
> > > So this seems to confirm what I think: your initial bug has been fixed and
> > > you're now hit by a new bug.
> > 
> > It has always been this way.
> 
> Not really: your *initial* report (from 2013-05-06 22:34:50 UTC) didn't
> mention any usage of an external monitor.
> 
> You started adding the usage of an external monitor in the picture since
> comment #17.

Yes, but I was always testing with it. Only at the time of comment 17 I figured out that is what makes a difference for me...

> > Without external monitor connected, everything
> > works as it should. 
> 
> Then as I stated previously, the issue is different from the original one
> (see the summary of your report).
> 
> > With external monitor connected, only splash is visible
> > both on external monitor and internal laptop display.
> 
> Looks like an issue specific to plymouth now where the later doesn't handle
> external monitor very well. In that case closing this bug and opening a new
> one describing (in the summary) your specific use case might be a good idea.

OK, I can report the bug again if it helps. Feel free to close this bug as you wish.

(In reply to Jan Kara from comment #24)
> OK, I can report the bug again if it helps. Feel free to close this bug as
> you wish.

or you might want to update the bug summary to something more relevant. It would include the following keywords "plymouth, dual-screen, passphrase, etc..."

I'm resetting assignee to default since it doesn't seem to be a bug related to systemd but plymouth.

maybe closing as a duplicate of bug 804607 would be the easiest solution ;-)
(assuming it's really just the misplaced/off-screen passphrase input field)

I agree. Closing the bug.

*** This bug has been marked as a duplicate of bug 804607 ***