Ich habe eine Vermutung, woran es liegen könnte…
Als wir letztes Jahr auf Linuxmuster 6.2 inkl. von Linbo 2.2 auf 2.3 geupdatet haben, gab es bei uns Probleme mit einigen Rechnern.
Die Rechner, bei denen unter Linbo 2.2 das Image geschrieben und unter 2.3 partitioniert wurde, sind nicht mehr gebootet. Uns hat man gesagt, dass es an dem neuen Partiontionierungstool unter Linbo 2.3 liegen würde.
Deswegen haben wir uns erstmal vorgenommen, an diesen Rechnern nicht mehr zu partitionieren, bis wir ein neues Image schreiben würden. Das haben wir wohl dann total vergessen.
Was mich auch darauf kommen lässt, ist dass ich am Mittwoch, als wir schon wieder auf 2.3.22 gedowngraded haben, einen Rechner von der betroffenen Hardware-Gruppe partitioniert habe (wohl gemerkt unter Linbo 2.3).
Dieser Rechner hat jetzt unter Linbo 2.3.27 nicht das beschriebene Problem und die Festplatte wird auch als /dev/sda eingebunden.
Grüße
Valentin
Edith:
Nach dem Umstellen von sda auf sdc in der start.conf wird die Festplatte wieder erkannt.
Ich kann jetzt wieder im Linbo starten, synchronisieren usw. .
Aber die Rechner stecken jetzt in einer Reboot-Schleife… Nachdem die Rechner im Linbo waren und rebooten, gehen sie wieder ins Linbo, anstatt ins Windows zu booten und das in einer Endlosschleife.
Ich hab mir dann gedacht, dass ich durch Partitionieren der Rechner unter Linbo 2.3 das richtige Einbinden gewährleisten kann, wie bei dem Rechner vom Mittwoch. Leider ist dem aber nicht so.
in der Logdatei kann ich leider nichts Auffälliges feststellen. Die
Festplatte /dev/sda wird mit allen Partitionen erkannt. Ich habe hier
mal ein System mit linbo 2.3.15 und Win7-Client auf linbo 2.3.27
aktualisiert. Lief ohne Probleme. Ich fürchte wir müssen warten, bis das
noch jemand nachvollziehen kann.
evtl. hilft als Workaround in der start.conf bei KernelOptions den
Parameter “splash” zu entfernen. Danach “import_workstations” ausführen.
Da immer mehr aktuelle Grakas mächtige “eingebaute” Framebuffer haben,
muss ich wohl jetzt mal die FB-Konfiguration des Linbo-Kernels überarbeiten.
Hallo zusammen,
ich klinke mich in diese Diskussion ein, da ich mit einigen wenigen Laptops dasselbe Problem habe!
Es handelt sich dabei um etwas ältere Acer Travelmate 5735z.
Ab Linbo 2.3.26 erkennt es die Festplatten nicht mehr als sda. Bei meinen Laptops werden die Festplatten als sdb erkannt.
Habe aus dem babo62-testing die Linbo-Version 2.3.28 installiert, da zeigt sich dasselbe Fehlerbild.
“splash” als Parameter bei den Kernel-Optionen zu entfernen bringt nichts.
Ich habe auf einem Gerät ein BIOS-Update durchgeführt, hat nichts gebracht.
Ändern der “start.conf” auf sdb führt zu einer Dauerschleife, wie von Valentin beschrieben.
Auch neue, unbeschriebene Festplatten werden von den betroffenen Geräten nicht richtig erkannt. Die Festplatten werden jedoch in anderen Geräten richtig eingebunden.
Ich habe zusätzlich erkannt, dass LINBO bei den betroffenen Geräten einen eingesteckten USB-Stick als Referenzfestplatte “sda” erkennt. Kann man das irgendwie überbrücken? Hat sonst jemand eine Idee??
Ich habe zusätzlich erkannt, dass LINBO bei den betroffenen Geräten
einen eingesteckten USB-Stick als Referenzfestplatte “sda” erkennt. Kann
man das irgendwie überbrücken? Hat sonst jemand eine Idee??
… das ist ein Problem der neueren Kernel: also nicht direkt von linbo.
Linbo verwendet nur seit 2.3.26 einen neueren Kernel: der eben diese
Probleme mitbrachte.
Das mit dem USB Stick ist doof, aber nicht so dramatisch.
Das Problem bei den Travelmate wird wohl der SD Kartenleser sein, der
sda bekommt.
Der Kernel schert sich da nicht so sehr drum, da man ja immer UUIDs
verwenden soll und nciht Devicenamen wie sda… aber das geht eben in
einer Klonumgebung nicht.
Ich würde bei den Travelmate mal den SD Kartenleser in der
bootreihenfolge nach hinten rücken … vielleicht hilft es ja.
Ich kann den SD-Kartenleser leider nicht aus dem BIOS ansteuern. Daher habe ich ein BIOS-Update durchgeführt, in der Hoffnung, dass dies danach gelingen würde. Leider ohne gewünschten Erfolg.
Ich habe den Laptop auch geöffnet, der SD-Kartenleser ist fest mit dem Mainboard verbaut. Ich hatte die Hoffnung, dass man den Kartenleser vielleicht abklemmen könnte. Leider nein.
Angenommen ích würde den SD-Kartenleser manuell vom Mainboard entfernen, könnte das eine Lösung sein?
SD-Karten mit z.B. 64GB sind inzwischen ja auch recht günstig zu haben. Reicht die Datenlese-/Schreibrate eines älteren SD-Slots für einen stabilen Betrieb aus?
Ich kann den SD-Kartenleser leider nicht aus dem BIOS ansteuern. Daher
habe ich ein BIOS-Update durchgeführt, in der Hoffnung, dass dies danach
gelingen würde. Leider ohne gewünschten Erfolg.
Ich habe den Laptop auch geöffnet, der SD-Kartenleser ist fest mit dem
Mainboard verbaut. Ich hatte die Hoffnung, dass man den Kartenleser
vielleicht abklemmen könnte. Leider nein.
Angenommen ích würde den SD-Kartenleser manuell vom Mainboard entfernen,
könnte das eine Lösung sein?
nein, ich denke nicht.
Logisch erscheint er noch immer im BIOS, auch wenn der „Slot“ weg ist.
SD-Karten mit z.B. 64GB sind inzwischen ja auch recht günstig zu haben.
Reicht die Datenlese-/Schreibrate eines älteren SD-Slots für einen
stabilen Betrieb aus?
… ich denke nicht.
Zuerst: in aller Regel sind die Dinger per USB 2 angebunden: selbst
Heutzutage bei aktuellen Laptops tritt das noch vereinzelt auf.
USB2 ist zu langsam.
Zweitens: die kleinen SD Karten haben nur einen Chip eingebaut: ihre
Geschwindigkeit ist unterirdisch …
Du brauchst das aber auch nicht unbedingt.
Erstmal würde ich mir so behelfen, dass ich die Laptops nur an einem
Testserver mit älterer Linbo Version klonen würde.
Ich bin zuversichtlich,dass wir dieses „sda Problem“ in den Griff bekommen.
ich habe jetzt mal ein wenig reingelesen in die Problematik.
Ich denke, da steht uns ein größres Problem bevor, da das dynamische
zuweisen der Blockdevicenamen eine notwendigkeit neuerer Kernel ist.
Ich habe keinen Weg gefunden, der dem Kernel sagt, welches Device wie
heißen soll (also sda) wenn man das Device nicht eindeutig bennen kann
(UUID): und genau das können wir ja nicht, weil wir auf verschiedene
Hardware klonen.
Wir können also den oft vorgeschlagenen udevrules Ansatz nicht fahren.
Aber: ich habe eine Idee: der kernel macht ja eigentlich alles richtig,
wenn ihn kein Cardreader der schon einsteckender USB Stick durcheinander
bringt.
Da könnte man sagen: dann kompilieren wir unseren Kernel ohne USB
Unterstützung … geht aber auch nicht, weil wir ja immer mehr USB Mäuse
haben…
Aber vielleicht kann man dem linbo Kernel USB Blockdevices
(„Festplatten“) abgewöhnen durch ein Flag beim KOmpilieren.
Dann gehen Mäuse vielleicht immer noch, aber die SD Kartenleser und USB
Sticks tauchen nicht mehr auf …
Damit könnten wir nachhaltig das Problem lösen (hoffentlich).
Für dich bedeutet es zum Testen: such einen Kernelparameter, der USB
abschaltet und teste das.
Wollte mich nur in die Liste der Leute mit dem “sda-Problem” einreihen. Habe heute unsere (älteren) Laptops seit längerer Zeit mal wieder zum Synchronisieren ans Netz gehängt. Das war ein schwerer Fehler! Ohne ein Downgrade von Linbo (aktuell 2.3.26) werde ich die wohl nicht wieder zum Laufen bekommen…
Jetzt fällt mir auf, dass ich vor einer Woche auch das “sda-Problem” hatte. Da es nur einen einzelnen Rechner betraf, habe ich es so gelöst, dass ich für diesen eine neue Hardwaregruppe als Klon der ursprünglichen erstellt habe. Danach konnte ich in start.conf.hwk alle Laufwerksbezeichnungen angepasst - das war bei diesem Rechner sdf statt sda. Mittels ls -la /dev/sd* sieht man, welche Platte infrage kommt. Die Festplatte war vorher bereits partitioniert.
Grüße
Christian
gibt es vielleicht - alternativ zu Thorstens Vorschlag- die Möglichkeit ein Script einzubauen, das der ersten Festplatte immer pro HW-Gruppe eine eindeutige UUID zuweist, die dann bei allen ersten Festplatten einer HW-Gruppe identisch ist?
Ich selbst arbeite bei Wechselplatten meiner Backupsysteme (“BackupPC”) so, beim ersten Einrichten vergebe ich beiden Wechselfestplatten die selbe UUID, dann gibt es nie Probleme nach dem Wechseln…
Danach konnte ich in start.conf.hwk alle Laufwerksbezeichnungen angepasst - das war bei diesem Rechner sdf statt sda. Mittels ls -la /dev/sd* sieht man, welche Platte infrage kommt. Die Festplatte war vorher bereits partitioniert.
Startet dein Rechner auch aus LINBO ins gewünschte Betriebssytem?
das Problem gestaltet sich schwieriger als ich gehofft hatte.
Das habe ich auch versucht, bei mir ist die Platte als sdb gemeldet. Linbo startet nun auch wieder korrekt, aber ich kann Ubuntu nicht mehr starten. Ich bekomme immer nur diese Fehlermeldung, und lande dann wieder in Linbo.
Ich weiß nicht, ob man mit udev-Regeln ans Ziel kommt (vor allem, weil ich nicht weiß, ob LINBO mit geänderten Namen in der start.conf klar kommt?). Aber hier wird eine Möglichkeit beschrieben, wie man mit eigenen udev-Regeln den Namen eines Blockdevices auf einen anderen Mountpoint umbiegt – vielleicht hilft’s?
Ein schneller Test heute, die /etc/fstab per postsync auszutauschen war nicht erfolgreich. Ich muss morgen mal genauer schauen, ob die Datei auch angekommen ist. Ich vermute allerdings, dass der Bootvorgang gar nicht so weit kommt die Datei auszulesen.
! 
