ich bin seit einigen Monaten Wiedereinsteiger im arch-Universum und bin gerade etwas verloren, da ich durch ein Kernelupdate in der oben benannten Bootfalle hängen bleibe und nur noch in die dracut emergency shell rein komme.
Hier habe ich versucht, mit ‘e’ ‘systemd.unit=rescue.target’ (ohne ’ ') an die linux-Zeile anzuhängen, es folgt ein Fehler ‘119 missing esetparameter…’ (so ungefähr - kein Screenshot vorhanden).
Ich habe versucht, mit dem Installationsimage vom April zu booten. Möglicherweise verwende ich den falschen Ansatz:
- “Boot existing OS” funktioniert eh nicht, da direkt grub2 der Platte angesprochen wird.
- “EndeavourOS All GPU (BIOS)” läuft durch und ich kann dort eine Shell öffnen und /dev/sda2 nach /mnt/ mounten - klappt und ich kann in /mnt/@/… fast alles sehen, was ich so brauche. Mir gelang es, mich per arch-chroot dort reinzusetzen und die Befehle dracut-rebuild und reinstall-kernels auszuführen. Letzteres geht eh nicht, da ich aufgrund der grub2-Installation nur das eos-dracut-Paket installiert habe - hier finde ich den Ersatzbefehl nicht. Hat btrfs zu berücksichtigende Besonderheiten oder reicht ‘arch-chroot /mnt/@’?
Klar ist, dass /dev/sda2 (uuid …6855) beim Booten nicht reagiert.
Durch das Update habe ich mir zwei VMs (1x HyperV und 1x Proxmox) zerschossen und möchte jetzt erst einmal verstehen, wie ich das System jeweils wieder zum Laufen bewegen kann, bevor ich meinen Desktop auf den aktuellen Stand zu heben versuche. Vielleicht hat jemand eine Anleitung oder einen Hinweis parat, wie ich vorgehen muss.
Leider noch keine Anleitung. Vor zwei Tagen hatte nach einem update dracut rumgezickt und ca. 30 Sekundenu verzögert. Ein cold boot mit Ausschalten hat geholfen. Heute habe ich mit einem frischen ISO eine externe USB SSD bespielt. Gleich beim booten Dein Fehler.
Es gibt aktuell einen weiteren (englischen) thread dazu. Mal warten, wann die ersten Tipps oder fixes kommen. Vorerst würde ich nichts weiter “kaupttspielen”, da ich einen Bug vermute.
Ich kann zumindest vermelden, dass die Probleme sowohl beim Update der aktuellen systemd-Pakete als auch beim separaten Einspielen der Kernel lts oder 7.1.15 passieren.
Daher habe ich acht Pakete nicht aktualisiert und mir davon einen Snapshot erstellt.
Ich habe heute einen ähnlichen Fehler, dass nach einem pacman Syu meine externe SSD unendlich lange bei der Meldung “A start job is running for…” feststeckt. Ich hoffe es gibt bald einen fix dafür.
Ich habe es jetzt so gelöst, dass erst einmal alles bis auf systemd- und kernel-Pakete aktualisiert wird:
yay -Syu --ignore=linux-lts,linux-lts-headers,linux,linux-headers,linux-api-headers,systemd,systemd-resolvconf,systemd-libs,systemd-sysvcompat
Das in ein shellskript kopiert, ausführbar gemacht und alles ist gut. Bestimmt geht das auch eleganter, Verbesserungen nehme ich gerne.
Bei Debian konnte ich Pakete anpinnen und laufe so nicht in die Falle, mein Skript außer acht zu lassen: nano /etc/pacman.conf und dort die Zeile ignore zu entkommentieren und zu ergänzen.
Ich bin darauf gekommen, dass ich bei einer Neuinstallation vom Image aus dem April nicht habe aktualisieren lassen und siehe da, es bootet auch nach dem Befehl. Mit online-Aktualisierung ging das schief.
Damit kann ich jetzt auch an den Desktop gehen und meine anderen VMs auf den aktuellen Stand bringen. Ein Glück bieten die meisten VM-Hypervisor eine Snapshotfunktion.
Auf dem Desktop muss ich mich noch in btrfs einlesen, wie ich da auf ein lauffähiges Stadium zurück komme. Wenn jemand was dazu hat, nehme ich das gerne.
Nachdem ich mir den Nachmittag um die Ohren geschlagen habe, fiel mir bei der Rückkehr ins Forum der Beitrag von @quodroc auf, der es gewagt hat, dracut und eos-dracut zu entfernen und durch mkinitcpio zu ersetzen. systemd habe ich mit dem Update erneuert.
Siehe da, es klappt mit den Updates und einem Reboot.
Einzig bei der Ausführung von mkinitcpio erhalte ich nachstehende Fehler, weiß jemand, was ich da machen muss?
Finde es persönlich ziemlich riskant, einfach so dracut durch mkinitcpio zu ersetzen, weiß nicht ob das auf dauer gutgehen wird, kenne mich da aber ehrlich gesagt nicht genug für aus. Ich habe eine Lösung in meinem englischen Thread gepostet wo man “nur” die Treiber beim Boot-Prozess zur Verfügung stellen muss. Ist m.M.n. die leichteste und am wenigsten riskanteste Variante: A start job is running for /dev/disk/<uui> running for 5min+ - #8 by 71387
Das schöne an VM und snapshot ist ja gerade, dass beide Wege ausprobiert werden können. Jetzt wissen wir aus einem anderen Thread, dass auf dracut 112 zu warten ist - ist erst gestern in Umlauf gekommen, habe es aber auch nicht auf testing gesehen. Bin mal gespannt, ob’s am Ende der Woche im Pöttchen ist und hoffentlich als gelöst markiert werden kann.
melde erfreut: dracut 112 ist online und Updates sind problemlos möglich. Dann kann ich mich morgen ans Update für den Desktoprechner machen, der ‘Umweg’ über mkinitcpio ist nicht mehr nötig.
Spaßes halber habe ich den bereits umgestellten VM-Snapshot auf dracut umgestellt und siehe da, klappt auch.
