[Solved] Luks - Failing to boot

Soultrigger · 2023-12-14 17:07:49

kermit63 wrote:

Soultrigger wrote:
Do you know if there is a terminal browser that would allow to run commands and post here? It might be useful in the future.
I haven't used one of those in more than a decade, so I'm not qualified to recommend any. What I do have though, is a bootable custom arch iso with GUI, browser and system tools for partitioning, backing up/cloning disks and general troubleshooting, which I was able to make with archiso. It does take a bit of a learning curve to make one, An alternative is to have a bootable arch-based USB like EndeavourOS available for those times when your arch install won't boot and you need to get on here to ask for help.

Oh I did one of those once, but my pendrive died. :X

I guess I will do a new one, it will help in a pinch like this. Thanks

Soultrigger · 2023-12-15 13:33:11

We got a flawless victory, ok ok, not flawless, but a victory it is.

I installed my system withouth issues. The only "hiccup" was that I changed my root partition from 8304 to 8300 so systemd wouldnt auto mount it, and then back to 8304 (linux root x86_64) and it didnt auto mount, so I had to nuke it and redo the partition, crypto and so on... Today I was thinking that I might have turned on flag 63 to dont auto mount, so I am not sure if the crypto partition cant be changed the id or if I screwed up and forgot I used that flag. (which I could also fix just providing the UUID to the kernel, but I wanted it to automount).

Anyway, the system is reinstalled, working as intended, got all my configs from /home properly, and it is as it was without any real effort. (Since whatever I had in etc, I already had copy and paste commands to make the edits in the files anyway).

I should have used btfrfs snapshots, but it is not on the top of my list to learn about right now. Far more interesting topics.

Thanks all for the help again, I am a happy arch user, this community is awesome.

Last edited by Soultrigger (2023-12-15 13:33:39)

Soultrigger · 2023-12-15 21:40:55

When I got home it started asking for dev by uuid with no limit again.

It was the opened Luks2 swap UUID that was requested again. When I created it, it had the label 'swap' and when I opened the Luks2 it showed the lavel 'swsuspend' is it normal to change the label baed on suspend?

Either way, after opening the Luks2 I mkswap -U and the requested UUID, it still kept looking for it.

So I mkswap -U with the right UUID again completely wiping the Luks2 and the system booted.

It seems to be some issue with systemd, luks2 and encrypted swaps. I am letting as unsolved so people can give me any helpful input, if with an unencrypted swap it stops giving me trouble I will change to solved again. (even though I will encrypt it if a fix is released).

seth · 2023-12-15 22:03:36

Does it help to add "systemd.swap=false" to the kernel parameters?

Did you try whether downgrading systemd and systemd-libs "fixes" it?
If it hallucinates devices from remnant blocks of the previous FS or somewhere™ out of the GPT, you'd effectively have to "dd if=/dev/zero" the entire disk…

If this is a regression and 254 doesn't exhibut this behavior, you also wanna force lennart to "notAorOurBug" this at https://github.com/systemd/systemd/issues

kermit63 · 2023-12-16 07:38:34

First off, you should give priority to what Seth is telling you since he is far more knowledgeable than me. I have an idea you can try though:

Split up your swap partition into 2. One is an unencrypted 256mb partition with UUID same as the swap your system is obsessing about. The 2nd is encrypted swap taking up the rest of the space with any random UUID.

The small unencrypted swap is there just to satisfy your system's obsession. The 2nd swap will be your actual swap. If you are not comfortable having an unencrypted swap you can just swapoff after boot either manually, or by some automated hook or script.

Soultrigger · 2023-12-17 15:06:10

seth wrote:

Does it help to add "systemd.swap=false" to the kernel parameters?
Did you try whether downgrading systemd and systemd-libs "fixes" it?
If it hallucinates devices from remnant blocks of the previous FS or somewhere™ out of the GPT, you'd effectively have to "dd if=/dev/zero" the entire disk…
If this is a regression and 254 doesn't exhibut this behavior, you also wanna force lennart to "notAorOurBug" this at https://github.com/systemd/systemd/issues

I will try later the kenel option you suggest. As far rolling back to 254 and fixing it, yes, I can try that too, but I dont think it is needed since that post you linked here at the beggining of your inputs our friend did rollback with his snapshot to 254 and that fixed it for him.

I dont think I would need to write my ssd full of zeroes, since the first UUID it was stuck was my previous swap, and I might have nuked my install too soon. The new UUID he asks is my current swap when the luks2 was opened, and for whatever reason the new 255 release is failing to open the luk2 for the swap alone. (which was the original problem and why I nuked my install - all other luks2 devices it opens fine, just the swap does cause an issue). So for now with the unencrypted swap it is working fine, when systemd gets updated again I might try to encrypt the swap again and see if it goes crazy again. The real problem here for me is that it is recovering the data from some place unknown, as you said can have something to do with the GPT, but I believe it is saving it in the UEFI, but my guess can be wrong. If it at least had a fimer of 1:30m and the followed the boot procedure with an error it would be fine, but it puts a no limit and that is why we had to create the unencrypted swap workaroud.

I am on a PC at home, I dont really need to encrypt anything, and I dont have any real sensitive data. Maybe if I had a laptop with data from my work it would be more troublesome and I would worry about some sensitive data being exploited from swap if my laptop was stolen.

I just used encryption for the sake of learning it. I will try the rollback on systemd, but probably on a virtual machine for the sake of learning and it might not simulate enough the real problem as on a barebones machine.

Thanks for your input, as I said I will try both and learn about it. I will mark as solved again because the system is working even though with an unencrypted swap.

Soultrigger · 2023-12-17 15:09:36

kermit63 wrote:

First off, you should give priority to what Seth is telling you since he is far more knowledgeable than me. I have an idea you can try though:
Split up your swap partition into 2. One is an unencrypted 256mb partition with UUID same as the swap your system is obsessing about. The 2nd is encrypted swap taking up the rest of the space with any random UUID.
The small unencrypted swap is there just to satisfy your system's obsession. The 2nd swap will be your actual swap. If you are not comfortable having an unencrypted swap you can just swapoff after boot either manually, or by some automated hook or script.

Thanks Kermit.

The real issue is not that it is stuck with an UUID that I need to make a partition to fix it, but that systemd is failling to mount an encrypted luk2 swap. All other encrypted luks2 paritions he is unlocking and mounting just fine. For now I followed your original idea of an unencrypted swap with a specific UUID.

Your proposed solution here would not work, because he would fail to unlock the second swap resulting in the same issue.

Thanks for your time and input, and you saved me a lot of time with the swap -U tip.

seth · 2023-12-17 16:35:53

[Edit: afiau the designated swap UUID was bogus, either dated or made up out of thin air. Yesno?]
Did you try to add "systemd.gpt_auto=0 systemd.swap=0" to the https://wiki.archlinux.org/title/Kernel_parameters ?

Last edited by seth (2023-12-17 16:37:28)

Soultrigger · 2023-12-18 16:56:11

seth wrote:

[Edit: afiau the designated swap UUID was bogus, either dated or made up out of thin air. Yesno?]
Did you try to add "systemd.gpt_auto=0 systemd.swap=0" to the https://wiki.archlinux.org/title/Kernel_parameters ?

No. not yet. When I get home today I will test the other one you pointed out and these two as two separate tests and let you know. I will wipe my current swap, encrypt again and test those parameters.

I will also post here the results of lsblk and blkid to show what I mean by UUID when luks2 is open, I saw 3-4 posts on these forums with a similar issue, but they all seem to believe that systemd came with a random UUID, but it is not the case. I dont get though how he gets the UUID information between various install on different storage devices, that is why I am putting my money in the PCR/UEFI supplying that information, since I removed the partition, created it, encrypted it, formated it and installed on it without any data from the old install.

Soultrigger · 2023-12-19 20:16:18

seth wrote:

Does it help to add "systemd.swap=false" to the kernel parameters?
Did you try whether downgrading systemd and systemd-libs "fixes" it?

No, it does not.

seth · 2023-12-19 20:25:22

"systemd.swap=false" or downgrading?
Also, while the syntax says "bool" all examples say "0", so did you try "systemd.gpt_auto=0 systemd.swap=0" as well?

Soultrigger · 2023-12-19 20:33:17

seth wrote:

[Edit: afiau the designated swap UUID was bogus, either dated or made up out of thin air. Yesno?]
Did you try to add "systemd.gpt_auto=0 systemd.swap=0" to the https://wiki.archlinux.org/title/Kernel_parameters ?

No, it didnt fix it either.

I tried the first one alone, the swap=0 alone, and gpt_auto and swap together. None of the tries fixed it. I did change the kernel parameters just hitting E to edit the kernel parameter lines in the sd-boot menu, but I believe it should work even with UKI?

Either way I created a new partition, encrypted it, created the swap and I could boot the system, and tried 3 times to reboot just to make sure. After I tried suspend and I could still recover and use the system After I tried hibernate it failed to mount the swap or recognize it, and asked device by uuid with no limit again. So it seems not that systemd release 255 cant open a luks2 swap, but it has some issue with it after a hibernate.

So some details about my system.

I ran bootctl install --esp-path=/efi, but didnt configure any of its configuration files. So he auto finds the UKIs (/efi/EFI/Linux/arch-linux.efi (and arch-linux-fallback.efi).

Mkinitcpio.conf have hooks systemd (in place of udev), sd-vconsole and sd-encrypt so that it will auto mount root partition with ID 8304 (root x86_64) and when asking for the passphrase to unlock it, save it so it will use to unlock eveything that is in the file /etc/crypttab, and later mounts as usual with /etc/fstab.

LSBLK:

NAME        MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS
sda           8:0    0 894,3G  0 disk  
├─sda1        8:1    0     1G  0 part  /efi
├─sda2        8:2    0 892,3G  0 part  
│ └─root    254:0    0 892,2G  0 crypt /mnt/games
│                                      /home
│                                      /
└─sda3        8:3    0     1G  0 part  
sdb           8:16   0   1,8T  0 disk  
├─sdb1        8:17   0   1,8T  0 part  
│ └─storage 254:2    0   1,8T  0 crypt /mnt/media
│                                      /mnt/arquivos
│                                      /home/soultrigger/.cache
│                                      /mnt/backup
│                                      /mnt/gameshdd
│                                      /mnt/vm
├─sdb2        8:18   0    32G  0 part  
│ └─var     254:1    0    32G  0 crypt /var/log
│                                      /var/tmp
│                                      /var/cache
│                                      /var/lib/portables
│                                      /var/lib/machines
│                                      /var
└─sdb3        8:19   0    32G  0 part  [SWAP]

BLKID

/dev/mapper/var: LABEL="var" UUID="57bf5d10-b9f9-497c-8a69-c7b4c8db22de" UUID_SUB="70fc0aba-5933-4fc0-b044-42095b9ce37d" BLOCK_SIZE="4096" TYPE="btrfs"
/dev/sdb2: UUID="3b821399-fad7-4c0d-a066-b4979a628ec8" TYPE="crypto_LUKS" PARTLABEL="var" PARTUUID="d4092f44-9502-4e16-adec-14ab8158e3a7"
/dev/sdb3: LABEL="swap" UUID="aab7fafb-3e91-46cb-87c3-5117e7428e92" TYPE="swap" PARTLABEL="swap" PARTUUID="e4d7fd45-f9d5-4b9f-abe2-4c05ea6450cf"
/dev/sdb1: UUID="48c479d9-f61a-4b84-9ff0-07e5b3c46f5b" TYPE="crypto_LUKS" PARTLABEL="storage" PARTUUID="6045f7b7-f955-4391-9cc2-f847095b7214"
/dev/mapper/storage: LABEL="storage" UUID="c1c9b477-c528-4491-b443-963e1c4385ab" UUID_SUB="08e0e17d-1da2-4b10-8869-58fe532d3e39" BLOCK_SIZE="4096" TYPE="btrfs"
/dev/mapper/root: LABEL="root" UUID="6212af1d-9acc-418e-9965-676230b0f323" UUID_SUB="f82a4cb6-019c-4bee-9986-7356e95c86f6" BLOCK_SIZE="4096" TYPE="btrfs"
/dev/sda2: UUID="89e38b91-c88a-4562-a24b-0af7445ea4b4" TYPE="crypto_LUKS" PARTLABEL="root" PARTUUID="bc034072-b3e9-4000-ad9b-bbd10a0496d9"
/dev/sda3: UUID="4F3C-39E6" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="rescue" PARTUUID="9c622e66-cc88-46c1-9a66-b8b5d5fdbcf4"
/dev/sda1: LABEL_FATBOOT="EFI" LABEL="EFI" UUID="87CC-D1E5" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="efi" PARTUUID="d0c00661-f809-46b7-a203-1b6c646d2d58"

At this moment the swap is unencrypted, but just to illustrate what I mean for swap luks2 opened UUID, lets compare the var partition, its UUID is 89e38b91-c88a-4562-a24b-0af7445ea4b4, but when the luks2 is open /dev/mapper/var its UUID is 57bf5d10-b9f9-497c-8a69-c7b4c8db22de.

So the UUID for the swap that he gets stuck is whatever was the last encrypted swap that systemd used when it is opened as /dev/mapper/swap. So we are with 3 different ones, the original one that I nuked, the second one that I used in the new install and nuked to make an unencrypted one, and the actual one that is the same UUID as the unencrypted swap partition, but was originally for the opened luks2 as /dev/mapper/swap.

etc/crypttab

# Configuration for encrypted block devices.
# See crypttab(5) for details.

# NOTE: Do not list your root (/) partition here, it must be set up
#       beforehand by the initramfs (/etc/mkinitcpio.conf).

# <name>       <device>                                     <password>              <options>
# home         UUID=b8ad5c18-f445-495d-9095-c9ec4f9d2f37    /etc/mypassword1
# data1        /dev/sda3                                    /etc/mypassword2
# data2        /dev/sda5                                    /etc/cryptfs.key
# swap         /dev/sdx4                                    /dev/urandom            swap,cipher=aes-cbc-essiv:sha256,s>
# vol          /dev/sdb7                                    none

storage         UUID=48c479d9-f61a-4b84-9ff0-07e5b3c46f5b
var             UUID=3b821399-fad7-4c0d-a066-b4979a628ec8
#swap           UUID=16d87301-9170-4bbc-a219-8dbce3f3a742

Swap is commented because it is not encrypted at this time.

/etc/fstab

# Static information about the filesystems.
# See fstab(5) for details.

# <file system> <dir> <type> <options> <dump> <pass>

# /dev/mapper/root LABEL=root
UUID=6212af1d-9acc-418e-9965-676230b0f323       /               btrfs           rw,noatime,compress=zstd:3,ssd,discard=async,space_cache=v2,subvolid=256,subvol=/@     0 0

# /dev/sda1 LABEL=EFI
UUID=87CC-D1E5                                  /efi            vfat            rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro  0 2

# /dev/mapper/root LABEL=root
UUID=6212af1d-9acc-418e-9965-676230b0f323       /home           btrfs           rw,noatime,compress=zstd:3,ssd,discard=async,space_cache=v2,subvolid=257,subvol=/@home 0 0

# /dev/mapper/storage LABEL=storage
UUID=c1c9b477-c528-4491-b443-963e1c4385ab       /home/soultrigger/.cache        btrfs           rw,noatime,compress=zstd:3,ssd,discard=async,space_cache=v2,subvolid=256,subvol=/@home_cache   0 0

# /dev/mapper/var LABEL=var
UUID=57bf5d10-b9f9-497c-8a69-c7b4c8db22de       /var            btrfs           rw,noatime,compress=zstd:3,ssd,discard=async,space_cache=v2,subvolid=256,subvol=/@var  0 0

# /dev/mapper/var LABEL=var
UUID=57bf5d10-b9f9-497c-8a69-c7b4c8db22de       /var/log        btrfs           rw,noatime,compress=zstd:3,ssd,discard=async,space_cache=v2,subvolid=257,subvol=/@var_log      0 0

# /dev/mapper/var LABEL=var
UUID=57bf5d10-b9f9-497c-8a69-c7b4c8db22de       /var/tmp        btrfs           rw,noatime,compress=zstd:3,ssd,discard=async,space_cache=v2,subvolid=258,subvol=/@var_tmp      0 0

# /dev/mapper/var LABEL=var
UUID=57bf5d10-b9f9-497c-8a69-c7b4c8db22de       /var/cache      btrfs           rw,noatime,compress=zstd:3,ssd,discard=async,space_cache=v2,subvolid=259,subvol=/@var_cache    0 0

# /dev/mapper/var LABEL=var
UUID=57bf5d10-b9f9-497c-8a69-c7b4c8db22de       /var/lib/portables      btrfs           rw,noatime,compress=zstd:3,ssd,discard=async,space_cache=v2,subvolid=260,subvol=/@var_lib_portables    0 0

# /dev/mapper/var LABEL=var
UUID=57bf5d10-b9f9-497c-8a69-c7b4c8db22de       /var/lib/machines       btrfs           rw,noatime,compress=zstd:3,ssd,discard=async,space_cache=v2,subvolid=261,subvol=/@var_lib_machines     0 0

# /dev/mapper/root LABEL=root
UUID=6212af1d-9acc-418e-9965-676230b0f323       /mnt/games      btrfs           rw,noatime,compress=zstd:3,ssd,discard=async,space_cache=v2,subvolid=258,subvol=/@games        0 0

# /dev/mapper/storage LABEL=storage
UUID=c1c9b477-c528-4491-b443-963e1c4385ab       /mnt/arquivos   btrfs           rw,noatime,compress=zstd:3,ssd,discard=async,space_cache=v2,subvolid=257,subvol=/@arquivos     0 0

# /dev/mapper/storage LABEL=storage
UUID=c1c9b477-c528-4491-b443-963e1c4385ab       /mnt/gameshdd   btrfs           rw,noatime,compress=zstd:3,ssd,discard=async,space_cache=v2,subvolid=260,subvol=/@gameshdd     0 0

# /dev/mapper/storage LABEL=storage
UUID=c1c9b477-c528-4491-b443-963e1c4385ab       /mnt/media      btrfs           rw,noatime,compress=zstd:3,ssd,discard=async,space_cache=v2,subvolid=259,subvol=/@media        0 0

# /dev/mapper/storage LABEL=storage
UUID=c1c9b477-c528-4491-b443-963e1c4385ab       /mnt/backup     btrfs           rw,noatime,compress=zstd:3,ssd,discard=async,space_cache=v2,subvolid=258,subvol=/@backup       0 0

# /dev/mapper/storage LABEL=storage
UUID=c1c9b477-c528-4491-b443-963e1c4385ab       /mnt/vm         btrfs           rw,noatime,compress=zstd:3,ssd,discard=async,space_cache=v2,subvolid=262,subvol=/@vm   0 0

# /dev/mapper/swap LABEL=swap
UUID=aab7fafb-3e91-46cb-87c3-5117e7428e92       none            swap            defaults        0 0

/etc/kernel/cmdline

splash

It is "slpash" just to be passed to plymouth and have it work.

gdisk /dev/sda

GPT fdisk (gdisk) version 1.0.9.1

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.

Command (? for help): p
Disk /dev/sda: 1875385008 sectors, 894.3 GiB
Model: KINGSTON SA400S3
Sector size (logical/physical): 512/512 bytes
Disk identifier (GUID): 3EF6C011-3388-4A47-A391-3FD5210E7935
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 1875384974
Partitions will be aligned on 2048-sector boundaries
Total free space is 2669 sectors (1.3 MiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048         2099199   1024.0 MiB  EF00  efi
   2         2099200      1873287167   892.3 GiB   8304  root
   3      1873287168      1875384319   1024.0 MiB  0700  rescue

Command (? for help):

gdisk /dev/sdb

GPT fdisk (gdisk) version 1.0.9.1

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.

Command (? for help): p
Disk /dev/sdb: 3907029168 sectors, 1.8 TiB
Model: WDC WD20EZRX-00D
Sector size (logical/physical): 512/4096 bytes
Disk identifier (GUID): 07849991-5CC2-4C36-A422-F6672E266613
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 3907029134
Partitions will be aligned on 2048-sector boundaries
Total free space is 2157 sectors (1.1 MiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048      3772782591   1.8 TiB     8300  storage
   2      3772782592      3839891455   32.0 GiB    8300  var
   3      3839891456      3907028991   32.0 GiB    8200  swap

Command (? for help):

Last edited by Soultrigger (2023-12-19 20:37:36)

Soultrigger · 2023-12-19 20:34:09

seth wrote:

"systemd.swap=false" or downgrading?
Also, while the syntax says "bool" all examples say "0", so did you try "systemd.gpt_auto=0 systemd.swap=0" as well?

You are just too fast, I was still typing the rest of it haha

Soultrigger · 2023-12-21 00:47:11

Just to let you know I reported this as a bug (even though I dont know if it is) https://github.com/systemd/systemd/issues/30557

Soultrigger · 2023-12-21 11:44:33

They said that the resume shoudl be completed in initramfs process, so my swap should be in /etc/crypttab.initramfs, so I will try to encrypt it and add no this file later today and regenerate the UKI.

They also said that in a future fix they wont wait for the swap forever and that should help. They also pointed that I was right in assuming they are saving the swap information in a UEFI variable, and with this there should be no need for resume= kernel option anymore.

This is one they pointed at might be a good reference https://github.com/systemd/systemd/issues/30395

Soultrigger · 2023-12-22 15:04:59

seth wrote:

"systemd.swap=false" or downgrading?
Also, while the syntax says "bool" all examples say "0", so did you try "systemd.gpt_auto=0 systemd.swap=0" as well?

I quoted just to let you know. The kernel option that will work is noresume, so it will bypass the requested UUID and boot, but I am told it can cause data corruption. (at the very least it wont resume at all).

Adding the swap partition UUID to /etc/cryptab.initramfs and the mkinitcpio -P to recreate the UKIs fixes it. It seems even though my system worked up to r254, the swap is needed in early initramfs to resume properly and since It would be unlocked later in the boot chain it failed to be mounted when systemd requested it, and thus it kept asking for it forever. (which will be no longer the case since they will "fix" it making it a timed error (1:30m probably)).

It might be interesting to remove /sys/firmware/efi/efivars/HibernateLocation-8cf2644b-4b0b-428f-9387-6d876050dc67 for which you need to remove the immutable attribute with sudo chattr -i /path/to/HibernateLocationFile, and then remove it with "sudo rm". Since it might have failed to update and cause the issue. (If I understood correctly it is the variable that saves the UUID).

seth · 2023-12-22 15:12:05

You get mails for every susbscribed thread anyway, no need to quote or "@seth" etc.

So the system was actually trying to resume from hibernation all along?
It never was a "clean" boot?

Soultrigger · 2023-12-22 17:17:32

I did pacman -Syu, and rebooted. After that I was stuck with the dev by uuid no limit screen.

To bypass that and do a clean boot the solution we got here was to mkswap -U with the systemd requested uuid, and since it was an unencrypted partition it booted as a "clean" boot, but I assume because since it was non encrypted systemd could mount it at any point.

But systemd getting stuck there seems to be because it saves the UUID in this HibernateLocation EFI variable and since it couldnt unlock it in early initramfs it got stuck. I just got this after you asked to test kernel parameters and I redid a crypted partition for the swap, after reboots and suspend it was ok, but after hibernate it got stuck again. At which point I used a non encrypted swap with the requested uuid again.

After I opened the bug report I was instructed that my setup was wrong because for resume the swap needs to be opened in early initramfs and thus I should add the swap to /etc/crypttab.initramfs

The strange thing though is that people who got stuck like that in the discussion in github said they never setup hibernation at all.

It will probably fix my hibernation issues from the other topic and I will mark as solved. It kind of failed a lot since I changed to crypttab.initramfs (hit key in the keyboard, power ups, no image to the screen, I wait for a few minutes and hit reset, after that it asks for the crypto passphrase and resumes from hibernation), then I though that might be because I need to add the swap in /etc/crypttab too when the system resumes. Pending tests after this change.

seth · 2023-12-22 21:38:28

The strange thing though is that people who got stuck like that in the discussion in github said they never setup hibernation at all.

There're the other threads here where systemd seems to be literally making up devices, the problem could be that it takes some garbage in the EFI at face value or maybe those are values from a parallel windows installation.
Did anyone indicate a switch to just ignore the HibernationLocation (because there're plenty of issues that boil down to the EFI containing/exposing garbage) or maybe just at least skip it if there's a resume parameter?

Soultrigger · 2023-12-23 19:58:38

On the topics I read the only kernel parameter was 'noresume' so it ignores the need for swap at least in early initramfs and it was advised to remove the HibernateLocation efivar that it would supposedly stop asking for the device.

As far as I got the other cases they all seem to be about luks2 and some UUID, in which case I believe it will be similar to mine, the UUID for /dev/mapper/whatever-name-you-gave-to-your-swap UUID.

Arch Linux

#26 2023-12-14 17:07:49

Re: [Solved] Luks - Failing to boot

#27 2023-12-15 13:33:11

Re: [Solved] Luks - Failing to boot

#28 2023-12-15 21:40:55

Re: [Solved] Luks - Failing to boot

#29 2023-12-15 22:03:36

Re: [Solved] Luks - Failing to boot

#30 2023-12-16 07:38:34

Re: [Solved] Luks - Failing to boot

#31 2023-12-17 15:06:10

Re: [Solved] Luks - Failing to boot

#32 2023-12-17 15:09:36

Re: [Solved] Luks - Failing to boot

#33 2023-12-17 16:35:53

Re: [Solved] Luks - Failing to boot

#34 2023-12-18 16:56:11

Re: [Solved] Luks - Failing to boot

#35 2023-12-19 20:16:18

Re: [Solved] Luks - Failing to boot

#36 2023-12-19 20:25:22

Re: [Solved] Luks - Failing to boot

#37 2023-12-19 20:33:17

Re: [Solved] Luks - Failing to boot

#38 2023-12-19 20:34:09

Re: [Solved] Luks - Failing to boot

#39 2023-12-21 00:47:11

Re: [Solved] Luks - Failing to boot

#40 2023-12-21 11:44:33

Re: [Solved] Luks - Failing to boot

#41 2023-12-22 15:04:59

Re: [Solved] Luks - Failing to boot

#42 2023-12-22 15:12:05

Re: [Solved] Luks - Failing to boot

#43 2023-12-22 17:17:32

Re: [Solved] Luks - Failing to boot

#44 2023-12-22 21:38:28

Re: [Solved] Luks - Failing to boot

#45 2023-12-23 19:58:38

Re: [Solved] Luks - Failing to boot

Board footer