• [gelöscht]

Ich habe gestern mein Arch mit pacman geupdatet.

Befehl: pacman -Syyu

Nach einem Neustart bekomme ich die Meldung:
Warning: /lib/modules/3.14.4-1-ARCH/modules.devname not found - ignoring
ERROR: device 'UUID=...' not found. Skipping fsck.
ERROR: Unable to find root device 'UUID=...'.
You are being dropped to a recovery shell
Type 'exit' to try and continue booting
sh: can't access tty: job control turned off
Doch die Tastatur lässt sich nicht benutzen weder beim normalen bootimage noch bei fallback.

Habt ihr eine Idee was ich machen kann?

Danke!
  • [gelöscht]

Danke für die Information.

Damit auch nicht Französich sprechende wissen was getan werden muss, erläutere ich was ich gemacht habe.

Ich habe von einer Arch Linux CD gebootet danach root, home, und boot nacheinander gemounted und pacman -Syyu aufgeführt.
Sollte pacman -Syyu nicht den gewünschten erfolg bringen kann man auch den Kernel neu installieren pacman -S linux.

Danke nochmal!
10 Tage später
Ich habe ein Backup-System auf einer zweiten Partition und das läuft noch.
Wenn ich von dem boote, kann ich dann auf das "kaputte" System chroot-en und obige Kommandos ausführen ?

Weil ich hab gerade keine Rohlinge mehr da und mein Mainboard kann nicht von USB-Stick booten.
Wenn du davon booten kannst, kannst du das auch benutzen.
OK, vielleicht hab ich vorhin in der Eile die wichtigste Frage nicht explizit gestellt ...
Muss ich irgendwas beachten, um sicherzustellen, dass ich das Backup-System nicht versehentlich auch lahmlege ?

Also ich wollte das "produktiv"-System unter /arch_prod mounten und dann dorthin chroot-en. Ich habe auch schon einen Versuch gemacht, in dieser chroot-Umgebung nur nochmal
mkinitcpio -p linux
aufzurufen, weil ich dachte, dass vielleicht nur das schiefgegangen war. Dabei bekam ich aber die Fehlermeldung, dass /proc gemounted sein muss. Keine Ahnung, was er da nachschaut. Die geladenen Module kriegt man ja auch anders raus ...

Jdenfalls hat mich das mit /proc verunsichert.

Ab jetzt reines Gedankenspiel, habs noch nicht ausprobiert ...

Wenn ich jetzt /proc vom laufenden System über ein bind-mount in der chroot-Umgebung einhänge, habe ich ja doch eine Vermischung.
  • Falls das mkinitcpio aus /proc auch die Kernel-Version lesen sollte, trägt es ein falsches Verzeichnis für die Module ein, da das Backup-System ja auf einem älteren Kernel läuft.
  • Falls es das root-device ausliest, schreibt es was auf das Backup-System.
  • ... keine Ahnung was noch alles schief gehen kann ...

Und ich gehe mal davon aus, dass die Neu-Installation des Linux-Kernels ein mkinitcpio zwingend nach sich zieht.

Ich will halt auf keinen Fall mein Backup-System riskieren, denn wenn ich das lahmlege, ist der PC erst mal unbrauchbar und ich muss außer Haus eine Rescue-CD besorgen gehen.
Markus.N schrieb Also ich wollte das "produktiv"-System unter /arch_prod mounten und dann dorthin chroot-en. Ich habe auch schon einen Versuch gemacht, in dieser chroot-Umgebung nur nochmal
mkinitcpio -p linux
aufzurufen, weil ich dachte, dass vielleicht nur das schiefgegangen war. Dabei bekam ich aber die Fehlermeldung, dass /proc gemounted sein muss. Keine Ahnung, was er da nachschaut. Die geladenen Module kriegt man ja auch anders raus ...
Wie "chrootest" du denn? Mit "arch-chroot" (befindet sich im Paket "arch-install-scripts") werden alle wichtigen Verzeichnisse eingehängt, auch /proc.
Ich will halt auf keinen Fall mein Backup-System riskieren, denn wenn ich das lahmlege, ist der PC erst mal unbrauchbar und ich muss außer Haus eine Rescue-CD besorgen gehen.
Sowas hat man eigentlich immer für den Fall der Fälle griffbereit in der Schublade. Sich Gedanken zu machen wo/wie man eine Notfall-CD brennen kann wenn das produktive System nicht mehr läuft ist eigentlich eine schlechte Strategie.

Ich habe übrigens als "echtes Fallback" noch den LTS-Kernel (zur Zeit 3.10.43-1) installiert. Von dem kann man meistens sein produktives System noch booten und Reparaturmaßnahmen durchführen, falls der aktuelle Kernel sich mal unpässlich zeigen sollte.
Ah, arch-chroot hatte ich ganz vergessen ... die Installation ist schon ne Weile her ...
Ich habe das "normale" chroot genommen.

Ja, den lts-Kernel habe ich auch installiert, hat aber in dem Fall nix geholfen, weil bei dem gestrigen Update gleichzeitig linux und linux-lts dabei waren und jetzt beide kaputt sind. Deswegen dachte ich ja auch, dass es nicht an der Kernel-Version liegt, sondern dass beim Update-Prozess an sich was schiefgelaufen ist.

Gibt es denn eine einfache Möglichkeit, bei einem Update einmalig "alles außer linx-lts" einzuspielen ? Und zwar, ohne das Paket in die ignore-Liste einzutragen ? Falls nein, müsste echt was her ...
Weil wenn nach dem linux-update alles OK ist, kann man ja danach linux-lts einzeln updaten. Und ich möchte das nicht ständig rein in die Liste, raus aus der Liste ...
Markus.N schriebGibt es denn eine einfache Möglichkeit, bei einem Update einmalig "alles außer linx-lts" einzuspielen ? Und zwar, ohne das Paket in die ignore-Liste einzutragen ? Falls nein, müsste echt was her ...
Weil wenn nach dem linux-update alles OK ist, kann man ja danach linux-lts einzeln updaten. Und ich möchte das nicht ständig rein in die Liste, raus aus der Liste ...
Ja, das ist möglich indem du Pacman die Option auf der Kommandozeile übergibst:
pacman -Syu --ignore linux-lts
Ich frage mich sowieso was da los gewesen sein könnte; ich hatte den Kernel 3.14.4-1 seit 18.05. aktiv und es kam zu keinen Auffälligkeiten.
So, jetzt hab ich mein System auch repariert, und zwar zur Sicherheit von der Installations-CD.
Diese Aufgaben-Teilung werde ich beibehalten: Das Backup-System ist nur dafür da, um in solchen Fällen was Lauffähiges zu haben. Aber nicht für Reparaturarbeiten am "Produktiv"-System. Dazu nehm ich dann immer die CD.

Tipp an alle, die - wie ich - eigentlich keine Installations-CD's mehr bennen wollten: GRUB kann auch direkt vom .iso file loopback booten. Wie das geht, steht im GRUB-Artikel im Wiki:
https://wiki.archlinux.org/index.php/GRUB#Booting_ISO9660_image_file_directly_via_GRUB