Re:gelöst: Grub2-UID Fehler
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.
Danke noch mal!
--
Einen Schönen Gruß,
Sigi
Reply to: