Update eos-update --aur macht systemd-boot kaputt

EOS Deutsch
1

Ich habe 3 Systeme auf der internen Notebook-Platte:

lsblk -f
NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS
nvme0n1
├─nvme0n1p1 vfat FAT32 ESP BDB2-89EE 1,8G 9% /efi
├─nvme0n1p2 ext4 1.0 EOSkdePlasma 67296915-3e9e-48a1-abe0-203590603f74 544,4G 41% /
├─nvme0n1p3 swap 1 4bdc9ec4-9844-4ae1-9e78-2f001598b9f0 [SWAP]
├─nvme0n1p4 ext4 1.0 Backup 5850736b-d834-4dc0-ac5d-d2d6bccd84ae 429G 36% /Backup
├─nvme0n1p5 ext4 1.0 TuxedoOS 62d559f1-282b-48da-be1a-a0256fa1a52f
└─nvme0n1p6 ext4 1.0 Hilf_p6 be19908a-35b3-42e1-aa9a-f76832b6f554

Beim Update mit eos-update --aur auf dem “Standard-System” auf nvme0n1p2 EOSkdePlasma von EOSkdePlasma 6.8.4-arch1-1 auf 6.8.5-arch1-1 wird ein Boot-File mit falschem root=UUID erstellt. Beim Reboot wird die System-Partition nicht mehr gefunden:

pnp 00:03: disabling [men 0xc0000000-0xcfffffff] because it overlaps 0000:00;02,
#1
#3#5#719 #11
000-Oxdfffffff 64bit prefl
hpet_acpi_add: no address or irqs in CRS
ENERGY_PERF_BIAS: Set to ‘normal’. was per fornance
tuxedo_compatibility_check: loading out-of-tree module taints kernel,
VBoxNetAdp: Successfully started.
VBoxNetFlt: Successfully started.
18042: PNP: PS/2 appears to have AUX port disabled. if this is incorrect please
[ OK ] Finished Virtual Console Setup
p
[OK ] Started Foruard Password Requests to Plymouth Directory Watch
Started Show Plymouth Boot Screen.
OK
]
OK
Reached target Path Units
[
]
[ xx I A start job is running for /dev/disk/by-uuid/6add4d92-27d0-4707-9e6e-6d99ad8a2a18 (37s / no limit)
OK
Reached target System Initialization
OK
Reached target Basic System
39.890545] ACPI BIOS Error (bug): Could not resolve symbol [^^^^NPCF.ACBT], AE_NOT_FOUND (20230628/psargs-330)
39.890665] ACPI Error: Aborting method _SB.PCOO.LPCB.EC0._Q83 due to previous error (AE_NOT_FOUND) (20230628/psparse-529)
[
ACPI BIOS Error (bug): Could not resolve symbol [^^^^NPCF .ACBT], RE_NOT_FOUND (20230628/psargs-330)
A start job is running for /dev/disk/by-uuid/6add4d92-27d0-4707-9e6e-6d99ad8a2a18 (10min 3s / no limit)
[x

Anschließend habe ich mein “Hilfssystem” nvme0n1p6 Hilf_p6 gebootet und die Datei

/efi/loader/entries/8d89d65c4df6427d951586e83c034d7f-6.8.5-arch1-1.conf

editiert und die falsche UUID durch die richtige ersetzt:

falsch: #options nvme_load=YES nowatchdog rw root=UUID=6add4d92-27d0-4707-9e6e-6d99ad8a2a18 systemd.machine_id=8d89d65c4df6427d951586e83c034d7f

richtig: options nvme_load=YES nowatchdog rw
root=UUID=67296915-3e9e-48a1-abe0-203590603f74 systemd.machine_id=8d89d65c4df6427d951586e83c034d7f

Danach bootet das System wieder richtig.

Dieser Fehler trat mindestens bei den letzen 3 Updates auf und konnte immer auf die gleiche Weise behoben werden.

Ich konnte nicht herausfinden, woher die falsche UUID stammt.

Was kann ich tun, damit das nicht wieder passiert?

2

Gestern abend wieder der gleiche Fehler mit demselben UUID nach:

sudo pacman -Syu

Und gleiche Reparatur hat wieder geholfen.

3

Das scheint die Lösung zu sein:
https://forum.endeavouros.com/t/loader-entries-resume-uuid-value-corrupted-on-system-update/54297/2
Die falsche UUID steht tatsächlich in

/etc/kernel/cmdline

Fragt sich nur, wo kommt die her?

4

Besser spät als nie…

In deiner /etc/kernel/cmdline ist eine resume UUID? Und diese existiert nicht?
Ist das so, wird der Grund nicht das Update selbst gewesen sein und auch nicht das eos-update script selbst.

Eine resume-UUID in der cmdline wird vermutlich die UUID einer Swap Partition sein, die bei der Installation eingerichtet wurde. Wird diese Partition entfernt oder neu erstellt, wird der Eintrag natürlich nicht mehr valide sein.

Entsprechend sollte da ein Eintrag in der /etc/fstab sein:
UUID=ddb36c9f-XXX swap swap defaults 0 0

Möglich, dass durch eine andere OS Installation, nachdem EndeavourOS installiert wurde, die Swappartition neu geschrieben wurde.

1 Like
5

Diese Einträge werden so weit ich weiss nur bei der initialen OS Installation erstellt.
Und die Natur einer UUID ist ja das sie unveränderlich bleibt.
Dies UUID stimmt ja mit keiner der UUIDS auf der Festplatte überein.

6

Danke für die Erklärung!

Ich kann das jetzt nicht mehr genau nachvollziehen. Aber ich habe damals auf der Suche, wo die falsche UUID herkommt, meine alten Backups durchforstet und gefunden, dass die “falsche” UUID eine inzwischen gelöschte Partition bezeichnete, die per clone auf eine neue Platte übertragen wurde und dort eine neue UUID bekam. Also Swap ist wohl nicht die Quelle. Der Hund liegt wohl in /etc/kernel/cmdline begraben, wo sich die Historie verewigt hat. Ich habe dann gefunden, dass es hilft, wenn man macht:

sudo rm /etc/kernel/cmdline
sudo reinstall-kernels

Bin jetzt aber nicht sicher, wie genau und unter welchen Bedingungen das funktiniert, dazu bin ich zu blöd.

7

entfernt ja alle kernel boot parameter die dort eingesetzt waren … auch parameter für resume

8

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.