14 Aug
2018
14 Aug
'18
10:42 a.m.
Am Dienstag, 14. August 2018 09:24 CEST, Uwe Kleine-König <uwe(a)kleine-koenig.org>
schrieb:
Genau, von dort sollten eig. die Module kommen ....
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? 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
14 Aug
14 Aug
1:51 p.m.
New subject: Notfall - Bootproblem
Am 14.08.2018 um 10:42 schrieb Ralf Mattes:
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
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
Am Dienstag, 14. August 2018 09:24 CEST, Uwe Kleine-König <uwe(a)kleine-koenig.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)
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.
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
--
Urs Liska
Glümerstr. 5
79102 Freiburg
+49(0)179-4642905
ul(a)openlilylib.org
3:50 p.m.
New subject: Notfall - Bootproblem
Am Dienstag, 14. August 2018 13:51 CEST, Urs Liska <ul(a)openlilylib.org> schrieb:
Du meinst denn 'ohne-X-(warum-auch-immer)-dubiose-module-installieren'-Weg? ;-)
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. 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(a)openlilylib.org
4:14 p.m.
New subject: Notfall - Bootproblem
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
2079
days inactive
2079
days old
3 comments
2 participants
participants (2)
-
Ralf Mattes -
Urs Liska