Am 14.08.2018 um 10:42 schrieb Ralf Mattes:
Am Dienstag, 14. August 2018 09:24 CEST, Uwe Kleine-König uwe@kleine-koenig.org schrieb:
Hallo Urs,
On 08/13/2018 11:20 PM, Urs Liska wrote:
Ich habe gerade ein Update gemacht. Zuletzt sagte es mir:
Trigger für initramfs-tools (0.132) werden verarbeitet ... update-initramfs: Generating /boot/initrd.img-4.17.0-1-amd64 find: ‘/var/tmp/mkinitramfs_lCHsSK/lib/modules/4.17.0-1-amd64/kernel’: Datei oder Verzeichnis nicht gefunden
Hmm - dann fehlen dem Kernel die Module, u.a. auch das um vfat-Dateisysteme zu lesen.
Ich bin gespannt, was der Rechner beim nächsten Neustart von sich geben wird ...
Nach der Fehlermeldung würde ich erwarten, dass 4.17 weiterhin nichtfunktioniert.
OK, nicht unerwartet scheitert das Booten, aber nun anders. In einer Schleife wird eine Weile lang (bis zur Aufgabe) ausgegeben:
WARNING: Failed to connect to lvmetad. Falling back to device scanning. Volume group "hanna-debian-laptop-vg" not found
(die erste Meldung kommt aber auch beim erfolgreichen Boot)
Schließlich:
Gave up waiting for root file system device. ... ALERT! /dev/mapper/hanna--debian--laptop--vg-root does not exist. Dropping to a shell!
Diese shell hat dann (initramfs) als Prompt.
Wie sieht denn die Ausgabe von
ls -l /lib/modules/4.17.0-1-amd64/
aus?
Genau, von dort sollten eig. die Module kommen ....
Nun wieder vom funktionierenden Boot aus:
da steht einiges: - Links "build" und "source" - Verzeichnis "kernel" - modules.NN mit - alias - alias.bin - builtin - builtin.bin - dep - dep.bin - devname - order - softdep - symbols - symbols.bin wobei alle außer modules.builtin und modules.order leer sind.
$ grep vfat * in diesem Verzeichnis bringt: modules.order:kernel/fs/fat/vfat.ko
Ist /var/tmp ein tmpfs das voll läuft? Oder ist der Kernel nicht> vollständig installiert? (-> "sudo apt install" ohne weitere Parameter) Kannst Du das Problem mit
sudo update-initramfs -k 4.17.0-1 -u
auch triggern? (Das ist im Prinzip, was das post-install-Skript macht.)
Ich würde ja einfach den 4.17er komplett deinstallieren und dann nochmals installieren;
$ sudo aptitude purge linux-image-4.17.0-1-amd64 $ sudo aptitude install linux-image-4.17.0-1-amd64
Gut, das habe ich jetzt gemacht, und dazwischen alles aktualisiert.
Anschließend stand 4.17.0-1 wieder als erstes in der GRUB-Liste und bootete korrekt. Wie erwartet war das Wifi erstmal weg, konnte aber auf dem normalen weg nachinstalliert werden.
Normalerweise installiere ich ja nicht manuell neue Kernel. Bleibt die GRUB-Konfiguration bzw. das mit den Kerneln jetzt automatisch richtig, bekomme ich also einen neuen Kernel wieder automatisch oder habe ich das durch das manuelle Entfernen/Installieren irgendwie unterbrochen?
Erst einmal herzlichen Dank an alle schon mal, es funktioniert wieder! Gruß Urs
Ich würde mir auch mal die Konfigurationsdateien für das initramfs ansehen, also in /etc/initramfs-tools sowohl update-initramfs.conf als auch initramfs.conf. In letzterer ist besonders der Eintrag MODULES interessant. ACHTUNG: bei Debian gibt's noch das Verzeichnis conf.d, da stehen dann u.U. Anpassungen welche die Einstellungen in initramfs.conf überschreiben! Du kannst auch zur Sicherheit 'vfat' in /etc/initramfs-tools/modules eintragen.
Gruss RalfD