11 Aug
2018
11 Aug
'18
8:54 a.m.
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
11 Aug
11 Aug
9:48 a.m.
-----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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iEYEARECAAYFAltulOgACgkQBcgs9XrR2kbG/QCeOvLde+wPs1AVyGtXwIyBtohW
EIUAn1dPYhmrJ2Dx/6HAtdDcudeIyavj
=p6gK
-----END PGP SIGNATURE-----
10:44 a.m.
Am Samstag, 11. August 2018 08:54 CEST, Urs Liska <ul(a)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
11:08 a.m.
Am 11.08.2018 um 10:44 schrieb Ralf Mattes:
Debian Testing.
Am Samstag, 11. August 2018 08:54 CEST, Urs Liska <ul(a)openlilylib.org> schrieb:
Kann ich nicht, das steht im README zu dem Treiber. Wenn man ihn im
Terminal unter dem normalen Desktop istalliert, friert der Rechner ein...
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'?
Das werde ich mir am Montag ansehen, wenn ich wieder Zugriff auf dieses
Laptop habe.
Gruß
Urs
Gruss RalfD
--
Urs Liska
Glümerstr. 5
79102 Freiburg
+49(0)179-4642905
ul(a)openlilylib.org
Danke
Urs
5:38 p.m.
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
13 Aug
13 Aug
10:44 p.m.
Am 11.08.2018 um 17:38 schrieb Uwe Kleine-König:
Hallo Urs,
On 08/11/2018 08:54 AM, Urs Liska wrote:
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?
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
--
Urs Liska
Glümerstr. 5
79102 Freiburg
+49(0)179-4642905
ul(a)openlilylib.org
10:54 p.m.
Urs Liska <ul(a)openlilylib.org> hat am 13. August
2018 um 22:44 geschrieben:
Am 11.08.2018 um 17:38 schrieb Uwe Kleine-König:
dann ist es kein großen Probelm, du kannst einfach den
default kernel in der Grubconfig auf 4.16 setzten und wieder booten.
Hallo Urs,
On 08/11/2018 08:54 AM, Urs Liska wrote:
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
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,
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(a)openlilylib.org
11:20 p.m.
Am 13.08.2018 um 22:54 schrieb Walter Harms:
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.
Urs Liska <ul(a)openlilylib.org> hat am 13.
August 2018 um 22:44 geschrieben:
Am 11.08.2018 um 17:38 schrieb Uwe Kleine-König:
dann ist es kein großen Probelm, du kannst einfach den
default kernel in der Grubconfig auf 4.16 setzten und wieder booten.
Hallo Urs,
On 08/11/2018 08:54 AM, Urs Liska wrote:
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
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, 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
?
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(a)openlilylib.org
>
14 Aug
14 Aug
9:24 a.m.
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
2083
days inactive
2086
days old
8 comments
5 participants
participants (5)
-
Ralf Mattes -
tomas＠tuxteam.de -
Urs Liska -
Uwe Kleine-König -
Walter Harms