hallo michael, >> 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? ich würde sagen nein. der normalfall für die autoerkennung ist, daß grub im mbr der platte installiert wird, auf der auch die boot partition ist. das sollte dann auch im updae/installations log stehn. wenn man selbst fähig ist partitionen umzubiegen, so geht "default" wohl davon aus, daß man auch selbst auf das installieren achtet...
> 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... hier ist wohl der eigentliche kritikpunkt. ich vermute, daß die größe von /boot prozentual zur gesamtplattengröße berechnet wird, ohne darauf hinzuweisen oder zu beschten, daß /boot eine mindestgröße haben muss. >>> 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... die fstab wird erst nach dem booten gelesen. grub startet als erstes die initrd, welche sich auf /boot befindet. und für dein grub auf platte 1 ist /boot eben auch auf platte 1. nach dem booten der initrd wird dann die fstab von /etc der rootpartition gelesen und weiter gebootet. das erklärt dann auch, weshalb nach dem kompletten start dein neues /boot eingebunden ist :) >> 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" so genau habe ich mir ipfire nicht angesehn. aber du hast ja sowieso die einfachste lösung selbst gefunden :-) einfach die bootreihenfolge im bios umstellen... >> 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 ... genau. so findet "der nächste" vermutlich die lösung schneller. und ich denke nicht, daß du der einzige mit dem problem einer vollen /boot bist... jonny _______________________________________________ linuxmuster-user mailing list [email protected] https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user
