Hallo @thomas,
ich bekomme seit LINBO 2.4.2 leider einen Boot-Loop. Habe gerade eine VM mit
Partitionieren, Neu+Start ganz neu aufgesetzt. LINBO bootet, meldet beim ersten Start auch keine Fehler. Wenn dann Ubuntu starten sollte, erscheint aber diese Meldung, weshalb vermutlich kein OS gefunden wird und auch nicht gestartet werden kann? Die Cache-Partition ist aber vorhanden und die start.conf sowie linbofs64.lz befinden sich darauf! Kann es sein, dass der Cache beim Starten einfach nicht gemountet wurde?
Danach beginnt der Spaß von vorne: LINBO startet neu. Idee?
Gleich noch eine Frage hinterher: Wenn ich das testing-Repo wieder deaktivieren will – wie komme ich nochmal zurück auf LINBO 2.4.1?
Beim letzten Upgrade wurden diese beiden Pakete verwendet:
Upgrade: linuxmuster-linbo7:amd64 (2.4.1-0, 2.4.2-0)
linuxmuster-linbo-common7:amd64 (2.4.1-0, 2.4.2-0)
Muss ich die einzeln und nacheinander mit
apt install linuxmuster-linbo-common7=2.4.1-0 und
apt install linuxmuster-linbo7=2.4.1-0
downgraden oder wie macht man’s gleich richtig?
Viele Grüße,
Michael
Hallo Michael,
ich bekomme seit LINBO 2.4.2 leider einen Boot-Loop. Habe gerade eine VM mit
Partitionieren>, |Neu+Start| ganz neu aufgesetzt. LINBO bootet, meldet
beim ersten Start auch keine Fehler. Wenn dann Ubuntu starten sollte,
erscheint aber diese Meldung, weshalb vermutlich kein OS gefunden wird
und auch nicht gestartet werden kann?
auf dem screenshot steht, dass linbo seine Partitionen auf der
Festplatte nicht finden kann.
Kannst du bitte nochmal genau beschreiben, was du gemacht hast?
Ich konnte deiner Darstellung nicht sicher folgen.
Du hast den server aktualisiert auf 2.4.2 und dann den Client gebootet
in linbo.
Dabei hat der Client, bevor das erste mal die gui erscheint einen reboot
gemacht, oder?
Hattest du auf dem Server mal ein linuxmuster-import-devices nach dem
Update gemacht?
Wie ging es dann weiter?
linbo zeigte nach dem reboot die GUI.
War der Client eigentlich vorher schon linboisiert gewesen?
Dann hast du ihn wohl partitioniert und danach ubuntu gesynct (so
vermute ich das aus deiner Nachricht heraus).
Und dann …
… warum schreibe ich das alles eigentlich?
Könntest du bitte einfach mal genau beschreiebn, was passiert ist?
LG
Holger
Hi Holger,
klar – also ich habe der VM unter Proxmox eine ganz neue virt. HDD verpasst. Der Rechner war schon vorher in der devices.csv erfasst und lief mit der verwendeten start.conf auch bereits. Nun kam das LINBO-Update gestern Abend, das normal durchlief.
Heute Morgen sollte der Rechner neu angelegt werden. Daher wie üblich per PXE gebootet und partitioniert. Alles fehlerfrei. Ich kann auch noch einen Screenshot vom ersten Start schicken: Da werden keine Fehler gemeldet.
Nochmal zur Reihenfolge:
Nach diesem Bild erscheint ganz normal LINBO – wenn man dann auf Start klickt oder den Timeout abwartet, kommt es zu o.g. Fehlermeldung (no such device: cache) => Linbo startet von vorne => Loop.
Hilft das weiter?
Ach ja: linuxmuster-import-devices habe ich gerade sicherheitshalber nochmal gemacht. Ändert leider nichts.
Michael
Hallo Michael,
klar – also ich habe der VM unter Proxmox eine ganz neue virt. HDD
verpasst. Der Rechner war schon vorher in der |devices.csv| erfasst und
lief mit der verwendeten |start.conf| auch bereits. Nun kam das
LINBO-Update gestern Abend, das normal durchlief.
Heute Morgen sollte der Rechner neu angelegt werden. Daher wie üblich
per PXE gebootet und partitioniert. Alles fehlerfrei. Ich kann auch noch
einen Screenshot vom ersten Start schicken: Da werden keine Fehler gemeldet.
… das paßt nicht zusammen.
Wenn der Client eine leere Festplatte hatte, warum aktualisiert er dann
beim ersten boot das linbo auf der Platte (wie man in deinem Screenshot
sieht)?
Oder war das der erste Boot nach dem ersten boot von linbo 2.4.2 bei dem
du den Client partitioniert hast?
… ich blick nicht durch.
LG
Holger
Gelöst! Mit LINBO ist alles in Ordnung!
Es lag an einer falschen Proxmox-Einstellung.
Ich hatte ja die virt. Platte entfernt (virtio) und dann eine neue virt. Platte hinzugefügt (scsi). Dabei wurde die Bootreihenfolge der Geräte nicht mit geändert…
Also alles gut – war ein pebkac.
Michael
