Ein schneller Test heute, die /etc/fstab per postsync auszutauschen war
nicht erfolgreich.
schade …
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.
… hmm, vielleicht eine Fehlannahme von mir: früher war es so, dass der
lokale grub des ubuntu nicht mehr zum booten genuzt wurde, weil linbo
direkt den kernel geladen und gestartet hat.
Jetzt wo man rebootet, kann ich das nicht mehr genau sagen.
Gibt es da eine Kette?
linbogrub wird gebootet, der den grub von ubutu bootet, der den kernel
bootet?
Ich glaube nicht: der grub von linbo wird den kernel direkt starten…
Du kannst aber ja mal ein rescue System booten und den grub neuinstallieren.
Ohne Linbo funktionieren die Rechner wieder! Ich habe die Rechner mit der Super-Grub2-Disk gestartet. Diese erkennt das Ubuntu auf /dev/sda1 und kann es starten. Daher darf man die /etc/fstab auch nicht auf /dev/sdb umschreiben, dann klappt das nämlich nicht.
Für mich stellt sich die Sache jetzt also so dar:
Super-Grub2 erkennt die Festplatte als /dev/sda und kann es starten. Linbo erkennt die Platte aber als /dev/sdb. Ändere ich die start.conf auf /dev/sdb, so wird die Platte von Linbo erkannt, und ich kann synchronisieren. Allerdings schreibt Linbo dann den MBR auf /dev/sdb, und kann daher Ubuntu nicht starten, da der Kernel von Ubuntu auf /dev/sdb nichts findet (der Ubuntu-Kernel bindet die Platte als /dev/sda ein).
Meiner Meinung nach haben wir hier ein Problem!
Ich konnte mir jetzt so helfen, dass ich das Ubuntu mit der Super-Grub2-CD gestartet habe, und dann den Grub neu auf /dev/sda geschrieben habe. Dann im Bios die Bootreihenfolge umgestellt auf HDD. Nun habe ich kein Linbo mehr, aber mein System läuft. Ich hoffe, dass wir eine Lösung haben, bis ich mein System das nächste Mal synchronisieren muss.
Super-Grub2 erkennt die Festplatte als /dev/sda und kann es starten.
Linbo erkennt die Platte aber als /dev/sdb. Ändere ich die start.conf
auf /dev/sdb, so wird die Platte von Linbo erkannt, und ich kann
synchronisieren. Allerdings schreibt Linbo dann den MBR auf /dev/sdb,
und kann daher Ubuntu nicht starten, da der Kernel von Ubuntu auf
/dev/sdb nichts findet (der Ubuntu-Kernel bindet die Platte als /dev/sda
ein).
kannst du hier mal schreiben, welche Kernel dein Ubuntu hat?
Möglichst genau.
Ich konnte mir jetzt so helfen, dass ich das Ubuntu mit der
Super-Grub2-CD gestartet habe, und dann den Grub neu auf /dev/sda
geschrieben habe. Dann im Bios die Bootreihenfolge umgestellt auf HDD.
Nun habe ich kein Linbo mehr, aber mein System läuft. Ich hoffe, dass
wir eine Lösung haben, bis ich mein System das nächste Mal
synchronisieren muss.
der Vorschlag von Thomas, um das ein für allemal zu lösen war weit aus
besser als meiner.
Er sagt:
Partitioniert wird ja immer von linbo (muss ja so sein).
Und linbo kann schon (und macht das auch) label vergeben.
Dann heißt sda1 eben nicht nur sda1 sondern hat auch noch das Label
windoof oder ubuntu.
Was nun noch fehlt ist, dass linbo beim mounten die label verwendet und
eben nicht die Devicenamen (sdax).
Damit könnten wir das Problem erschlagen.
Das würde uns vielleicht auch in Hinsicht auf die nvme SSDs (die
wirklich exotische Devicenamen haben) helfen.
Bis dahin können wir die Problematik vielleicht auch entschärfen, wenn
wir linbo einen anderen kernel verpassen: der gerade scheint da ein
wenig seltsam zu entscheiden …
Ich hab es gerade nicht so genau auf dem Schirm, abr es gibt linbo
2.3.27, welches vielelicht einen anderen kernel mitbringt (4.4?)
Magst du mal das testing versuchen, ob das schon dein Problem behebt?
Es würde nur das linbo aktualisiert werden.
Kann nochmal jemand sagen, welche Kernel Version hier Stress macht? Und das geschieht auch, wenn nur eine Platte (und ein anderes USB-Gerät) eingebaut sind?? Die erste Festplatte sollte doch per default immer sda heißen. Klingt mir alles in allem eher nach einer Bios-Einstellung, wenn die Reihenfolge anders ist, oder??
Kann nochmal jemand sagen, welche Kernel Version hier Stress macht? Und
das geschieht auch, wenn nur eine Platte (und ein anderes USB-Gerät)
eingebaut sind??
ja: nur wenn Cardreader vorhanden oder USB Sticks stecken.
Die erste Festplatte sollte doch per default /immer/
sda heißen.
… ja, sollte.
Ist aber nicht so.
Klingt mir alles in allem eher nach einer Bios-Einstellung,
wenn die Reihenfolge anders ist, oder??
Einstellung: ja wenn das BIOS welche bietet.
Ich kann nicht entscheiden, ob da die BIOS Programmierer Mist machen,
oder ob der Kernel irrt …
Habe nachgeschaut: seit linbo 2.3.22 hat linbo den kernel 4.9.10
der Vorschlag von Thomas ist sicher eine gute Idee.
Dazu braucht man aber zusätzlich noch eine Lösung für das Problem, dass
bei neuen Platten die Label noch fehlen. Auch beim Neupartitionieren
muss Linbo die Platten erkennen können.
Es führt wohl kein Weg daran vorbei, dass man beim allerersten Kontakt
mit Linbo im Konfliktfall die Festplatte manuell bestätigen muss. Dann
könnte Linbo aber die Information /dev/disk/by-id für diese Platte
auslesen und auf dem Server speichern, z. B. in einer Datei
festplatten.hwklasse
Den Pfad /dev/disk/by-id müsste man deshalb verwenden, weil nur dort
ganze Platten bekannt sind - woanders (label, uuid) immer nur Partitionen.
Später kann Linbo nachsehen, ob in dieser Datei die Platte gelistet ist,
und falls ja mit den entsprechenden Labeln formatieren.
Was mich an der ganzen Sache wundert: Die Benennung der Devices ist ja schon seit Ewigkeiten so - es müsste ja im changelog irgendeine neue (?) Option zu finden sein, was da neuerdings anders ist oder hinzu gekommen ist? Ich habe nichts dergleichen gefunden/gehört…
Was mich an der ganzen Sache wundert: Die Benennung der Devices ist ja
schon seit Ewigkeiten so - es müsste ja im changelog irgendeine neue (?)
Option zu finden sein, was da neuerdings anders ist oder hinzu gekommen
ist? Ich habe nichts dergleichen gefunden/gehört…
… das macht der kernel anders, nicht linbo.
Deswegen mußt du im kernel Changelog nachschauen.
Ja, das meinte ich: Wenn da was geändert wurde, müsste es im Changelog vom Kernel auftauchen und dokumentiert sein?!? Vielleicht hier? —> https://kernelnewbies.org/LinuxVersions
das ist leider nicht so eindeutig zu klären. Die Benennung der Devices kommt so zustande: Der Kernel lädt sämtliche Treiber, und wenn dabei ein Gerät gefunden wird, wird die nächste freie Bezeichnung verwendet. Da die Treiber parallel geladen werden, ist das Ergebnis nicht vorhersehbar. Wenn zum Beispiel eine neue Version eines Treibers ein wenig länger benötigt als die alte, dann kann es schon sein, dass ein Gerät in der Liste nach hinten wandert, weil es später erkannt wird.
Der beste Ansatz ist, von den /dev/sdX-Bezeichnungen unabhängig zu werden.
Nur als Rückfrage: Wenn das so wäre, müsste das Problem aber schon immer bestanden haben???
Da es ja mit Kernel 4.9.x erstmals auftauchte, bin ich weiterhin der Meinung, dass sich ab da etwas geändert haben muss? Ich habe natürlich nichts gegen den Ansatz mit den Labels.
Nur als Rückfrage: Wenn das so wäre, müsste das Problem aber schon immer
bestanden haben???
nö, eigentlich nicht.
Jörg hat das ja dargelegt: wenn ein neuer Treiber länger braucht (oder
schneller ist… in unserem Falls: als der ahci Treiber), dann verschiebt
sich die Suppe.
Da es ja mit Kernel 4.9.x erstmals auftauchte, bin ich weiterhin der
Meinung, dass sich ab da etwas geändert haben muss?
ja: ein (oder mehrere) Treiber.
Ich würde aber mal um folgendes bitten: wir haben schon linbo Versionen
mit neueren Kerneln.
Bisher haben wir ja nur 4.9.10 gefunden, der uns Probleme macht: der ist
in linbo 2.3.23 bis 2.3.26
In Testing gibt es aber auch linbo 2.3.27 und 2.3.28 jeweils mit 4.9.27
als Kernel.
Also: wer mag, der bindet das linuxmuster-testing Repo ein:
zusätzliches Eintragen von
wie Valentin weiter oben, am 15.Sep. schon schrieb hatten wir testing ausprobiert und hatten damit die gleichen Probleme. Gestern habe ich das noch mal an einem weiteren Standort gegengeprüft, ebenfalls das gleiche Resultat:
Wegen des Laufwerksdrehers kann Linbo die Laufwerke anschließend nicht mehr mounten.
eine etwas späte Antwort auf Holgers vorletzten Post: Auch unter linbo 2.3.28 kommen dieselben Probleme. Diese bestehen seit linbo 2.3.26. Kann hierbei Gerd bestätigen.
