Ich habe kürzlich auf eine ext. USB-HDD zwei squeeze (6.0.4 LXDE 686) installiert (parallel, je in primäre Partition, eine in 'sauberem' Urzustand, in der anderen wird rumgewurstelt). Grub-pc (1.98+20100804-14+squeeze1) ist im MBR der USB-HDD installiert. Nach ein paar update-grub (angestoßen durch Kernel- (De)-Installationen) trat der "wrong UUID for kernel root parameter" bug (zB. [1][2]) auf, d.h. in einem grub.cfg menuentry zeigte die Zeile
'search --no-floppy --fs-uuid --set=root 000-die-richtige-uuid-000'
auf die richtige UUID, aber darunter die Zeile
'linux /boot/vmlinuz-x.y.-z-arch root=UUID=000-eine-falsche-uuid-000 foo bar bla'
verwies unsinnigerweise auf eine andere UUID irgendeiner im System vorhanden(gewesen)en Partition.
Die ext. USB-HDD wird mit einem Laptop betrieben, auf dem an sich Wheezy 686 installiert ist, grub-pc (1.99-17) ist im MBR der int. SSD. Zwecks Fehlersuche stieß ich unter Wheezy 'update-grub' an, i.d. Hoffnung, aus diesem Grub-Menü erst mal wieder auf beide externen Installationen zugreifen zu können.
Überraschung:
in der wheezy /boot/grub/grub.cfg steht danach der selbe Käse (s.o.), zudem ist das Menü mit den div. squeeze 'recovery mode' Einträgen zuge'müllt', obwohl in der wheezy /etc/default/grub 'GRUB_DISABLE_RECOVERY=true' aktiviert ist, zudem blieb versuchsweises Aktivieren von 'GRUB_DISABLE_LINUX_UUID=true' wirkungslos.
Ursache afaik:
'update-grub' stößt via 'grub-mkconfig' das script /etc/grub.d/30_os-prober an, das stumpf
Code: Alles auswählen
LINUXPROBED="`linux-boot-prober ${DEVICE} 2> /dev/null | tr ' ' '^' | paste -s -d ' '`"
prepare_boot_cache=
for LINUX in ${LINUXPROBED} ; do
LROOT="`echo ${LINUX} | cut -d ':' -f 1`"
LBOOT="`echo ${LINUX} | cut -d ':' -f 2`"
LLABEL="`echo ${LINUX} | cut -d ':' -f 3 | tr '^' ' '`"
LKERNEL="`echo ${LINUX} | cut -d ':' -f 4`"
LINITRD="`echo ${LINUX} | cut -d ':' -f 5`"
LPARAMS="`echo ${LINUX} | cut -d ':' -f 6- | tr '^' ' '`"'/usr/bin/linux-boot-prober' lässt durch die scripte in /usr/lib/linux-boot-probes/mounted/ [40grub | 40grub2 | 50lilo] einfach [menu.lst | grub.cfg | lilo.conf] auslesen, idF
Code: Alles auswählen
parse_grub_menu "$mpoint" "$partition" "$bootpart" < "$mpoint/boot/grub/grub.cfg"Imho ist das ein (hässlicher) Bug, denn bei Ausführen von 'update-grub' bzw. 'grub-mkconfig' wäre
-erwartetes Ergebnis:
die erstellte grub.cfg
- wird (gänzlich) durch die zum Zeitpunkt des Befehlsaufrufes im System vorhandene Software (Version) erstellt.
- bezieht sich gänzlich auf die Konfiguration (Hardware und Software) im scope des Systems zum Zeitpunkt des Befehlsaufrufes.
-Tatsächliches Ergebnis:
Für den user nicht kenntlich oder kontrollierbar wird grub.cfg
- ggf. teilweise durch ungeprüfte Übernahme von Daten aus [menu.lst | grub.cfg | lilo.conf] anderer lokaler Linuxsysteme erstellt, durch beliebige andere Versionen der o.g. Programme, was Kompatibilitäts- u. Sicherheitsrisiken bedingen könnte.
- daher ggf. nichtaktuellen /falschen Inhalt hinsichtlich evtl. veränderter Hardwarekonfiguration (Partitionsnummerierung, uuid) enthalten. Zudem wird dadurch die Konfiguration der Software grub-pc in /etc/default/grub zum Zeitpunkt des Befehlsaufrufes nicht bzw. nur partiell umgesetzt, zB. 'GRUB_DISABLE_RECOVERY' und 'GRUB_DISABLE_LINUX_UUID'. Bes. in Hinblick auf 'GRUB_DISABLE_OS_PROBER' sehe ich spannende Seiten- und Sicherheitsaspekte.
(Unzulänglich) lösbar scheint mir die Angelegenheit nur durch entweder [löschen | umbenennen] der [menu.lst | grub.cfg | lilo.conf] in allen (anderen) lokal vorhandenen Linuxsystemen (inakzeptabel) oder durch erneutes Aufrufen (u. ggf. umkonfigurieren) von [grub-legacy | grub-pc | lilo] in allen lokal vorhandenen Linuxsystemen (habe ich schließlich gemacht, halte ich aber im Grunde auch für inakzeptabel, ist evtl. nicht durchführbar, falls eine Linuxinstallation einem anderen Benutzer gehört).
Einen entsprechenden Bugreport habe ich nicht finden können [3].
Hat irgendjemand eine Idee, inwiefern dies evtl. nicht als Bug, sondern als erwünschtes Feature zu interpretieren ist?
Habe ich hier vielleicht nur mal wieder den Wald vor lauter Bäumen übersehen [4]?
Wäre ein Bugreport ggf. eher gegen Grub2 oder vllt. doch gegen os-prober/linux-boot-prober zu richten ?
[1] Grub development list: issues with grub.cfg http://comments.gmane.org/gmane.comp.bo ... evel/17599
[2] bugs.launchpad.net https://bugs.launchpad.net/ubuntu/+sour ... bug/554307
[3] GNU GRUB - Fehler: http://savannah.gnu.org/bugs/?group=grub
[4] GRUB Documentation http://www.gnu.org/software/grub/grub-d ... ation.html
!