[opensuse] Bootup of Luks partitions not waiting long for Password

older
RE: [opensuse] can't get rid of...

John Andersen

23 Jan 2016 23 Jan '16

02:44

I've got a 13.2 installation that for some reason some time ago started waiting a real short time for passwords on the Plymouth screen (or at least the Plymouth wallpaper) for a password for the Luks encrypted partition. I have to hover over the keyboard waiting for that prompt to come up and type it really quick or it boots without my home partition mounted. I thought it was /etc/crypttab where the delay was set, but this appears to be ignored. There are a few bug reports but they appear full of arguing back and forth and nobody has a clue. Has anyone else seen this, or have a solution? -- After all is said and done, more is said than done. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Show replies by date

listreader

23 Jan 23 Jan

02:56

On Fri, 22 Jan 2016 18:44:53 -0800 John Andersen wrote:

...

I've got a 13.2 installation that for some reason some time ago started waiting a real short time for passwords on the Plymouth screen (or at least the Plymouth wallpaper) for a password for the Luks encrypted partition.

I have to hover over the keyboard waiting for that prompt to come up and type it really quick or it boots without my home partition mounted.

I thought it was /etc/crypttab where the delay was set, but this appears to be ignored. There are a few bug reports but they appear full of arguing back and forth and nobody has a clue.

Has anyone else seen this, or have a solution?

I have a bugzilla open on something similar: http://bugzilla.opensuse.org/show_bug.cgi?id=960258 Ralph -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

John Andersen

03:52

On 01/22/2016 06:56 PM, listreader wrote:

...

On Fri, 22 Jan 2016 18:44:53 -0800 John Andersen wrote:

...
I've got a 13.2 installation that for some reason some time ago started waiting a real short time for passwords on the Plymouth screen (or at least the Plymouth wallpaper) for a password for the Luks encrypted partition.

I have to hover over the keyboard waiting for that prompt to come up and type it really quick or it boots without my home partition mounted.

I thought it was /etc/crypttab where the delay was set, but this appears to be ignored. There are a few bug reports but they appear full of arguing back and forth and nobody has a clue.

Has anyone else seen this, or have a solution?

I have a bugzilla open on something similar:

http://bugzilla.opensuse.org/show_bug.cgi?id=960258

Ralph

I actually have two different luks partitions with the same password, (I never have to enter it twice). It seems systemd is involved somewhere along the chain and it does not honor any wait time. This used to work just fine, it would wait all day but some update last year caused it to start being real quick. -- After all is said and done, more is said than done. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

listreader

04:51

On Fri, 22 Jan 2016 19:52:23 -0800 John Andersen wrote:

...

I actually have two different luks partitions with the same password, (I never have to enter it twice).

It seems systemd is involved somewhere along the chain and it does not honor any wait time.

This used to work just fine, it would wait all day but some update last year caused it to start being real quick.

If you haven't manually edited them lately, look at the dates on your /etc/fstab and /etc/crypttab. Mine are dated 19 December 2015, which is likely the date the set of updates that caused my problem were installed here. Is swap one of your LUKS partitions? On my setup it is, and I tend to think that the only reason I get the first LUKS prompt at all is because the system needs to check to see if there is a hibernate image stored there (on swap) before fresh starting. Ralph -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

John M Andersen

05:20

On 1/22/2016 8:51 PM, listreader wrote:

...

On Fri, 22 Jan 2016 19:52:23 -0800 John Andersen wrote:

...
I actually have two different luks partitions with the same password, (I never have to enter it twice).

It seems systemd is involved somewhere along the chain and it does not honor any wait time.

This used to work just fine, it would wait all day but some update last year caused it to start being real quick.

If you haven't manually edited them lately, look at the dates on your /etc/fstab and /etc/crypttab. Mine are dated 19 December 2015, which is likely the date the set of updates that caused my problem were installed here.

Is swap one of your LUKS partitions? On my setup it is, and I tend to think that the only reason I get the first LUKS prompt at all is because the system needs to check to see if there is a hibernate image stored there (on swap) before fresh starting.

Ralph

Aaargh! Too late I just hacked it to add 300s in place of the last parameter, which didn't work, so I hacked back to "none". -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

John M Andersen

05:23

On 1/22/2016 8:51 PM, listreader wrote:

...

On Fri, 22 Jan 2016 19:52:23 -0800 John Andersen wrote:

...
I actually have two different luks partitions with the same password, (I never have to enter it twice).

It seems systemd is involved somewhere along the chain and it does not honor any wait time.

This used to work just fine, it would wait all day but some update last year caused it to start being real quick.

If you haven't manually edited them lately, look at the dates on your /etc/fstab and /etc/crypttab. Mine are dated 19 December 2015, which is likely the date the set of updates that caused my problem were installed here.

Is swap one of your LUKS partitions? On my setup it is, and I tend to think that the only reason I get the first LUKS prompt at all is because the system needs to check to see if there is a hibernate image stored there (on swap) before fresh starting.

Ralph

Oh, and no, my swap wasn't encrypted. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Andrei Borzenkov

07:59

23.01.2016 05:44, John Andersen пишет:

...

I've got a 13.2 installation that for some reason some time ago started waiting a real short time for passwords on the Plymouth screen (or at least the Plymouth wallpaper) for a password for the Luks encrypted partition.

Could you try without Plymouth (plymouth.enable=0 on kernel command line); do you still see the same problem?

...

I have to hover over the keyboard waiting for that prompt to come up and type it really quick or it boots without my home partition mounted.

I thought it was /etc/crypttab where the delay was set, but this appears to be ignored. There are a few bug reports but they appear full of arguing back and forth and nobody has a clue.

Has anyone else seen this, or have a solution?

-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

John Andersen

19:40

On 01/22/2016 11:59 PM, Andrei Borzenkov wrote:

...

...
...
I've got a 13.2 installation that for some reason some time ago started waiting a real short time for passwords on the Plymouth screen (or at least the Plymouth wallpaper) for a password for the Luks encrypted partition.

Could you try without Plymouth (plymouth.enable=0 on kernel command

23.01.2016 05:44, John Andersen пишет: line); do you still see the same problem?

Where does one get at the kernel command line these days? With Plymouth in there before you even get a chance, to hit any key, it seems like the only way to change that is go into yast and add the parameter there. (which didn't work by the way, even though I saw that it was written to grub2/grug.cfg) I didn't want to modify grub2/grub.cfg because the first thing it says in that file is DO NOT EDIT THIS FILE. But I was able to dance on the escape key fast enough to see the scrolling boot messages in text mode, and saw where it asked for the password for the first ENCRYPTED partition. So I just sat there and counted off the seconds, and at about 7 or 8 seconds it resumed the stream of boot messages and booted normally, showing the log in screen, but the encrypted partition was not mounted. (It has nofail in fstab). I see these suspicious looking lines in grub2/grub.cfg: if [ x${boot_once} = xtrue ]; then set timeout=0 elif [ x$feature_timeout_style = xy ] ; then set timeout_style=menu set timeout=8 # Fallback normal timeout code in case the timeout_style feature is # unavailable. else set timeout=8 fi But, I'm not supposed to mess with that file, apparently under penalty of death, so I look for the safe place to set that, but before I do, I would like to know if that is really where this timeout is set. -- After all is said and done, more is said than done. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Carlos E. R.

22:46

On 2016-01-23 20:40, John Andersen wrote:

...

On 01/22/2016 11:59 PM, Andrei Borzenkov wrote:

...

...
Could you try without Plymouth (plymouth.enable=0 on kernel command line); do you still see the same problem?

Where does one get at the kernel command line these days? With Plymouth in there before you even get a chance,

At the grub prompt, as always, which displays before plymouth has a chance to start, just after the Bios boot screens.

...

the only way to change that is go into yast and add the parameter there. (which didn't work by the way, even though I saw that it was written to grub2/grug.cfg)

Edit "/etc/default/grub", and run the command it says in the comments to run to apply the changes.

...

I didn't want to modify grub2/grub.cfg because the first thing it says in that file is DO NOT EDIT THIS FILE.

You can edit it, but the changes are not permanent. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

John Andersen

23:01

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 1/23/2016 2:46 PM, Carlos E. R. wrote:

...

At the grub prompt, as always, which displays before plymouth has a chance to start, just after the Bios boot screens.

It flashes Welcom to GRUB and BAM Plymouth screen is up. Even with ore-loading the keyboard buffer you can't get inbetween that. - -- _____________________________________ - ---This space for rent--- -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlakBlMACgkQv7M3G5+2DLKp1QCeNpsckcYyKy/i92V5gay7DVxz uI0An2CGuV28ZYtb1JNjJ1pbGUEUJXrx =YUr6 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Carlos E. R.

23:06

On 2016-01-24 00:01, John Andersen wrote:

...

On 1/23/2016 2:46 PM, Carlos E. R. wrote:

...
At the grub prompt, as always, which displays before plymouth has a chance to start, just after the Bios boot screens.

It flashes Welcom to GRUB and BAM Plymouth screen is up. Even with ore-loading the keyboard buffer you can't get inbetween that.

That's because you probably have set grub delay to zero. You don't get a chance that way to choose which kernel to boot. Of course, if you are booting an hibernating machine, any menu is disabled intentionally. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

John Andersen

23:15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 1/23/2016 3:06 PM, Carlos E. R. wrote:

...

On 2016-01-24 00:01, John Andersen wrote:

...
On 1/23/2016 2:46 PM, Carlos E. R. wrote:

...
At the grub prompt, as always, which displays before plymouth has a chance to start, just after the Bios boot screens.

It flashes Welcom to GRUB and BAM Plymouth screen is up. Even with ore-loading the keyboard buffer you can't get inbetween that.

That's because you probably have set grub delay to zero. You don't get a chance that way to choose which kernel to boot. Of course, if you are booting an hibernating machine, any menu is disabled intentionally.

I certainly don't remember making such a choice. Nor do I know where to do so. Same place? - -- _____________________________________ - ---This space for rent--- -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlakCYYACgkQv7M3G5+2DLKA6ACeIvKzSkHWW99ONjyLvib1VD5h dKcAoKEZ/vwe9B4NoLf13HerPw9x56rX =4O73 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Carlos E. R.

23:30

On 2016-01-24 00:15, John Andersen wrote:

...

On 1/23/2016 3:06 PM, Carlos E. R. wrote:

...

...
That's because you probably have set grub delay to zero. You don't get a chance that way to choose which kernel to boot. Of course, if you are booting an hibernating machine, any menu is disabled intentionally.

I certainly don't remember making such a choice. Nor do I know where to do so. Same place?

In YaST, module boot loader. Also in "/etc/default/grub", value "GRUB_TIMEOUT". Typical is "8". Then run the command the comments tell to run to apply. Same file as you disable plymouth. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

John Andersen

23:34

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 1/23/2016 3:30 PM, Carlos E. R. wrote:

...

On 2016-01-24 00:15, John Andersen wrote:

...
On 1/23/2016 3:06 PM, Carlos E. R. wrote:

...
...
That's because you probably have set grub delay to zero. You don't get a chance that way to choose which kernel to boot. Of course, if you are booting an hibernating machine, any menu is disabled intentionally.

I certainly don't remember making such a choice. Nor do I know where to do so. Same place?

In YaST, module boot loader.

Also in "/etc/default/grub", value "GRUB_TIMEOUT". Typical is "8". Then run the command the comments tell to run to apply. Same file as you disable plymouth.

I did the above things as you instructed. Yes, timeout 8 there, but the timeout between Welcome to Grub and Plymouth is typically zero. There is another thing in there called hidden timeout. Maybe I will mess with that. And the time out waiting for a LUKS password is still around 5 to 7 seconds. - -- _____________________________________ - ---This space for rent--- -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlakDiMACgkQv7M3G5+2DLKvegCfeOA2i8HGTAmNFFInZ87uPxRL 1v4AnijpsSbxMhnDf1H8z20R9AaatGhf =rkX4 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Carlos E. R.

23:39

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday, 2016-01-23 at 15:34 -0800, John Andersen wrote:

...

I did the above things as you instructed.

Yes, timeout 8 there, but the timeout between Welcome to Grub and Plymouth is typically zero.

Then that file is not applied, or you are booting a different grub. Is your machine dual boot?

...

There is another thing in there called hidden timeout. Maybe I will mess with that.

I have it to zero.

...

And the time out waiting for a LUKS password is still around 5 to 7 seconds.

Did you disable plymouth as instructed? - -- Cheers, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlakDyEACgkQtTMYHG2NR9XR9QCfX5apNJJ0YA5BbGdJFCHpOMlS yrIAn0yscRMWfWhCgEIkhEco6fxMaltb =D7xb -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

listreader

24 Jan 24 Jan

05:48

On Sun, 24 Jan 2016 00:39:13 +0100 (CET) "Carlos E. R." wrote:

...

On Saturday, 2016-01-23 at 15:34 -0800, John Andersen wrote:

...

...
Yes, timeout 8 there, but the timeout between Welcome to Grub and Plymouth is typically zero.

John, probably a dumb question but do you have a password on the bootloader? (yast2, bootloader module, bootloader options)

...

Did you disable plymouth as instructed?

Carlos, I tried that. Did not help my problem (bugzilla 960258), which may or may not have the same base cause as John's but likely does, since both the problems seem to have begun with the ~19 December system updates. So, in my case at least, plymouth appears innocent of this particular crime. Ralph -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Andrei Borzenkov

05:57

24.01.2016 08:48, listreader пишет:

...

On Sun, 24 Jan 2016 00:39:13 +0100 (CET) "Carlos E. R." wrote:

...
On Saturday, 2016-01-23 at 15:34 -0800, John Andersen wrote:

...
...
Yes, timeout 8 there, but the timeout between Welcome to Grub and Plymouth is typically zero.

John, probably a dumb question but do you have a password on the bootloader? (yast2, bootloader module, bootloader options)

...
Did you disable plymouth as instructed?

Carlos, I tried that. Did not help my problem (bugzilla 960258), which may or may not have the same base cause as John's but likely does, since both the problems seem to have begun with the ~19 December system updates. So, in my case at least, plymouth appears innocent of this particular crime.

...

From your bug report it is absolutely unclear whether you disabled Plymouth or not. I do not understand what "text front (F12)" means. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

listreader

06:23

On Sun, 24 Jan 2016 08:57:39 +0300 Andrei Borzenkov wrote:

...

...
...
Did you disable plymouth as instructed?

Carlos, I tried that. Did not help my problem (bugzilla 960258), which may or may not have the same base cause as John's but likely does, since both the problems seem to have begun with the ~19 December system updates. So, in my case at least, plymouth appears innocent of this particular crime.

From your bug report it is absolutely unclear whether you disabled Plymouth or not. I do not understand what "text front (F12)" means.

"Absolutely unclear." That's very funny! :) No, I think you've misunderstood. I just now, today, disabled plymouth, following Carlos' suggestion. It was not disabled before. Sorry if that was not clearly stated. The F12 was keypress to switch to text display during boot while plymouth was still enabled. Ralph -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Carlos E. R.

12:09

On 2016-01-24 06:48, listreader wrote:

...

On Sun, 24 Jan 2016 00:39:13 +0100 (CET) "Carlos E. R." <> wrote:

...

...
Did you disable plymouth as instructed?

Carlos, I tried that. Did not help my problem (bugzilla 960258), which may or may not have the same base cause as John's but likely does, since both the problems seem to have begun with the ~19 December system updates. So, in my case at least, plymouth appears innocent of this particular crime.

But do you see the grub menu? He doesn't. His problem is different. After grub loads the kernel (and plymouth) and asks for the password, you both have the same or similar problem. Thus the proposal to disable Plymouth. But he can not disable Plymouth because he doesn't reach the grub menu in which to do it. So I proposed to instead edit the file in which this is defined, and apply the changes in the manner explained in that same file. If this doesn't disable plymouth, then he is not using that grub to boot, and we have to learn how is he really booting that machine. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

Andrei Borzenkov

05:46

24.01.2016 02:34, John Andersen пишет:

...

On 1/23/2016 3:30 PM, Carlos E. R. wrote:

...
On 2016-01-24 00:15, John Andersen wrote:

...
On 1/23/2016 3:06 PM, Carlos E. R. wrote:

...
...
...
That's because you probably have set grub delay to zero. You don't get a chance that way to choose which kernel to boot. Of course, if you are booting an hibernating machine, any menu is disabled intentionally.

I certainly don't remember making such a choice. Nor do I know where to do so. Same place?

...
In YaST, module boot loader.

...
Also in "/etc/default/grub", value "GRUB_TIMEOUT". Typical is "8". Then run the command the comments tell to run to apply. Same file as you disable plymouth.

I did the above things as you instructed.

Yes, timeout 8 there, but the timeout between Welcome to Grub and Plymouth is typically zero.

You may have "stuck" hibernation; what grub2-editenv - list says? (It is really lone `-' there).

...

There is another thing in there called hidden timeout. Maybe I will mess with that.

And the time out waiting for a LUKS password is still around 5 to 7 seconds.

John Andersen

07:05

On January 23, 2016 9:46:05 PM PST, Andrei Borzenkov wrote:

...

24.01.2016 02:34, John Andersen пишет:

...
On 1/23/2016 3:30 PM, Carlos E. R. wrote:

...
On 2016-01-24 00:15, John Andersen wrote:

...
On 1/23/2016 3:06 PM, Carlos E. R. wrote:

...
...
...
That's because you probably have set grub delay to zero. You don't get a chance that way to choose which kernel to boot. Of course, if you are booting an hibernating machine, any menu is disabled intentionally.

I certainly don't remember making such a choice. Nor do I know where to do so. Same place?

...
In YaST, module boot loader.

...
Also in "/etc/default/grub", value "GRUB_TIMEOUT". Typical is "8". Then run the command the comments tell to run to apply. Same file as you disable plymouth.

I did the above things as you instructed.

Yes, timeout 8 there, but the timeout between Welcome to Grub and Plymouth is typically zero.

You may have "stuck" hibernation; what

grub2-editenv - list

says? (It is really lone `-' there).

This is not s hibernation issue. I shut down the machine normally. I powered it up normally. In each time upon power up, whether in text mode, or using Plymouth, I simply waited, counting second from the time the request for luks password appears. After 5 to 7 seconds it would resume without a password. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Carlos E. R.

11:59

On 2016-01-24 08:05, John Andersen wrote:

...

...
You may have "stuck" hibernation; what

grub2-editenv - list

says? (It is really lone `-' there).

This is not s hibernation issue. I shut down the machine normally.

Nevertheless, please try that command. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

Carlos E. R.

12:26

On 2016-01-24 12:59, Carlos E. R. wrote:

...

Nevertheless, please try that command.

I would also suggest to download and run this script: https://github.com/arvidjaar/bootinfoscript/raw/master/bootinfoscript It creates a text file with lots of information, which you can upload to susepaste.org, then post a link to it in this thread. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

John Andersen

21:26

On 01/24/2016 03:59 AM, Carlos E. R. wrote:

...

On 2016-01-24 08:05, John Andersen wrote:

...
...
You may have "stuck" hibernation; what

grub2-editenv - list

says? (It is really lone `-' there).

This is not s hibernation issue. I shut down the machine normally.

Nevertheless, please try that command.

I've forgotten which command I am supposed to run. So starting back at Andrei's suggestion appended to your suggestion this is what I did. I edited /etc/default/grub as you suggested, and added plymouth.enable=0 to the default cmd line per Andrei Borzenkov. See trimmed listing of /etc/default/grub after this edit: # Modified by YaST2. Last modification on Sat Jan 23 11:07:33 PST 2016 # THIS FILE WILL BE PARTIALLY OVERWRITTEN by perl-Bootloader # For the new kernel it try to figure out old parameters. In case we are not able to recognize it (e.g. change of flavor or strange install order ) it it use as fallback installation parameters from /etc/sysconfig/bootloader # If you change this file, run 'grub2-mkconfig -o /boot/grub2/grub.cfg' afterwards to update # /boot/grub2/grub.cfg. GRUB_DISTRIBUTOR=openSUSE GRUB_DEFAULT=saved GRUB_HIDDEN_TIMEOUT=0 GRUB_HIDDEN_TIMEOUT_QUIET=true GRUB_TIMEOUT=8 GRUB_CMDLINE_LINUX_DEFAULT=" resume=/dev/disk/by-uuid/86b250ea-1e75-433f-a045-73f2a117c1a6 splash=silent quiet showopts plymouth.enable=0" # ###################################################################################################################### Added above per Andrei Borzenkov # kernel command line options for failsafe mode GRUB_CMDLINE_LINUX_RECOVERY="showopts apm=off noresume edd=off powersaved=off nohz=off highres=off processor.max_cstate=1 nomodeset x11failsafe" GRUB_CMDLINE_LINUX="" # Uncomment to enable BadRAM filtering, modify to suit your needs # This works with Linux (no patch required) and with any kernel that obtains ---clip to save space Then I did: poulsbo:/etc/default # grub2-mkconfig -o /boot/grub2/grub.cfg Generating grub configuration file ... Found theme: /boot/grub2/themes/openSUSE/theme.txt Found linux image: /boot/vmlinuz-3.16.7-29-desktop Found initrd image: /boot/initrd-3.16.7-29-desktop Found linux image: /boot/vmlinuz-3.16.7-24-desktop Found initrd image: /boot/initrd-3.16.7-24-desktop WARNING: lvmetad is running but disabled. Restart lvmetad before enabling it! No volume groups found done Then Shutdown to power off. Then Reboot The reboot Said Welcome to Grub, then popped up a default and advanced options choice (in a graphical display) I sat there till the count down timer expired and the Default was taken automatically. It flashed the screen to black a couple of times then proceeded to show the old familiar scrolling text display. It stopped after a line reading Please enter the passphrase for disc WDC-yadda-yadda-2 (cr-mysource) on /mysource! At this point, I sat there and counted seconds. At 5 seconds it auto resumed. It finished booting, but did not mount /mysource nor did it mount /home which is also encrypted. (Nor did it ask me for the password of /home) I shutdown, and repeated the boot, this time typing at less than full speed when it asked for the password. In spite of the fact that I was only 4 characters into the password, it resumed booting, (and failing to mount) the encrypted partitions. I repeated again, typed quickly, and it booted properly and mounted both encrypted partitions (but again only asking for one password, - they are both the same, and it must try what it was given the first time before asking the second time) So you see this is not dependent on presence or absence of plymouth. When Plymouth is there it stops and waits the same 5 or 6 seconds before resuming (but it gives no clue which disk it is asking the password for. But the problem is STILL that it will resume the boot process in 5 seconds or so. Again this is a pretty much stock 13.2 without BTRFS, with two partitions encrypted xfs partitions as shown below: poulsbo:~ # cat /etc/fstab UUID=9c13c3bb-c0c6-4b95-be1f-e34e7c9498ab / ext4 acl,user_xattr 1 1 /dev/mapper/cr_mysource /mysource xfs nofail 0 2 UUID=86b250ea-1e75-433f-a045-73f2a117c1a6 swap swap defaults 0 0 /dev/mapper/cr_ata-WDC_WD5000BPKX-22HPJT0_WD-WX31A64R7974-part4 /home xfs nofail 0 2 I would like to push that wait time at least to 10 seconds, because the slightet distraction while booting, and I miss the oppertunity entirely. -- After all is said and done, more is said than done. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Carlos E. R.

21:51

On 2016-01-24 22:26, John Andersen wrote:

...

On 01/24/2016 03:59 AM, Carlos E. R. wrote:

...
On 2016-01-24 08:05, John Andersen wrote:

...
...
You may have "stuck" hibernation; what

grub2-editenv - list <=============

says? (It is really lone `-' there).

This is not s hibernation issue. I shut down the machine normally.

Nevertheless, please try that command.

I've forgotten which command I am supposed to run.

You have it above in the email you sent. I'll mark it with an arrow like this: "<============="

...

Then Shutdown to power off. Then Reboot

The reboot Said Welcome to Grub, then popped up a default and advanced options choice (in a graphical display) I sat there till the count down timer expired and the Default was taken automatically.

Good! Before the timer expires you can reach the grub editor.

...

It flashed the screen to black a couple of times then proceeded to show the old familiar scrolling text display.

It stopped after a line reading Please enter the passphrase for disc WDC-yadda-yadda-2 (cr-mysource) on /mysource!

At this point, I sat there and counted seconds. At 5 seconds it auto resumed.

Ah. In my machines it waits for minutes.

...

It finished booting, but did not mount /mysource nor did it mount /home which is also encrypted. (Nor did it ask me for the password of /home)

I shutdown, and repeated the boot, this time typing at less than full speed when it asked for the password. In spite of the fact that I was only 4 characters into the password, it resumed booting, (and failing to mount) the encrypted partitions.

Strange. I don't know where this timeout is defined. It is not in grub.

...

I repeated again, typed quickly, and it booted properly and mounted both encrypted partitions (but again only asking for one password, - they are both the same, and it must try what it was given the first time before asking the second time)

So you see this is not dependent on presence or absence of plymouth.

Well, no, not in this case. But at least you can see what is going on.

...

When Plymouth is there it stops and waits the same 5 or 6 seconds before resuming (but it gives no clue which disk it is asking the password for.

One of the reasons I remove it :-)

...

But the problem is STILL that it will resume the boot process in 5 seconds or so.

Yes.

...

Again this is a pretty much stock 13.2 without BTRFS, with two partitions encrypted xfs partitions as shown below:

poulsbo:~ # cat /etc/fstab UUID=9c13c3bb-c0c6-4b95-be1f-e34e7c9498ab / ext4 acl,user_xattr 1 1 /dev/mapper/cr_mysource /mysource xfs nofail 0 2 UUID=86b250ea-1e75-433f-a045-73f2a117c1a6 swap swap defaults 0 0 /dev/mapper/cr_ata-WDC_WD5000BPKX-22HPJT0_WD-WX31A64R7974-part4 /home xfs nofail 0 2

I would like to push that wait time at least to 10 seconds, because the slightet distraction while booting, and I miss the oppertunity entirely.

I know that it is not set up in fstab, nor in crypttab, AFAIK. Well, I'm wrong. See "man crypttab". timeout= Specifies the timeout for querying for a password. If no unit is specified, seconds is used. Supported units are s, ms, us, min, h, d. A timeout of 0 waits indefinitely (which is the default). You see, the default is wait for ever. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

John Andersen

21:56

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/24/2016 01:51 PM, Carlos E. R. wrote:

...

timeout= Specifies the timeout for querying for a password. If no unit is specified, seconds is used. Supported units are s, ms, us, min, h, d. A timeout of 0 waits indefinitely (which is the default).

I'm trying this as soon as I get this email sent. Setting it to 30. - -- After all is said and done, more is said than done. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlalSHkACgkQv7M3G5+2DLLcfACeOKQgK1SXkqWtDBWeDLhoF0/K on0AnjobdLhanEWurdD8jnQHYitJb8t2 =3dS7 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

John Andersen

23:24

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 1/24/2016 1:56 PM, John Andersen wrote:

...

On 01/24/2016 01:51 PM, Carlos E. R. wrote:

...
timeout= Specifies the timeout for querying for a password. If no unit is specified, seconds is used. Supported units are s, ms, us, min, h, d. A timeout of 0 waits indefinitely (which is the default).

I'm trying this as soon as I get this email sent. Setting it to 30.

-- After all is said and done, more is said than done.

I have found that the timeout in cryttab are honored if you mount it at the command line like systemctl start systemd-cryptsetup@cr_home.service but the are still not honored at boot time. Carlos: Do you suppose I have to rebuild the initrd after changing these settings in crypptab? Is it perhaps included there in, such that none of my changes take effect? And if so remeind me how I do that. - -- _____________________________________ - ---This space for rent--- -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlalXTMACgkQv7M3G5+2DLKmSQCcCKqa87W6NlAhAjXrCJZgNwyF NukAn3bPr6Td9/qzT8Z2x1x4QUu/oE9H =zDgo -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Carlos E. R.

23:36

On 2016-01-25 00:24, John Andersen wrote:

...

Carlos: Do you suppose I have to rebuild the initrd after changing these settings in crypptab? Is it perhaps included there in, such that none of my changes take effect?

Depends... I would definitely rebuild it to be sure. It depends on what point the mount happens. If early on boot, before "/" is mounted, then it is obviously reading from the initrd. If it happens afterwards, then no.

...

And if so remeind me how I do that.

As simple as running "mkinitrd" as root :-) -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

John M Andersen

25 Jan 25 Jan

08:35

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 1/24/2016 3:36 PM, Carlos E. R. wrote:

...

On 2016-01-25 00:24, John Andersen wrote:

...
Carlos: Do you suppose I have to rebuild the initrd after changing these settings in crypptab? Is it perhaps included there in, such that none of my changes take effect?

Depends... I would definitely rebuild it to be sure.

It depends on what point the mount happens. If early on boot, before "/" is mounted, then it is obviously reading from the initrd. If it happens afterwards, then no.

...
And if so remeind me how I do that.

As simple as running "mkinitrd" as root :-)

Did this. No help. It still stops waiting for a password 5 to 6 seconds. Mounting the same partitions manually with something like: systemctl start systemd-cryptsetup@cr_home.service it will wait for the duration specified in crypptab. The last tests I will do on this, tomorrow, is to remove "nofail" on these partitions in the fstab. But realistically, I don't want it to fail, I just want it to wait a few seconds longer. I have a dummy /home on the root directory tree, with some dummy data in there in case someone steals my laptop, it will boot and look normal-(ish) with no confidential data. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlal3kcACgkQv7M3G5+2DLI46ACfZFmHTP1ab6DhUdn2JguJBblD HzMAmwT5kgJa8WH4RZ34jIQDS2rC2oSE =driH -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Carlos E. R.

12:23

On 2016-01-25 09:35, John M Andersen wrote:

...

On 1/24/2016 3:36 PM, Carlos E. R. wrote:

...

...
...
And if so remeind me how I do that.

...
As simple as running "mkinitrd" as root :-)

Did this.

No help. It still stops waiting for a password 5 to 6 seconds.

:-(

...

Mounting the same partitions manually with something like: systemctl start systemd-cryptsetup@cr_home.service it will wait for the duration specified in crypptab.

Then the code in the initrd comes from somewhere else.

...

The last tests I will do on this, tomorrow, is to remove "nofail" on these partitions in the fstab.

But realistically, I don't want it to fail, I just want it to wait a few seconds longer.

What "nofail" does is not to abort the boot process if the mounting fails. Just ignore that partition and continue. In your case, it should go to emergency mode.

...

I have a dummy /home on the root directory tree, with some dummy data in there in case someone steals my laptop, it will boot and look normal-(ish) with no confidential data.

Good thing :-) -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

John Andersen

19:46

New subject: SOLVED Re: [opensuse] Bootup of Luks partitions not waiting long for Password

On 01/25/2016 04:23 AM, Carlos E. R. wrote:

...

...
Mounting the same partitions manually with something like:

...
systemctl start systemd-cryptsetup@cr_home.service it will wait for the duration specified in crypptab.

Then the code in the initrd comes from somewhere else.

More specifically, I don't think anything in initrd is involved. I suspect, as you indicated up-thread, that it has root mounted by that point, and is working out of the actual /etc directory.

...

...
...
The last tests I will do on this, tomorrow, is to remove "nofail" on these partitions in the fstab.

But realistically, I don't want it to fail, I just want it to wait a few seconds longer.

...

What "nofail" does is not to abort the boot process if the mounting fails. Just ignore that partition and continue. In your case, it should go to emergency mode.

We have found the guilty party here, it is systemd ignoring /etc/cryptab when Nofail appears in /etc/fstab. (And this explains why Andrei's tests did not show this problem) When I replaced "nofail" with "defaults" in fstab, the boot-time prompt (either text mode or plymouth's graphical mode) will wait the _full 15 seconds_ that I specified in /etc/crypttab for the passphrase for LUKS encrypted partition. If I enter nothing, it drops to emergency mode, indicates that a password is needed, and asks what to do. If I select continue, it jumps right back and asks for the password again. If I give it the password it boots fine and mounts both LUKS partitions. With nofail in place in fstab, it simply times out after the 5 seconds, and boots without waiting for, or mounting, the LUKS partitions, and the timeout parameter in /etc/crypttab is ignored. The problem appears to be that systemd is not aware of /etc/crypttab _SOLUTION:_ ---------------------------------------- Systemd (at least as implimented in opensuse 13.2) is ignoring the wait time in /etc/crypttab Yast, seems to set up LUKS partitions with nofail (and has done so for several releases), and, quite frankly, this is what I want in my case. Workaround: In /etc/fstab, add a parameter to the options to explicitly tell systemd to wait your desired interval. x-systemd.device-timeout=15 does this. Example fstab line: /dev/mapper/cr_myprivate /myprivate xfs nofail,x-systemd.device-timeout=15 = 0 2 This causes systemd to wait 15 seconds after displaying the password request before booting with the partitions left un mounted. Thanks to Carlos and Andrei Borzenkov for their hints and testing. Against WHAT should I file the bug report? -- After all is said and done, more is said than done. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

John Andersen

19:58

New subject: SOLVED Re: [opensuse] Bootup of Luks partitions not waiting long for Password

On 01/25/2016 11:46 AM, John Andersen wrote:

...

Example fstab line: /dev/mapper/cr_myprivate /myprivate xfs nofail,x-systemd.device-timeout=15 = 0 2

Arrrrgh: That last = sign is not supposed to be there. It should be:

...

/dev/mapper/cr_myprivate /myprivate xfs nofail,x-systemd.device-timeout=15 0 2

-- After all is said and done, more is said than done. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Andrei Borzenkov

26 Jan 26 Jan

03:19

New subject: SOLVED Re: [opensuse] Bootup of Luks partitions not waiting long for Password

25.01.2016 22:46, John Andersen пишет:

...

Against WHAT should I file the bug report?

Basesystem. You can assign bug to systemd-maintainers@suse.de to save time. Please post number here. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

John Andersen

04:28

New subject: SOLVED Re: [opensuse] Bootup of Luks partitions not waiting long for Password

On 01/25/2016 07:19 PM, Andrei Borzenkov wrote:

...

25.01.2016 22:46, John Andersen пишет:

...
Against WHAT should I file the bug report?

Basesystem. You can assign bug to systemd-maintainers@suse.de to save time. Please post number here.

Done: https://bugzilla.opensuse.org/show_bug.cgi?id=963526 -- After all is said and done, more is said than done. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Andrei Borzenkov

24 Jan 24 Jan

16:32

23.01.2016 05:44, John Andersen пишет:

...

I've got a 13.2 installation that for some reason some time ago started waiting a real short time for passwords on the Plymouth screen (or at least the Plymouth wallpaper) for a password for the Luks encrypted partition.

I have to hover over the keyboard waiting for that prompt to come up and type it really quick or it boots without my home partition mounted.

I thought it was /etc/crypttab where the delay was set, but this appears to be ignored. There are a few bug reports but they appear full of arguing back and forth and nobody has a clue.

Has anyone else seen this, or have a solution?

I cannot reproduce it. I installed minimal 13.2 with all current updates, added plymouth, couple of encrypted filesystems and right now it sits on Plymouth screen waiting passphrase for a cpuple of minutes at least. Of course what is stupid is complete lack of indication for which device password is expected. It is just blank input field without any hint whatsoever. May be I miss some Plpymouth packages. They are not installed in minimal text installation pattern, I selected them manually. OTOH I remember definitely having seen at least device name in the past. I suggest you try adding systemd.log_level=debug and remove "quiet" from kernel command line and upload "journalctl -b" output after boot to susepaste.org. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

John Andersen

23:30

On 1/24/2016 8:32 AM, Andrei Borzenkov wrote:

...

23.01.2016 05:44, John Andersen пишет:

...
I've got a 13.2 installation that for some reason some time ago started waiting a real short time for passwords on the Plymouth screen (or at least the Plymouth wallpaper) for a password for the Luks encrypted partition.

I have to hover over the keyboard waiting for that prompt to come up and type it really quick or it boots without my home partition mounted.

I thought it was /etc/crypttab where the delay was set, but this appears to be ignored. There are a few bug reports but they appear full of arguing back and forth and nobody has a clue.

Has anyone else seen this, or have a solution?

I cannot reproduce it. I installed minimal 13.2 with all current updates, added plymouth, couple of encrypted filesystems and right now it sits on Plymouth screen waiting passphrase for a cpuple of minutes at least.

Andrei, are your luks partitions in fstab with nofail option? Mine are, I believe that is how opensuse set them up. -- _____________________________________ ---This space for rent--- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Andrei Borzenkov

25 Jan 25 Jan

19:02

25.01.2016 02:30, John Andersen пишет:

...

On 1/24/2016 8:32 AM, Andrei Borzenkov wrote:

...
23.01.2016 05:44, John Andersen пишет:

...
I've got a 13.2 installation that for some reason some time ago started waiting a real short time for passwords on the Plymouth screen (or at least the Plymouth wallpaper) for a password for the Luks encrypted partition.

I have to hover over the keyboard waiting for that prompt to come up and type it really quick or it boots without my home partition mounted.

I thought it was /etc/crypttab where the delay was set, but this appears to be ignored. There are a few bug reports but they appear full of arguing back and forth and nobody has a clue.

Has anyone else seen this, or have a solution?

I cannot reproduce it. I installed minimal 13.2 with all current updates, added plymouth, couple of encrypted filesystems and right now it sits on Plymouth screen waiting passphrase for a cpuple of minutes at least.

Andrei, are your luks partitions in fstab with nofail option?

Of course not. This is the first time you mention it. How do you expect me to know you were using it? Yes, I see it with nofail and now it is obvious what causes it. Mon Nov 23 14:20:23 GMT 2015 - Thomas.Blume@suse.com - disable device timeout when nofail is set (bsc#949683) You can restore previous behavior by adding x-systemd.device-timeout=0 to options in /etc/fstab.

...

Mine are, I believe that is how opensuse set them up.

I cannot even make yast partitioner to encrypt partition that is used for file system. You would need to provide step by step description how you managed to convince openSUSE to set this up ... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

John Andersen

19:53

On 01/25/2016 11:02 AM, Andrei Borzenkov wrote:

...

25.01.2016 02:30, John Andersen пишет:

...
On 1/24/2016 8:32 AM, Andrei Borzenkov wrote:

...
23.01.2016 05:44, John Andersen пишет:

...
I've got a 13.2 installation that for some reason some time ago started waiting a real short time for passwords on the Plymouth screen (or at least the Plymouth wallpaper) for a password for the Luks encrypted partition.

I have to hover over the keyboard waiting for that prompt to come up and type it really quick or it boots without my home partition mounted.

I thought it was /etc/crypttab where the delay was set, but this appears to be ignored. There are a few bug reports but they appear full of arguing back and forth and nobody has a clue.

Has anyone else seen this, or have a solution?

I cannot reproduce it. I installed minimal 13.2 with all current updates, added plymouth, couple of encrypted filesystems and right now it sits on Plymouth screen waiting passphrase for a cpuple of minutes at least.

Andrei, are your luks partitions in fstab with nofail option?

Of course not. This is the first time you mention it. How do you expect me to know you were using it?

Yes, I see it with nofail and now it is obvious what causes it.

Mon Nov 23 14:20:23 GMT 2015 - Thomas.Blume@suse.com

- disable device timeout when nofail is set (bsc#949683)

You can restore previous behavior by adding

x-systemd.device-timeout=0

Yes, see my SOLVED post, in a another message. I found the same solution you mention on an ARCH mailing-list. https://bbs.archlinux.org/viewtopic.php?id=199218

...

to options in /etc/fstab.

...
Mine are, I believe that is how opensuse set them up.

I cannot even make yast partitioner to encrypt partition that is used for file system. You would need to provide step by step description how you managed to convince openSUSE to set this up ...

I just used the normal installer to do this with an XFS partition. Its been in Yast for some time. In my case this is not the root partition, it is /home and another partition that I use for storing confidential information. Thanks for your testing Andrei -- After all is said and done, more is said than done. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

3019

Age (days ago)

3022

Last active (days ago)

List overview

Download

37 comments

5 participants

participants (5)

Andrei Borzenkov
Carlos E. R.
John Andersen
John M Andersen
listreader