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.
Wie sieht denn die Ausgabe von
ls -l /lib/modules/4.17.0-1-amd64/
aus?
Genau, von dort sollten eig. die Module kommen ....
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
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
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
Am Dienstag, 14. August 2018 13:51 CEST, Urs Liska ul@openlilylib.org schrieb:
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)
Nun ja, wenn Dein Kernel keine Module hat wird so ziemlich viel niht mehr funktionieren.
[ ... ]
Wie sieht denn die Ausgabe von
ls -l /lib/modules/4.17.0-1-amd64/
aus?
Genau, von dort sollten eig. die Module kommen ....
Wahrscheinliche wäre:
find /lib/modules/4.17.0-1-amd64/ -name '*.ko'
besser, dann siehst Du welche Module überhaupt vorhanden sind.
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
Also ist vfat nicht im Kernel selbst (buildin). Die Frage ist nur: warum hat Dein System nicht mitbekommen dass das Kernelpaket nicht vollständig entpackt/installiert wurde.
[...]
$ 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.
Du meinst denn 'ohne-X-(warum-auch-immer)-dubiose-module-installieren'-Weg? ;-)
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?
Kernel installiere ich generell _immer_ _nur_ manuell. Nach einem Kernel-Install muss die Kiste ja sowieso neu gebootet werden. Das möchte ich schon wissen. Generell: ich habe nirgens auto-update aktiviert. Was ich mache: ich habe überall apticron installiert, der macht einmal am Tag ein 'apt-get update' und schickt mir eine freundliche Mail wenn's was neues zu installieren gibt (samt Zusammenfassung was sich geändert hat und warum). Dann kann ich mir das überlegen und ggf. auf den entsprechenden Kisten mit 'aptitude dist-upgrade' einspielen.
Gruss RalfD
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
-- Urs Liska Glümerstr. 5 79102 Freiburg +49(0)179-4642905 ul@openlilylib.org
Noch einen kleinen Nachtrag/Nachschlag nach all dem Gelästere über Dein WLAN-Modul. Du wirst Dir wahrscheinlich einiges an Update-Ärger ersparen wenn Du Dir mal dkms anschaust. Damit kannst Du Kernelmodule für alle installierten Kernel bauen. Besonders schön daran: wenn Du (oder Dein System) einen neuen Kernel installierst dann wird automatisch versucht dafür das/die Module neu zu bauen un zu installieren. Hier noch ein Link auf eine just-enough-info Einführung:
http://xmodulo.com/build-kernel-module-dkms-linux.html
N.B.: bei Debian ist seit einiger Zeit '/usr/sbin' nicht mehr in Non-Root Pfad (grrr, catering the stupid), Du must also als Normalsterblicher /usr/sbin/dkms aufrufen,
Gruss RalfD
-
Ralf Mattes -
Urs Liska