[oS-EN] Question on full disk encription
Hi, new laptop here, and I decided to install Leap 15.4 with full disk encryption, no LVM (a feature I wanted to have for years, so I'm happy). It asks for the password twice (contrary to my customs, I'm using plymouth). It asks once before grub loads. Well, ok, there is no separate /boot, so it has to read "/" which is encrypted. Nice. But after selecting the boot entry in grub, it asks again. Once, despite being 3 partitions ("/", "/boot" and swap). Ok. Is there some way to make it ask only once? I guess not, but perhaps I'm wrong. -- Cheers / Saludos, Carlos E. R. (from Elesar, using openSUSE Leap 15.4)
On Tue, Mar 28, 2023 at 1:42 PM Carlos E. R. <robin.listas@telefonica.net> wrote:
Hi,
new laptop here, and I decided to install Leap 15.4 with full disk encryption, no LVM (a feature I wanted to have for years, so I'm happy).
It asks for the password twice (contrary to my customs, I'm using plymouth).
It asks once before grub loads. Well, ok, there is no separate /boot, so it has to read "/" which is encrypted. Nice.
But after selecting the boot entry in grub, it asks again. Once, despite being 3 partitions ("/", "/boot" and swap). Ok.
Is there some way to make it ask only once? I guess not, but perhaps I'm wrong.
You did not describe how many partitions are encrypted or whether you are using the same passphrase for all of them or not.
On 2023-03-28 13:11, Andrei Borzenkov wrote:
On Tue, Mar 28, 2023 at 1:42 PM Carlos E. R. <> wrote:
Hi,
new laptop here, and I decided to install Leap 15.4 with full disk encryption, no LVM (a feature I wanted to have for years, so I'm happy).
It asks for the password twice (contrary to my customs, I'm using plymouth).
It asks once before grub loads. Well, ok, there is no separate /boot, so it has to read "/" which is encrypted. Nice.
But after selecting the boot entry in grub, it asks again. Once, despite being 3 partitions ("/", "/boot" and swap). Ok.
---------************************************
Is there some way to make it ask only once? I guess not, but perhaps I'm wrong.
You did not describe how many partitions are encrypted or whether you are using the same passphrase for all of them or not.
See the underline :-) But I made a mistake, it is "/", "/home" and swap. Yes, of course I am using the same password for all 3. -- Cheers / Saludos, Carlos E. R. (from Elesar, using openSUSE Leap 15.4)
On Tue, Mar 28, 2023 at 2:17 PM Carlos E. R. <robin.listas@telefonica.net> wrote:
On 2023-03-28 13:11, Andrei Borzenkov wrote:
On Tue, Mar 28, 2023 at 1:42 PM Carlos E. R. <> wrote:
Hi,
new laptop here, and I decided to install Leap 15.4 with full disk encryption, no LVM (a feature I wanted to have for years, so I'm happy).
It asks for the password twice (contrary to my customs, I'm using plymouth).
It asks once before grub loads. Well, ok, there is no separate /boot, so it has to read "/" which is encrypted. Nice.
But after selecting the boot entry in grub, it asks again. Once, despite being 3 partitions ("/", "/boot" and swap). Ok.
---------************************************
Is there some way to make it ask only once? I guess not, but perhaps I'm wrong.
You did not describe how many partitions are encrypted or whether you are using the same passphrase for all of them or not.
See the underline :-)
Read your sentence above the underline and tell me where you see anything about "three *encrypted* partitions". The only vague hint was about root being encrypted.
But I made a mistake, it is "/", "/home" and swap.
Yes, of course I am using the same password for all 3.
Not sure why it is "of course", for me it is "of course" to use different passwords. The first password request comes from grub, the second password request comes from the booted system (initrd). There is only one request because plymouth caches the first password and attempts to reuse it later for other requests. This is known for years and I am really surprised you are asking about it now. Tumbleweed grub2 has patches to forward passphrase to initrd, but it only works for the root partition, you still need to unlock other partitions. To avoid second password prompt you could add a second key to your LUKS partitions and store it on disk (key for root needs to additionally be included in initrd). This has been asked and answered dozens of times, you certainly can find an explanation how to do it.
On 2023-03-28 16:41, Andrei Borzenkov wrote:
On Tue, Mar 28, 2023 at 2:17 PM Carlos E. R. <> wrote:
On 2023-03-28 13:11, Andrei Borzenkov wrote:
On Tue, Mar 28, 2023 at 1:42 PM Carlos E. R. <> wrote:
Hi,
new laptop here, and I decided to install Leap 15.4 with full disk encryption, no LVM (a feature I wanted to have for years, so I'm happy).
It asks for the password twice (contrary to my customs, I'm using plymouth).
It asks once before grub loads. Well, ok, there is no separate /boot, so it has to read "/" which is encrypted. Nice.
But after selecting the boot entry in grub, it asks again. Once, despite being 3 partitions ("/", "/boot" and swap). Ok.
---------************************************
Is there some way to make it ask only once? I guess not, but perhaps I'm wrong.
You did not describe how many partitions are encrypted or whether you are using the same passphrase for all of them or not.
See the underline :-)
Read your sentence above the underline and tell me where you see anything about "three *encrypted* partitions". The only vague hint was about root being encrypted.
I said "full disk encryption" before. :-)
But I made a mistake, it is "/", "/home" and swap.
Yes, of course I am using the same password for all 3.
Not sure why it is "of course", for me it is "of course" to use different passwords.
Ow. That surprises me. If they were different, I wouldn't have any hope of entering the password just once (although I know it is possible, by using a key file on the first partition).
The first password request comes from grub, the second password request comes from the booted system (initrd).
Yes, I thought so.
There is only one request because plymouth caches the first password and attempts to reuse it later for other requests.
Yes, I know that part, which is the reason that this time I decided to not remove plymouth as I always do.
This is known for years and I am really surprised you are asking about it now.
Because I have never done full disk encryption, and I wanted to confirm my thoughts :-) Maybe someone has ideas.
Tumbleweed grub2 has patches to forward passphrase to initrd, but it only works for the root partition, you still need to unlock other partitions.
Ah.
To avoid second password prompt you could add a second key to your LUKS partitions and store it on disk (key for root needs to additionally be included in initrd). This has been asked and answered dozens of times, you certainly can find an explanation how to do it.
Yes, I am aware of the method to use a file for the key, which is stored on the first disk that is opened; I use it on other machines. Having it in initrd had not occurred to me. And passing it from grub is beyond me. You see, you do have ideas I don't. Do you know of documents for all this? -- Cheers / Saludos, Carlos E. R. (from Elesar, using openSUSE Leap 15.4)
On 2023-03-28 19:38, Andrei Borzenkov wrote:
On 28.03.2023 19:16, Carlos E. R. wrote:
I said "full disk encryption" before. :-)
Everyone understands something different when saying it.
That's true :-)
Do you know of documents for all this?
I think you have been given link already.
Yes, I saw that after sending the post. I guessed right some of the steps, but a bunch of them, not. -- Cheers / Saludos, Carlos E. R. (from Elesar, using openSUSE Leap 15.4)
On 3/28/23 12:16 PM, Carlos E. R. wrote:
Maybe someone has ideas.
Very recently I did a whole disk encryption for just the second time. Actually, two times isn't enough to be comfortable doing it... not for me anyway. So with that caveat... The reading I did said it was possible to separately encrypt various partition separately, but was also possible to encrypt the entire disk at once... well except for /boot and /boot/efi (I think). The advantage of whole disk encryption (as opposed to each partition separately) it's a small bit simpler, but more importantly (to me, anyway) is that it's faster due to less processing entailed. Have to ask: What's the point of encrypting /boot and /boot/efi? What sensitive information could be found there?
On 2023-03-28 21:36, gebser@mousecar.com wrote:
On 3/28/23 12:16 PM, Carlos E. R. wrote:
Maybe someone has ideas.
Very recently I did a whole disk encryption for just the second time. Actually, two times isn't enough to be comfortable doing it... not for me anyway. So with that caveat...
The reading I did said it was possible to separately encrypt various partition separately, but was also possible to encrypt the entire disk at once... well except for /boot and /boot/efi (I think). The advantage of whole disk encryption (as opposed to each partition separately) it's a small bit simpler, but more importantly (to me, anyway) is that it's faster due to less processing entailed.
Traditionally, full disk encryption on openSUSE was done with LVM. The LVM was encrypted, and inside there were the several partitions. /boot had to be outside. Now, since not many versions, YaST offers to encrypt the various partitions without LVM. /boot/efi can't be encrypted, the bios has to be able to read, load and run it directly. There is another method which is firmware encryption. The hard disk firmware does it. I know my laptop can handle that, but I don't really like it, and I don't know how Linux copes with it.
Have to ask: What's the point of encrypting /boot and /boot/efi? What sensitive information could be found there?
I don't really know. Till "recently" /boot could not be encrypted. -- Cheers / Saludos, Carlos E. R. (from Elesar, using openSUSE Leap 15.4)
From: "Carlos E. R." <robin.listas@telefonica.net> Date: Tue, 28 Mar 2023 22:04:08 +0200 On 2023-03-28 21:36, gebser@mousecar.com wrote: . . .
Have to ask: What's the point of encrypting /boot and /boot/efi? What sensitive information could be found there?
I don't really know. Tamper-proofing. So nobody with physical access can substitute a kernel with a backdoor, and then get access to your oh-so-carefully encrypted partitions after you've booted into it. -- Bob Rogers http://www.rgrjr.com/
On 2023-03-29 02:15, Bob Rogers wrote:
From: "Carlos E. R." <robin.listas@telefonica.net> Date: Tue, 28 Mar 2023 22:04:08 +0200
On 2023-03-28 21:36, gebser@mousecar.com wrote: . . . > Have to ask: What's the point of encrypting /boot and /boot/efi? What > sensitive information could be found there?
I don't really know.
Tamper-proofing. So nobody with physical access can substitute a kernel with a backdoor, and then get access to your oh-so-carefully encrypted partitions after you've booted into it.
Yes, that seem obvious :-) -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
On 2023-03-29 13:02, Carlos E. R. wrote:
On 2023-03-29 02:15, Bob Rogers wrote:
From: "Carlos E. R." <robin.listas@telefonica.net> Date: Tue, 28 Mar 2023 22:04:08 +0200
On 2023-03-28 21:36, gebser@mousecar.com wrote: . . . > Have to ask: What's the point of encrypting /boot and /boot/efi? What > sensitive information could be found there?
I don't really know.
Tamper-proofing. So nobody with physical access can substitute a kernel with a backdoor, and then get access to your oh-so-carefully encrypted partitions after you've booted into it.
Yes, that seem obvious :-)
Now that I think, /boot/efi is not encrypted. Is it vulnerable? It is somewhat protected by the uefi key, though. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
On 3/28/23 8:15 PM, Bob Rogers wrote:
From: "Carlos E. R." <robin.listas@telefonica.net> Date: Tue, 28 Mar 2023 22:04:08 +0200
On 2023-03-28 21:36, gebser@mousecar.com wrote: . . . > Have to ask: What's the point of encrypting /boot and /boot/efi? What > sensitive information could be found there?
I don't really know.
Tamper-proofing. So nobody with physical access can substitute a kernel with a backdoor, and then get access to your oh-so-carefully encrypted partitions after you've booted into it.
That's a very good point. Looking at /boot files, there'd be plenty of opportunity for that for a malicious actor. I don't even know how I'd test or recover from that once I got my laptop back.
On Tue, Mar 28, 2023 at 12:42 PM Carlos E. R. <robin.listas@telefonica.net> wrote:
new laptop here, and I decided to install Leap 15.4 with full disk encryption, no LVM (a feature I wanted to have for years, so I'm happy). It asks for the password twice (contrary to my customs, I'm using plymouth). It asks once before grub loads. Well, ok, there is no separate /boot, so it has to read "/" which is encrypted. Nice. But after selecting the boot entry in grub, it asks again. Once, despite being 3 partitions ("/", "/boot" and swap). Ok.
doesnt the official opensuse pages state about the situation about double entry of passphrases. i have double passphrase questionaire as well with 15.4 fresh install via the propsed partition setup on a notebook. btrfs or something and the snapshot filesystem stuff and all. not expert though
On 2023-03-28 15:01, cagsm wrote:
On Tue, Mar 28, 2023 at 12:42 PM Carlos E. R. <robin.listas@telefonica.net> wrote:
new laptop here, and I decided to install Leap 15.4 with full disk encryption, no LVM (a feature I wanted to have for years, so I'm happy). It asks for the password twice (contrary to my customs, I'm using plymouth). It asks once before grub loads. Well, ok, there is no separate /boot, so it has to read "/" which is encrypted. Nice. But after selecting the boot entry in grub, it asks again. Once, despite being 3 partitions ("/", "/boot" and swap). Ok.
doesnt the official opensuse pages state about the situation about double entry of passphrases. i have double passphrase questionaire as well with 15.4 fresh install via the propsed partition setup on a notebook. btrfs or something and the snapshot filesystem stuff and all. not expert though
Ah! this is very interesting, thanks. Is there a reason YaST doesn't do this during install? Dangers perhaps? Well, this is something to add to my to-do list. -- Cheers / Saludos, Carlos E. R. (from Elesar, using openSUSE Leap 15.4)
On 2023-03-28 15:01, cagsm wrote:
On Tue, Mar 28, 2023 at 12:42 PM Carlos E. R. <robin.listas@telefonica.net> wrote:
new laptop here, and I decided to install Leap 15.4 with full disk encryption, no LVM (a feature I wanted to have for years, so I'm happy). It asks for the password twice (contrary to my customs, I'm using plymouth). It asks once before grub loads. Well, ok, there is no separate /boot, so it has to read "/" which is encrypted. Nice. But after selecting the boot entry in grub, it asks again. Once, despite being 3 partitions ("/", "/boot" and swap). Ok.
doesnt the official opensuse pages state about the situation about double entry of passphrases. i have double passphrase questionaire as well with 15.4 fresh install via the propsed partition setup on a notebook. btrfs or something and the snapshot filesystem stuff and all. not expert though
The article mentions having each partition with a different encryption key. Andrei thought I would have different passwords on each. The idea of doing that never occurred to me. Something must be eluding me: why having different password or keys for partitions in the same disk? -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
On Wed, Mar 29, 2023 at 2:11 PM Carlos E. R. <robin.listas@telefonica.net> wrote:
The article mentions having each partition with a different encryption key. Andrei thought I would have different passwords on each. The idea of doing that never occurred to me. Something must be eluding me: why having different password or keys for partitions in the same disk?
For the same reason you should have a different password for each resource on the same Internet. Because compromise of the password for one partition does not automatically allow access to other partitions.
On 2023-03-29 13:32, Andrei Borzenkov wrote:
On Wed, Mar 29, 2023 at 2:11 PM Carlos E. R. <robin.listas@telefonica.net> wrote:
The article mentions having each partition with a different encryption key. Andrei thought I would have different passwords on each. The idea of doing that never occurred to me. Something must be eluding me: why having different password or keys for partitions in the same disk?
For the same reason you should have a different password for each resource on the same Internet. Because compromise of the password for one partition does not automatically allow access to other partitions.
To me the resource is the computer. It is the same as the car that has three doors and an ignition, all using the same key. It is not more vulnerable. Anyway, the main partition holds a key that opens the other partitions. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
On 3/29/23 7:11 AM, Carlos E. R. wrote:
On 2023-03-28 15:01, cagsm wrote:
On Tue, Mar 28, 2023 at 12:42 PM Carlos E. R. <robin.listas@telefonica.net> wrote:
new laptop here, and I decided to install Leap 15.4 with full disk encryption, no LVM (a feature I wanted to have for years, so I'm happy). It asks for the password twice (contrary to my customs, I'm using plymouth). It asks once before grub loads. Well, ok, there is no separate /boot, so it has to read "/" which is encrypted. Nice. But after selecting the boot entry in grub, it asks again. Once, despite being 3 partitions ("/", "/boot" and swap). Ok.
doesnt the official opensuse pages state about the situation about double entry of passphrases. i have double passphrase questionaire as well with 15.4 fresh install via the propsed partition setup on a notebook. btrfs or something and the snapshot filesystem stuff and all. not expert though
The article mentions having each partition with a different encryption key. Andrei thought I would have different passwords on each. The idea of doing that never occurred to me. Something must be eluding me: why having different password or keys for partitions in the same disk?
The only downside to two identical passwords I can imagine is that an observer has two chances to see what you typed.
On 2023-03-29 15:23, gebser@mousecar.com wrote:
On 3/29/23 7:11 AM, Carlos E. R. wrote:
On 2023-03-28 15:01, cagsm wrote:
On Tue, Mar 28, 2023 at 12:42 PM Carlos E. R. <robin.listas@telefonica.net> wrote:
new laptop here, and I decided to install Leap 15.4 with full disk encryption, no LVM (a feature I wanted to have for years, so I'm happy). It asks for the password twice (contrary to my customs, I'm using plymouth). It asks once before grub loads. Well, ok, there is no separate /boot, so it has to read "/" which is encrypted. Nice. But after selecting the boot entry in grub, it asks again. Once, despite being 3 partitions ("/", "/boot" and swap). Ok.
doesnt the official opensuse pages state about the situation about double entry of passphrases. i have double passphrase questionaire as well with 15.4 fresh install via the propsed partition setup on a notebook. btrfs or something and the snapshot filesystem stuff and all. not expert though
The article mentions having each partition with a different encryption key. Andrei thought I would have different passwords on each. The idea of doing that never occurred to me. Something must be eluding me: why having different password or keys for partitions in the same disk?
The only downside to two identical passwords I can imagine is that an observer has two chances to see what you typed.
True. But with the procedure on the link above, the user only types it once, no matter if the partitions use the same password or not. The trick is: generate a random key in a file store that file in the first partition that is opened assign that key to the encrypted device If you have several partitions, the file, be it one or several, is stored in the first partition (/). So once they crack the first one, the rest of the disk can be opened. The file(s) is(are) also stored in initrd. (I still have not implemented this, too many things to do) The current method (implemented by YaST) is: - Enter password before grub loads. Where is that code stored, is it protected? It has to be outside of /boot (in root partition), so I assume it is in /boot/EFI, not encrypted. - grub loads, displays the menu, you choose an entry, boots starts. - plymouth intervenes and asks for the password (a second time for the user). Plymouth caches that password and tries it on the other partitions, so only asking once for it (which I find convenient). -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Content-ID: <39a95a12-7b82-24d9-802b-d6b2e6264346@Laicolasse.valinor> El 2023-03-28 a las 15:01 +0200, cagsm escribió:
On Tue, Mar 28, 2023 at 12:42 PM Carlos E. R. <...> wrote:
new laptop here, and I decided to install Leap 15.4 with full disk encryption, no LVM (a feature I wanted to have for years, so I'm happy). It asks for the password twice (contrary to my customs, I'm using plymouth). It asks once before grub loads. Well, ok, there is no separate /boot, so it has to read "/" which is encrypted. Nice. But after selecting the boot entry in grub, it asks again. Once, despite being 3 partitions ("/", "/boot" and swap). Ok.
doesnt the official opensuse pages state about the situation about double entry of passphrases. i have double passphrase questionaire as well with 15.4 fresh install via the propsed partition setup on a notebook. btrfs or something and the snapshot filesystem stuff and all. not expert though
I finally took a chance to do this, but it is not working for me. It is three partitions with the same password and the same key file. Creation: touch /.root.key chmod 600 /.root.key dd if=/dev/urandom of=/.root.key bs=1024 count=1 cryptsetup luksAddKey /dev/nvme0n1p3 /.root.key cryptsetup luksAddKey /dev/nvme0n1p4 /.root.key cryptsetup luksAddKey /dev/nvme0n1p2 /.root.key Check: Laicolasse:~ # ls -l /.root.key - -rw------- 1 root root 1024 Aug 20 18:32 /.root.key Laicolasse:~ # Laicolasse:~ # lsblk --output NAME,KNAME,RA,RM,RO,PARTFLAGS,SIZE,TYPE,FSTYPE,LABEL,PARTLABEL,PTTYPE,MOUNTPOINT,UUID,PARTUUID,WWN,MODEL,ALIGNMENT > /tmp/p NAME KNAME RA RM RO PARTFLAGS SIZE TYPE FSTYPE LABEL PARTLABEL PTTYPE MOUNTPOINT UUID PARTUUID WWN MODEL ALIGNMENT nvme0n1 nvme0n1 512 0 0 953.9G disk gpt eui.8ce38e1000956753 KBG5AZNT1T02 LA KIOXIA 0 ├─nvme0n1p1 nvme0n1p1 512 0 0 512M part vfat ESP gpt /boot/efi 3EBE-58A3 5a916363-34cb-4729-b825-8be7a4da7527 eui.8ce38e1000956753 0 ├─nvme0n1p2 nvme0n1p2 512 0 0 100G part crypto_LUKS gpt 43662ac8-d98d-4b1a-a483-0f16e06b419c 28066fb6-919c-4922-a9a7-b0333af002ef eui.8ce38e1000956753 0 │ └─cr-auto-1 dm-0 512 0 0 100G crypt ext4 Main / 858cc569-e2ae-4d12-adf6-3a06ade8281c 0 ├─nvme0n1p3 nvme0n1p3 512 0 0 40G part crypto_LUKS gpt d153e878-b32c-4a14-856e-cbc8c6101280 a87889fc-3ecf-43d3-9699-92967fbfe75f eui.8ce38e1000956753 0 │ └─cr-auto-2 dm-2 512 0 0 40G crypt swap Swap [SWAP] 55db7bff-8d71-4862-8e31-1c2a7fd52c9d 0 ├─nvme0n1p4 nvme0n1p4 512 0 0 716.8G part crypto_LUKS gpt 253d3fd9-7f53-465a-85f9-1900b6b87a3c 08d2166d-aa90-46db-bc60-440c6005d3c3 eui.8ce38e1000956753 0 │ └─cr-auto-3 dm-1 512 0 0 716.8G crypt xfs Home /home 149fc869-e7e8-46c8-b6c9-2a773d49880e 0 ├─nvme0n1p5 nvme0n1p5 512 0 0 50G part ext4 Beta gpt /Other c2c74f2c-abc4-4f3b-b55e-1afc82dfeedf f6c33ec1-8abe-439a-9ce1-7f20be8914b5 eui.8ce38e1000956753 0 └─nvme0n1p6 nvme0n1p6 512 0 0 25G part swap PlainSwap gpt 198840e4-54cd-4d2d-83ac-b5009b01f5e0 b98447ab-603a-4369-a71d-c4e1273bc511 eui.8ce38e1000956753 0 Laicolasse:~ # cat /etc/crypttab # nvme0n1p4, Main # nvme0n1p3 Swap # nvme0n1p2 Home cr-auto-3 UUID=253d3fd9-7f53-465a-85f9-1900b6b87a3c /.root.key cr-auto-2 UUID=d153e878-b32c-4a14-856e-cbc8c6101280 /.root.key cr-auto-1 UUID=43662ac8-d98d-4b1a-a483-0f16e06b419c /.root.key x-initrd.attach Laicolasse:~ # The "x-initrd.attach" keyword was already there. The one that I'm getting prompted to enter the password for is cr-auto-3, swap partition. I tried adding x-initrd.attach to the second line, no difference. Laicolasse:~ # cat /etc/dracut.conf.d/99-root-key.conf install_items+=" /.root.key " Laicolasse:~ # Laicolasse:~ # tail /etc/permissions.local # All disk partitions encryption <https://en.opensuse.org/SDB:Encrypted_root_file_system#Avoiding_to_type_the_passphrase_twice_in_Leap_and_Tumbleweed> /boot/ root:root 750 Laicolasse:~ # dracut -f Also did mkinitrd. Ideas? If some data is missing, just ask. Using Leap 15.5. - -- Cheers Carlos E. R. (from openSUSE 15.5 (Laicolasse)) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCZOJXdBwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVRtEAnRNV226d1rk/4slt8mTZ IehFNrp2AJ0eU12AiGIHh0IJVvMJUOf//l+miA== =XjF7 -----END PGP SIGNATURE-----
On Mon, Aug 21, 2023 at 4:59 AM Carlos E. R. <robin.listas@gmx.es> wrote:
Ideas?
Low hanging fruits. Show the actual /etc/crypttab from initrd. lsinitrd /boot/initrd-xxx /etc/crypttab You may also want to verify that /.root.key is actually present in initrd and its content is the right one.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2023-08-21 a las 10:27 +0300, Andrei Borzenkov escribió:
On Mon, Aug 21, 2023 at 4:59 AM Carlos E. R. <...> wrote:
Ideas?
Low hanging fruits.
{chuckle} :-)
Show the actual /etc/crypttab from initrd.
lsinitrd /boot/initrd-xxx /etc/crypttab
Laicolasse:~ # lsinitrd /boot/initrd-5.14.21-150500.55.12-default /etc/crypttab cr-auto-1 /dev/disk/by-uuid/43662ac8-d98d-4b1a-a483-0f16e06b419c /.root.key x-initrd.attach Laicolasse:~ # Wow. How come the rest "got removed"?
You may also want to verify that /.root.key is actually present in initrd and its content is the right one.
No, that one is included and correct. Laicolasse:~ # lsinitrd /boot/initrd-5.14.21-150500.55.12-default /.root.key > p Laicolasse:~ # cmp p /.root.key Laicolasse:~ # Ok, how can I convince mkinitrd or dracut to actually include the actual contents of crypttab? - -- Cheers Carlos E. R. (from openSUSE 15.5 (Laicolasse)) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCZONHIxwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfV7GAAnjh2fMvr3ne1nQ6bsn7U KUp2H996AJ9rX1xuh+w1oF+hbc49708uemO4GQ== =/N1j -----END PGP SIGNATURE-----
On Mon, Aug 21, 2023 at 2:20 PM Carlos E. R. <robin.listas@gmx.es> wrote:
Laicolasse:~ # lsinitrd /boot/initrd-5.14.21-150500.55.12-default /etc/crypttab cr-auto-1 /dev/disk/by-uuid/43662ac8-d98d-4b1a-a483-0f16e06b419c /.root.key x-initrd.attach Laicolasse:~ #
Wow. How come the rest "got removed"?
Try adding x-initrd.mount as an option in /etc/fstab for. And you still need x-initrd.attach for those lines you want to be mounted in initrd.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Content-ID: <1bb6fd81-eee8-9325-e72d-29650d3ad19a@Laicolasse.valinor> El 2023-08-21 a las 15:32 +0300, Andrei Borzenkov escribió:
On Mon, Aug 21, 2023 at 2:20 PM Carlos E. R. <robin.listas@gmx.es> wrote:
Laicolasse:~ # lsinitrd /boot/initrd-5.14.21-150500.55.12-default /etc/crypttab cr-auto-1 /dev/disk/by-uuid/43662ac8-d98d-4b1a-a483-0f16e06b419c /.root.key x-initrd.attach Laicolasse:~ #
Wow. How come the rest "got removed"?
Try adding x-initrd.mount as an option in /etc/fstab for. And you still need x-initrd.attach for those lines you want to be mounted in initrd.
The later worked; at least the lines are on the initrd. I will try rebooting now. [...] No, I'm still prompted twice for the pasword, once by grub, and another by plymouth. Current status: Laicolasse:~ # lsinitrd /boot/initrd-5.14.21-150500.55.12-default /etc/crypttab cr-auto-3 /dev/disk/by-uuid/253d3fd9-7f53-465a-85f9-1900b6b87a3c /.root.key x-initrd.attach cr-auto-2 /dev/disk/by-uuid/d153e878-b32c-4a14-856e-cbc8c6101280 /.root.key x-initrd.attach cr-auto-1 /dev/disk/by-uuid/43662ac8-d98d-4b1a-a483-0f16e06b419c /.root.key x-initrd.attach Laicolasse:~ # Which corresponds to: nvme0n1p4 home nvme0n1p3 swap nvme0n1p2 / Laicolasse:~ # head /etc/fstab LABEL=Main / ext4 defaults 0 1 LABEL=Home /home xfs defaults,x-initrd.mount 0 0 LABEL=ESP /boot/efi vfat utf8 0 2 LABEL=Swap swap swap defaults,x-initrd.mount 0 0 LABEL=Beta /Other ext4 data=ordered 0 2 Laicolasse:~ # Ok, I see a mistake in the /etc/crypttab file, home should have /.root.key x-initrd.attach. But I tried with them all How can I check if the key file was actually added to the encrypted devices? I can do: cryptsetup luksDump /dev/nvme0n1p2 but I do not know what each key is. Or at least the key size. On /dev/nvme0n1p2 I see one key slot has Key material offset: 8 and the second key has Key material offset: 512 But /dev/nvme0n1p4 has only one key slot, so it is probably missing the key file. I'll add it again. [...] done. And Swap has 3 keys, go figure. Maybe I goofed and added the key fille twice to the same partition. Key material offset: 8 Key material offset: 512 Key material offset: 1016 Ah, I see. Not size, but an index, and offset in the array. Ah. So I should delete slot 3. Ok, done. Laicolasse:~/Telcontar/notas/crypto # cryptsetup luksKillSlot /dev/nvme0n1p3 2 Enter any remaining passphrase: Laicolasse:~/Telcontar/notas/crypto # [...] Booted, et voilá! It worked :-) - -- Cheers Carlos E. R. (from openSUSE 15.5 (Laicolasse)) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCZONvKBwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVh2UAnj0YRvRTVZJgyiOdPpJb s7CNJ5p0AJ941MkMx8Zn/ovyprfkmJSbHGPJLQ== =HiTP -----END PGP SIGNATURE-----
On 2023-08-21 10:05, Carlos E. R. wrote: ...
How can I check if the key file was actually added to the encrypted devices? I can do:
cryptsetup luksDump /dev/nvme0n1p2
but I do not know what each key is. Or at least the key size.
On /dev/nvme0n1p2 I see one key slot has
Key material offset: 8
and the second key has
Key material offset: 512
But /dev/nvme0n1p4 has only one key slot, so it is probably missing the key file. I'll add it again. [...] done.
And Swap has 3 keys, go figure. Maybe I goofed and added the key fille twice to the same partition.
Key material offset: 8 Key material offset: 512 Key material offset: 1016
Ah, I see. Not size, but an index, and offset in the array. Ah. So I should delete slot 3.
Ok, done.
Laicolasse:~/Telcontar/notas/crypto # cryptsetup luksKillSlot /dev/nvme0n1p3 2 Enter any remaining passphrase: Laicolasse:~/Telcontar/notas/crypto #
[...]
Booted, et voilá! It worked :-)
Somehow, restore from hibernation, aka suspend to disk, is not working. It silently boots instead, after I enter the decryption password on Grub prompt. Next step will be attempting it, and examine journal on next boot. I have not tried for a few days, so the log entry pertaining to the failure I don't know where it is. [...] I see this in the log of the next boot just when I hoped it would restore from hibernation: Aug 27 23:19:04 Laicolasse swapon[860]: swapon: /dev/mapper/cr-auto-2: software suspend data detected. Rewriting the swap signature. The kernel boot line at the start of the journal is: Aug 27 23:18:58 Laicolasse kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-5.14.21-150500.55.19-default root=UUID=858cc569-e2ae-4d12-adf6-3a06ade8281c security=apparmor no_console_suspend splash=silent resume= preempt=full quiet mitigations=auto Laicolasse:~ # l /dev/mapper/cr-auto-2 lrwxrwxrwx 1 root root 7 Aug 28 13:57 /dev/mapper/cr-auto-2 -> ../dm-1 Laicolasse:~ # file -s /dev/mapper/cr-auto-2 /dev/mapper/cr-auto-2: symbolic link to ../dm-1 Laicolasse:~ # file -s /dev/mapper/cr-auto-2/ /dev/mapper/cr-auto-2/: cannot open `/dev/mapper/cr-auto-2/' (Not a directory) Laicolasse:~ # file -s /dev/mapper/cr-auto-2/ /dev/mapper/cr-auto-2/: cannot open `/dev/mapper/cr-auto-2/' (Not a directory) Laicolasse:~ # file -s /dev/dm-1 /dev/dm-1: Linux/i386 swap file (new style), version 1 (4K pages), size 10485247 pages, LABEL=Swap, UUID=55db7bff-8d71-4862-8e31-1c2a7fd52c9d Laicolasse:~ # l /dev/disk/by-label/Swap lrwxrwxrwx 1 root root 10 Aug 28 13:57 /dev/disk/by-label/Swap -> ../../dm-1 Laicolasse:~ # Ideas? -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.5 (Laicolasse))
On 28.08.2023 18:14, Carlos E. R. wrote:
Somehow, restore from hibernation, aka suspend to disk, is not working. It silently boots instead, after I enter the decryption password on Grub prompt.
Next step will be attempting it, and examine journal on next boot. I have not tried for a few days, so the log entry pertaining to the failure I don't know where it is.
[...]
I see this in the log of the next boot just when I hoped it would restore from hibernation:
Aug 27 23:19:04 Laicolasse swapon[860]: swapon: /dev/mapper/cr-auto-2: software suspend data detected. Rewriting the swap signature.
It is already too late. Add printk.devkmsg=on to kernel parameters and provide dmesh output after resume.
The kernel boot line at the start of the journal is:
Aug 27 23:18:58 Laicolasse kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-5.14.21-150500.55.19-default root=UUID=858cc569-e2ae-4d12-adf6-3a06ade8281c security=apparmor no_console_suspend splash=silent resume= preempt=full quiet mitigations=auto
Laicolasse:~ # l /dev/mapper/cr-auto-2 lrwxrwxrwx 1 root root 7 Aug 28 13:57 /dev/mapper/cr-auto-2 -> ../dm-1 Laicolasse:~ # file -s /dev/mapper/cr-auto-2 /dev/mapper/cr-auto-2: symbolic link to ../dm-1 Laicolasse:~ # file -s /dev/mapper/cr-auto-2/ /dev/mapper/cr-auto-2/: cannot open `/dev/mapper/cr-auto-2/' (Not a directory) Laicolasse:~ # file -s /dev/mapper/cr-auto-2/ /dev/mapper/cr-auto-2/: cannot open `/dev/mapper/cr-auto-2/' (Not a directory) Laicolasse:~ # file -s /dev/dm-1 /dev/dm-1: Linux/i386 swap file (new style), version 1 (4K pages), size 10485247 pages, LABEL=Swap, UUID=55db7bff-8d71-4862-8e31-1c2a7fd52c9d
Laicolasse:~ # l /dev/disk/by-label/Swap lrwxrwxrwx 1 root root 10 Aug 28 13:57 /dev/disk/by-label/Swap -> ../../dm-1 Laicolasse:~ #
Ideas?
On 2023-08-28 13:32, Andrei Borzenkov wrote:
On 28.08.2023 18:14, Carlos E. R. wrote:
Somehow, restore from hibernation, aka suspend to disk, is not working. It silently boots instead, after I enter the decryption password on Grub prompt.
Next step will be attempting it, and examine journal on next boot. I have not tried for a few days, so the log entry pertaining to the failure I don't know where it is.
[...]
I see this in the log of the next boot just when I hoped it would restore from hibernation:
Aug 27 23:19:04 Laicolasse swapon[860]: swapon: /dev/mapper/cr-auto-2: software suspend data detected. Rewriting the swap signature.
It is already too late. Add
printk.devkmsg=on
to kernel parameters and provide dmesh output after resume. https://susepaste.org/b607972c1e8a https://paste.opensuse.org/b607972c1e8a
AFAIK, it doesn't even attempt to resume :-? -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.5 (Laicolasse))
On Mon, 28 Aug 2023 17:02:39 -0400, "Carlos E. R." <robin.listas@gmx.es> wrote:
On 2023-08-28 13:32, Andrei Borzenkov wrote:
It is already too late. Add
printk.devkmsg=on
to kernel parameters and provide dmesh output after resume.
susepaste.org is obsolete.
BTW, your dmesg shows that the Bluetooth BNEP protocol is initialized: $ grep -Ei 'bluetooth|bnep' carlos-dmesg [ 8.120666] thinkpad_acpi: rfkill switch tpacpi_bluetooth_sw: radio is unblocked [ 9.255844] Bluetooth: Core ver 2.22 [ 9.255879] NET: Registered PF_BLUETOOTH protocol family [ 9.255881] Bluetooth: HCI device and connection manager initialized [ 9.255884] Bluetooth: HCI socket layer initialized [ 9.255886] Bluetooth: L2CAP socket layer initialized [ 9.255890] Bluetooth: SCO socket layer initialized [ 9.326347] Bluetooth: BNEP (Ethernet Emulation) ver 1.3 [ 9.326351] Bluetooth: BNEP filters: protocol multicast [ 9.326354] Bluetooth: BNEP socket layer initialized [ 12.579632] Bluetooth: hci0: Device setup in 3237056 usecs [ 12.579641] Bluetooth: hci0: HCI Enhanced Setup Synchronous Connection command is advertised, but not supported. [ 12.641413] Bluetooth: hci0: AOSP extensions version v1.00 [ 12.641419] Bluetooth: hci0: AOSP quality report is supported [ 12.641551] Bluetooth: MGMT ver 1.22 [ 26.507068] Bluetooth: RFCOMM TTY layer initialized [ 26.507074] Bluetooth: RFCOMM socket layer initialized [ 26.507078] Bluetooth: RFCOMM ver 1.11 Question: Is there a way to download the pasted text from paste.opensuse.org? I had to copy and paste it into a file. The "Raw" link did not work. 'elinks -dump URL' got the page, but without the pasted contents. -- Robert Webb
On Mon, 28 Aug 2023 23:48:06 +0000 (UTC) Robert Webb via openSUSE Users <users@lists.opensuse.org> wrote:
Question: Is there a way to download the pasted text from paste.opensuse.org? I had to copy and paste it into a file. The "Raw" link did not work. 'elinks -dump URL' got the page, but without the pasted contents.
The raw link works for me and displays https://s3.opensuse-project.net/paste-o-o/12nuvsnsjw2vd1jtr2dat1sn3wog?response-content-disposition=inline%3B%20filename%3D%22f8130a6f28fca9e0710246a5c84c3619.txt%22%3B%20filename%2A%3DUTF-8%27%27f8130a6f28fca9e0710246a5c84c3619.txt&response-content-type=text%2Fplain&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=YI5KOnADj6WdQSae%2F20230829%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20230829T094057Z&X-Amz-Expires=300&X-Amz-SignedHeaders=host&X-Amz-Signature=e20fb6adffa078e7b9ab4a66901a6e9491a7defb29edbc55a5733fd6b72bb008 I can then 'save page as' to download it or whatever else.
-- Robert Webb
Dne úterý 29. srpna 2023 11:45:33 CEST, Dave Howorth napsal(a):
On Mon, 28 Aug 2023 23:48:06 +0000 (UTC) Robert Webb via openSUSE Users wrote:
Question: Is there a way to download the pasted text from paste.opensuse.org? I had to copy and paste it into a file. The "Raw" link did not work. 'elinks -dump URL' got the page, but without the pasted contents.
The raw link works for me and displays https://s3.opensuse-project.net/paste-o-o/12nuvsnsjw2vd1jtr2dat1sn3wog?respo nse-content-disposition=inline%3B%20filename%3D%22f8130a6f28fca9e0710246a5c8 4c3619.txt%22%3B%20filename%2A%3DUTF-8%27%27f8130a6f28fca9e0710246a5c84c3619 .txt&response-content-type=text%2Fplain&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-A mz-Credential=YI5KOnADj6WdQSae%2F20230829%2Fus-east-1%2Fs3%2Faws4_request&X- Amz-Date=20230829T094057Z&X-Amz-Expires=300&X-Amz-SignedHeaders=host&X-Amz-S ignature=e20fb6adffa078e7b9ab4a66901a6e9491a7defb29edbc55a5733fd6b72bb008 I can then 'save page as' to download it or whatever else.
This indeed works, but only for limited time. The link expires pretty soon (but I didn't do any measurements). -- Vojtěch Zeisek https://trapa.cz/ Komunita openSUSE GNU/Linuxu Community of the openSUSE GNU/Linux https://www.opensuse.org/
On Tue, 29 Aug 2023 11:50:47 +0200 Vojtěch Zeisek <vojtech.zeisek@opensuse.org> wrote:
Dne úterý 29. srpna 2023 11:45:33 CEST, Dave Howorth napsal(a):
On Mon, 28 Aug 2023 23:48:06 +0000 (UTC) Robert Webb via openSUSE Users wrote:
Question: Is there a way to download the pasted text from paste.opensuse.org? I had to copy and paste it into a file. The "Raw" link did not work. 'elinks -dump URL' got the page, but without the pasted contents.
The raw link works for me and displays https://s3.opensuse-project.net/paste-o-o/12nuvsnsjw2vd1jtr2dat1sn3wog?respo nse-content-disposition=inline%3B%20filename%3D%22f8130a6f28fca9e0710246a5c8 4c3619.txt%22%3B%20filename%2A%3DUTF-8%27%27f8130a6f28fca9e0710246a5c84c3619 .txt&response-content-type=text%2Fplain&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-A mz-Credential=YI5KOnADj6WdQSae%2F20230829%2Fus-east-1%2Fs3%2Faws4_request&X- Amz-Date=20230829T094057Z&X-Amz-Expires=300&X-Amz-SignedHeaders=host&X-Amz-S ignature=e20fb6adffa078e7b9ab4a66901a6e9491a7defb29edbc55a5733fd6b72bb008 I can then 'save page as' to download it or whatever else.
This indeed works, but only for limited time. The link expires pretty soon (but I didn't do any measurements).
Well it's still there now. I'm not sure what you call 'pretty soon'?
Dne úterý 29. srpna 2023 12:29:38 CEST, Dave Howorth napsal(a):
On Tue, 29 Aug 2023 11:50:47 +0200 Vojtěch Zeisek wrote:
Dne úterý 29. srpna 2023 11:45:33 CEST, Dave Howorth napsal(a):
On Mon, 28 Aug 2023 23:48:06 +0000 (UTC)
Robert Webb via openSUSE Users wrote:
Question: Is there a way to download the pasted text from paste.opensuse.org? I had to copy and paste it into a file. The "Raw" link did not work. 'elinks -dump URL' got the page, but without the pasted contents.
The raw link works for me and displays https://s3.opensuse-project.net/paste-o-o/12nuvsnsjw2vd1jtr 2dat1sn3wog?response-content-disposition=inline%3B%20filena me%3D%22f8130a6f28fca9e0710246a5c84c3619.txt%22%3B%20filena me%2A%3DUTF-8%27%27f8130a6f28fca9e0710246a5c84c3619.txt&res ponse-content-type=text%2Fplain&X-Amz-Algorithm=AWS4-HMAC-S HA25&X-Amz-Credential=YI5KOnADj6WdQSae%2F20230829%2Fus-east -1%2Fs3%2Faws4_request&X-Amz-Date=20230829T094057Z&X-Amz-Ex pires=300&X-Amz-SignedHeaders=host&X-Amz-Signature=e20fb6ad ffa078e7b9ab4a66901a6e9491a7defb29edbc55a5733fd6b72bb008 I can then 'save page as' to download it or whatever else.
This indeed works, but only for limited time. The link expires pretty soon (but I didn't do any measurements).
Well it's still there now. I'm not sure what you call 'pretty soon'?
If I remember correctly, it expired within ca. an hour or so, or soon after I closed the window. Well, the whole URL contains "...Amz-Expires=300&X..." which does suggest something. Interestingly, when I again open my saved paste, I get different download link. -- Vojtěch Zeisek https://trapa.cz/ Komunita openSUSE GNU/Linuxu Community of the openSUSE GNU/Linux https://www.opensuse.org/
On Tue, 29 Aug 2023 13:31:48 +0200, Vojtěch Zeisek <vojtech.zeisek@opensuse.org> wrote:
Dne úterý 29. srpna 2023 12:29:38 CEST, Dave Howorth napsal(a):
On Tue, 29 Aug 2023 11:50:47 +0200 Vojtěch Zeisek wrote:
Dne úterý 29. srpna 2023 11:45:33 CEST, Dave Howorth napsal(a):
On Mon, 28 Aug 2023 23:48:06 +0000 (UTC)
Robert Webb via openSUSE Users wrote:
Question: Is there a way to download the pasted text from paste.opensuse.org? I had to copy and paste it into a file. The "Raw" link did not work. 'elinks -dump URL' got the page, but without the pasted contents.
The raw link works for me and displays https://s3.opensuse-project.net/paste-o-o/12nuvsnsjw2vd1jtr 2dat1sn3wog?response-content-disposition=inline%3B%20filena me%3D%22f8130a6f28fca9e0710246a5c84c3619.txt%22%3B%20filena me%2A%3DUTF-8%27%27f8130a6f28fca9e0710246a5c84c3619.txt&res ponse-content-type=text%2Fplain&X-Amz-Algorithm=AWS4-HMAC-S HA25&X-Amz-Credential=YI5KOnADj6WdQSae%2F20230829%2Fus-east -1%2Fs3%2Faws4_request&X-Amz-Date=20230829T094057Z&X-Amz-Ex pires=300&X-Amz-SignedHeaders=host&X-Amz-Signature=e20fb6ad ffa078e7b9ab4a66901a6e9491a7defb29edbc55a5733fd6b72bb008 I can then 'save page as' to download it or whatever else.
This indeed works, but only for limited time. The link expires pretty soon (but I didn't do any measurements).
Well it's still there now. I'm not sure what you call 'pretty soon'?
If I remember correctly, it expired within ca. an hour or so, or soon after I closed the window. Well, the whole URL contains "...Amz-Expires=300&X..." which does suggest something. Interestingly, when I again open my saved paste, I get different download link.
I can confirm this. Thank you both. Each time the page [1] is loaded, yes, the "Raw" link is different, containing a new timestamp and signature. The "Raw" link on an old page does not work (I don't know the timeout value either), but the link on a freshly loaded, or refreshed, page does work. BTW, using wget to download the "Raw" URL creates a "beautiful" file name: 12nuvsnsjw2vd1jtr2dat1sn3wog?response-content-disposition=inline; filename="f8130a6f28fca9e0710246a5c84c3619.txt"; filename*=UTF-8''f8130a6f28fca9e0710246a5c84c3619.txt&response-content-type=text%2Fplain&X-Amz-Algorithm=AWS4-HMAC-SHA256 [1] https://paste.opensuse.org/b607972c1e8a -- Robert Webb
On 2023-08-28 19:48, Robert Webb via openSUSE Users wrote:
On Mon, 28 Aug 2023 17:02:39 -0400, "Carlos E. R." <robin.listas@gmx.es> wrote:
On 2023-08-28 13:32, Andrei Borzenkov wrote:
It is already too late. Add
printk.devkmsg=on
to kernel parameters and provide dmesh output after resume.
susepaste.org is obsolete.
I know that one of the two links work, but I did not want to try which using my limited bandwidth (5 gigs), so I pasted both ;-)
BTW, your dmesg shows that the Bluetooth BNEP protocol is initialized:
$ grep -Ei 'bluetooth|bnep' carlos-dmesg [ 8.120666] thinkpad_acpi: rfkill switch tpacpi_bluetooth_sw: radio is unblocked [ 9.255844] Bluetooth: Core ver 2.22 [ 9.255879] NET: Registered PF_BLUETOOTH protocol family [ 9.255881] Bluetooth: HCI device and connection manager initialized [ 9.255884] Bluetooth: HCI socket layer initialized [ 9.255886] Bluetooth: L2CAP socket layer initialized [ 9.255890] Bluetooth: SCO socket layer initialized [ 9.326347] Bluetooth: BNEP (Ethernet Emulation) ver 1.3 [ 9.326351] Bluetooth: BNEP filters: protocol multicast [ 9.326354] Bluetooth: BNEP socket layer initialized [ 12.579632] Bluetooth: hci0: Device setup in 3237056 usecs [ 12.579641] Bluetooth: hci0: HCI Enhanced Setup Synchronous Connection command is advertised, but not supported. [ 12.641413] Bluetooth: hci0: AOSP extensions version v1.00 [ 12.641419] Bluetooth: hci0: AOSP quality report is supported [ 12.641551] Bluetooth: MGMT ver 1.22 [ 26.507068] Bluetooth: RFCOMM TTY layer initialized [ 26.507074] Bluetooth: RFCOMM socket layer initialized [ 26.507078] Bluetooth: RFCOMM ver 1.11
Curious. The WiFi was active. I failed to see how to connect to BT network on the userland tools in XFCE.
Question: Is there a way to download the pasted text from paste.opensuse.org? I had to copy and paste it into a file. The "Raw" link did not work. 'elinks -dump URL' got the page, but without the pasted contents.
Raw should work. Perhaps there is a problem, the site was reworked. Maybe I can try in a day or two. -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.5 (Laicolasse))
On Tue, 29 Aug 2023 07:55:53 -0400, "Carlos E. R." <robin.listas@gmx.es> wrote:
On 2023-08-28 19:48, Robert Webb via openSUSE Users wrote:
Question: Is there a way to download the pasted text from paste.opensuse.org? I had to copy and paste it into a file. The "Raw" link did not work. 'elinks -dump URL' got the page, but without the pasted contents.
Raw should work. Perhaps there is a problem, the site was reworked. Maybe I can try in a day or two.
The "Raw" link includes a timestamp. The page just needed a reload for the link to work. -- Robert Webb
On 2023-08-30 20:04, Robert Webb via openSUSE Users wrote:
On Tue, 29 Aug 2023 07:55:53 -0400, "Carlos E. R." <robin.listas@gmx.es> wrote:
On 2023-08-28 19:48, Robert Webb via openSUSE Users wrote:
Question: Is there a way to download the pasted text from paste.opensuse.org? I had to copy and paste it into a file. The "Raw" link did not work. 'elinks -dump URL' got the page, but without the pasted contents.
Raw should work. Perhaps there is a problem, the site was reworked. Maybe I can try in a day or two.
The "Raw" link includes a timestamp. The page just needed a reload for the link to work.
I have no idea why it is done that way, why not a static link. -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.5 (Laicolasse))
On Wed, 30 Aug 2023 21:50:12 -0400 "Carlos E. R." <robin.listas@gmx.es> wrote:
On 2023-08-30 20:04, Robert Webb via openSUSE Users wrote:
On Tue, 29 Aug 2023 07:55:53 -0400, "Carlos E. R." <robin.listas@gmx.es> wrote:
On 2023-08-28 19:48, Robert Webb via openSUSE Users wrote:
Question: Is there a way to download the pasted text from paste.opensuse.org? I had to copy and paste it into a file. The "Raw" link did not work. 'elinks -dump URL' got the page, but without the pasted contents.
Raw should work. Perhaps there is a problem, the site was reworked. Maybe I can try in a day or two.
The "Raw" link includes a timestamp. The page just needed a reload for the link to work.
I have no idea why it is done that way, why not a static link.
Because the work flow of the system is evidently silly. It seems it makes a copy of the 'raw' content to serve and therefore wants to discard this extra copy so as not to fill up wherever it lives. Why it can't simply serve the original data it is displaying in a fancy way is beyond my pay grade. I can understand why it doesn't want to expose the original data to the intertubes but still.
On Tue, Aug 29, 2023 at 12:13 AM Carlos E. R. <robin.listas@gmx.es> wrote:
On 2023-08-28 13:32, Andrei Borzenkov wrote:
On 28.08.2023 18:14, Carlos E. R. wrote:
Somehow, restore from hibernation, aka suspend to disk, is not working. It silently boots instead, after I enter the decryption password on Grub prompt.
Next step will be attempting it, and examine journal on next boot. I have not tried for a few days, so the log entry pertaining to the failure I don't know where it is.
[...]
I see this in the log of the next boot just when I hoped it would restore from hibernation:
Aug 27 23:19:04 Laicolasse swapon[860]: swapon: /dev/mapper/cr-auto-2: software suspend data detected. Rewriting the swap signature.
It is already too late. Add
printk.devkmsg=on
to kernel parameters and provide dmesh output after resume. https://susepaste.org/b607972c1e8a https://paste.opensuse.org/b607972c1e8a
AFAIK, it doesn't even attempt to resume :-?
The logs in initrd stop as soon as journald is loaded so systemd probably switches to journal. Could you also show journal outputs, both for the current and for the previous boots? If the system fails (or skips) resume, any interesting message should be in the current journal. OTOH if the system did resume, then any kernel messages before resuming would be lost as well (replaced by the message buffer in hibernation image).
On 2023-08-29 05:35, Andrei Borzenkov wrote:
On Tue, Aug 29, 2023 at 12:13 AM Carlos E. R. <> wrote:
On 2023-08-28 13:32, Andrei Borzenkov wrote:
On 28.08.2023 18:14, Carlos E. R. wrote:
Somehow, restore from hibernation, aka suspend to disk, is not working. It silently boots instead, after I enter the decryption password on Grub prompt.
Next step will be attempting it, and examine journal on next boot. I have not tried for a few days, so the log entry pertaining to the failure I don't know where it is.
[...]
I see this in the log of the next boot just when I hoped it would restore from hibernation:
Aug 27 23:19:04 Laicolasse swapon[860]: swapon: /dev/mapper/cr-auto-2: software suspend data detected. Rewriting the swap signature.
It is already too late. Add
printk.devkmsg=on
to kernel parameters and provide dmesh output after resume. https://susepaste.org/b607972c1e8a https://paste.opensuse.org/b607972c1e8a
AFAIK, it doesn't even attempt to resume :-?
The logs in initrd stop as soon as journald is loaded so systemd probably switches to journal. Could you also show journal outputs, both for the current and for the previous boots? If the system fails (or skips) resume, any interesting message should be in the current journal.
OTOH if the system did resume, then any kernel messages before resuming would be lost as well (replaced by the message buffer in hibernation image).
Nono, it did not resume. I use "systemctl hibernate", wait till it powers down, press the power button to power up (hoping to restore), get the grub prompt for the encryption password, wait a minute or two, and I get the login prompt. It is a full login, not a restore. Then I get that log I pasted. The log "should" contain the somehow failed attempt to restore from swap, but I can not see it. That log was obtained with dmesg, so that's the current session when it was made. These are the last sessions journalctl knows about: -6 fef617382f50477b82cf1c44d9cfd0e9 Sun 2023-08-27 13:23:55 CEST—Sun 2023-08-27 14:48:39 CEST -5 1d49fbf7286a4833a88725dbc8db9eb8 Sun 2023-08-27 20:45:33 CEST—Sun 2023-08-27 21:01:04 CEST -4 37a8a03535684c028922c6773f0c7eeb Sun 2023-08-27 23:18:58 CEST—Sun 2023-08-27 23:55:07 CEST -3 de2beed4877c466d9d2162238a68bb14 Mon 2023-08-28 03:08:51 CEST—Mon 2023-08-28 03:41:15 CEST -2 88e4ca96f94d4b059871b8d62ca91f77 Mon 2023-08-28 13:57:46 CEST—Mon 2023-08-28 22:41:30 CEST -1 7393c4e1f22c4308b3933cafbbcb8629 Mon 2023-08-28 22:43:59 CEST—Mon 2023-08-28 23:14:26 CEST 0 b23744d28ec84ff1ac8bd7e3ffc1dfab Tue 2023-08-29 13:46:38 CEST—Tue 2023-08-29 14:06:39 CEST dmesg file: -rw-r--r-- 1 root root 87340 Aug 28 22:47 boot_to_study_after.dmesg.txt So #-1 above should be the same session as dmesg: Aug 28 22:43:59 Laicolasse kernel: Linux version 5.14.21-150500.55.19-default (geeko@buildhost) (gcc (SUSE Linux) 7.5.0, GNU ld (GNU Binutils; SUSE Linux Enterprise 1> Aug 28 22:43:59 Laicolasse kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-5.14.21-150500.55.19-default root=UUID=858cc569-e2ae-4d12-adf6-3a06ade8281c security=apparmo> #-2 is when I when I run the hibernate command. Aug 28 22:41:30 Laicolasse.valinor systemd-sleep[20384]: Entering sleep state 'hibernate'... #1 Pasted as: https://susepaste.org/2a3ea4bbdcba https://paste.opensuse.org/2a3ea4bbdcba Link is also in your clipboard. (till X start up, I edited out the rest) If you want another journal, it is easy enough to paste them. -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.5 (Laicolasse))
On 2023-08-28 11:14, Carlos E. R. wrote:
On 2023-08-21 10:05, Carlos E. R. wrote:
...
[...]
Booted, et voilá! It worked :-)
Somehow, restore from hibernation, aka suspend to disk, is not working. It silently boots instead, after I enter the decryption password on Grub prompt.
Next step will be attempting it, and examine journal on next boot. I have not tried for a few days, so the log entry pertaining to the failure I don't know where it is.
[...]
I see this in the log of the next boot just when I hoped it would restore from hibernation:
Aug 27 23:19:04 Laicolasse swapon[860]: swapon: /dev/mapper/cr-auto-2: software suspend data detected. Rewriting the swap signature.
The kernel boot line at the start of the journal is:
Aug 27 23:18:58 Laicolasse kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-5.14.21-150500.55.19-default root=UUID=858cc569-e2ae-4d12-adf6-3a06ade8281c security=apparmor no_console_suspend splash=silent resume= preempt=full quiet mitigations=auto
Laicolasse:~ # l /dev/mapper/cr-auto-2 lrwxrwxrwx 1 root root 7 Aug 28 13:57 /dev/mapper/cr-auto-2 -> ../dm-1 Laicolasse:~ # file -s /dev/mapper/cr-auto-2 /dev/mapper/cr-auto-2: symbolic link to ../dm-1 Laicolasse:~ # file -s /dev/mapper/cr-auto-2/ /dev/mapper/cr-auto-2/: cannot open `/dev/mapper/cr-auto-2/' (Not a directory) Laicolasse:~ # file -s /dev/mapper/cr-auto-2/ /dev/mapper/cr-auto-2/: cannot open `/dev/mapper/cr-auto-2/' (Not a directory) Laicolasse:~ # file -s /dev/dm-1 /dev/dm-1: Linux/i386 swap file (new style), version 1 (4K pages), size 10485247 pages, LABEL=Swap, UUID=55db7bff-8d71-4862-8e31-1c2a7fd52c9d
Laicolasse:~ # l /dev/disk/by-label/Swap lrwxrwxrwx 1 root root 10 Aug 28 13:57 /dev/disk/by-label/Swap -> ../../dm-1 Laicolasse:~ #
Ideas?
Well, I reverted the procedure described in <https://en.opensuse.org/SDB:Encrypted_root_file_system#Avoiding_to_type_the_passphrase_twice_in_Leap_and_Tumbleweed> Laicolasse:~ # cat /etc/crypttab # nvme0n1p2 Home # nvme0n1p3 Swap # nvme0n1p4, Main #cr-auto-3 UUID=253d3fd9-7f53-465a-85f9-1900b6b87a3c /.root.key x-initrd.attach #cr-auto-2 UUID=d153e878-b32c-4a14-856e-cbc8c6101280 /.root.key x-initrd.attach #cr-auto-1 UUID=43662ac8-d98d-4b1a-a483-0f16e06b419c /.root.key x-initrd.attach cr-auto-3 UUID=253d3fd9-7f53-465a-85f9-1900b6b87a3c none none cr-auto-2 UUID=d153e878-b32c-4a14-856e-cbc8c6101280 none none cr-auto-1 UUID=43662ac8-d98d-4b1a-a483-0f16e06b419c none none Laicolasse:~ # aicolasse:~ # cat /etc/fstab LABEL=Main / ext4 defaults,lazytime 0 1 LABEL=Home /home xfs defaults,lazytime 0 1 LABEL=ESP /boot/efi vfat utf8,lazytime 0 1 LABEL=Swap swap swap defaults 0 0 LABEL=Beta /Other ext4 data=ordered,lazytime 0 2 #LABEL=Main / ext4 defaults,x-initrd.mount 0 1 #LABEL=Home /home xfs defaults,x-initrd.mount 0 0 #LABEL=ESP /boot/efi vfat utf8 0 2 #LABEL=Swap swap swap defaults,x-initrd.mount 0 0 #LABEL=Beta /Other ext4 data=ordered 0 2 Laicolasse:~ # and now hibernation to disk is working again, as before. I have to type the disk encryption password twice, but I prefer to have hibernation working again. Bug? -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.5 (Laicolasse))
On 8/29/23 17:07, Carlos E. R. wrote:
and now hibernation to disk is working again, as before. I have to type the disk encryption password twice, but I prefer to have hibernation working again.
Good, I've followed the thread with great interest. (even saved the finer points between you and Andrei as "full-disk-encrypt-carlow-andrei.txt" :) I've always wanted to get single-password full-disk encryption working but didn't want to get stuck in the mud-hole you have where it kind of works but hibernate/resume, pick your feature, etc.. is not working. Keep plugging away and hopefully you will show us all the proper path for full-disk encryption setup. (don't know if it's a bug or not...) -- David C. Rankin, J.D.,P.E.
On 30.08.2023 01:07, Carlos E. R. wrote: ...
Well, I reverted the procedure described in
Laicolasse:~ # cat /etc/crypttab # nvme0n1p2 Home # nvme0n1p3 Swap # nvme0n1p4, Main
#cr-auto-3 UUID=253d3fd9-7f53-465a-85f9-1900b6b87a3c /.root.key x-initrd.attach #cr-auto-2 UUID=d153e878-b32c-4a14-856e-cbc8c6101280 /.root.key x-initrd.attach #cr-auto-1 UUID=43662ac8-d98d-4b1a-a483-0f16e06b419c /.root.key x-initrd.attach
cr-auto-3 UUID=253d3fd9-7f53-465a-85f9-1900b6b87a3c none none cr-auto-2 UUID=d153e878-b32c-4a14-856e-cbc8c6101280 none none cr-auto-1 UUID=43662ac8-d98d-4b1a-a483-0f16e06b419c none none
...
Bug?
dracut explicitly skips /etc/crypttab entries with valid third field (which refers to the existing key file on disk). There is no explanation, why. So, dracut does not find any swap device and skips "resume" module. Why it does it for swaps only I do not know. Otherwise it is happy to actually unlock this device in initrd. So yes, it does sound like a bug. It should either completely skip this device or fully configure it.
On 2023-08-30 17:10, Andrei Borzenkov wrote:
On 30.08.2023 01:07, Carlos E. R. wrote: ...
Well, I reverted the procedure described in
Laicolasse:~ # cat /etc/crypttab # nvme0n1p2 Home # nvme0n1p3 Swap # nvme0n1p4, Main
#cr-auto-3 UUID=253d3fd9-7f53-465a-85f9-1900b6b87a3c /.root.key x-initrd.attach #cr-auto-2 UUID=d153e878-b32c-4a14-856e-cbc8c6101280 /.root.key x-initrd.attach #cr-auto-1 UUID=43662ac8-d98d-4b1a-a483-0f16e06b419c /.root.key x-initrd.attach
cr-auto-3 UUID=253d3fd9-7f53-465a-85f9-1900b6b87a3c none none cr-auto-2 UUID=d153e878-b32c-4a14-856e-cbc8c6101280 none none cr-auto-1 UUID=43662ac8-d98d-4b1a-a483-0f16e06b419c none none
...
Bug?
dracut explicitly skips /etc/crypttab entries with valid third field (which refers to the existing key file on disk). There is no explanation, why. So, dracut does not find any swap device and skips "resume" module.
Why it does it for swaps only I do not know. Otherwise it is happy to actually unlock this device in initrd.
So yes, it does sound like a bug. It should either completely skip this device or fully configure it.
Sorry, what do you mean by fully configure it? When I had cr-auto-3 UUID=253d3fd9-7f53-465a-85f... /.root.key x-initrd.attach cr-auto-2 UUID=d153e878-b32c-4a14-856... /.root.key x-initrd.attach cr-auto-1 UUID=43662ac8-d98d-4b1a-a48... /.root.key x-initrd.attach then I only had to enter the password once on boot (on grub prompt for it), swap and all was unlocked, but machine would fail to restore from hibernation. AFAIR, lsinitrd /boot/initrd-5.14.21-150500.55.19-default /etc/crypttab did show the correct contents of the file, they looked complete. -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.5 (Laicolasse))
On Thu, Aug 31, 2023 at 12:58 AM Carlos E. R. <robin.listas@gmx.es> wrote:
On 2023-08-30 17:10, Andrei Borzenkov wrote:
On 30.08.2023 01:07, Carlos E. R. wrote: ...
Well, I reverted the procedure described in
Laicolasse:~ # cat /etc/crypttab # nvme0n1p2 Home # nvme0n1p3 Swap # nvme0n1p4, Main
#cr-auto-3 UUID=253d3fd9-7f53-465a-85f9-1900b6b87a3c /.root.key x-initrd.attach #cr-auto-2 UUID=d153e878-b32c-4a14-856e-cbc8c6101280 /.root.key x-initrd.attach #cr-auto-1 UUID=43662ac8-d98d-4b1a-a483-0f16e06b419c /.root.key x-initrd.attach
cr-auto-3 UUID=253d3fd9-7f53-465a-85f9-1900b6b87a3c none none cr-auto-2 UUID=d153e878-b32c-4a14-856e-cbc8c6101280 none none cr-auto-1 UUID=43662ac8-d98d-4b1a-a483-0f16e06b419c none none
...
Bug?
dracut explicitly skips /etc/crypttab entries with valid third field (which refers to the existing key file on disk). There is no explanation, why. So, dracut does not find any swap device and skips "resume" module.
Why it does it for swaps only I do not know. Otherwise it is happy to actually unlock this device in initrd.
So yes, it does sound like a bug. It should either completely skip this device or fully configure it.
Sorry, what do you mean by fully configure it?
dracut ignores swap on LUKS device with key file as resume device but has no problems adding the same LUKS device if it has x-initrd.mount option. This is inconsistent.
On 2023-08-31 06:53, Andrei Borzenkov wrote:
On Thu, Aug 31, 2023 at 12:58 AM Carlos E. R. <robin.listas@gmx.es> wrote:
On 2023-08-30 17:10, Andrei Borzenkov wrote:
On 30.08.2023 01:07, Carlos E. R. wrote: ...
...
Bug?
dracut explicitly skips /etc/crypttab entries with valid third field (which refers to the existing key file on disk). There is no explanation, why. So, dracut does not find any swap device and skips "resume" module.
Why it does it for swaps only I do not know. Otherwise it is happy to actually unlock this device in initrd.
So yes, it does sound like a bug. It should either completely skip this device or fully configure it.
Sorry, what do you mean by fully configure it?
dracut ignores swap on LUKS device with key file as resume device but has no problems adding the same LUKS device if it has x-initrd.mount option. This is inconsistent.
Ah. Thanks. Well, I will write a bugzilla. -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.5 (Laicolasse))
On 2023-08-31 06:53, Andrei Borzenkov wrote:
On Thu, Aug 31, 2023 at 12:58 AM Carlos E. R. <robin.listas@gmx.es> wrote:
On 2023-08-30 17:10, Andrei Borzenkov wrote:
On 30.08.2023 01:07, Carlos E. R. wrote: ...
Well, I reverted the procedure described in
Laicolasse:~ # cat /etc/crypttab # nvme0n1p2 Home # nvme0n1p3 Swap # nvme0n1p4, Main
#cr-auto-3 UUID=253d3fd9-7f53-465a-85f9-1900b6b87a3c /.root.key x-initrd.attach #cr-auto-2 UUID=d153e878-b32c-4a14-856e-cbc8c6101280 /.root.key x-initrd.attach #cr-auto-1 UUID=43662ac8-d98d-4b1a-a483-0f16e06b419c /.root.key x-initrd.attach
cr-auto-3 UUID=253d3fd9-7f53-465a-85f9-1900b6b87a3c none none cr-auto-2 UUID=d153e878-b32c-4a14-856e-cbc8c6101280 none none cr-auto-1 UUID=43662ac8-d98d-4b1a-a483-0f16e06b419c none none
...
Bug?
dracut explicitly skips /etc/crypttab entries with valid third field (which refers to the existing key file on disk). There is no explanation, why. So, dracut does not find any swap device and skips "resume" module.
Why it does it for swaps only I do not know. Otherwise it is happy to actually unlock this device in initrd.
So yes, it does sound like a bug. It should either completely skip this device or fully configure it.
Sorry, what do you mean by fully configure it?
dracut ignores swap on LUKS device with key file as resume device but has no problems adding the same LUKS device if it has x-initrd.mount option. This is inconsistent.
<https://bugzilla.opensuse.org/show_bug.cgi?id=1214849> -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.5 (Laicolasse))
On 2023-08-31 17:56, Carlos E. R. wrote:
On 2023-08-31 06:53, Andrei Borzenkov wrote:
On Thu, Aug 31, 2023 at 12:58 AM Carlos E. R. <> wrote:
dracut ignores swap on LUKS device with key file as resume device but has no problems adding the same LUKS device if it has x-initrd.mount option. This is inconsistent.
I got two quick replies. https://github.com/dracutdevs/dracut/issues/2128 https://github.com/dracutdevs/dracut/issues/2425 And the suggestion to try adding `add_dracutmodules+=" resume "`, which worked :-) Laicolasse:~ # cat /etc/dracut.conf.d/99-root-key.conf install_items+=" /.root.key " add_dracutmodules+=" resume " Laicolasse:~ # Happy camper here :-) I will try to add the information to the wiki page. -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.5 (Laicolasse))
On 2023-09-01 12:17, Carlos E. R. wrote:
On 2023-08-31 17:56, Carlos E. R. wrote:
On 2023-08-31 06:53, Andrei Borzenkov wrote:
On Thu, Aug 31, 2023 at 12:58 AM Carlos E. R. <> wrote:
dracut ignores swap on LUKS device with key file as resume device but has no problems adding the same LUKS device if it has x-initrd.mount option. This is inconsistent.
I got two quick replies.
https://github.com/dracutdevs/dracut/issues/2128 https://github.com/dracutdevs/dracut/issues/2425
And the suggestion to try adding `add_dracutmodules+=" resume "`, which worked :-)
Laicolasse:~ # cat /etc/dracut.conf.d/99-root-key.conf install_items+=" /.root.key " add_dracutmodules+=" resume " Laicolasse:~ #
Happy camper here :-)
I will try to add the information to the wiki page.
Well, not yet! I get the prompt from grub for the password, goes through the motions to restore, but at some point, it powers off instead! I have to press the power button, enter the password a second time, and now it fully restores. I'm not sure it happens every time, but for sure happened twice. Nothing is displayed on the screen, and nothing can be in the logs, system is not "running" while this is going on. -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.5 (Laicolasse))
From: "Carlos E. R." <robin.listas@gmx.es> Date: Fri, 1 Sep 2023 16:13:19 -0400 . . . Well, not yet! I get the prompt from grub for the password, goes through the motions to restore, but at some point, it powers off instead! I have to press the power button, enter the password a second time, and now it fully restores. I'm not sure it happens every time, but for sure happened twice. Nothing is displayed on the screen, and nothing can be in the logs, system is not "running" while this is going on. -- Cheers / Saludos, Carlos E. R. Have you enabled persistent logging (/var/log/journal/)? Something in the log from the previous boot may say why it it is powering the system off; creating /var/log/journal/ (since it sounds like you haven't already) would let you see it. -- Bob Rogers http://www.rgrjr.com/
On 2023-09-01 23:27, Bob Rogers wrote:
From: "Carlos E. R." <robin.listas@gmx.es> Date: Fri, 1 Sep 2023 16:13:19 -0400
. . .
Well, not yet!
I get the prompt from grub for the password, goes through the motions to restore, but at some point, it powers off instead!
I have to press the power button, enter the password a second time, and now it fully restores.
I'm not sure it happens every time, but for sure happened twice.
Nothing is displayed on the screen, and nothing can be in the logs, system is not "running" while this is going on.
Have you enabled persistent logging (/var/log/journal/)? Something in the log from the previous boot may say why it it is powering the system off; creating /var/log/journal/ (since it sounds like you haven't already) would let you see it.
The journal is permanent. The sequence is: Machine hibernates, so it powers off. Hours later, I power it up. Sometimes it recovers normally, asking for the password once, sometimes it powers down again after entering the password. The kernel doesn't intervene. This event can not be logged. Today it recovered normally. -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.5 (Laicolasse))
On 9/1/23 15:13, Carlos E. R. wrote:
Well, not yet!
So, so, so damn close. All has been added to: full-disk-encrypt-carlos-andrei.txt Now we just have to finish it. :) -- David C. Rankin, J.D.,P.E.
On 2023-09-02 01:52, David C. Rankin wrote:
On 9/1/23 15:13, Carlos E. R. wrote:
Well, not yet!
So, so, so damn close. All has been added to:
full-disk-encrypt-carlos-andrei.txt
Now we just have to finish it. :)
Today it worked. What if... what if I entered the wrong password and it reacted by powering off? :-??? Before, on entering the wrong password, it went to grub rescue prompt. -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.5 (Laicolasse))
On 02.09.2023 15:36, Carlos E. R. wrote:
On 2023-09-02 01:52, David C. Rankin wrote:
On 9/1/23 15:13, Carlos E. R. wrote:
Well, not yet!
So, so, so damn close. All has been added to:
full-disk-encrypt-carlos-andrei.txt
Now we just have to finish it. :)
Today it worked.
What if... what if I entered the wrong password and it reacted by powering off? :-???
You do not even tell us, where you enter password (it is grub or somewhere else).
Before, on entering the wrong password, it went to grub rescue prompt.
On 2023-09-02 08:45, Andrei Borzenkov wrote:
On 02.09.2023 15:36, Carlos E. R. wrote:
On 2023-09-02 01:52, David C. Rankin wrote:
On 9/1/23 15:13, Carlos E. R. wrote:
Well, not yet!
So, so, so damn close. All has been added to:
full-disk-encrypt-carlos-andrei.txt
Now we just have to finish it. :)
Today it worked.
What if... what if I entered the wrong password and it reacted by powering off? :-???
You do not even tell us, where you enter password (it is grub or somewhere else).
Grub prompt. A very spartan prompt, doesn't handle an error in password, drops to grub rescue. -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.5 (Laicolasse))
On 01.09.2023 23:13, Carlos E. R. wrote:
I get the prompt from grub for the password, goes through the motions to restore, but at some point, it powers off instead!
You most certainly should be familiar with disabling plymouth and increasing verbosity to get more information. If it happens too fast - configure (additional) serial console and capture full output.
I have to press the power button, enter the password a second time, and now it fully restores.
I'm not sure it happens every time, but for sure happened twice.
Nothing is displayed on the screen, and nothing can be in the logs, system is not "running" while this is going on.
On 2023-09-02 08:44, Andrei Borzenkov wrote:
On 01.09.2023 23:13, Carlos E. R. wrote:
I get the prompt from grub for the password, goes through the motions to restore, but at some point, it powers off instead!
You most certainly should be familiar with disabling plymouth and increasing verbosity to get more information.
True, I forgot. I was using Plymouth till now because it avoided entering the same password for each partition.
If it happens too fast - configure (additional) serial console and capture full output.
Unfortunately I am on a trip, so I only have this laptop. Back at home, perhaps, but this thing doesn't have a serial port, somehow grub would have to write using usb. Unless someone has created a feature for grub to log things to the ESP partition :-? A few blocks could be assigned for direct write to some LBAs. -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.5 (Laicolasse))
On 02.09.2023 16:29, Carlos E. R. wrote:
Unfortunately I am on a trip, so I only have this laptop. Back at home, perhaps, but this thing doesn't have a serial port, somehow grub would have to write using usb.
It is very unlikely that grub powers off the system (which is rather trivial to determine - either you see grub messages about loading kernel/initrd or not). And if it is kernel - there is netconsole (I used it in the past to troubleshoot suspend problems).
Unless someone has created a feature for grub to log things to the ESP partition :-? A few blocks could be assigned for direct write to some LBAs.
On 2023-09-02 10:17, Andrei Borzenkov wrote:
On 02.09.2023 16:29, Carlos E. R. wrote:
Unfortunately I am on a trip, so I only have this laptop. Back at home, perhaps, but this thing doesn't have a serial port, somehow grub would have to write using usb.
It is very unlikely that grub powers off the system (which is rather trivial to determine - either you see grub messages about loading kernel/initrd or not). And if it is kernel - there is netconsole (I used it in the past to troubleshoot suspend problems).
Well, as I have now verbose booting, I will see what happens. Before, it was just blank. I assumed it was grub because the hibernation image was not reset. However, it has only happened twice. Today it hasn't happened. Next time, I'll try with the wrong password on purpose. -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.5 (Laicolasse))
On 2023-03-28 12:41, Carlos E. R. wrote:
Hi,
new laptop here, and I decided to install Leap 15.4 with full disk encryption, no LVM (a feature I wanted to have for years, so I'm happy).
It asks for the password twice (contrary to my customs, I'm using plymouth).
It asks once before grub loads. Well, ok, there is no separate /boot, so it has to read "/" which is encrypted. Nice.
I forgot to ask, this phase from password entry till grub menu appearing is quite slow. Why? :-? -- Cheers / Saludos, Carlos E. R. (from Elesar, using openSUSE Leap 15.4)
On 28.03.2023 20:25, Carlos E. R. wrote:
On 2023-03-28 12:41, Carlos E. R. wrote:
Hi,
new laptop here, and I decided to install Leap 15.4 with full disk encryption, no LVM (a feature I wanted to have for years, so I'm happy).
It asks for the password twice (contrary to my customs, I'm using plymouth).
It asks once before grub loads. Well, ok, there is no separate /boot, so it has to read "/" which is encrypted. Nice.
I forgot to ask, this phase from password entry till grub menu appearing is quite slow. Why? :-?
Because grub is not optimized for the decryption.
participants (10)
-
Andrei Borzenkov -
Bob Rogers -
cagsm -
Carlos E. R. -
Carlos E. R. -
Dave Howorth -
David C. Rankin -
gebser＠mousecar.com -
Robert Webb -
Vojtěch Zeisek