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,0000 Minimale Taktfrequenz der CPU: 800,0000 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:~$
