Re: Re:gelöst: Grub2-UID Fehler
Am Montag, den 20.06.2011, 04:54 +0100 schrieb Siegfrid Brandstätter:
> Am Donnerstag, 16. Juni 2011 schrieb Sascha Reißner:
> > Am Mittwoch, den 15.06.2011, 21:56 +0100 schrieb Siegfrid
> Brandstätter:
> > > Booten tut es jetzt auch aber verkehrt, es wird die falsche
> > > Partition mit diesem Kernel geladen.
> > >
> > > Auf /dev/sdb13 ist Wheezy mit Kernel 2.6.38-2-686
> > > und in
> > > /dev/sdb17 ist Squeeze mit Kernel 2.6.32-5-486
> > >
> > > von dem gibt es aber auch eins mit 2.6.32-5-686
> > >
> > > nur dieses letzte erhielt mal die UID von Wheezy, frage nicht
> > > warum. Da ich aber dies reparieren wollte, weil es immer am Ende
> > > kein X bekam wie Wheezy, aus bekannten Gründen (Nvidia) habe ich
> > > mich gewundert und nun mal genau nachgesehen warum und finde dabei
> > > das die UID von Wheezy auf dieses Squeeze läuft. Daher auch der
> > > Wheezy Fehler in Squeeze bei dieser Installation, wobei hier ja
> > > der Nvidia Effekt gar nicht vorhanden sein dürfte. Anscheinend
> > > wurde wegen dem "-686" am Ende was vertauscht. Darum möchte ich
> > > dies auch reparieren.
> >
> > [...]
> >
> > > OK schau dir mal die UID's an und den Kernel dazu.
> > > Die boot/grub/grub.cfg
> > >
> > > ### BEGIN /etc/grub.d/10_linux ###
> > > menuentry 'Debian GNU/Linux, with Linux 2.6.38-2-686' --class
> > > debian -- class gnu-linux --class gnu --class os {
> > >
> > > insmod part_msdos
> > > insmod ext2
> > > set root='(hd1,msdos13)'
> > > search --no-floppy --fs-uuid --set=root ca68ee6b-4019-49cf-
> > >
> > > b2dd-0c686b6dfca2
> > >
> > > echo 'Loading Linux 2.6.38-2-686 ...'
> > > linux /boot/vmlinuz-2.6.38-2-686 root=UUID=ca68ee6b-4019-49cf-
> > >
> > > b2dd-0c686b6dfca2 ro quiet
> > >
> > > echo 'Loading initial ramdisk ...'
> > > initrd /boot/initrd.img-2.6.38-2-686
> > >
> > > }
> > > menuentry 'Debian GNU/Linux, with Linux 2.6.32-5-686' --class
> > > debian -- class gnu-linux --class gnu --class os {
> > >
> > > insmod part_msdos
> > > insmod ext2
> > > set root='(hd1,msdos13)'
> > > search --no-floppy --fs-uuid --set=root ca68ee6b-4019-49cf-
> > >
> > > b2dd-0c686b6dfca2
> > >
> > > echo 'Loading Linux 2.6.32-5-686 ...'
> > > linux /boot/vmlinuz-2.6.32-5-686 root=UUID=ca68ee6b-4019-49cf-
> > >
> > > b2dd-0c686b6dfca2 ro quiet
> > >
> > > echo 'Loading initial ramdisk ...'
> > > initrd /boot/initrd.img-2.6.32-5-686
> > >
> > > Hier unten ist es richtig!
> > >
> > > menuentry 'Debian GNU/Linux, with Linux 2.6.32-5-486' (Squeeze-
> > > Stable_sdb17)-class debian --class gnu-linux --class gnu --class os
> > > {
> > >
> > > insmod part_msdos
> > > insmod ext2
> > > set root='(hd1,msdos17)'
> > > search --no-floppy --fs-uuid --set 9bf4de71-
> > >
> > > a37f-41fe-8b21-64a171688537
> > >
> > > echo 'Loading Linux 2.6.32-5-486 ...'
> > > linux /boot/vmlinuz-2.6.32-5-486 root=UUID=9bf4de71-
> > >
> > > a37f-41fe-8b21-64a171688537 ro
> > >
> > >
> > > Und ich wunderte mich ewig warum der "Linux 2.6.32-5-686" nicht
> > > will.
> >
> > [...]
> >
> > Hieraus wird ersichtlich, daß du /boot nicht auf einer eigenen
> > Partition hast.
> > Bei dir liegt /boot in der /-Partition und das in beiden Fällen.
> > Du hast also zwei /-Partitionen und daher auch zwei
> > /boot-Verzeichnisse. Wenn du ein update-grub anstößt, werden die
> > Einträge unterhalb vom /boot-Verzeichnis auf der aktuellen
> > /-Partition aktualisiert. Das /boot-Verzeichnis in der anderen
> > /-Partition bekommt davon nichts mit.
> > Welches /boot-Verzeichnis Grub beim booten verwendet, kann ich leider
> > nicht feststellen, aber Fakt ist, daß sich beide /boot-Verzeichnis
> > sicher im Inhalt unterscheiden.
> >
> > Prüfen kannst du das, indem du ein Linux bootest und dann die
> > andere /-Partition mal in /mnt mountest.
> > Dann vergleich mal /boot mit /mnt/boot.
> >
> > Mein Vorschlag wäre, du erstellst eine eigene /boot-Partition die
> > dann von allen Systemen gemountet wird.
> > Dann ist es egal aus welcher Distribution du update-grub aufrufst, da
> > alle mit dem selben /boot-Verzeichnis arbeiten.
> >
> > > > Wichtig ist, dass /boot/grub/device.map stimmt.
> > >
> > > Da steht ja nun wirklich nicht viel drinnen, aber das dürfte
> > > stimmen, zumindest sind diese beiden Festplatten richtig
> > > zugeordnet. Hat aber nichts mit falchen Partitionen zu tun. Die
> > > liegen alle auf der (hd1)
> > >
> > > (hd0) /dev/disk/by-id/ata-ST340014A_5JX0D218
> > > (hd1) /dev/disk/by-id/ata-ST3160021A_5JS178X3
> > >
> > > > > Aber möglicherweise weiß ja wer wie ich es einfacher und besser
> > > > > machen könnte, muß ja wohl gehen.
> > > >
> > > > GRUB einfach so lassen, wie der Debian Installer ihn auf die
> > > > Platte hievte, und es gut sein lassen?
> > >
> > > Würde ich gerne so machen, aber allein schon das ich oben in der
> > > Liste scheintote Installationen stehen habe, macht es nötig da was
> > > zu ändern.
> >
> > Grub läd vermutlich die /boot/grub/grub.cfg die nicht aktualisiert
> > wurde.
> >
> > > > Und wenn damit dann wirklich ein Fehler ist, was ja sein kann,
> > > > dann erstmal *verstehen*, wo der Fehler liegt, und *dann*
> > > > handeln.
> > >
> > > Verstehen tu ich ja wo der Fehler ist, aber nicht wie ich ihn
> > > behebe :-) Aber danke das du dir die Zeit genommen hast dafür!
> >
> > Selbst wenn du den UUID-Fehler händisch behebst, wird er beim
> > nächsten update-grub wieder auftauchen, da du zwei
> > /boot-Verzeichnisse hast.
> >
> > Ich empfehle eine Partition für /boot in die du die neuesten Files
> > kopierst (nicht verschieben, vieleicht brauchst du sie noch).
> > Dann mountest du die neue Partition in /boot, führst zur Sicherheit
> > ein grub-mkdevicemap aus und dannach ein update-grub.
> > Stell auch sicher, daß die neue Partition über die /etc/fstab nach
> > /boot gemountet wird (in beiden root-FS).
> >
> > Ob das zur Lösung führt kann ich dir allerdings nicht sagen, denn ich
> > frage mich, wie Grub zu jedem Kernel die richtige /-Partition
> > feststellt um diese im Eintrag zu setzen (vieleicht über
> > /lib/modules ???).
>
> Nach dem ich damit immer mehr Fehler im System bekam wollte ich endlich
> ein squeeze das normal ist. Da habe ich es neu installiert. Das dauerte
> nicht länger als die ganze bastelei die ich nun schon seit Monaten
> mache. Aber das frische läuft nun echt gut, außer der Fehler von Kmail,
> der ist geblieben, CPU volle Touren.
Sorry, hatte die letzten Tage viel zutun und daher wenig Zeit.
Die alte boot-Partition (/dev/sda1) enthielt vermutlich sowieso nur
veraltete und daher unnütze Daten. Du hättest diese auch gleich neu
formatieren können wodurch diese auch gleich eine UUID bekommt. Die
boot-Partition formatiere ich immer mit ext2, da sich in dieser
Partition wenig ändert (nur bei Updates) braucht man hier kein Jornal
und da ext2 vom Kernel nativ unterstützt wird ist man auf geine Module
angewiesen.
Dann die frische Partition mounten.
> # mount /dev/sda1
> mount: can't find /dev/sda1 in /etc/fstab or /etc/mtab
Wenn die Partition nicht in der fstab angeführt ist, mußt du zur
Partition auch den Mountpoint angeben.
# mount /dev/sda1 /mnt
Nun kopiert man alles von /boot nach /mnt , was dadurch auf der frischen
Partition landet da diese hier gemountet ist.
Bei dir wäre hier aber der nächste Haken. Welches der beiden
boot-Verzeichnisse verwendet Grub wirklich?
Dazu hätte ich in beiden grub.cfg eine Infozeile eingefühgt.
menuentry "*** grub.cfg from /dev/sdX|Y ***" {}
Beim nächsten Start hättest du gesehen, welche grub.cfg Grub wirklich
liest und daher auch welches Verzeichnis Grub verwendet.
Mit dieser Info hättest du das richtige boot-Verzeichnis dann auf die
frische Partition kopiert.
Danach unmounten ...
# umount /mnt
... und dort mounten wo es eigendlich hin soll.
# mount /dev/sda1 /boot
Nun in beide /etc/fstab die Partition eintragen, damit diese automatisch
in /boot gemountet wird.
Zum Abschluß noch ein
# update-grub
und eventuell die /boot/grub/grub.cfg prüfen, ob jetzt wirklich die neue
Partition mit der richtigen UUID eingetragen ist.
So in etwa wäre ich vorgegangen, rein aus dem Kopf jetzt mal
geschrieben.
Wenn alles klappt, kann man die root-Partition(en) loop-mounten und das
Verzeichnis boot leeren. Hier liegen nähmlich immer noch Daten die man
nicht sieht aber ab jetzt nur Platz verschwenden.
Auf keinen Fall /boot direkt leeren!!!!
Denn da ist ja die neue Partition gemountet.
Die Dateien im boot-Verzeichnis auf der root-Partition siehst du im
Normalfall nicht, da durch das mounter der Partition nach /boot die
Dateien darin ausgeblendet/überlagert werden.
Deshalb loop-mounten.
> Danke noch mal!
Wofür? Ich bin viel zu spät. Du hast schon neu installiert.
Wollte es aber trotzdem noch ausführlich erklären, da solche Situationen
immer wieder mal auftreten und viele Anwender, gerade mit
Partitionsvielfalt und den Mountpoints, nicht ganz durchschauen.
Das Vorgehen ob ist, wie schon geschrieben, rein aus dem Kopf.
Wenn jemand Fehler findet oder ich etwas vergessen haben, bitte ich um
Korrektur.
--
mfG Sascha
~~~
Die schönste Metamorphose des unorganischen Reiches ist, wenn
beim Entstehen das Amorphe sich ins Gestaltete verwandelt. Jede Masse
hat hiezu Trieb und Recht. Der Glimmerschiefer verwandelt sich in
Granaten und bildet oft Gebirgsmassen, in denen der Glimmer beinahe
ganz aufgehoben ist und nur als geringes Bindungsmittel sich zwischen
jenen Kristallen befindet.
-- Goethe, Maximen und Reflektionen, Nr. 1087
Reply to: