Bei meinem Laptop muss nach jedem Kernelupdate der Wlan-Treiber neu installiert werden, und zwar von der nichtgrafischen Konsole.
Währenddessen blieb der Rechner hängen, und ich habe ihn ausgeschaltet. Seither bootet er nicht mehr - mit den Symptomen, die auf dem Foto https://cloud.ursliska.de/s/tQcWy1EHq6c6iVT zu sehen sind.
Geben euch die irgendwelche Hinweise auf eine Ursache? Wie kann ich denn jetzt weitersuchen?
Danke Urs
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Sat, Aug 11, 2018 at 08:54:10AM +0200, Urs Liska wrote:
Bei meinem Laptop muss nach jedem Kernelupdate der Wlan-Treiber neu installiert werden, und zwar von der nichtgrafischen Konsole.
Währenddessen blieb der Rechner hängen, und ich habe ihn ausgeschaltet. Seither bootet er nicht mehr - mit den Symptomen, die auf dem Foto https://cloud.ursliska.de/s/tQcWy1EHq6c6iVT zu sehen sind.
Du meinst
This application requires JavaScript for correct operation. Please enable JavaScript and reload the page.
Tsk, tsk. Laptops brauchen dieser Tage Javascript zum Booten. O tempora, o mores.
(Jaja, ich weiss -- ich konnte es mir trotzdem nicht verkneifen).
lg - -- t
Am Samstag, 11. August 2018 08:54 CEST, Urs Liska ul@openlilylib.org schrieb:
Bei meinem Laptop muss nach jedem Kernelupdate der Wlan-Treiber neu installiert werden, und zwar von der nichtgrafischen Konsole.
??? Irgendwann musst Du mir erklären warum das nicht aus eine X-Term gehen soll ....
Währenddessen blieb der Rechner hängen, und ich habe ihn ausgeschaltet.
Hmmm.
Seither bootet er nicht mehr - mit den Symptomen, die auf dem Foto https://cloud.ursliska.de/s/tQcWy1EHq6c6iVT zu sehen sind.
Geben euch die irgendwelche Hinweise auf eine Ursache? Wie kann ich denn jetzt weitersuchen?
Da fehlen ein paar wichtige Hinweise: welche Distro nutzt Du? Die Fehlermeldung ist ja recht klar - da wird versucht /boot/efi zu mounten und das schlägt fehl. Ab dann bootet da nur noch ein Rescue-System (beachtlich was die - trotz dependecy checks im ach-so-tollen Systemd noch alles hochfahren). Was sagt den 'systemctl status boot-efi.mount'?
Gruss RalfD
Danke Urs
Am 11.08.2018 um 10:44 schrieb Ralf Mattes:
Am Samstag, 11. August 2018 08:54 CEST, Urs Liska ul@openlilylib.org schrieb:
Bei meinem Laptop muss nach jedem Kernelupdate der Wlan-Treiber neu installiert werden, und zwar von der nichtgrafischen Konsole.
??? Irgendwann musst Du mir erklären warum das nicht aus eine X-Term gehen soll ....
Kann ich nicht, das steht im README zu dem Treiber. Wenn man ihn im Terminal unter dem normalen Desktop istalliert, friert der Rechner ein...
Währenddessen blieb der Rechner hängen, und ich habe ihn ausgeschaltet.
Hmmm.
Seither bootet er nicht mehr - mit den Symptomen, die auf dem Foto https://cloud.ursliska.de/s/tQcWy1EHq6c6iVT zu sehen sind.
Geben euch die irgendwelche Hinweise auf eine Ursache? Wie kann ich denn jetzt weitersuchen?
Da fehlen ein paar wichtige Hinweise: welche Distro nutzt Du?
Debian Testing.
Die Fehlermeldung ist ja recht klar - da wird versucht /boot/efi zu mounten und das schlägt fehl. Ab dann bootet da nur noch ein Rescue-System (beachtlich was die - trotz dependecy checks im ach-so-tollen Systemd noch alles hochfahren). Was sagt den 'systemctl status boot-efi.mount'?
Das werde ich mir am Montag ansehen, wenn ich wieder Zugriff auf dieses Laptop habe.
Gruß Urs
Gruss RalfD
Danke Urs
Hallo Urs,
On 08/11/2018 08:54 AM, Urs Liska wrote:
Bei meinem Laptop muss nach jedem Kernelupdate der Wlan-Treiber neu installiert werden, und zwar von der nichtgrafischen Konsole.
Währenddessen blieb der Rechner hängen, und ich habe ihn ausgeschaltet. Seither bootet er nicht mehr - mit den Symptomen, die auf dem Foto https://cloud.ursliska.de/s/tQcWy1EHq6c6iVT zu sehen sind.
Geben euch die irgendwelche Hinweise auf eine Ursache? Wie kann ich denn jetzt weitersuchen?
Wenn Ralfs Tipp mit "systemctl status boot-efi.mount" nicht was offensichtliches aufzeigt, probiere mal in die /etc/fstab "nofail" zu den Optionen von /boot/efi hinzuzufügen.
Liebe Grüße Uwe
Am 11.08.2018 um 17:38 schrieb Uwe Kleine-König:
Hallo Urs,
On 08/11/2018 08:54 AM, Urs Liska wrote:
Bei meinem Laptop muss nach jedem Kernelupdate der Wlan-Treiber neu installiert werden, und zwar von der nichtgrafischen Konsole.
Währenddessen blieb der Rechner hängen, und ich habe ihn ausgeschaltet. Seither bootet er nicht mehr - mit den Symptomen, die auf dem Foto https://cloud.ursliska.de/s/tQcWy1EHq6c6iVT zu sehen sind.
Geben euch die irgendwelche Hinweise auf eine Ursache? Wie kann ich denn jetzt weitersuchen?
Wenn Ralfs Tipp mit "systemctl status boot-efi.mount" nicht was offensichtliches aufzeigt,
Ich vermute, die relevante Zeile ist mount: /boot/efi; unknown filesystem type 'vfat'
Danach zu suchen brachte mich auf https://bbs.archlinux.org/viewtopic.php?id=152284 und die Vermutung, dass ein fehlerhaftes (unterbrochenes?) Kernel-Update das Problem sein könnte (mein *Eindruck* war ja irgendein Hardware-Kollaps, weshalb ich mir keine größeren Hoffnungen machte...)
Und tatsächlich lässt sich der Rechner mit dem vorigen Kernel (aus dem GRUB-Menü) booten.
Der funktionierende Kernel ist
$uname -a Linux ... 4.16.0-2-amd64 #+1 SMP Debian 4.16.12-1
der nicht-funktionierende (laut GRUB) 4.17.0-1-amd64
So, das heißt also, ich muss mich nicht mit einer zerschossenen Partitionstabelle oder sowas rumschlagen, sondern "nur" die Kernel-Installation reparieren. Bevor ich jetzt aber was Falsches und Alles nur noch schlimmer mache:
Wäre es richtig, einfach vom funktionierenden Boot aus ein apt update && apt upgrade zu machen? Oder zerschieße ich damit endgültig etwas?
probiere mal in die /etc/fstab "nofail" zu den Optionen von /boot/efi hinzuzufügen.
Liebe Grüße Uwe
Urs Liska ul@openlilylib.org hat am 13. August 2018 um 22:44 geschrieben:
Am 11.08.2018 um 17:38 schrieb Uwe Kleine-König:
Hallo Urs,
On 08/11/2018 08:54 AM, Urs Liska wrote:
Bei meinem Laptop muss nach jedem Kernelupdate der Wlan-Treiber neu installiert werden, und zwar von der nichtgrafischen Konsole.
Währenddessen blieb der Rechner hängen, und ich habe ihn ausgeschaltet. Seither bootet er nicht mehr - mit den Symptomen, die auf dem Foto https://cloud.ursliska.de/s/tQcWy1EHq6c6iVT zu sehen sind.
Geben euch die irgendwelche Hinweise auf eine Ursache? Wie kann ich denn jetzt weitersuchen?
Wenn Ralfs Tipp mit "systemctl status boot-efi.mount" nicht was offensichtliches aufzeigt,
Ich vermute, die relevante Zeile ist mount: /boot/efi; unknown filesystem type 'vfat'
Danach zu suchen brachte mich auf https://bbs.archlinux.org/viewtopic.php?id=152284 und die Vermutung, dass ein fehlerhaftes (unterbrochenes?) Kernel-Update das Problem sein könnte (mein *Eindruck* war ja irgendein Hardware-Kollaps, weshalb ich mir keine größeren Hoffnungen machte...)
Und tatsächlich lässt sich der Rechner mit dem vorigen Kernel (aus dem GRUB-Menü) booten.
Der funktionierende Kernel ist
$uname -a Linux ... 4.16.0-2-amd64 #+1 SMP Debian 4.16.12-1
der nicht-funktionierende (laut GRUB) 4.17.0-1-amd64
dann ist es kein großen Probelm, du kannst einfach den default kernel in der Grubconfig auf 4.16 setzten und wieder booten.
So, das heißt also, ich muss mich nicht mit einer zerschossenen Partitionstabelle oder sowas rumschlagen, sondern "nur" die Kernel-Installation reparieren. Bevor ich jetzt aber was Falsches und Alles nur noch schlimmer mache:
Wäre es richtig, einfach vom funktionierenden Boot aus ein apt update && apt upgrade zu machen? Oder zerschieße ich damit endgültig etwas?
die spannende frage ist: was ist passiert ? mit einem grub update wird man "nur" einen zweiten installationsversuch machen. Gibt es genügend speicher ? sind alle sektoren lesbar ?
re, wh
probiere mal in die /etc/fstab "nofail" zu den Optionen von /boot/efi hinzuzufügen.
Liebe Grüße Uwe
-- Urs Liska Glümerstr. 5 79102 Freiburg +49(0)179-4642905 ul@openlilylib.org
Am 13.08.2018 um 22:54 schrieb Walter Harms:
Urs Liska ul@openlilylib.org hat am 13. August 2018 um 22:44 geschrieben:
Am 11.08.2018 um 17:38 schrieb Uwe Kleine-König:
Hallo Urs,
On 08/11/2018 08:54 AM, Urs Liska wrote:
Bei meinem Laptop muss nach jedem Kernelupdate der Wlan-Treiber neu installiert werden, und zwar von der nichtgrafischen Konsole.
Währenddessen blieb der Rechner hängen, und ich habe ihn ausgeschaltet. Seither bootet er nicht mehr - mit den Symptomen, die auf dem Foto https://cloud.ursliska.de/s/tQcWy1EHq6c6iVT zu sehen sind.
Geben euch die irgendwelche Hinweise auf eine Ursache? Wie kann ich denn jetzt weitersuchen?
Wenn Ralfs Tipp mit "systemctl status boot-efi.mount" nicht was offensichtliches aufzeigt,
Ich vermute, die relevante Zeile ist mount: /boot/efi; unknown filesystem type 'vfat'
Danach zu suchen brachte mich auf https://bbs.archlinux.org/viewtopic.php?id=152284 und die Vermutung, dass ein fehlerhaftes (unterbrochenes?) Kernel-Update das Problem sein könnte (mein *Eindruck* war ja irgendein Hardware-Kollaps, weshalb ich mir keine größeren Hoffnungen machte...)
Und tatsächlich lässt sich der Rechner mit dem vorigen Kernel (aus dem GRUB-Menü) booten.
Der funktionierende Kernel ist
$uname -a Linux ... 4.16.0-2-amd64 #+1 SMP Debian 4.16.12-1
der nicht-funktionierende (laut GRUB) 4.17.0-1-amd64
dann ist es kein großen Probelm, du kannst einfach den default kernel in der Grubconfig auf 4.16 setzten und wieder booten.
So, das heißt also, ich muss mich nicht mit einer zerschossenen Partitionstabelle oder sowas rumschlagen, sondern "nur" die Kernel-Installation reparieren. Bevor ich jetzt aber was Falsches und Alles nur noch schlimmer mache:
Wäre es richtig, einfach vom funktionierenden Boot aus ein apt update && apt upgrade zu machen? Oder zerschieße ich damit endgültig etwas?
die spannende frage ist: was ist passiert ? mit einem grub update wird man "nur" einen zweiten installationsversuch machen.
OK, das hatte ich auch vermutet. Eine Sache könnte ich mir vorstellen: Möglicherweise lief, während ich die Wifi-Firmware kompilierte und installierte, im Hintergrund ein `apt upgrade` (ich weiß gerade nicht, ob ich bei *diesem* Laptop die automatischen Updated deaktiviert habe oder nicht), das durch den "Hardware-Shutdown" an einer kritischen Stelle unterbrochen war.
Gibt es genügend speicher ? sind alle sektoren lesbar ?
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
Ich bin gespannt, was der Rechner beim nächsten Neustart von sich geben wird ...
re, wh
probiere mal in die /etc/fstab "nofail" zu den Optionen von /boot/efi hinzuzufügen.
Liebe Grüße Uwe
-- Urs Liska Glümerstr. 5 79102 Freiburg +49(0)179-4642905 ul@openlilylib.org
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
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 nicht funktioniert.
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.)
Wenn das das Problem auch triggert, dann kannst Du ja mal:
sudo sh -x /usr/sbin/update-initramfs -k 4.17.0-1 -u
machen und die Ausgabe entweder hier oder in einem bugreport an initramfs-tools abkippen. Ich vermute das find, das oben kaputt geht, kommt aus mkinitramfs.
Liebe Grüße Uwe
-
Ralf Mattes -
tomas＠tuxteam.de -
Urs Liska -
Uwe Kleine-König -
Walter Harms