Hi. > ja, im normalfall schon. aber da du ja dein boot auf ner andren platte > haben willst, wie das root, so kann es sein, daß das default hier nicht > greift... Ok -- aber ist das nun als Bug zu bezeichnen oder nicht?
Das eigentlich Problem bei mir war, dass die automatische Partitionierung bei der Installation die Partition /boot zu klein angelegt hat. Irgendwann gab es da Platzprobleme, da ein neuer Kernel da nicht mehr hineinpasste. Daher hatte ich die ganze Aktion mit der zusätzlichen Platte ja überhaupt gestartet. Ich hätte es auch mit gparted versuchen können -- allerdings wusste ich ja "damals" noch nichts von den anstehenden Problemen... ich vermute auch, dass nicht bei _jedem_ core-Upgrade ein neuer Kernel installiert wird?!? Daher habe ich das vorher auch nicht bemerkt... >>und siehe da: Dort steckt weiterhin der alte Kernel. > ja, klar. was sonst hast du erwatet? :) Ich hatte erwartet, dass vda1 GAR nicht gemounted wird, da es in der fstab ja auch nicht aktiviert ist!?!? Aber GRUB ist natürlich noch auf vda installiert... >nein. es liegt nicht an der zusätzlichen boot. >es liegt daran, daß diese auf einer andren platte liegt und du dem grub >gesagt hast, er soll sich dann auch in deren bootsektor schreiben, Ok -- offenbar ist dieser Vorgang *so* nicht vorgesehen. Dennoch müsste man ja mit Bordmitteln in der Lage sein, Grub nach /dev/vdb1 zu schreiben bzw ihn von /dev/vda1 so umzuleiten, dass er von vdb1 bootet?!? Diese Einstellung hatte ich offenbar versäumt -- leider gibt's im IPFire aber auch kein "grub2-install" >vor allem, weil deine neuinstallation vermutlich garnichts geändert >hätte, wenn du /boot weiterhin auf der zweiten platte angelegt hättest Ne -- bei der Neuinstallation hätte ich dann natürlich vda entsprechend größer angelegt, so dass das Problem erst gar nicht mehr auftetreten wäre. Aber gut, dass das nun geklärt ist ... Michael _______________________________________________ linuxmuster-user mailing list [email protected] https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user
