Hibernation device 'UUID[...]' not found

EOS Deutsch
1

Beim Starten von EOS kriege ich folgende Meldung:

Waiting 10 seconds for device /dev/disk/by-uuid/4537b567-1b41-400d-bb48-3f5a579efc6d ...
ERROR: hibernation device 'UUID=4537b567-1b41-400d-bb48-3f5a579efc6d' not found
mount: /new_root: can't find UUID=8d06096e-46ce-4371-8371-bc31df2d4c3f.
You are now being dropped into emergency shell.
sh: can't access tty; jobcontrol turned off
[rootfs ]#

Es wird ein Input über die Tastatur erwartet, aber aus unbekannten Gründen geht die Tastatur nicht. Sogar das Licht meiner Maus ist aus und neu anschließen bringt nichts.

Also gehe ich in den Grub-Menü, drücke e und siehe bei linux […]

resume=UUID=4537b567-1b41-400d-bb48-3f5a579efc6d

Weil mir das nach einem Update schon einmal passierte, habe ich hier im Grub-Menü resume=[…] entfernt und dann F10 gedrückt. Ich konnte ins System rein und habe mit einem Befehl den Ruhemodus deaktiviert. Es kam nicht nochmal wieder vor.

Aber nach meinem heutigen Update kommt diese Meldung nochmal. Jetzt kommt der Twist. Das Löschen von resume=[…] im Grub-Menü bringt nichts und bringt mich auf die selbe Fehler-Meldung von vorher. Zusätzlich steht:

ERROR: resume: no device specified for hibernation

über die restliche Meldung.

Also bin ich mit einem USB-Stick rein > Grub Boot Menü > e > init=/bin/bash. Mit fdisk -l:

/dev/nvme0n1p1  1050624  17065983  16015360   7.6G Linux swap
/dev/nvme0n1p2 17065984 976773134 959707151 457.6G Linux filesystem
/dev/nvme0n1p3     2048   1050623   1048576   512M BIOS boot

Ich nutze BTFRS und EFI ist aktiv. Für mehr Infos, siehe hier.

  • Ist ein Copy & Past aus dem Thread im Link. Bei meinen NVME Partitionen haben sich die Namen nicht geändert.

Mein Plan ist mit arch-chroot den einen Befehl zu nutzen, um den Ruhemodus zu deaktivieren. Allerdings klappt es nicht und ich weiß nicht weiter.
Mein Vorgang war:

mount -o subvol=@ /dev/nvme0n1p2 /mnt
mount /dev/nvme0n1p3 /mnt
arch-chroot /mnt

Nun kommt die Fehlermeldung /mnt/dev/pts mount point does not exist und ab hier stecke ich fest. Ich weiß nicht weiter. Ich habe auch die Schritte befolgt im Arch Wiki zu arch-chroot. Zu diesem Fehler habe ich im Arch Forum (siehe hier) stumpf

pacstrap /mnt base linux linux-firmware

ausgeführt …und es kommt die selbe Fehlermeldung von vorher raus.

Nachtrag: Hab vergessen zu fragen, warum diese Meldung bezogen zum Ruhemodus aufgetreten ist, obwohl ich den Ruhemodus vorhin schon deaktiviert habe? Und weiß einer warum diese Meldung nochmal aufgetreten ist? Ich weiß, ich kann leicht mit einem Snapshot zurückgehen. Allerdings möchte ich die Ursache der Fehlermeldung wenn möglich klären.

2

Hallo,
kannst du uns noch deine Hardware Informationen geben mit

inxi -Fz

Starten nach herunterfahren oder starten nach hibernate?

Hast du hibernate oder sleep deaktiviert. Die deutsche Begrifflichkeit mag da in die Irre führen, da das zwei unterschieldiche Modi sind.

Hast du eine Swap Partotion/Datei? Wenn ja wie groß? Die wäre für solche Hibernate-Sachen essentiell.

Um ehrlich zu sein sagt mir diese Option subvol=@ nichts? Welchen Zweck hat die?
Für mich sieht es so aus als würdest du zwei Partitionen nach /mnt mounten.

3 
mount -o subvol=@ /dev/nvme0n1p2 /mnt
mount /dev/nvme0n1p3 /mnt

hat das keine Fehlermeldung ausgespuckt? wenn nicht hat es deine efi boot partition über dein root filesystem gemounted …
wenn das eine ESP efi partition ist und das system im efi modus bootet… müsste diese als /boot/efi (bei grub) eingebunden werden also für das chrooten unter /mnt/boot/efi

wenn du dann pacstrap veranlasst hast in deine ESP Pakete zu installieren… kann da etzt schon ein kleines Durcheinander vorhanden sein…

das wird benötigt um die Untervolumen im BTRFS filesystem zu mounten @ = /

https://discovery.endeavouros.com/system-rescue/arch-chroot/2022/12/

1 Like
4

Nach dem Herunterfahren und (nach einer Weile) hochfahren. Wie bereits erklärt, weil mir das einmal passierte, habe ich sleep und hibernate deaktiviert mit einem Befehl im Terminal. Habe das gemacht, weil die Fehlermeldung mit UUID[…] auftrat und ich die weghaben wollte. Das Bearbeiten der einen Konfigdatei von Bash, wo resume=[…] steht, hat nichts gebracht, nachdem ich resume=[…] rausgenommen habe. Darum habe ich diesen Befehl ausgeführt, damit sleep, hibernate, etc. deaktiviert werden.

Bash sagt bei inxi -Fz, dass der den Befehl nicht kennt. Ich bin der Kommandozeile von Bash. Ich kann nicht in EOS rein weder noch mit arch-chroot.

Meinst du die Hardware meines PC Setups?

5900X, MSI Tomahawk X570S, 6700XT Sapphire Nitro+, 16GB RAM, 650W Seasonic Focus Plus

Hast du eine Swap Partotion/Datei? Wenn ja wie groß? Die wäre für solche Hibernate-Sachen essentiell.

Habe ich angegeben. ^^ Die Swap Partition ist 7.6GB groß. Zumindest spuckt mir das fdisk -l so aus.

5

Sorry, falls dieser Post durcheinander erscheint. Ich habe gerade wenig Zeit. Später schreibe ich mehr.

Ich habe vergessen zu schreiben, dass unter

/dev/nvme0n1p1  1050624  17065983  16015360   7.6G Linux swap
/dev/nvme0n1p2 17065984 976773134 959707151 457.6G Linux filesystem
/dev/nvme0n1p3     2048   1050623   1048576   512M BIOS boot

steht: Partition table entried are not in disk order. Keine Ahnung, warum das da steht. Da steht p1, p2, p3. Also schon in einer Reihenfolge.

`mount -o subvol=@ /dev/nvme0n1p2 /mnt

mount /dev/nvme0n1p3 /mnt

hat das keine Fehlermeldung ausgespuckt?

Nein. Selbst mit arch-chroot /mnt/boot/efi komme ich nicht rein und kriege eine Fehlermeldung.

wenn du dann pacstrap veranlasst hast in deine ESP Pakete zu installieren… kann da etzt schon ein kleines Durcheinander vorhanden sein…

Der Befehl konnte gestern nicht ausgeführt werden und endete mit einer Fehlermeldung.

Die Partition nvme0n1p3 ist vom Typ FAT32. Wie kann ich sonst herausfinden, dass ESP vorhanden ist? Sorry, ich muss gleich los zur Arbeit. Weil wir haben in diesem Thread herausgefunden, dass EFI genutzt wird.

6

Das sollte auch aus der Live-ISO-Umgebung heraus funktionieren.

Als mountpoint für deine EFI-Partition könntest du /mnt/boot o.Ä. wählen.

7

Klink mich hier kurz nutzlos rein, weil ich seit heute (cold boot, ich hibernate nicht) das gleiche Problem habe.

Gestern ging noch alles.

Vor dem Shutdown mach ich i.d.R ein pacman -Syu - also update (nahezu) täglich und am Folgetag geht alles via Coldboot los.

Ob das Problem nun mit einer Paketaktualisierung von gestern Abend zu tun hat, oder davon unabhängig ist, kann ich nicht sagen - allerdings glaube ich nicht an Zufälle dieser Art.

Habe gerade leider nicht die Zeit mit einem Stick rumzuspielen. Frühestens heute Abend.

EDIT: Die folgende Pakete wurden gestern bei mir geupdated:

[2023-05-02T23:02:40+0200] [ALPM] upgraded btrfs-progs (6.2.2-1 -> 6.3-2)
[2023-05-02T23:02:40+0200] [ALPM] upgraded clang (15.0.7-4 -> 15.0.7-8)
[2023-05-02T23:02:40+0200] [ALPM] upgraded libsoup3 (3.4.1-1 -> 3.4.2-1)
[2023-05-02T23:02:40+0200] [ALPM] upgraded gspell (1.12.0-2 -> 1.12.1-1)
[2023-05-02T23:02:40+0200] [ALPM] upgraded eos-bash-shared (23-11 -> 23-12)
[2023-05-02T23:02:40+0200] [ALPM] upgraded fzf (0.39.0-1 -> 0.40.0-1)
[2023-05-02T23:02:41+0200] [ALPM] upgraded go (2:1.20.3-1 -> 2:1.20.4-1)
[2023-05-02T23:02:41+0200] [ALPM] upgraded graphviz (8.0.4-1 -> 8.0.5-1)
[2023-05-02T23:02:41+0200] [ALPM] upgraded libopenmpt (0.6.10-1 -> 0.7.0-1)
[2023-05-02T23:02:41+0200] [ALPM] upgraded libupnp (1.14.16-1 -> 1.14.17-1)
[2023-05-02T23:02:41+0200] [ALPM] upgraded python-platformdirs (3.2.0-1 -> 3.5.0-1)
[2023-05-02T23:02:41+0200] [ALPM] upgraded reflector-simple (2023-1 -> 2023-2)
[2023-05-02T23:02:41+0200] [ALPM] upgraded welcome (3.59-1 -> 3.60-1)

Ein Downgrade via Image hat das Problem gelöst. Welches im Detail dafür verantwortlich ist, lässt sich vermutlich durch Überlappung herausfinden.

Nun graust es mir vor den angeblichen 250+ Updates, die auf mich warten :clown_face:

EDIT: Alles geklappt :face_with_peeking_eye:

8

Ich bins wieder.
Hatte gestern keine Zeit gehabt. Heute nachmittag hätte ich wieder die Möglichkeit mehr zu machen. Problem ist, dass ich nicht auf meiner NVME, wo EOS drauf ist, nicht in die Konsole über den Grub Boot Menü rein kann. Der spuckt mir erneut aus “hibernation device not found”. inxi -Fz hat nicht funktioniert, weil ich zu dem Zeitpunkt kein EOS-USB habe zum booten. Deshalb habe ich eine andere ISO benutzt (ja ich weiß hätte ich nicht machen sollen…). Ich melde mich heute wieder. Danke für deine Unterstützung!

9

Führe nach dem nächsten Update

sudo systemctl mask sleep.target suspend.target hibernate.target hybrid-sleep.target

aus zum vollständigen Deaktivieren aller Ruhemodis nur zur Sicherheit. Nachdem du das ausgeführt hast, wird dir der Terminal sagen welche Dateien bearbeitet wurden.

Wie hast du es geschafft downzugraden?

Ich melde mich später wieder. Gestern hatte ich keine Zeit.

10

Von welcher ISO aus hast du denn arch-chroot versucht?

11

Wie hast du es geschafft downzugraden?

Einfach die neuste EOS ISO gezogen und mein kaputtes System gemounted.

Hier auch in Form einer Anleitung.

Nach dem arch-chroot auf das System /var/log/pacman.log geprüft um herauszufinden, welche Pakete zuletzt geupdated wurden, sowie ihre alte Version.

Im Anschluss dann alle Pakate via

sudo pacman -U /var/cache/pacman/pkg/<Paketname1-alteVersion1> /var/cache/pacman/pkg/<Paketname2-alteVersion2>

...

gedowngraded.

Entweder jedes Paket einzelnd, oder einfach alle via Space an den Befehl hängen.

arch-chroot via exit verlassen und neugestartet. System startete dann wie gewohnt.

Ein erneutes pacman -Syu lief dann sauber durch und System bootete nach wie vor problemlos.

12

Den normalen Arch :woozy_face:
Ist jetzt auch egal. Hab meinen EOS USB wiedergefunden und versuche gerade etwas. inxi -Fz spuckt folgendes:

Summary 
System:
  Kernel: 6.1.27-1-lts arch: x86_64 bits: 64 Desktop: Xfce v: 4.18.1
    Distro: EndeavourOS
Machine:
  Type: Desktop Mobo: Micro-Star model: MAG X570S TORPEDO MAX (MS-7D54) v: 2.0
    serial: <superuser required> UEFI: American Megatrends LLC. v: A.40
    date: 08/11/2022
CPU:
  Info: 12-core model: AMD Ryzen 9 5900X bits: 64 type: MT MCP cache:
    L2: 6 MiB
  Speed (MHz): avg: 2537 min/max: 2200/4950 cores: 1: 2200 2: 2200 3: 2200
    4: 2200 5: 3700 6: 2200 7: 2200 8: 3700 9: 2200 10: 2200 11: 2200 12: 2200
    13: 3700 14: 2200 15: 2200 16: 2200 17: 3627 18: 2200 19: 3700 20: 2200
    21: 2200 22: 2880 23: 2200 24: 2200
Graphics:
  Device-1: AMD Navi 22 [Radeon RX 6700/6700 XT/6750 XT / 6800M/6850M XT]
    driver: amdgpu v: kernel
  Display: x11 server: X.Org v: 21.1.8 with: Xwayland v: 23.1.1 driver: X:
    loaded: amdgpu unloaded: modesetting,radeon dri: radeonsi gpu: amdgpu
    resolution: 1920x1080~60Hz
  API: OpenGL v: 4.6 Mesa 23.0.3 renderer: AMD Radeon RX 6700 XT (navi22
    LLVM 15.0.7 DRM 3.49 6.1.27-1-lts)
Audio:
  Device-1: AMD Navi 21/23 HDMI/DP Audio driver: snd_hda_intel
  Device-2: AMD Starship/Matisse HD Audio driver: snd_hda_intel
  Device-3: C-Media Audio Adapter (Unitek Y-247A) type: USB
    driver: cmedia_hs100b,snd-usb-audio,usbhid
  Device-4: Micro Star USB Audio type: USB
    driver: hid-generic,snd-usb-audio,usbhid
  API: ALSA v: k6.1.27-1-lts status: kernel-api
  Server-1: PipeWire v: 0.3.70 status: active
Network:
  Device-1: Realtek RTL8125 2.5GbE driver: r8169
  IF: enp38s0 state: down mac: <filter>
  Device-2: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet
    driver: r8169
  IF: eno1 state: up speed: 1000 Mbps duplex: full mac: <filter>
Drives:
  Local Storage: total: 4.12 TiB used: 161.06 GiB (3.8%)
  ID-1: /dev/nvme0n1 vendor: Samsung model: SSD 980 500GB size: 465.76 GiB
  ID-2: /dev/sda vendor: Seagate model: ST1000DM010-2EP102 size: 931.51 GiB
  ID-3: /dev/sdb vendor: Samsung model: SSD 870 EVO 500GB size: 465.76 GiB
  ID-4: /dev/sdc vendor: Western Digital model: WD20EZBX-00AYRA0
    size: 1.82 TiB
  ID-5: /dev/sdd vendor: Samsung model: SSD 870 EVO 500GB size: 465.76 GiB
  ID-6: /dev/sde type: USB vendor: SanDisk model: USB 3.2Gen1
    size: 28.65 GiB
Partition:
  ID-1: / size: 457.62 GiB used: 161.06 GiB (35.2%) fs: btrfs
    dev: /dev/nvme0n1p2
  ID-2: /boot/efi size: 511 MiB used: 876 KiB (0.2%) fs: vfat
    dev: /dev/nvme0n1p3
  ID-3: /home size: 457.62 GiB used: 161.06 GiB (35.2%) fs: btrfs
    dev: /dev/nvme0n1p2
  ID-4: /var/log size: 457.62 GiB used: 161.06 GiB (35.2%) fs: btrfs
    dev: /dev/nvme0n1p2
Swap:
  ID-1: swap-1 type: partition size: 7.64 GiB used: 0 KiB (0.0%)
    dev: /dev/nvme0n1p1
Sensors:
  System Temperatures: cpu: 36.2 C mobo: N/A gpu: amdgpu temp: 38.0 C
  Fan Speeds (RPM): N/A gpu: amdgpu fan: 0
Info:
  Processes: 421 Uptime: 37m Memory: 15.54 GiB used: 3.35 GiB (21.6%)
  Shell: Bash inxi: 3.3.26

Okay, ich bin mit sudo mount -o subvol=@ /dev/nvme0n1p2 reingekommen und mit sudo arch-chroot /mnt. Muss ich zwingend /dev/nvme0n1p3/boot anhängen?

Was kann ich nun von dem Live ISO machen um den hibernatie device zu entfernen? Ich schaue gerade, was ich machen kann.

Edit: Hab gerade den hibernation device entdeckt in etc/fstab, der beim Boot nicht gefunden werden kann… was ich nicht verstehe…

Summary 
UUID=183B-758A                            /boot/efi      vfat    defaults,noatime 0 2
UUID=4537b564-1b41-480d-bb48-3f5a579efc6d swap           swap    defaults   0 0
UUID=8d06096e-46ce-4371-8371-bc31df2d4c3f /              btrfs   subvol=/@,defaults,noatime,compress=zstd 0 0
UUID=8d06096e-46ce-4371-8371-bc31df2d4c3f /home          btrfs   subvol=/@home,defaults,noatime,compress=zstd 0 0
UUID=8d06096e-46ce-4371-8371-bc31df2d4c3f /var/cache     btrfs   subvol=/@cache,defaults,noatime,compress=zstd 0 0
UUID=8d06096e-46ce-4371-8371-bc31df2d4c3f /var/log       btrfs   subvol=/@log,defaults,noatime,compress=zstd 0 0

Das ist komisch. Ich hätte schwören können, dass ich EOS installierte ohne Ruhemodus für Swap…
Dritter Nachtrag: Korrektur

13

Ja, geht ja für arch-chroot und erklärt warum inxi nicht vorhanden ist. Das ist in Arch nicht in der ISO enthalten.

Kannst du mal mit

sudo blkid /dev/nvme0n1p1

die UUID deiner swap Partition anzeigen lassen und mit der in deiner fstab vergleichen?

Meiner Meinung nach macht deine Partitionierung mit der swap-Partition schon Sinn, so wie sie ist.

Edit:
Aus der Liste, die @Derp gepostet hat würden solche Komplikationen für mich am ehesten Sinn machen wegen

Wenn die UUID passt würde ich vlt als nächstes versuchen was passiert, wenn due btrfs-progs wieder downgradest. Entweder aus deinem lokalen Cache oder mittels Arch Linux Archive (ehemals Arch Rollback Machine): https://archive.archlinux.org/packages/b/btrfs-progs/btrfs-progs-6.2.2-2-x86_64.pkg.tar.zst
also

sudo pacman -U https://archive.archlinux.org/packages/b/btrfs-progs/btrfs-progs-6.2.2-2-x86_64.pkg.tar.zst
14

Meine Nachricht kommt zu spät.

Wie gesagt, bin mit arch-chroot /mnt reingekommen. Habe einfach EOS geupdatet und versehentlich neugestartet. Ich kam wieder normal in EOS rein, ohne dass diese Meldung wieder kam. Ich gehe mal aus, da war ein Package mit einem Fehler, der dann schnell mit dem nächsten Update behoben wurde… Allerdings wüsste ich nicht genau, welches Package dafür verantwortlich wäre…

Eine letzte Frage noch. Mir ist aufgefallen, dass mein aktuellstes BTFRS Snapshop nicht im Grub Boot Menü unter Snapshops aufgelistet wird. Woran liegt es? Ich habe diese Lösung (Manjaro Forum) gefunden, bin aber nicht so ganz sicher…

1 Like
15

Schön, dass sich das Problem erledigt hat. Wenn es dich wirklich interessiert, kannst du dir mit

expac --timefmt='%Y-%m-%d %T' '%l\t%n' | sort | tail -n 20

(Quelle: https://wiki.archlinux.org/title/Pacman/Tips_and_tricks)
Die 20 zuletzt installierten oder upgedateten Pakete anzeigen lassen, ggf. musst du vorher noch expac installieren.
Die Anzahl der angezeigten Installationen bzw. Pakete kannst du in der Befehlszeile anpassen. Das fragliche Paket sollte ja dann unter den letzten updates sein.

Was die BTRFS Snapshots angeht bin ich überfragt, weil ich ext4 benutze.

1 Like
16

Habs rausgekriegt. Es ist wegen dem Package grub-btrfs. Es wurde schon so konfiguriert worden, dass in grub.cfg in /boot/grub aktualisiert wird, nachdem neue Snapshots erstellt wurden.
Es gibt auch die Option das auch manuell zu machen mit:

sudo grub-mkconfig -o /boot/grub/grub.cfg

Siehe die Github Seite von grub-btrfs für mehr Info.

17

Ja, das macht Sinn.

Siehe auch:

Es würde Sinn machen sich einen pacman hook anzulegen, der
grub-install
und
grub-mkconfig -o /boot/grub/grub.cfg
ausführt wenn grub aktualisiert wird. Das liese sich ja dann auch auf grub-btrfs ausweiten.

18 
UUID=183B-758A                            /boot/efi      vfat    defaults,noatime 0 2

/boot/efi wenn grub bitte :wink: und nicht unbeding nötig nur wenn z.B. etwas dort geändert werden muss z.B. Grub neu ins system gepackt werden muss -e-t-c wenn etwas am boot bearbeitet un geändert wird sollte die ESP (fat32 boot efi partition) eingebunden sein… auch wenn grub-mkconfig nur in /boot/grub/grub.cfg schreibt… kann es sein das etwas unter /boote/efi gelesen werden muss…