Fwd: Ubuntu: Bootproblem auf neuer Hardware

2022-07-22 Diskussionsfäden Wolf-R . Müller

Hallo allerseits,

ich möchte abschließend kurz informieren, daß sich mein u. a. Problem (nochmal 
Danke für die verschiedenen Beiträge) nun von selbst geklärt hat.

Meine Überlegung unter 1) hat sich letztendlich bewahrheitet. Nach weiteren 
diversen Releases mit Kernel 5.13.0 (alle mit demselben Problem) gab's dann für 
20.04.4 auf einmal ein Update auf einen neuen Kernel 5.15.0, mit dem sich bei 
mir ab Release 5.15.0-41 dann das Problem in Luft aufgelöst hat.

Gruß Wolf
Niederkassel

--
Mein öffentlicher PGP-Schlüssel 
<https://share.mailbox.org/ajax/share/05f9f4aa0d3c7a475c4c061d3c7a43d2b607c29e03d6350f/1/8/MzA>

 Weitergeleitete Nachricht 
Betreff:    Ubuntu: Bootproblem auf neuer Hardware
Datum:  Sun, 12 Jun 2022 15:21:11 +0200
Von:Wolf-R. Müller 
Antwort an: trolug@trolug.de
An: Trolug-Liste 



Hallo allerseits,

Ich habe mir kürzlich beim lokalen PC-Händler ein neues System zugelegt (i5, s. 
Anhang), mit dem ich ein unerwartetes Problem habe, zu dem ich einen Rat suche.

Im Vorfeld hatte ich auf meinem alten DELL-System (Praxissystem Xubuntu 
18.04.6) damit begonnen, ein Xubuntu 20.04 neu aufzusetzen, nebst einem Ubuntu 
20.04 auf einer separaten HD als Test- und Servicesystem. Mit dem Upgrade auf 
22.04 wollte ich erst noch einige Zeit warten, bis sich 22.04 konsolidiert hat.

Mit diesem Xubuntu 20.04.4 mit Kernel 5.13.0-37 hatte ich dann den neuen PC vor 
Abnahme verifiziert - also daß darauf Xubuntu einwandfrei läuft - und gut war. 
Dachte ich.
Aber PROBLEM:
Zwischenzeitlich hatte ich dieses System auf dem alten Rechner routinemäßig auf 
Kernel 5.13.0-41 geupdated. Und dieses System läßt sich auf dem neuen PC nun nicht 
mehr booten, hängt beim Hochfahren (Start initramfs). FAZIT diverser Versuche: Die 
Demarkationslinie zwischen System bootet / bootet nicht liegt bei den Kerneln 
5.13.0-40 / 5.13.0-41, sowohl bei Ubuntu wie bei Xubuntu, unabhängig davon, auf 
welchem System das Update von Release A < 5.13.0-41 auf Release B > 5.13.0-40 
erfolgt ist.

Dann dachte ich mir:
1) OK, ein Release kann mal ein Problem haben, das sich dann bei einem nächsten 
Update auswächst. Dies ist aber nicht der Fall: Inzwischen ist Release 
5.13.0-48 das aktuelle, und das Problem besteht nach wie vor.
2) Es ist vielleicht nicht sinnig, ein neues System auf 14 Jahre alter Hardware 
aufzusetzen, um es dann auf aktueller Hardware zu nutzen, und daß darin begründet  
evtl. irgendeine Hakelei vergraben sein könnte. Also habe ich AUF DEM NEUEN System 
auf einer separaten HD nochmal Ubuntu und Xubuntu jeweils in den Versionen 20.04 und 
22.04 NEU installiert (ISOs mit Releases < 5.13.0-40) und anschließend auf die 
jeweils aktuellen Releases > 5.13.0-40 geupdated. FAZIT:
- 20.04: Releases älter als 5.13.0-41 booten wie gehabt, neuere nicht.
- 22.04: Ubuntu wie Xubuntu booten einwandfrei.

Ich möchte meine Mail nicht mit weiteren Details überfrachten (nutzloses 
Grub-Debug), und im erstem Schritt einfach mal fragen, ob sich jmd. einen Reim 
auf den geschilderten Sachverhalt machen kann.

Der Königsweg bestünde natürlich darin, daß ich gleich auf 22.04 gehe, dabei 
bliebe aber ein ungutes Gefühl zurück. Ich hätte die Ursache für das Problem 
schon gerne verstanden und beseitigt und 20.04 'im Griff' (und nicht umgekehrt).

Also dankbar für jede Idee ...

Gruß Wolf,
Niederkassel

--
Mein öffentlicher PGP-Schlüssel 
<https://share.mailbox.org/ajax/share/05f9f4aa0d3c7a475c4c061d3c7a43d2b607c29e03d6350f/1/8/MzA>

wolf@DELL:~$ lscpu
Architektur:   i686
CPU Operationsmodus:   32-bit, 64-bit
Byte-Reihenfolge:  Little Endian
CPU(s):8
Liste der Online-CPU(s):   0-7
Thread(s) pro Kern:1
Kern(e) pro Socket:6
Sockel:1
Anbieterkennung:   GenuineIntel
Prozessorfamilie:  6
Modell:165
Modellname:Intel(R) Core(TM) i5-10400 CPU @ 2.90GHz
Stepping:  3
CPU MHz:   2804.070
Maximale Taktfrequenz der CPU: 4300,
Minimale Taktfrequenz der CPU: 800,
BogoMIPS:  5799.77
Virtualisierung:   VT-x
L1d Cache: 32K
L1i Cache: 32K
L2 Cache:  256K
L3 Cache:  12288K
Markierungen:  fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg fma cx16 xtpr pdcm sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault ssbd ibrs ibpb stibp ibrs_enhanced tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid mpx rdseed adx smap clflushopt intel_pt

Re: Fwd: Fwd: Ubuntu: Bootproblem auf neuer Hardware

2022-06-29 Diskussionsfäden Wolf-R . Müller

Hallo Torben,

vielen Dank für den interessanten Link! Ich habe mal einen Arduino mittels 
PuTTY an Linux angebunden, ging gut, lange her.

Bis Grub & Kernel erfolgreich mit dem Client sprechen, werden einem sicherlich 
'ne Menge Knüppel zwischen die Beine geschmissen. Als ultima ratio durchaus ein 
Rettungsanker, zunächst drücke ich mich da aber lieber mal, da das mich treibende 
letztendlich akademische Interesse an dem Problem (s. parallele Mail an @Jonas) den 
Verschleiß an Nerven und Zeit erst einmal nicht rechtfertigt.

Gruß Wolf
Niederkassel

--
Mein öffentlicher PGP-Schlüssel 
<https://share.mailbox.org/ajax/share/05f9f4aa0d3c7a475c4c061d3c7a43d2b607c29e03d6350f/1/8/MzA>


Am 25.06.22 um 14:19 schrieb Torben Keil:

Hallo Wolf,
Du könntest versuchen, die Bootmeldungen direkt auf einem TTY-Device auszugeben.

Schau mal hier, dort wird das näher erläutert.

https://wiki.archlinux.org/title/working_with_the_serial_console


Viele Grüße,
Torben

Am 25. Juni 2022 13:28:00 MESZ schrieb "Wolf-R. Müller" :

Sorry, das war wohl nix mit dem Link. 
nochmal:https://c.gmx.net/@340439481158992671/-xpduo7ARFGN0Ugkqylk_A

--
Mein öffentlicher PGP-Schlüssel 
<https://share.mailbox.org/ajax/share/05f9f4aa0d3c7a475c4c061d3c7a43d2b607c29e03d6350f/1/8/MzA>

 Weitergeleitete Nachricht 
    Betreff:    Fwd: Ubuntu: Bootproblem auf neuer Hardware
Datum:  Sat, 25 Jun 2022 13:25:32 +0200
Von:Wolf-R. Müller
An: Trolug-Liste



Da capo ... Attachments zu groß -> 
hier
  finden sich jetzt die zitierten Anlagen.

Ich hoffe, das geballte Linux-KnowHow dieser Community hilft, Licht in's 
Dunkel dieses Mysteriums zu bringen ...

Gruß wolf

--
Mein öffentlicher PGP-Schlüssel 
<https://share.mailbox.org/ajax/share/05f9f4aa0d3c7a475c4c061d3c7a43d2b607c29e03d6350f/1/8/MzA>

 Weitergeleitete Nachricht ----
Betreff:    Fwd: Ubuntu: Bootproblem auf neuer Hardware
Datum:  Fri, 24 Jun 2022 17:03:59 +0200
Von:Wolf-R. Müller
An: Trolug-Liste



Hallo allerseits,

    Bezug: Mail 'Ubuntu: Bootproblem auf neuer Hardware' vom 12.06.22
Update: Mittlerweile ist Kernel 5.13.0-51 in Betrieb mit dem gleichen 
Fehlerbild wie nachfolgend für 5.13.0-48 dokumentiert.

<... melde mich danach mit den zusätzlichen Infos von lspci & Co.>
Bevor ich dazu komme, aus aktuellem Anlaß zwei allgemeine Fragen in die 
Community:

1) Wie kann man, wenn man QUIET im Grub-Menu ausschaltet, die Ausgaben von 
Kernel-Meldungen Bildschirmweise bremsen, also a la ' | more'? So werden einem 
die Ausgaben um die Ohren gehauen ohne daß man eine Chance hat, sich das in 
Ruhe anzuschauen und insbesondere Normal- und Fehlerfall schrittweise zu 
vergleichen.

2) Zu Kernel Debug-Parametern aushttps://wiki.ubuntuusers.de/Bootoptionen/
Weiß jemand, Wohin 'BOOT_DEBUG=2 / 3' Ihren Output schreiben?
Zu 'debug' s. u..


Leitfaden zu meinen Attachments:
a) Die beiden PDFs zeigen im Normal- wie Fehlerfall, was man an Infos 
ierhält, wenn man QUIET in Grub ausschaltet.

b) initramfs.debug zeigt bei ordentlich bootendem System den Output unter 
/run/initramfs/, wenn man den o. a. Kenelparameter 'debug' aktiviert.
Wenn man das System 'runterfährt, wird /run/initramfs/ automatisch 
gelöscht. Man muß sich den File also ggfs. vorher weg kopieren.
Hoffnung:
Bei NICHT bootendem System wird auch so ein Debug-File generiert, den man 
dann von einem parallelen System aus (z. B. Live-System) sichern und dann mit 
dem Debug-File vom Normalstart vergleichen kann. Das passiert aber nicht: Es 
gibt in dem Fall kein /run/iniŕamfs/ ... clever gemacht!

c) Drei Logs zu den von @Jonas angefragten Zusatzinfos. Interessant, für 
mich als Dummi aber nutzlos.


Wäre schön, falls noch jmd. einen erhellenden Geistesblitz hat ...

Gruß Wolf
Niederkassel

--
Mein öffentlicher 
PGP-Schlüssel<https://share.mailbox.org/ajax/share/05f9f4aa0d3c7a475c4c061d3c7a43d2b607c29e03d6350f/1/8/MzA>

 Weitergeleitete Nachricht ----
Betreff:Re: Ubuntu: Bootproblem auf neuer Hardware
Datum:  Mon, 13 Jun 2022 18:03:24 +0200
Von:Wolf-R. Müller
Antwort an: trolug@trolug.de
An: trolug@trolug.de



Hallo zusammen,

@Werner:
Interessant & gräßlich. Daß etwas generell nicht funktioniert, ist eine 
Sache. Bei mir ist's ja verwirrender: Mit Release A geht's ja, also gibt es kein 
grundsätzliches Problem. Erst nach turnusmäßigem Update auf's nächste Release B 
geht's nicht mehr ... -!?!-

@Jonas:
Ich muß meine unbefriedigenden Debug-Ergebnise mal ordentlich zusammenstellen 
(Grub im erweiterten / Recovery-Mode mit splash und ohne quiet und auch mit debug 
... alles Mist). Diese Woche habe ich familiär Land unter, melde mich danach mit 
den zusätzlichen Infos von lspci & Co.
Wie wer

Re: Fwd: Fwd: Ubuntu: Bootproblem auf neuer Hardware

2022-06-29 Diskussionsfäden Wolf-R . Müller

Hallo Jonas,


Danke für den Tipp, Null Ahnung davon, terra incognita. Muß ich mal bei Gel. 
ausprobieren -> WVL.


Nö: Kernel-Parameter noapic bringt nix, Problem wie gehabt.


Im Prinzip schon richtig, wobei 20.04 mit 5.13 aber ja noch im Zenit seines 
Daseins steht: Ende Standard-Support April '25.
22.04 mit 5.15 tut's ja wie gesagt, auch nach einigen Updates zwischenzeitlich. Am 
4. Aug. kommt das erste Point-Release, solange warte ich noch und stelle dann 
darauf um; solange kann ich noch mit 18.04 leben (obwohl es dabei ein weiteres 
höchst merkwürdiges & störendes Problem gibt ... ).

Insofern ist mein Interesse, das Problem zu lösen, mehr akademischer Natur und 
nicht blanker Not geschuldet. Aber als Physiker bin ich darauf trainiert, 
solche Merkwürdigkeiten nicht zu ignorieren, sondern zu ergründen (im Rahmen 
eines vertretbaren Aufwand / Nutzen-Verhältnisses). Bei so Gelegenheiten kann 
man meist 'ne Menge lernen.
Denn es ist ja schon strange, Beispiel im übertragenen Sinne:
Ich betanke mein tadellos funktionierendes Auto, und es fährt nicht mehr. Ich 
nehme den Sprit aus dem Reservekanister, und das Auto fährt wieder, ist also 
technisch nach wie vor OK. Ich tue nochmal neuen Sprit rein, und es fährt 
wieder nicht, usw..

Gruß Wolf
Niederkassel

--
Mein öffentlicher PGP-Schlüssel 



Am 25.06.22 um 19:32 schrieb Jonas Stein:

Sorry, das war wohl nix mit dem Link. nochmal: 
https://c.gmx.net/@340439481158992671/-xpduo7ARFGN0Ugkqylk_A


Die Meldung sieht so aus als käme das vom Powermanagement.
Das in einem so altem Kernel zu debuggen ist die Arbeit nicht wert.
Kernel 5.13 ist aus mir unbekannten Gründen bei Gentoo komplett raus geflogen. 
5.15 ist hier mittlerweile als stable ausgerollt.

Probiere es am besten einfach mit einem neuen/aktuellen Kernel.

Wenn Du wgetpaste oder pastebinit installierst, kannst Du Ausgaben von der 
Kommandozeile leicht in ein pastebin senden und den Text von einem Rechner mit 
Mailzugang mailen.
Dann brauchst Du den Umweg mit Fotos vom Bildschirm nicht machen.

Beste Grüße,






Re: Fwd: Fwd: Ubuntu: Bootproblem auf neuer Hardware

2022-06-25 Diskussionsfäden Jonas Stein
Sorry, das war wohl nix mit dem Link. nochmal: 
https://c.gmx.net/@340439481158992671/-xpduo7ARFGN0Ugkqylk_A


Die Meldung sieht so aus als käme das vom Powermanagement.
Das in einem so altem Kernel zu debuggen ist die Arbeit nicht wert.
Kernel 5.13 ist aus mir unbekannten Gründen bei Gentoo komplett raus 
geflogen. 5.15 ist hier mittlerweile als stable ausgerollt.


Probiere es am besten einfach mit einem neuen/aktuellen Kernel.

Wenn Du wgetpaste oder pastebinit installierst, kannst Du Ausgaben von 
der Kommandozeile leicht in ein pastebin senden und den Text von einem 
Rechner mit Mailzugang mailen.

Dann brauchst Du den Umweg mit Fotos vom Bildschirm nicht machen.

Beste Grüße,

--
Jonas Stein



Re: Fwd: Fwd: Ubuntu: Bootproblem auf neuer Hardware

2022-06-25 Diskussionsfäden Torben Keil
Hallo Wolf,
Du könntest versuchen, die Bootmeldungen direkt auf einem TTY-Device auszugeben.

Schau mal hier, dort wird das näher erläutert.

https://wiki.archlinux.org/title/working_with_the_serial_console


Viele Grüße,
Torben

Am 25. Juni 2022 13:28:00 MESZ schrieb "Wolf-R. Müller" :
>Sorry, das war wohl nix mit dem Link. nochmal: 
>https://c.gmx.net/@340439481158992671/-xpduo7ARFGN0Ugkqylk_A
>
>--
>Mein öffentlicher PGP-Schlüssel 
><https://share.mailbox.org/ajax/share/05f9f4aa0d3c7a475c4c061d3c7a43d2b607c29e03d6350f/1/8/MzA>
>
> Weitergeleitete Nachricht 
>Betreff:   Fwd: Ubuntu: Bootproblem auf neuer Hardware
>Datum: Sat, 25 Jun 2022 13:25:32 +0200
>Von:   Wolf-R. Müller 
>An:Trolug-Liste 
>
>
>
>Da capo ... Attachments zu groß -> hier 
>
> finden sich jetzt die zitierten Anlagen.
>
>Ich hoffe, das geballte Linux-KnowHow dieser Community hilft, Licht in's 
>Dunkel dieses Mysteriums zu bringen ...
>
>Gruß wolf
>
>--
>Mein öffentlicher PGP-Schlüssel 
><https://share.mailbox.org/ajax/share/05f9f4aa0d3c7a475c4c061d3c7a43d2b607c29e03d6350f/1/8/MzA>
>
> Weitergeleitete Nachricht 
>Betreff:   Fwd: Ubuntu: Bootproblem auf neuer Hardware
>Datum: Fri, 24 Jun 2022 17:03:59 +0200
>Von:   Wolf-R. Müller 
>An:Trolug-Liste 
>
>
>
>Hallo allerseits,
>
>Bezug: Mail 'Ubuntu: Bootproblem auf neuer Hardware' vom 12.06.22
>Update: Mittlerweile ist Kernel 5.13.0-51 in Betrieb mit dem gleichen 
>Fehlerbild wie nachfolgend für 5.13.0-48 dokumentiert.
>
><... melde mich danach mit den zusätzlichen Infos von lspci & Co.>
>Bevor ich dazu komme, aus aktuellem Anlaß zwei allgemeine Fragen in die 
>Community:
>
>1) Wie kann man, wenn man QUIET im Grub-Menu ausschaltet, die Ausgaben von 
>Kernel-Meldungen Bildschirmweise bremsen, also a la ' | more'? So werden einem 
>die Ausgaben um die Ohren gehauen ohne daß man eine Chance hat, sich das in 
>Ruhe anzuschauen und insbesondere Normal- und Fehlerfall schrittweise zu 
>vergleichen.
>
>2) Zu Kernel Debug-Parametern aus https://wiki.ubuntuusers.de/Bootoptionen/
>Weiß jemand, Wohin 'BOOT_DEBUG=2 / 3' Ihren Output schreiben?
>Zu 'debug' s. u..
>
>
>Leitfaden zu meinen Attachments:
>a) Die beiden PDFs zeigen im Normal- wie Fehlerfall, was man an Infos ierhält, 
>wenn man QUIET in Grub ausschaltet.
>
>b) initramfs.debug zeigt bei ordentlich bootendem System den Output unter 
>/run/initramfs/, wenn man den o. a. Kenelparameter 'debug' aktiviert.
>Wenn man das System 'runterfährt, wird /run/initramfs/ automatisch gelöscht. 
>Man muß sich den File also ggfs. vorher weg kopieren.
>Hoffnung:
>Bei NICHT bootendem System wird auch so ein Debug-File generiert, den man dann 
>von einem parallelen System aus (z. B. Live-System) sichern und dann mit dem 
>Debug-File vom Normalstart vergleichen kann. Das passiert aber nicht: Es gibt 
>in dem Fall kein /run/iniŕamfs/ ... clever gemacht!
>
>c) Drei Logs zu den von @Jonas angefragten Zusatzinfos. Interessant, für mich 
>als Dummi aber nutzlos.
>
>
>Wäre schön, falls noch jmd. einen erhellenden Geistesblitz hat ...
>
>Gruß Wolf
>Niederkassel
>
>--
>Mein öffentlicher 
>PGP-Schlüssel<https://share.mailbox.org/ajax/share/05f9f4aa0d3c7a475c4c061d3c7a43d2b607c29e03d6350f/1/8/MzA>
>
> Weitergeleitete Nachricht 
>Betreff:   Re: Ubuntu: Bootproblem auf neuer Hardware
>Datum: Mon, 13 Jun 2022 18:03:24 +0200
>Von:   Wolf-R. Müller
>Antwort an:trolug@trolug.de
>An:trolug@trolug.de
>
>
>
>Hallo zusammen,
>
>@Werner:
>Interessant & gräßlich. Daß etwas generell nicht funktioniert, ist eine Sache. 
>Bei mir ist's ja verwirrender: Mit Release A geht's ja, also gibt es kein 
>grundsätzliches Problem. Erst nach turnusmäßigem Update auf's nächste Release 
>B geht's nicht mehr ... -!?!-
>
>@Jonas:
>Ich muß meine unbefriedigenden Debug-Ergebnise mal ordentlich zusammenstellen 
>(Grub im erweiterten / Recovery-Mode mit splash und ohne quiet und auch mit 
>debug ... alles Mist). Diese Woche habe ich familiär Land unter, melde mich 
>danach mit den zusätzlichen Infos von lspci & Co.
>Wie werfe ich denn ein Auge auf den Chipsatz? Ich dachte, das wäre inlscpu 
>vielleicht  mit 'drin. Das Board ist ein Z590D von Gigabyte, mit einem weit 
>verbreiteten i5 der 10 Gen. aus II/2020 wie mir mein Händler sagte, d. h. der 
>aktuelle Kernel ist da eigentlich nicht mit überraschendem Neuland 
>konfrontiert.
>
>Zunächst schon mal vielen Dank für's bisherige Feedback ... für weitere 
>Anregungen bin ich höchst dankbar.
>
>Gruß Wolf
>Niederkassel
>
>--
>Mein öffentlicher 
>PGP-Schlüsse

Fwd: Ubuntu: Bootproblem auf neuer Hardware

2022-06-25 Diskussionsfäden Wolf-R . Müller

Da capo ... Attachments zu groß -> hier 

 finden sich jetzt die zitierten Anlagen.

Ich hoffe, das geballte Linux-KnowHow dieser Community hilft, Licht in's Dunkel 
dieses Mysteriums zu bringen ...

Gruß wolf

--
Mein öffentlicher PGP-Schlüssel 
<https://share.mailbox.org/ajax/share/05f9f4aa0d3c7a475c4c061d3c7a43d2b607c29e03d6350f/1/8/MzA>

 Weitergeleitete Nachricht 
Betreff:Fwd: Ubuntu: Bootproblem auf neuer Hardware
Datum:  Fri, 24 Jun 2022 17:03:59 +0200
Von:Wolf-R. Müller 
An: Trolug-Liste 



Hallo allerseits,

Bezug: Mail 'Ubuntu: Bootproblem auf neuer Hardware' vom 12.06.22
Update: Mittlerweile ist Kernel 5.13.0-51 in Betrieb mit dem gleichen 
Fehlerbild wie nachfolgend für 5.13.0-48 dokumentiert.

<... melde mich danach mit den zusätzlichen Infos von lspci & Co.>
Bevor ich dazu komme, aus aktuellem Anlaß zwei allgemeine Fragen in die 
Community:

1) Wie kann man, wenn man QUIET im Grub-Menu ausschaltet, die Ausgaben von 
Kernel-Meldungen Bildschirmweise bremsen, also a la ' | more'? So werden einem 
die Ausgaben um die Ohren gehauen ohne daß man eine Chance hat, sich das in 
Ruhe anzuschauen und insbesondere Normal- und Fehlerfall schrittweise zu 
vergleichen.

2) Zu Kernel Debug-Parametern aus https://wiki.ubuntuusers.de/Bootoptionen/
Weiß jemand, Wohin 'BOOT_DEBUG=2 / 3' Ihren Output schreiben?
Zu 'debug' s. u..


Leitfaden zu meinen Attachments:
a) Die beiden PDFs zeigen im Normal- wie Fehlerfall, was man an Infos ierhält, 
wenn man QUIET in Grub ausschaltet.

b) initramfs.debug zeigt bei ordentlich bootendem System den Output unter 
/run/initramfs/, wenn man den o. a. Kenelparameter 'debug' aktiviert.
Wenn man das System 'runterfährt, wird /run/initramfs/ automatisch gelöscht. 
Man muß sich den File also ggfs. vorher weg kopieren.
Hoffnung:
Bei NICHT bootendem System wird auch so ein Debug-File generiert, den man dann 
von einem parallelen System aus (z. B. Live-System) sichern und dann mit dem 
Debug-File vom Normalstart vergleichen kann. Das passiert aber nicht: Es gibt 
in dem Fall kein /run/iniŕamfs/ ... clever gemacht!

c) Drei Logs zu den von @Jonas angefragten Zusatzinfos. Interessant, für mich 
als Dummi aber nutzlos.


Wäre schön, falls noch jmd. einen erhellenden Geistesblitz hat ...

Gruß Wolf
Niederkassel

--
Mein öffentlicher 
PGP-Schlüssel<https://share.mailbox.org/ajax/share/05f9f4aa0d3c7a475c4c061d3c7a43d2b607c29e03d6350f/1/8/MzA>

 Weitergeleitete Nachricht 
Betreff:    Re: Ubuntu: Bootproblem auf neuer Hardware
Datum:  Mon, 13 Jun 2022 18:03:24 +0200
Von:Wolf-R. Müller
Antwort an: trolug@trolug.de
An: trolug@trolug.de



Hallo zusammen,

@Werner:
Interessant & gräßlich. Daß etwas generell nicht funktioniert, ist eine Sache. 
Bei mir ist's ja verwirrender: Mit Release A geht's ja, also gibt es kein 
grundsätzliches Problem. Erst nach turnusmäßigem Update auf's nächste Release B 
geht's nicht mehr ... -!?!-

@Jonas:
Ich muß meine unbefriedigenden Debug-Ergebnise mal ordentlich zusammenstellen (Grub 
im erweiterten / Recovery-Mode mit splash und ohne quiet und auch mit debug ... 
alles Mist). Diese Woche habe ich familiär Land unter, melde mich danach mit den 
zusätzlichen Infos von lspci & Co.
Wie werfe ich denn ein Auge auf den Chipsatz? Ich dachte, das wäre inlscpu 
vielleicht  mit 'drin. Das Board ist ein Z590D von Gigabyte, mit einem weit 
verbreiteten i5 der 10 Gen. aus II/2020 wie mir mein Händler sagte, d. h. der 
aktuelle Kernel ist da eigentlich nicht mit überraschendem Neuland konfrontiert.

Zunächst schon mal vielen Dank für's bisherige Feedback ... für weitere 
Anregungen bin ich höchst dankbar.

Gruß Wolf
Niederkassel

--
Mein öffentlicher 
PGP-Schlüssel<https://share.mailbox.org/ajax/share/05f9f4aa0d3c7a475c4c061d3c7a43d2b607c29e03d6350f/1/8/MzA>


Am 13.06.22 um 06:04 schrieb gr:


Hallo zusammen,
dass Problem hatte ich ich schon vor Jahren auf dem Lenovo Notebook
mit Ubuntu oder auch mit MINT. Habe das Problem nicht lösen können und das 
System immer von DVD gestartet.
Im Netz stand dann irgendtwas von einem Bootloader, den man speziell anpassen 
muss für SSD Platten, was aber doch recht kompliziert war.
Das Notebook blieb beim hochfahren immer an der gleichen Stelle hängen. Ich 
hatte nachher die neue HD SSD Platte in Verdacht, weil die alte defekt war.

Viele Grüße Werner



Von meinem/meiner Galaxy gesendet


 Ursprüngliche Nachricht 
Von: Jonas Stein
Datum: 13.06.22 00:31 (GMT+01:00)
An:trolug@trolug.de
Betreff: Re: Ubuntu: Bootproblem auf neuer Hardware


Aber PROBLEM:
Zwischenzeitlich hatte ich dieses System auf dem alten Rechner
routinemäßig auf Kernel 5.13.0-41 geupdated. Und dieses System läßt sich
auf dem neuen PC nun nicht mehr booten, hängt beim Hochfahren (Start
initramfs). FAZIT diverser Versuche: Die Demarkationslinie zwischen
System bootet / bootet nicht liegt bei den Kerneln 5.13.0-40 /
5.13.0-41, sowohl bei Ubuntu wie bei

Re: Ubuntu: Bootproblem auf neuer Hardware

2022-06-13 Diskussionsfäden Wolf-R . Müller

Hallo zusammen,

@Werner:
Interessant & gräßlich. Daß etwas generell nicht funktioniert, ist eine Sache. 
Bei mir ist's ja verwirrender: Mit Release A geht's ja, also gibt es kein 
grundsätzliches Problem. Erst nach turnusmäßigem Update auf's nächste Release B 
geht's nicht mehr ... -!?!-

@Jonas:
Ich muß meine unbefriedigenden Debug-Ergebnise mal ordentlich zusammenstellen (Grub 
im erweiterten / Recovery-Mode mit splash und ohne quiet und auch mit debug ... 
alles Mist). Diese Woche habe ich familiär Land unter, melde mich danach mit den 
zusätzlichen Infos von lspci & Co.
Wie werfe ich denn ein Auge auf den Chipsatz? Ich dachte, das wäre in lscpu 
vielleicht  mit 'drin. Das Board ist ein Z590D von Gigabyte, mit einem weit 
verbreiteten i5 der 10 Gen. aus II/2020 wie mir mein Händler sagte, d. h. der 
aktuelle Kernel ist da eigentlich nicht mit überraschendem Neuland konfrontiert.

Zunächst schon mal vielen Dank für's bisherige Feedback ... für weitere 
Anregungen bin ich höchst dankbar.

Gruß Wolf
Niederkassel

--
Mein öffentlicher PGP-Schlüssel 
<https://share.mailbox.org/ajax/share/05f9f4aa0d3c7a475c4c061d3c7a43d2b607c29e03d6350f/1/8/MzA>


Am 13.06.22 um 06:04 schrieb gr:

Hallo zusammen,
dass Problem hatte ich ich schon vor Jahren auf dem Lenovo Notebook
mit Ubuntu oder auch mit MINT. Habe das Problem nicht lösen können und das 
System immer von DVD gestartet.
Im Netz stand dann irgendtwas von einem Bootloader, den man speziell anpassen 
muss für SSD Platten, was aber doch recht kompliziert war.
Das Notebook blieb beim hochfahren immer an der gleichen Stelle hängen. Ich 
hatte nachher die neue HD SSD Platte in Verdacht, weil die alte defekt war.

Viele Grüße Werner



Von meinem/meiner Galaxy gesendet


 Ursprüngliche Nachricht 
Von: Jonas Stein 
Datum: 13.06.22 00:31 (GMT+01:00)
An: trolug@trolug.de
Betreff: Re: Ubuntu: Bootproblem auf neuer Hardware

> Aber PROBLEM:
> Zwischenzeitlich hatte ich dieses System auf dem alten Rechner
> routinemäßig auf Kernel 5.13.0-41 geupdated. Und dieses System läßt sich
> auf dem neuen PC nun nicht mehr booten, hängt beim Hochfahren (Start
> initramfs). FAZIT diverser Versuche: Die Demarkationslinie zwischen
> System bootet / bootet nicht liegt bei den Kerneln 5.13.0-40 /
> 5.13.0-41, sowohl bei Ubuntu wie bei Xubuntu, unabhängig davon, auf
> welchem System das Update von Release A < 5.13.0-41 auf Release B >
> 5.13.0-40 erfolgt ist.

Ein paar Ideen, wie man systematisch das Problem einkreisen kann:

Mit welcher Zeile bleibt der Bootvorgang stehen?

Welche Hardware wurde mit welchen Kernelmodulen geladen?
lspci -kv
lsmod
..

inxi gibt auch noch viele hilfreiche Informationen lesbar aus.

Vermutlich macht es Sinn dabei auch mal ein Auge auf den Chipsatz des
Motherboards zu werfen.

Beste Grüße,

--
Jonas Stein






Re: Ubuntu: Bootproblem auf neuer Hardware

2022-06-12 Diskussionsfäden gr
Hallo zusammen, dass Problem hatte ich ich schon vor Jahren auf dem Lenovo 
Notebookmit Ubuntu oder auch mit MINT. Habe das Problem nicht lösen können und 
das System immer von DVD gestartet.Im Netz stand dann irgendtwas von einem 
Bootloader, den man speziell anpassen muss für SSD Platten, was aber doch recht 
kompliziert war.Das Notebook blieb beim hochfahren immer an der gleichen Stelle 
hängen. Ich hatte nachher die neue HD SSD Platte in Verdacht, weil die alte 
defekt war.Viele Grüße WernerVon meinem/meiner Galaxy gesendet
 Ursprüngliche Nachricht Von: Jonas Stein  
Datum: 13.06.22  00:31  (GMT+01:00) An: trolug@trolug.de Betreff: Re: Ubuntu: 
Bootproblem auf neuer Hardware > Aber PROBLEM:> Zwischenzeitlich hatte ich 
dieses System auf dem alten Rechner > routinemäßig auf Kernel 5.13.0-41 
geupdated. Und dieses System läßt sich > auf dem neuen PC nun nicht mehr 
booten, hängt beim Hochfahren (Start > initramfs). FAZIT diverser Versuche: Die 
Demarkationslinie zwischen > System bootet / bootet nicht liegt bei den Kerneln 
5.13.0-40 / > 5.13.0-41, sowohl bei Ubuntu wie bei Xubuntu, unabhängig davon, 
auf > welchem System das Update von Release A < 5.13.0-41 auf Release B > > 
5.13.0-40 erfolgt ist.Ein paar Ideen, wie man systematisch das Problem 
einkreisen kann:Mit welcher Zeile bleibt der Bootvorgang stehen?Welche Hardware 
wurde mit welchen Kernelmodulen geladen?lspci -kvlsmod..inxi gibt auch noch 
viele hilfreiche Informationen lesbar aus.Vermutlich macht es Sinn dabei auch 
mal ein Auge auf den Chipsatz des Motherboards zu werfen.Beste Grüße,-- Jonas 
Stein

Re: Ubuntu: Bootproblem auf neuer Hardware

2022-06-12 Diskussionsfäden Jonas Stein

Aber PROBLEM:
Zwischenzeitlich hatte ich dieses System auf dem alten Rechner 
routinemäßig auf Kernel 5.13.0-41 geupdated. Und dieses System läßt sich 
auf dem neuen PC nun nicht mehr booten, hängt beim Hochfahren (Start 
initramfs). FAZIT diverser Versuche: Die Demarkationslinie zwischen 
System bootet / bootet nicht liegt bei den Kerneln 5.13.0-40 / 
5.13.0-41, sowohl bei Ubuntu wie bei Xubuntu, unabhängig davon, auf 
welchem System das Update von Release A < 5.13.0-41 auf Release B > 
5.13.0-40 erfolgt ist.


Ein paar Ideen, wie man systematisch das Problem einkreisen kann:

Mit welcher Zeile bleibt der Bootvorgang stehen?

Welche Hardware wurde mit welchen Kernelmodulen geladen?
lspci -kv
lsmod
..

inxi gibt auch noch viele hilfreiche Informationen lesbar aus.

Vermutlich macht es Sinn dabei auch mal ein Auge auf den Chipsatz des 
Motherboards zu werfen.


Beste Grüße,

--
Jonas Stein



Ubuntu: Bootproblem auf neuer Hardware

2022-06-12 Diskussionsfäden Wolf-R . Müller

Hallo allerseits,

Ich habe mir kürzlich beim lokalen PC-Händler ein neues System zugelegt (i5, s. 
Anhang), mit dem ich ein unerwartetes Problem habe, zu dem ich einen Rat suche.

Im Vorfeld hatte ich auf meinem alten DELL-System (Praxissystem Xubuntu 
18.04.6) damit begonnen, ein Xubuntu 20.04 neu aufzusetzen, nebst einem Ubuntu 
20.04 auf einer separaten HD als Test- und Servicesystem. Mit dem Upgrade auf 
22.04 wollte ich erst noch einige Zeit warten, bis sich 22.04 konsolidiert hat.

Mit diesem Xubuntu 20.04.4 mit Kernel 5.13.0-37 hatte ich dann den neuen PC vor 
Abnahme verifiziert - also daß darauf Xubuntu einwandfrei läuft - und gut war. 
Dachte ich.
Aber PROBLEM:
Zwischenzeitlich hatte ich dieses System auf dem alten Rechner routinemäßig auf 
Kernel 5.13.0-41 geupdated. Und dieses System läßt sich auf dem neuen PC nun nicht 
mehr booten, hängt beim Hochfahren (Start initramfs). FAZIT diverser Versuche: Die 
Demarkationslinie zwischen System bootet / bootet nicht liegt bei den Kerneln 
5.13.0-40 / 5.13.0-41, sowohl bei Ubuntu wie bei Xubuntu, unabhängig davon, auf 
welchem System das Update von Release A < 5.13.0-41 auf Release B > 5.13.0-40 
erfolgt ist.

Dann dachte ich mir:
1) OK, ein Release kann mal ein Problem haben, das sich dann bei einem nächsten 
Update auswächst. Dies ist aber nicht der Fall: Inzwischen ist Release 
5.13.0-48 das aktuelle, und das Problem besteht nach wie vor.
2) Es ist vielleicht nicht sinnig, ein neues System auf 14 Jahre alter Hardware 
aufzusetzen, um es dann auf aktueller Hardware zu nutzen, und daß darin begründet  
evtl. irgendeine Hakelei vergraben sein könnte. Also habe ich AUF DEM NEUEN System 
auf einer separaten HD nochmal Ubuntu und Xubuntu jeweils in den Versionen 20.04 und 
22.04 NEU installiert (ISOs mit Releases < 5.13.0-40) und anschließend auf die 
jeweils aktuellen Releases > 5.13.0-40 geupdated. FAZIT:
- 20.04: Releases älter als 5.13.0-41 booten wie gehabt, neuere nicht.
- 22.04: Ubuntu wie Xubuntu booten einwandfrei.

Ich möchte meine Mail nicht mit weiteren Details überfrachten (nutzloses 
Grub-Debug), und im erstem Schritt einfach mal fragen, ob sich jmd. einen Reim 
auf den geschilderten Sachverhalt machen kann.

Der Königsweg bestünde natürlich darin, daß ich gleich auf 22.04 gehe, dabei 
bliebe aber ein ungutes Gefühl zurück. Ich hätte die Ursache für das Problem 
schon gerne verstanden und beseitigt und 20.04 'im Griff' (und nicht umgekehrt).

Also dankbar für jede Idee ...

Gruß Wolf,
Niederkassel

--
Mein öffentlicher PGP-Schlüssel 


wolf@DELL:~$ lscpu
Architektur:   i686
CPU Operationsmodus:   32-bit, 64-bit
Byte-Reihenfolge:  Little Endian
CPU(s):8
Liste der Online-CPU(s):   0-7
Thread(s) pro Kern:1
Kern(e) pro Socket:6
Sockel:1
Anbieterkennung:   GenuineIntel
Prozessorfamilie:  6
Modell:165
Modellname:Intel(R) Core(TM) i5-10400 CPU @ 2.90GHz
Stepping:  3
CPU MHz:   2804.070
Maximale Taktfrequenz der CPU: 4300,
Minimale Taktfrequenz der CPU: 800,
BogoMIPS:  5799.77
Virtualisierung:   VT-x
L1d Cache: 32K
L1i Cache: 32K
L2 Cache:  256K
L3 Cache:  12288K
Markierungen:  fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg fma cx16 xtpr pdcm sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault ssbd ibrs ibpb stibp ibrs_enhanced tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid mpx rdseed adx smap clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp md_clear flush_l1d arch_capabilities
wolf@DELL:~$