[LMN7.2] Linux Mint Clients booten nicht mehr/hängen bei "Uploading linbo.log"

Server v7
1

Hallo liebes Forum,

ich habe seit einigen Tagen das Problem, dass mein produktiver Computerraum nicht mehr läuft. Das erste Fehlerbild war, dass die PC’s (alles Lenovo ThinkCentre M70q), die seit ca. einem Jahr problemlos gelaufen sind, nun auf einmal beim Start in „Uploading linbo.log“ hängen blieben.

Nach einiger Recherche hier im Forum bin ich auf Themen rund um die devices.csv gestoßen und hab dann mal ein linuxmuster-import-devices durchgeführt. Das lief auch durch, dort sind mir aber Fehlermeldungen aufgefallen, die ich nicht in Erinnerung habe:

------------------------------------------------------------------------------
#### linuxmuster-import-devices started at 2025-06-25 21:01:03            ####
------------------------------------------------------------------------------
#### Starting sophomorix-device syntax check:                             ####
#### sophomorix-device finished  OK!                                      ####
------------------------------------------------------------------------------
#### Working on dhcp configuration for devices                            ####
No option 'systemtype' in section: 'LINBO'
No option 'systemtype' in section: 'LINBO'
No option 'systemtype' in section: 'LINBO'
No option 'systemtype' in section: 'LINBO'
No option 'systemtype' in section: 'LINBO'
No option 'systemtype' in section: 'LINBO'
No option 'systemtype' in section: 'LINBO'
No option 'systemtype' in section: 'LINBO'
No option 'systemtype' in section: 'LINBO'
No option 'systemtype' in section: 'LINBO'
No option 'systemtype' in section: 'LINBO'
No option 'systemtype' in section: 'LINBO'
No option 'systemtype' in section: 'LINBO'
No option 'systemtype' in section: 'LINBO'
No option 'systemtype' in section: 'LINBO'
No option 'systemtype' in section: 'LINBO'
No option 'systemtype' in section: 'LINBO'
No option 'systemtype' in section: 'LINBO'
No option 'systemtype' in section: 'LINBO'
No option 'systemtype' in section: 'LINBO'
No option 'systemtype' in section: 'LINBO'
No option 'systemtype' in section: 'LINBO'
No option 'systemtype' in section: 'LINBO'
No option 'systemtype' in section: 'LINBO'
No option 'systemtype' in section: 'LINBO'
No option 'systemtype' in section: 'LINBO'
No option 'systemtype' in section: 'LINBO'
No option 'systemtype' in section: 'LINBO'
No option 'systemtype' in section: 'LINBO'
No option 'systemtype' in section: 'LINBO'
No option 'systemtype' in section: 'LINBO'
No option 'systemtype' in section: 'LINBO'
No option 'systemtype' in section: 'LINBO'
No option 'systemtype' in section: 'LINBO'
No option 'systemtype' in section: 'LINBO'
No option 'systemtype' in section: 'LINBO'
#### * in subnet 10.32.0.0/12:                                            ####
####   server          | 10.32.1.1       | addc            | 0 |          ####
####   firewall        | 10.32.1.254     | server          | 0 |          ####
####   docker       | 10.32.1.10      | server          | 0 |          ####
####   213pc01         | 10.32.213.101   | classroom-stude | 1 | efi64    ####
####   213pc02         | 10.32.213.102   | classroom-stude | 1 | efi64    ####
####   213pc03         | 10.32.213.103   | classroom-stude | 1 | efi64    ####
####   213pc04         | 10.32.213.104   | classroom-stude | 1 | efi64    ####
####   213pc05         | 10.32.213.105   | classroom-stude | 1 | efi64    ####
####   213pc06         | 10.32.213.106   | classroom-stude | 1 | efi64    ####
####   213pc07         | 10.32.213.107   | classroom-stude | 1 | efi64    ####
####   213pc08         | 10.32.213.108   | classroom-stude | 1 | efi64    ####
####   213pc09         | 10.32.213.109   | classroom-stude | 1 | efi64    ####
####   213pc10         | 10.32.213.110   | classroom-stude | 1 | efi64    ####
####   213pc11         | 10.32.213.111   | classroom-stude | 1 | efi64    ####
####   213pc12         | 10.32.213.112   | classroom-stude | 1 | efi64    ####
####   213pc13         | 10.32.213.113   | classroom-stude | 1 | efi64    ####
####   213pc14         | 10.32.213.114   | classroom-stude | 1 | efi64    ####
####   213pc15         | 10.32.213.115   | classroom-stude | 1 | efi64    ####
####   213pc16         | 10.32.213.116   | classroom-stude | 1 | efi64    ####
####   213pc17         | 10.32.213.117   | classroom-stude | 1 | efi64    ####
####   213pc18         | 10.32.213.118   | classroom-stude | 1 | efi64    ####
####   213pc19         | 10.32.213.119   | classroom-stude | 1 | efi64    ####
####   213pc20         | 10.32.213.120   | classroom-stude | 1 | efi64    ####
####   213pc21         | 10.32.213.121   | classroom-stude | 1 | efi64    ####
####   213pc22         | 10.32.213.122   | classroom-stude | 1 | efi64    ####
####   213pc23         | 10.32.213.123   | classroom-stude | 1 | efi64    ####
####   213pc24         | 10.32.213.124   | classroom-stude | 1 | efi64    ####
####   213pc25         | 10.32.213.125   | classroom-stude | 1 | efi64    ####
####   213pc26         | 10.32.213.126   | classroom-stude | 1 | efi64    ####
####   213pcteach      | 10.32.213.130   | classroom-stude | 1 | efi64    ####
------------------------------------------------------------------------------
#### Working on linbo/grub configuration for devices:                     ####
####   213pc01         | r213mint                                         ####
####   213pc02         | r213mint                                         ####
####   213pc03         | r213mint                                         ####
####   213pc04         | r213mint                                         ####
####   213pc05         | r213mint                                         ####
####   213pc06         | r213mint                                         ####
####   213pc07         | r213mint                                         ####
####   213pc08         | r213mint                                         ####
####   213pc09         | r213mint                                         ####
####   213pc10         | r213mint                                         ####
####   213pc11         | r213mint                                         ####
####   213pc12         | r213mint                                         ####
####   213pc13         | r213mint                                         ####
####   213pc14         | r213mint                                         ####
####   213pc15         | r213mint                                         ####
####   213pc16         | r213mint                                         ####
####   213pc17         | r213mint                                         ####
####   213pc18         | r213mint                                         ####
####   213pc19         | r213mint                                         ####
####   213pc20         | r213mint                                         ####
####   213pc21         | r213mint                                         ####
####   213pc22         | r213mint                                         ####
####   213pc23         | r213mint                                         ####
####   213pc24         | r213mint                                         ####
####   213pc25         | r213mint                                         ####
####   213pc26         | r213mint                                         ####
####   213pcteach      | r213mint                                         ####
------------------------------------------------------------------------------
#### Working on linbo/grub configuration for groups:                      ####
####                   | linbo start.conf     | grub cfg                  ####
####   ----------------+----------------------+---------------------      ####
####   r213mint        | present              | replaced                  ####
------------------------------------------------------------------------------
#### Finally restarting dhcp service.                                     ####
------------------------------------------------------------------------------
#### linuxmuster-import-devices finished at 2025-06-25 21:01:19           ####
------------------------------------------------------------------------------

Ist dieses No option 'systemtype' in section: 'LINBO' normal? Kennt das jemand?

Starte ich im Linbo-Startbildschirm per linbo-ssh das Mint-System manuell, sieht das so aus:

213pc02: ~ # linbo_start 1
Found kernel boot/vmlinuz on partition /dev/nvme0n1p2.
Mounting cache partition /dev/nvme0n1p3 ...
mk_boot /dev/nvme0n1p2 boot/vmlinuz boot/initrd.img root=/dev/nvme0n1p2 ro splash
prepare_grub /cache/boot/grub /cache/boot/grub/grubenv /usr/share/grub
prepare_reboot /dev/nvme0n1 /dev/nvme0n1p2 /cache/boot/grub/grubenv boot/vmlinuz boot/initrd.img root=/dev/nvme0n1p2 ro splash /dev/nvme0n1p1
repair_efi /dev/nvme0n1p1
EFI bootnext for grub has been set to 0000.
EFI bootorder has been successfully set.
BootNext: 0000
BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0000,0001
Boot0000* grub
Boot0001* UEFI: PXE IPv4 Intel(R) Ethernet Connection (22) I219-LM
Boot0002* UEFI OS
Boot0003* UEFI: PXE IPv6 Intel(R) Ethernet Connection (22) I219-LM
Boot0004* UEFI:Network Device
Boot0005* Mint
Boot0006* Linux-Firmware-Updater
Write reboot informations to /cache/boot/grub/grubenv.
Installing GRUB in MBR/EFI of /dev/nvme0n1 ... OK!
receiving incremental file list
receiving incremental file list
Initiating machine password update on server 10.32.1.1 ...
receiving incremental file list
Uploading linbo.log ...

Und auch dort hängt es dann.

Noch ein paar Informationen:

  • Die Clients bekommen eine IP-Adresse und sind in Linbo auch per linbo-ssh vom Server erreichbar.
  • Die Systemzeiten zwischen OpnSense, LMN 7.2-Server und Client sind identisch und bei Ausgabe von date alle in derselben Zeitzone CST.
  • Ein Zurückgehen auf ein altes (Linux Mint-)Image hat natürlich nichts verändert. So weit komme ich im Boot-Prozess ja nicht. Das Auftreten des Fehlers korreliert auch nicht mit einem neu erstellten Image.
  • Das Ergänzen eines „nomodeset“ bei den Linbo-Parametern in der entsprechenden start.conf.gruppe führt dazu, dass der Client im kreiselnden Linbo-Screen nach Empfang der IP-Adresse stehen bleibt.

Das Problem ist insofern lästig, als dass ich das Problem derzeit nur vor Ort in der Schule anschauen kann (in der ich normal nicht bin - bin ehrenamtlicher (meist) Remote-Admin).

Aktuell fällt mir auch nichts ein, was das Problem verursacht haben könnte. Was ich natürlich gemacht habe, ist regelmäßig die aktuellen Pakete installiert. Das sind derzeit:

linuxmuster.net packages:
     █████     █████         -Base...........: 7.2.18-0
      ███       ███          -Linbo..........: 4.2.16-0
  ███               ███      -WebUI..........: 7.2.82
 █████             █████     -Sophomorix.....: 3.92.1-3

Hier meine start.conf.r213mint:

[LINBO]
Server = 10.32.1.1
Group = r213mint
Cache = /dev/nvme0n1p3
RootTimeout = 600
AutoPartition = no
AutoFormat = no
AutoInitCache = no
DownloadType = torrent
GuiDisabled = no
UseMinimalLayout = no
Locale = de-DE
SystemType = efi64
KernelOptions = forcegrub splash warmstart=no dhcpretry=9
clientDetailsVisibleByDefault = no

[Partition]
Bootable = yes
FSType = vfat
Id = ef
Size = 2G
Label = efi
Dev = /dev/nvme0n1p1

[Partition]
Dev = /dev/nvme0n1p2
Label = mint
Size = 100G
Id = 83
FSType = ext4
Bootable = yes

[Partition]
Dev = /dev/nvme0n1p3
Label = cache
Size = 100G
Id = 83
FSType = ext4
Bootable = yes

[Partition]
Dev = /dev/nvme0n1p4
Label = swap
Size = 16G
Id = 82
FSType = swap
Bootable = no

[OS]
Name = Mint
Version = 
Description = Linux Mint 21.2
IconName = mint.svg
BaseImage = mintr213.qcow2
Boot = /dev/nvme0n1p2
Root = /dev/nvme0n1p2
Kernel = boot/vmlinuz
Initrd = boot/initrd.img
Append = ro splash
StartEnabled = yes
SyncEnabled = yes
NewEnabled = yes
Autostart = yes
AutostartTimeout = 3
DefaultAction = start
Hidden = yes

Meine devices.csv kann ich gern per DM zur Verfügung stellen.

Ausgabe von dmesg, wenn Linbo im „Uploading linbo.log …“ steht ist

dmesg-output.zip (12,7 KB)

Um die chaotische Situation perfekt zu machen: mancher Client bleibt auch in diesem Screen hier stehen:

image
image1920×1440 112 KB

Tut mir leid für die vielen Infos, die (für mich bisher noch) ein ziemliches Durcheinander ergeben. Hat denn jemand eine Idee, was da schief läuft?

Danke,
Jens

2

Hallo Jens,

da du nichts verändert hast, sondern nur updates eingespielt hast, nehme ich an, dass es an einem neuen linbo liegt.

Dabei fallen mir natürlich die Kernel Parameter zuerst ein.

  1. warmstart=no ist der alte Switch. Der heißt nun nowarmstart (sollte aber noch keinen Unterschied machen: das also nur der Vollständigkeit halber).

  2. hier geht es ja um ein „EFI Bootissue“. Um die zu „behandeln“ gibt es 3 Möglichkeiten:

  • man macht nix (also weder forcegrub noch noefibootmgr)
  • man versucht forcegrub (was du hast)
  • man versucht noefibootmgr

Da würde ich bei dir also mal alle drei möglichkeiten durchtesten.
Zuerst: entferne forcegrub und mach ein linuxmuster-import-devices
Dann einen Client starten und testen.

Wenn es nicht hilft, füge noefibootmgr ein , mach den import und teste.

Wenn es das auch nicht ist, dann muss ich mal nochmehr nachdenken.
Was man bei efi Bootproblemen natürlich auch imemr machen kann, ist das EFI der Clients upzudaten: manchmal reparieren die ja sogar Fehler und meist ist das EFI auf dn Clients überraschend alt. Klar: macht viel Arbeit, weil man alle Clietns flashen muss…

Jetzt noch zu der Fehlermeldung:

No option 'systemtype' in section: 'LINBO'

das sollte kommen, wenn der import eine start.conf.GRUPPE findet, in der das eben fehlt.
Hast du unter
/srv/linbo/ vielelicht noch alte oder andere start.conf Dateien, in denen eben dieser Eintrag fehlt?
In der von dir geschickten start.conf.r213mint steht sie ja drin.

Also: die Meldung betrifft nicht deine fragliche Gruppe, würde ich sagen.

Ach so: da du den output des imports gepostet hast, kann ich wegen dieser Zeile:

sagen: deine r213mint.cfg unter /srv/linbo/boot/grub/ ist nicht verändert worden: Änderungen in der Appen Zeile der start.conf.r213mint kommen also dort an :slight_smile:

LG
Holger

3

Ich hänge mich mal hier mit an. Wir haben zwar Windows-Clients, nach dem Update aber ebenfalls Boot-Probleme, die wir vorher nicht hatten.

Die letzten Meldungen vor dem Absturz lauten
Write reboot informations to /cache/boot/grub/grubenv. prepare_reboot /dev/nvme0n1p3 /cache/boot/grub/grubenv auto /dev/nvme0n1p1 prepare_grub /cache/boot/grub /cache/boot/grub/grubenv /usr/share/grub mk_boot /dev/nvme0n1p3 auto No kernel auto on partition /dev/nvme0n1p3. Using "auto".

Die Kernel-Parameter der Hardwaregruppe lauten
quiet splash nomodeset noefibootmgr

noefibootmgr hatte ich mal rausgenommen, dann gibt es eine Boot-Schleife.

Es handelt sich um ziemlich neue IBM-ThinkCentre (AMD) mit UEFI und mit NVME-Platten.

LG

Lars

4

Lieber Holger,

danke für Deine ausführliche Antwort. Ich konnte leider erst heute wieder in der Schule sein (und dieses Problem muss man vor Ort versuchen zu lösen).

Zunächst mal vorweg: das

No option 'systemtype' in section: 'LINBO'

bin ich in der Tat losgeworden, indem ich die start.conf., die noch so (warum auch immer …) unter /srv/linbo rumflogen, weg verschoben habe. Mal ein Punkt, der erledigt ist.

Zum allgemeinen Problem:

  • Erst habe ich mal warmstart=no durch nowarmstart ersetzt. Wie erwartet ohne Veränderung im Verhalten des Clients. Der Client bootet bis in die Linbo-GUI, wenn man dann versucht nicht synchronisiert zu starten, bleibt er bei Uploading linbo.log ... hängen.
  • Dann habe ich forecegrub entfernt. Ebenfalls keine Veränderung des Verhaltens (Linbo GUI > Start Mint mit grün > endloses Uploading linbo.log …).
  • Mit noefibootmgr starten die Clients gar kein Linbo, sondern booten nach dem Lenovo-Splash-Screen sofort neu und wollen dann ins BIOS.

Also bei den Versuchen bisher keine Lösung.

Ist denn das „Uploading linbo.log“ nicht eher ein Problem der Vertrauensstellung zwischen Clients und Server (den ich übrigens auch schon mal rebootet habe, um das als Ursache auszuschließen) als ein EFI-Bootproblem?

Was mir noch so aufgefallen ist:

  • An den PC’s geht der Reboot nicht mehr. Weder über den kreisförmigen Pfeil im Linbo-GUI-Screen, noch wenn der PC selbst versucht neu zu starten.

Ein Update des EFI’s der Clients könnte heute an einem vergessenen USB-Stick scheitern. Mal sehen, ob mir noch was einfällt.

Hat jemand Ideen, wie ich weiter komme?

DANKE!
Jens

5

Vielleicht hilft das den Experten noch weiter, was tut und was nicht: ich habe das splash aus den Linbo-Startoptionen mal rausgenommen und den Client dann mit

linbo-remote -i 213pc04 -w0 -p start:1

gestartet. Dann kommt man so zum endlosen „Uploading linbo.log …“:

image
image1920×2560 300 KB

Dabei ist mir heute auch noch aufgefallen: nachdem der Client per DHCP eine IP-Adresse bekommen hat, ist er vom Server aus per ping erreichbar. Sobald die Konsole (sieht man jetzt ohne die Option splash besser) beim endlosen Uploading linbo.log ... hängen geblieben ist, ist der Client wieder weg vom Netzwerk.

Ich glaub, ich habe eher ein reboot-Problem als ein Boot-Problem, oder? Hat jemand sowas schon gehabt, dass ein Reboot aus LINBO nicht geht?

Danke,
Jens

6

Nächstes Update (sorry für die vielen Posts): auch ein BIOS/EFI-Update an einem Client hat keine Verbesserung gebracht.

Ich fürchte, ich habe mir ggf. ein Problem durch LINBO 4.2.16 und den darin enthaltenen neuen Kernel vor drei Wochen eingetreten.

Ich habe daher jetzt mit KERNELPATH="longterm" in /etc/linuxmuster/linbo/custom_kernel und einem anschließendem update-linbofs den 6.1.x-Kernel ausgewählt und siehe da: der Reboot funktioniert wieder.

Wie kommen wir dem Problem jetzt mit aktuellem Kernel näher?

7

Hallo Jens,

du kannst ja einfach mal einen älteren Kernel für linbo probieren.
Das geht relativ einfach, indem du unter /etc/ eine Datei erschaffst und korrekt befüllst: dann kannst du dort rein schreiben, welcher Kernel verwendet werden soll.
Ich empfehle nicht den 5er Kernel zu nehmen, da dieser in der nächsten linboVersion 4.3 nicht mehr zur Verfügung steht (… aus Gründen …)

Schau mal hier:

Vorletzter Punkt (fast ganz unten).

LG
Holger

8

Hallo Holger,

danke. Ok, dann wüsste ich, dass es mit einem anderen Kernel geht (das weiß ich aber jetzt auch schon, denn der Longterm funktioniert ja).

Ich würde gern rausfinden, was mit dem aktuellen Default-Kernel das Reboot-Problem verursacht … das kriege ich ja so nicht raus, oder was übersehe ich?

Beste Grüße,
Jens

P.S.: Jetzt habe ich - warum auch immer - seit über einem Jahr wieder das Domain-Beitritts-Problem aus Link auf meinem Client. :frowning:

9

Hallo Jens,

ich versuche mal die wichtigsten Dinge zusammen zu fassen:
Seit dem UPdate auf linbo 4.2.16 schafft es linbo nach Sync und auch nach „Start“ Knopf drücken, nicht, das installierte Linux? zu starten (bleibt bei uploading linbo.log hängen).

Vorher ging es ohne Probleme? (oder warst du schon früher wegen solcher Probleme oder anderer auf einen anderen kernel für linbo ausgewichen? Wenn ja: auf welchen?)

Es betrifft bei dir nur UEFI Clients (… aber du hast auch garkeine anderen?).

Du bist jetzt in linbo 4.2.16 auf Kernel ??? umgestiegen: dann geht es wieder?

LG
Holger

10

Also, wir haben jetzt auch eine ganze Hardwaregruppe die nach der Aktualisierung auf das neue Linbo 4.2.16 nicht mehr bootet. Mit Mint hat es nix zu tun, wir verwenden ubuntu. Ich hätte ja geree einen linbo-downgrade gemacht, aber wenn ich das richtig sehe, wird auf dem Paketserver immer nur die gerade aktuelle Version bereit gestellt…

Gruß
Sascha

11

Hallo Sascha,

nur eine HWK?
Ist die UEFI?
Betrifft es bei euch auch 4.2.16?
Ist es die einzige UEFI Gruppe?
Helfen forcegrub oder der andere uefi related Switch?
Hast du andere kernel versucht?

LG
Holger

12

HI Holger,
tatsächlich sind es doch mehrere HWK, so wie es aussieht alle, die mit UEFI laufen.
Ja, das Problem gibt es erst seit dem Update auf 4.2.16 und wir hatten vorher schon forcegrub als switch und den Linbo-Kernel auf „longterm“ (es wird also 6.1.141 geladen).
Ich habe das Problem jetzt durch Hinzufügen von „nowarmstart“ erstmal lösen können.

Gruß
Sascha

13

Hallo Holger,

zur Dokumentation des Problems hier gern die Antworten auf Deine Fragen:

Genau. Wobei nicht das Starten des installierten Linux Mint (@Sascha basiert auch auf Ubuntu) m.E. das Problem war, sondern, dass der zugehörige Reset mit der neuen Linbo-Version nicht mehr funktioniert hat. Der Rechner hing eigentlich nicht im „Uploading linbo.log …“ sondern hat den darauffolgenden Neustart nicht hinbekommen.

Ja, vorher ging es ohne Probleme und ich war bisher beim „default-Kernel“ von LINBO. Eine Datei /etc/linuxmuster/linbo/custom_kernel gab es bei mir bis vorgestern nicht. Jetzt bin ich auf KERNELPATH="longterm" (wie @Sascha).

Genau. Ich habe auch nur UEFI-Clients.

Genau. S.o. Ich bin jetzt auf dem longterm Kernel und da funktioniert wieder alles (auch bei mir in Verbindung mit den Kernel-Optionen forcegrub und nowarmstart).

Ich kämpfe leider immer noch (jetzt im Linux Mint) mit der Vertrauensstellung zwischen Clients und Server, nachdem das über ein Jahr problemlos funktioniert hat, aber dazu poste ich später ggf. nochmal in einem passenderen Thread.

Wenn’s noch Fragen gibt: gern.

Beste Grüße,
Jens

14

Hallo Jens,

das ist normal: wenn man das nutzen will, muss man die Datei anlegen.

Der Longterm Kernel funktioniert: das ist der 6.1er und kein 5.x, also erstmal: alles gut.

Zu deinem „Vertrauensstellungsproblem“: hast du die Systemzeit der Clients mit der des Servers mal verglichen?
Hast du einen Mechanismus, der dafür sorgt, dass das Client Betriebsystem seine Systemzeit mit dem Server synchronisiert?

LG
Holger

15

Salut,
und jetzt eine ganz lustige Geschichte bei diesem Problem: ich bin mal quasi aus Versehen per ssh auf einen Rechner gegangen, der im „Uploading linbo.log …“ festhing (wollte eigentlich mit linbo-ssh drauf und hab mich vertippt). Und siehe da
Das Ubuntu war gebootet, ich konnte mich remote als root anmelden und sogar mit einem Domänenuser (inkl. Einhängen der Shares etc)
Das Booten des Clientsystem selbst hat also sogar funkioniert, aber Linbo hat die Kontrolle über die Hardware nicht vollständig abgegeben (z.B. über die Grafik). Auch interessant - wenn ich remote einen „poweroff“ absetze, fährt das Clientsystem zumindest soweit runter, das erneutes ssh nicht möglich ist, der Computer geht aber nicht aus.

Ich bin mir nicht sicher, ob das generell so ist, ich habe das bis jetzt nur mit einem Hardwaretyp probiert. Hoffe trotzdem dass das bei der Suche nach dem eigentlichen Fehler hilft.

Gruß
Sascha

16

Hallo Sascha,

moderne linuxkernel initialisieren die Hardware „tiefer“ als frühere Versionen (zum Ausnutzen der Fähigkeiten und der Stromsparfunktionen).
Das ist gut, aber: wenn linbo einen neueren Kernel verwendet und deswegen die Hardware besser initialisiert, dann kommt es vor, dass das booten eines weiteren linuxkernels dann Probleme bekommt. Bisher hatten wir das meistens mit netzwerkkarten.
Die zuvor von linbo initialisierten Karten konnte der nächste Kernel nicht mehr richtig initialisieren: weswegen sie dann nicht funktionierten.
Du bist der erste, bei dem es die Grafikkarte betrifft.
Derartige Probleme werden umschifft, indem linbo den Rechner neustartet (wie bei Windows) und so dem zweiten kernel „frische“ Hardware präsentiert.

Also solltest du den switch:
nowarmstart
verwenden und schauen, was passiert.

LG
Holger

17

Hi Holger,
ja, so hatte ich es ja dann auch letztendlich gelöst, siehe oben.

Ich hatte das nur beschrieben für den Fall das die Entwickler sich tiefer mit dem Problem beschäftigen wollen…

Gruß
Sascha

18

Und noch ein Nachtrag:
ich habe eine Maschine, bei der im UEFI-Boot der Ubuntu-Boot per Warmstart nicht mehr funktioniert auf Legacy umgestellt (also CSM aktiviert, Legacy LAN als Bootquelle und eine entsprechende start.conf mit SystemType=bios64 etc)
Ergebnis: die Kiste bootet problemlos durch. Das in diesem Thread beschriebene Problem hängt also ziemlich sicher in erster Linie mit UEFI zusammen.
Die drei Posts weiter oben beschriebene Geschichte mit der eingefrorenen Grafikhardware dürfte nur ein Symptom sein (mit anderer Hardware kann ich das auch nicht reproduzieren, die friert bei einem Warmstart einfach komplett ein).
Gruß
Sascha