[opensuse-support] 15.2, plymouth, and multiple LUKS partitions
Hello! Some strangeness in a fresh install of Leap 15.2 on a system with multiple LUKS partitions mounted at boot, all owning the same password. Normal boot and plymouth(?) displays a neon green text line on a blank background asking for the LUKS password for swap. After entering pw, plymouth(?) then displays three neon green blocks for several seconds. Remaining three LUKS partitions are invisibly mounted without further prompting and system boots into graphical mode. Boot with plymouth.enable=0 and I get the text display, as expected and usual in previous revs, but then I get prompted for passwords for all 4 partitions, even though they all have the same password. This used to be buffered and pw retried on additional partitions first before system would ask for any needed additional pw. Not now, apparently. What is happening here? No 'you must immediately delete plymouth from the system' suggestions, please ;) Ralph -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
On 14/10/2020 13.39, Ralph wrote:
Hello!
Some strangeness in a fresh install of Leap 15.2 on a system with multiple LUKS partitions mounted at boot, all owning the same password.
Normal boot and plymouth(?) displays a neon green text line on a blank background asking for the LUKS password for swap. After entering pw, plymouth(?) then displays three neon green blocks for several seconds. Remaining three LUKS partitions are invisibly mounted without further prompting and system boots into graphical mode.
Boot with plymouth.enable=0 and I get the text display, as expected and usual in previous revs, but then I get prompted for passwords for all 4 partitions, even though they all have the same password. This used to be buffered and pw retried on additional partitions first before system would ask for any needed additional pw. Not now, apparently.
What is happening here? No 'you must immediately delete plymouth from the system' suggestions, please ;)
(I do delete plymouth from all my systems :-p ) Well, what you see is the expected behaviour, and I have seen it for years. plymouth captures and caches the passphrase for using it on other partitions. If plymouth is disabled, then nothing does the same job. There is a trick, which is to add to all LUKS partitions another key, stored in a file, which resides in the first partition to be opened. On boot, that partition is opened, and the other partitions use that keyfile to be opened without prompting for the passphrase. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
On Wed, 14 Oct 2020 14:30:59 +0200
"Carlos E. R."
On 14/10/2020 13.39, Ralph wrote:
Well, what you see is the expected behaviour, and I have seen it for years. plymouth captures and caches the passphrase for using it on other partitions. If plymouth is disabled, then nothing does the same job.
No, that is not expected behavior. Previously, plymouth.enable=0 did NOT stop the pw caching from working, it still worked (and still works) on my remaining 15.1 boot. Something else is involved here.
There is a trick, which is to add to all LUKS partitions another key, stored in a file, which resides in the first partition to be opened. On boot, that partition is opened, and the other partitions use that keyfile to be opened without prompting for the passphrase.
This 'trick' would seem to have the same problem as other 'unofficial' temporary fixes: when you next do a fresh install you have to remember all the temporary fixes you had installed in the previous system and re-install them in the new system, and this as I just found out (again) is not an easy thing even if you kept copious notes. One simple example: I have a mlocate database in my /home. Official changes that were made to o/s stopped this from working. I installed a provided temporary fix / manual edit that allowed the updatedb/locate to again work on this local database. A permanent fix was supposedly submitted and accepted into the o/s. But, as I just discovered when first running my new install, that permanent fix doesn't work, which I didn't know before as I still had the temporary work-around installed on the old system. In this case I remembered the work-around, it was only 2 years ago :) so I just reinstalled it, and all is good, but I've still got other unrelated problems in the new system that I am scratching my head saying 'why doesn't this work like it used to'? So I would hesitate to use your 'trick' solution unless it is a life or death situation, which this is fortunately not :) Ralph -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
On 15/10/2020 17.54, Ralph wrote:
On Wed, 14 Oct 2020 14:30:59 +0200 "Carlos E. R." <> wrote:
On 14/10/2020 13.39, Ralph wrote:
Well, what you see is the expected behaviour, and I have seen it for years. plymouth captures and caches the passphrase for using it on other partitions. If plymouth is disabled, then nothing does the same job.
No, that is not expected behavior. Previously, plymouth.enable=0 did NOT stop the pw caching from working, it still worked (and still works) on my remaining 15.1 boot. Something else is involved here.
Correction. It was the expected behaviour for many years, till at some point in time systemd caught up and did the caching. I have a computer where it doesn't work, with 15.1, and I use the file trick. Plymouth is not even installed.
There is a trick, which is to add to all LUKS partitions another key, stored in a file, which resides in the first partition to be opened. On boot, that partition is opened, and the other partitions use that keyfile to be opened without prompting for the passphrase.
This 'trick' would seem to have the same problem as other 'unofficial' temporary fixes: when you next do a fresh install you have to remember all the temporary fixes you had installed in the previous system and re-install them in the new system, and this as I just found out (again) is not an easy thing even if you kept copious notes.
Well, I never reinstall, I upgrade :-D (yes, it is one of the things that is in my notes)
One simple example: I have a mlocate database in my /home. Official changes that were made to o/s stopped this from working. I installed a provided temporary fix / manual edit that allowed the updatedb/locate to again work on this local database. A permanent fix was supposedly submitted and accepted into the o/s. But, as I just discovered when first running my new install, that permanent fix doesn't work, which I didn't know before as I still had the temporary work-around installed on the old system. In this case I remembered the work-around, it was only 2 years ago :) so I just reinstalled it, and all is good, but I've still got other unrelated problems in the new system that I am scratching my head saying 'why doesn't this work like it used to'? So I would hesitate to use your 'trick' solution unless it is a life or death situation, which this is fortunately not :)
Heh :-D -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
On 10/14/20 6:39 AM, Ralph wrote:
Boot with plymouth.enable=0 and I get the text display, as expected and usual in previous revs, but then I get prompted for passwords for all 4 partitions, even though they all have the same password. This used to be buffered and pw retried on additional partitions first before system would ask for any needed additional pw. Not now, apparently.
I am surprised at this. For me, it is working. I use an encrypted LVM for root, home, swap. And I have a separate partition that I mount as "/shared". That "/shared" partition is also LUKS encrypted. For normal booting, I have removed the "splash=silent" line from the boot command. I get the full details of boot. My understand is that plymouth is still there handling the crypto, but not trying to display its splash screen. So I just rebooted, using "plymouth.enable=0". And I was still only prompted once for the password. As I understand it, in this case "dracut" is managing the crypto prompting and remembering the password that worked for the encrypted LVM. I'm not sure why that did not work for you. -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
14.10.2020 20:20, Neil Rickert пишет:
So I just rebooted, using "plymouth.enable=0". And I was still only prompted once for the password. As I understand it, in this case "dracut" is managing the crypto prompting and remembering the password that worked for the encrypted LVM.
dracut handles only root (and may be /usr or similar) - i.e. only those partitions required for accessing root filesystem. Anything after that is handled by systemd which caches provided passphrase. -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
On Wed, 14 Oct 2020 12:20:40 -0500
Neil Rickert
On 10/14/20 6:39 AM, Ralph wrote:
Boot with plymouth.enable=0 and I get the text display, as expected and usual in previous revs, but then I get prompted for passwords for all 4 partitions, even though they all have the same password. This used to be buffered and pw retried on additional partitions first before system would ask for any needed additional pw. Not now, apparently.
I am surprised at this. For me, it is working.
So I just rebooted, using "plymouth.enable=0". And I was still only prompted once for the password. As I understand it, in this case "dracut" is managing the crypto prompting and remembering the password that worked for the encrypted LVM.
I'm not sure why that did not work for you.
Thanks for the confirm that it SHOULD be working, which means something particular to me is messed up. At the moment I have no idea what it might be... Ralph -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
14.10.2020 14:39, Ralph пишет:
Hello!
Some strangeness in a fresh install of Leap 15.2 on a system with multiple LUKS partitions mounted at boot, all owning the same password.
Normal boot and plymouth(?) displays a neon green text line on a blank background asking for the LUKS password for swap. After entering pw, plymouth(?) then displays three neon green blocks for several seconds. Remaining three LUKS partitions are invisibly mounted without further prompting and system boots into graphical mode.
Boot with plymouth.enable=0 and I get the text display, as expected and usual in previous revs, but then I get prompted for passwords for all 4 partitions, even though they all have the same password. This used to be buffered and pw retried on additional partitions first before system would ask for any needed additional pw. Not now, apparently.
I cannot reproduce it. I create two encrypted partitions with the same passphrase and I'm asked just once. Systemd should actually cache passphrase in kernel keyring for short period of time. How long is interval between password requests? You may want to boot with systemd.log_level=debug which /may/ provide more information what happens.
What is happening here? No 'you must immediately delete plymouth from the system' suggestions, please ;)
Ralph
-- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
On Wed, 2020-10-14 at 20:42 +0300, Andrei Borzenkov wrote:
14.10.2020 14:39, Ralph пишет:
Hello!
Some strangeness in a fresh install of Leap 15.2 on a system with multiple LUKS partitions mounted at boot, all owning the same password.
Normal boot and plymouth(?) displays a neon green text line on a blank background asking for the LUKS password for swap. After entering pw, plymouth(?) then displays three neon green blocks for several seconds. Remaining three LUKS partitions are invisibly mounted without further prompting and system boots into graphical mode.
Boot with plymouth.enable=0 and I get the text display, as expected and usual in previous revs, but then I get prompted for passwords for all 4 partitions, even though they all have the same password. This used to be buffered and pw retried on additional partitions first before system would ask for any needed additional pw. Not now, apparently.
I cannot reproduce it. I create two encrypted partitions with the same passphrase and I'm asked just once. Systemd should actually cache passphrase in kernel keyring for short period of time. How long is interval between password requests?
You may want to boot with systemd.log_level=debug which /may/ provide more information what happens.
I observe the same "annoying" behavior - having to enter disk encryption password two times - in grub and at swap activation during boot. My install is default Leap 15.2 install with encrypted disk (default = 2 encrypted partitions = btrfs file system + swap) I have never questioned it as I thought that this is unavoidable in openSuSE - and assumed that the other distro's which do not need this are cutting some security corners for the sake of convenience. Now that you remind me how annoying this actually is - I might get rid off swap partition altogether and setup swap file (with disabled COW) instead. It will cost performance, but it really bothers me to watch the laptop boot every time. Perhaps the different LUKS behavior depends on UEFI/secureBoot+UEFI/not-UEFI boot paths. Tomas
On 14/10/2020 23.42, tomas.kuchta.lists@gmail.com wrote:
On Wed, 2020-10-14 at 20:42 +0300, Andrei Borzenkov wrote:
I observe the same "annoying" behavior - having to enter disk encryption password two times - in grub and at swap activation during boot. My install is default Leap 15.2 install with encrypted disk (default = 2 encrypted partitions = btrfs file system + swap)
I have never questioned it as I thought that this is unavoidable in openSuSE - and assumed that the other distro's which do not need this are cutting some security corners for the sake of convenience.
Now that you remind me how annoying this actually is - I might get rid off swap partition altogether and setup swap file (with disabled COW) instead. It will cost performance, but it really bothers me to watch the laptop boot every time.
The trick I mentioned before solves or bypasses this issue for me. I was not aware that systemd should cache it. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
On Wed, 2020-10-14 at 23:50 +0200, Carlos E.R. wrote:
On 14/10/2020 23.42, tomas.kuchta.lists@gmail.com wrote:
I observe the same "annoying" behavior - having to enter disk encryption password two times - in grub and at swap activation during boot. My install is default Leap 15.2 install with encrypted disk (default = 2 encrypted partitions = btrfs file system + swap)
I have never questioned it as I thought that this is unavoidable in openSuSE - and assumed that the other distro's which do not need this are cutting some security corners for the sake of convenience.
Now that you remind me how annoying this actually is - I might get rid off swap partition altogether and setup swap file (with disabled COW) instead. It will cost performance, but it really bothers me to watch the laptop boot every time.
The trick I mentioned before solves or bypasses this issue for me.
I was not aware that systemd should cache it.
Storing swap key in encrypted root partition seems OK workaround - though not configurable at install. Perhaps with different, even unknown, encryption password to avoid exposing swap+root partition key file in backups or multi user or compromised situations. Though - me re-thinks - if this is suppose to work with single password entry out of the box - it may be worth digging in a little and submitting a bug report. Thanks for suggesting the keyfile. Tomas
On 15/10/2020 00.15, tomas.kuchta.lists@gmail.com wrote:
On Wed, 2020-10-14 at 23:50 +0200, Carlos E.R. wrote:
On 14/10/2020 23.42,tomas.kuchta.lists@gmail.com mailto:tomas.kuchta.lists@gmail.com wrote:
I observe the same "annoying" behavior - having to enter disk encryption password two times - in grub and at swap activation during boot. My install is default Leap 15.2 install with encrypted disk (default = 2 encrypted partitions = btrfs file system + swap) I have never questioned it as I thought that this is unavoidable in openSuSE - and assumed that the other distro's which do not need this are cutting some security corners for the sake of convenience. Now that you remind me how annoying this actually is - I might get rid off swap partition altogether and setup swap file (with disabled COW) instead. It will cost performance, but it really bothers me to watch the laptop boot every time.
The trick I mentioned before solves or bypasses this issue for me.
I was not aware that systemd should cache it.
Storing swap key in encrypted root partition seems OK workaround - though not configurable at install.
Right.
Perhaps with different, even unknown, encryption password to avoid exposing swap+root partition key file in backups or multi user or compromised situations.
I use encrypted backups, too. In multiuser environments, you could set up an extra partition, very small, that just holds the key. After the system has booted, a cron job umounts it.
Though - me re-thinks - if this is suppose to work with single password entry out of the box - it may be worth digging in a little and submitting a bug report.
Yep.
Thanks for suggesting the keyfile.
Welcome :-) -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
15.10.2020 00:42, tomas.kuchta.lists@gmail.com пишет:
I observe the same "annoying" behavior - having to enter disk encryption password two times - in grub and at swap activation during boot.
Which is completely unrelated to the issue discussed in the thread, -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
On Thu, 2020-10-15 at 07:59 +0300, Andrei Borzenkov wrote:
15.10.2020 00:42, Tomask пишет:
I observe the same "annoying" behavior - having to enter disk encryption password two times - in grub and at swap activation during boot.
Which is completely unrelated to the issue discussed in the thread,
How is that different? Is it not the issue he is describing - being queried for the same LUKS password two times during the boot? I do not suspect that plymouth (just putting a decoration over boot messages to hide them) could have anything to do with passwords though. Sure, I do not have explanation to this problem suddenly appearing - knowing that others have the same problem from the moment of install can be meaningful in problem solving. Tomas -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
On 15/10/2020 08.33, TomasK wrote:
On Thu, 2020-10-15 at 07:59 +0300, Andrei Borzenkov wrote:
15.10.2020 00:42, Tomask пишет:
I observe the same "annoying" behavior - having to enter disk encryption password two times - in grub and at swap activation during boot.
Which is completely unrelated to the issue discussed in the thread,
How is that different? Is it not the issue he is describing - being queried for the same LUKS password two times during the boot? I do not suspect that plymouth (just putting a decoration over boot messages to hide them) could have anything to do with passwords though.
Sure, I do not have explanation to this problem suddenly appearing - knowing that others have the same problem from the moment of install can be meaningful in problem solving.
I think he refers to having entered a password on grub. That password can not be told or passed on to the kernel that boots an instant later, or to systemd. I think not even to plymouth. Grub is an isolated thing. I think grub needs the LUKS password only when /boot is encrypted (be it directory or separate partition). Grub needs to be able to load the kernel into memory, for which it needs to read-decrypt what is in /boot. Support for this is relatively recent: previously full disk encryption needed a separate /boot partition in the clear. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
On Thu, 2020-10-15 at 09:21 +0200, Carlos E. R. wrote:
On 15/10/2020 08.33, TomasK wrote:
On Thu, 2020-10-15 at 07:59 +0300, Andrei Borzenkov wrote:
15.10.2020 00:42, Tomask пишет:
I observe the same "annoying" behavior - having to enter disk encryption password two times - in grub and at swap activation during boot.
Which is completely unrelated to the issue discussed in the thread,
How is that different? Is it not the issue he is describing - being queried for the same LUKS password two times during the boot? I do not suspect that plymouth (just putting a decoration over boot messages to hide them) could have anything to do with passwords though.
Sure, I do not have explanation to this problem suddenly appearing - knowing that others have the same problem from the moment of install can be meaningful in problem solving.
I think he refers to having entered a password on grub. That password can not be told or passed on to the kernel that boots an instant later, or to systemd. I think not even to plymouth. Grub is an isolated thing.
I think grub needs the LUKS password only when /boot is encrypted (be it directory or separate partition). Grub needs to be able to load the kernel into memory, for which it needs to read-decrypt what is in /boot.
Support for this is relatively recent: previously full disk encryption needed a separate /boot partition in the clear.
Thank you Carlos, Andrei, I see, that would make sense - I did not check if /boot now lives in / - I assumed not - I will check it for my own sake when I have time. Tomas
On Wed, 14 Oct 2020 20:42:53 +0300
Andrei Borzenkov
14.10.2020 14:39, Ralph пишет:
Some strangeness in a fresh install of Leap 15.2 on a system with multiple LUKS partitions mounted at boot, all owning the same password.
Normal boot and plymouth(?) displays a neon green text line on a blank background asking for the LUKS password for swap. After entering pw, plymouth(?) then displays three neon green blocks for several seconds. Remaining three LUKS partitions are invisibly mounted without further prompting and system boots into graphical mode.
Boot with plymouth.enable=0 and I get the text display, as expected and usual in previous revs, but then I get prompted for passwords for all 4 partitions, even though they all have the same password. This used to be buffered and pw retried on additional partitions first before system would ask for any needed additional pw. Not now, apparently.
I cannot reproduce it. I create two encrypted partitions with the same passphrase and I'm asked just once. Systemd should actually cache passphrase in kernel keyring for short period of time. How long is interval between password requests?
You may want to boot with systemd.log_level=debug which /may/ provide more information what happens.
Thank you very much for taking the time to try to reproduce the problem. More confirmation that it SHOULD be working, which means something particular to me is messed up. At the moment I have no idea what it might be. Interval between pw requests is just from time boot asks for pw for encrypted swap to check for hibernated system and time it mounts encrypted /home and additional LUKS partitions, looks like max 2 clock seconds during a 'normal' boot. I don't have a log from booting with plymouth.enable=0, thanks to default openSUSE setting of logs going to non-permanent storage, but I've fixed that and will get a log at next opportunity to boot. I will try your log suggestion at next reboot. Ralph -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
On Thu, 15 Oct 2020 10:55:10 -0500 Ralph wrote:
On Wed, 14 Oct 2020 20:42:53 +0300 Andrei Borzenkov wrote:
14.10.2020 14:39, Ralph пишет:
Some strangeness in a fresh install of Leap 15.2 on a system with multiple LUKS partitions mounted at boot, all owning the same password.
Normal boot and plymouth(?) displays a neon green text line on a blank background asking for the LUKS password for swap. After entering pw, plymouth(?) then displays three neon green blocks for several seconds. Remaining three LUKS partitions are invisibly mounted without further prompting and system boots into graphical mode.
Boot with plymouth.enable=0 and I get the text display, as expected and usual in previous revs, but then I get prompted for passwords for all 4 partitions, even though they all have the same password. This used to be buffered and pw retried on additional partitions first before system would ask for any needed additional pw. Not now, apparently.
I cannot reproduce it. I create two encrypted partitions with the same passphrase and I'm asked just once. Systemd should actually cache passphrase in kernel keyring for short period of time. How long is interval between password requests?
You may want to boot with systemd.log_level=debug which /may/ provide more information what happens.
Thank you very much for taking the time to try to reproduce the problem. More confirmation that it SHOULD be working, which means something particular to me is messed up. At the moment I have no idea what it might be.
Interval between pw requests is just from time boot asks for pw for encrypted swap to check for hibernated system and time it mounts encrypted /home and additional LUKS partitions, looks like max 2 clock seconds during a 'normal' boot. I don't have a log from booting with plymouth.enable=0, thanks to default openSUSE setting of logs going to non-permanent storage, but I've fixed that and will get a log at next opportunity to boot.
I will try your log suggestion at next reboot.
I have not had time to dig back into this, but I did need to reboot for something else day or two ago so I have a log on a boot using plymouth.enable=0 (but without your suggested systemd.log_level=debug as email was out at that moment) and I got the following in the log... systemd-tty-ask-password-agent[881]: Invalid password file /run/systemd/ask-password/ask.FjjVli systemd-tty-ask-password-agent[881]: Failed to show password: Bad message ...which looks mighty similar to a problem we had with multi-LUKS a few years ago. I will need to dig up the discussion and the bugzilla from back then and see if it's the same. Ralph -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
participants (7)
-
Andrei Borzenkov -
Carlos E. R. -
Carlos E.R. -
Neil Rickert -
Ralph -
tomas.kuchta.lists＠gmail.com -
TomasK