Mal wieder grub (gelöst - na so in etwa )

[Luise]

Vor einiger Zeit hatte ich mein System (lenny) vollständig auf /dev/sda4 kopiert - mal erst nur als als bu zu verwenden, da es zu voll für ein lauffähiges System war.

Daher habe ich zu der Zeit auch die fstab nicht angepasst.

DANACH habe ich dann squeeze auf sda2 installiert - grub 2 auf sda2 ist das aktuelle grub. Es hatte die anderen Bts erkannt und fährt auch ohne Probleme nach sda 1, 2 und 5 hoch.

Danach habe ich das kopierte System auf sda4 verschlankt (nur die persönlichen Daten rausgenommen - also nichts am System geändert ) und die fstab angepasst.

Wenn ich aber im grub menu sda4, also das kopierte System, anklicke, fährt grub ohne Kommentar wieder nach sda5 hoch.

In der /boot/grub/grub.cfg hatten die beiden Partitionen die gleiche uuid.

Nachdem ich dann update-grub ausgeführt habe, waren die uuids voneinander verschieden.

ABER:

Das System fährt immer noch nach sda5 hoch wenn ich sda4 anklicke.

Ich weiß nicht, was ich sonst noch versuchen kann. Hat jemand einen Rat?

[Emess]

Wie wäre es mit ein wenig Info!
fstab, fdisk -l oder was sonst noch weiter helfen könnte!

[Luise]

Wie wäre es mit ein wenig Info!
fstab, fdisk -l oder was sonst noch weiter helfen könnte!

Ich habe weiter gesucht und evtl. den Grund gefunden - in der /boot/grub/grub.cfg hat die automatischen Konfiguration zum Hochfahren auf sd4 nicht richtig geklappt:

Code: Alles auswählen

menuentry "Debian GNU/Linux, kernel 2.6.26-2-686 ([b]on /dev/sd[/b]a4)" {
        insmod part_msdos
        insmod ext2
        set root='(hd0,msdos4)'
        search --no-floppy --fs-uuid --set cd702688-9292-4f08-a9a6-bfab84813aa8
        linux /boot/vmlinuz-2.6.26-2-686 root=/dev/sda5 ro
        initrd /boot/initrd.img-2.6.26-2-686

Ich denke, ich müsste das jetzt manuell editieren, oder?

Aber wie?

Oben in der Datei /boot/grub/grub.cfg heißt es:

Code: Alles auswählen

# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub

In der Datei /boot/grub/grub.cfg steht über den Einträgen, zu denen der von /sda4 gehört, folgendes:

Code: Alles auswählen

### BEGIN /etc/grub.d/30_os-prober ###

So weit, so gut, aber das ist ein script, bei dem ich keine 'Ahnung habe, was ich ändern sollte.

D. h. ich sollte ich wohl auch darin nichts editierem, denn im debian wiki steht für grub v2, man soll das file /etc/default/grub editieren.

In dieser Datei steht aber bei mir nur

Code: Alles auswählen

# If you change this file, run 'update-grub' afterwards to update
# /boot/grub/grub.cfg.

GRUB_DEFAULT=0
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT="quiet"
GRUB_CMDLINE_LINUX=""

]# Uncomment to enable BadRAM filtering, modify to suit your needs
# This works with Linux (no patch required) and with any kernel that obtains
# the memory map information from GRUB (GNU Mach, kernel of FreeBSD ...)
#GRUB_BADRAM="0x01234567,0xfefefefe,0x89abcdef,0xefefefef"

# Uncomment to disable graphical terminal (grub-pc only)
#GRUB_TERMINAL=console

# The resolution used on graphical terminal
# note that you can use only modes which your graphic card supports via VBE
# you can see them in real GRUB with the command `vbeinfo'
#GRUB_GFXMODE=640x480

# Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to Linux
#GRUB_DISABLE_LINUX_UUID=true

# Uncomment to disable generation of recovery mode menu entries
#GRUB_DISABLE_LINUX_RECOVERY="true"

# Uncomment to get a beep at grub start
#GRUB_INIT_TUNE="480 440 1"

Ich schreibe die /boot/grub/grub.cfg mal nach paste :

http://nopaste.debianforum.de/35725

[wilfried]

du kannst die grub.cfg editieren, die manuell vorgenommenen Änderung werden aber beim nächsten update-grub überschrieben.

ersetze mal unter:
menuentry "Debian GNU/Linux, kernel 2.6.26-2-686 (single-user mode) (on /dev/sda4)" {
insmod part_msdos
insmod ext2
set root='(hd0,msdos4)'
search --no-floppy --fs-uuid --set cd702688-9292-4f08-a9a6-bfab84813aa8
# linux /boot/vmlinuz-2.6.26-2-686 root=/dev/sda5 ro single
linux /boot/vmlinuz-2.6.26-2-686 root=UUID=cd702688-9292-4f08-a9a6-bfab84813aa8 ro single
initrd /boot/initrd.img-2.6.26-2-686

falls die UUID von sda4 stimmt...

dann wäre noch zu erforschen, warum da nicht sowieso die uuid steht...

[KBDCALLS]

Von der grub.cfg sollte man schon die Finger von lassen, da dürften noch leichter Fehler passieren als in der menu.lst (Die war dagegen trivial) des Grubs-legacy

Der Lösung steht in den ersten Zeilen. grub-mkconfig Die generierte Datei wird erstmal auf den Bildschirm ausgegeben. Will man die Config dann übenehmen schreibt man sie in eine Datei.

Code: Alles auswählen

grub-mkconfig -o /boot/grub/grub.cfg

[Luise]

Von der grub.cfg sollte man schon die Finger von lassen, da dürften noch leichter Fehler passieren als in der menu.lst (Die war dagegen trivial) des Grubs-legacy

Der Lösung steht in den ersten Zeilen. grub-mkconfig Die generierte Datei wird erstmal auf den Bildschirm ausgegeben. Will man die Config dann übenehmen schreibt man sie in eine Datei.

Code: Alles auswählen

grub-mkconfig -o /boot/grub/grub.cfg

Das verstehe ich nicht ganz.

Sollte ich die Datei nicht in /etc/default/grub schreiben und dann ein upadate-grub machen?

[wilfried]

nein...
KBDCALLS wollte dir lediglich sagen, dass du die grub.cfg nicht per hand editieren sollst,

du kannst aber, wenn du grub-mkconfig ohne Parameter aufrufst eine Ausgabe der grub.cfg auf dem Bildschirm erzeugen,
wenn du glaubst, dass alles in Ordnung ist mit grub-mkconfig -o /boot/grub/grub.cfg, bzw. update-grub eine neu grub.cfg erzeugen.

[Luise]

Das wird langsam zur Komödie

Wenn ich grub-mkconfig aufrufe, wird die Datei /boot/grub/grub.cfg auf dem Bildschirm ausgegeben - keine Möglichkeit zu editieren.

Mit update-grub bzw. grub-mkconfig -o wird sie dann wie gehabt, also falsch, wieder in die /boot/grub/grub.cfg reingeschrieben.

Wenn ich in /etc/grub.d/40_custom das "menuentry" von der grub.cfg rein kopiere und dann editiere, dann wird nach update-grub zwar diese editierte Datei in die grub.cfg reingeschrieben - aber da sie ganz unten angehängt wird und der ursprüngliche Eintrag nicht gelöscht wird, wird die der falsche Eintrag zuerst abgearbeitet und grub fährt wieder auf die falsche Partition hoch.

Also müsste der ursprüngliche Eintrag jetzt gelöscht werden - aber wie?

Ich glaube, es bleibt mir nur die Möglichkeit, trotz aller Warnungen die /boot/grub/grub.cfg zu editieren -- oder weiß jemand noch etwas?

In man-pages und wiki und sonst im Netz finde ich überhaupt nichts, was mir da weiter hilft .

Ich glaube, ich kehre reumütig zu lilo zurück. Ist zwar langsam - aber grub 2 ist ja schlimmer als win (wenn das möglich sein sollte )

[KBDCALLS]

Was erwartest du? Wenn verschiedene Partitionen dir gleiche UUID haben das kann das auch nur im Chaos enden.

Poste die Ausgabe von blkid. Vorher zur Sicherheit den Cache löschen. Das /etc/blkid.tab und /etc/blkid.tab.old

PS. Lilo ist keine Lösung.

[Luise]

Was erwartest du? Wenn verschiedene Partitionen dir gleiche UUID haben das kann das auch nur im Chaos enden.

Haben sie aber nicht

Code: Alles auswählen

menuentry "Debian GNU/Linux, kernel 2.6.26-2-686 (on /dev/sda4)" {
        insmod part_msdos
        insmod ext2
        set root='(hd0,msdos4)'
        search --no-floppy --fs-uuid --set cd702688-9292-4f08-a9a6-bfab84813aa8
        linux /boot/vmlinuz-2.6.26-2-686 root=/dev/sda5 ro
        initrd /boot/initrd.img-2.6.26-2-686
}
menuentry "Debian GNU/Linux, kernel 2.6.26-2-686 (on /dev/sda5)" {
        insmod part_msdos
        insmod ext2
        set root='(hd0,msdos5)'
        search --no-floppy --fs-uuid --set afb9ed0b-1bda-436a-a1c7-12a830aa5c8c
        linux /boot/vmlinuz-2.6.26-2-686 root=/dev/sda5 ro
        initrd /boot/initrd.img-2.6.26-2-686
}

Für root= haben sie dieselbe Partition angegeben (sda5) - und gerade das will ich ja ändern und weiß nicht wie.

Beim Hochfahren nach sda5 klappt es mit der Angabe von sda ohne UUID problemlos. Am Fehlen der UUID kann es also wohl nicht liegen.

Poste die Ausgabe von blkid. Vorher zur Sicherheit den Cache löschen. Das /etc/blkid.tab und /etc/blkid.tab.old

Code: Alles auswählen

norbu:/home/sem-pa# blkid
/dev/sda1: UUID="4ee6dbcd-6fd6-411c-b3c0-106d4971db46" TYPE="ext2" 
/dev/sda2: LABEL="squeezyhome" UUID="1b4a83ae-9934-496b-a093-906993113ad4" TYPE="ext3" 
/dev/sda4: UUID="cd702688-9292-4f08-a9a6-bfab84813aa8" TYPE="ext2" 
/dev/sda5: LABEL="debby" UUID="afb9ed0b-1bda-436a-a1c7-12a830aa5c8c" TYPE="ext2" 
/dev/sda6: UUID="36249ba6-8641-4640-a610-aee3793491df" TYPE="swap" 
/dev/sda7: LABEL="Luise" UUID="27e1991b-d782-4b41-93cb-d1af7f1fa9d0" TYPE="ext2"

PS. Lilo ist keine Lösung.

Warum nicht?

[guennid]

Ich glaube, ich kehre reumütig zu lilo zurück.

Mach's doch einfach mal. Bin gespannt auf das Ergebnis. Ich verstehe sowieso nicht, wieso man freiwillig in die grube fährt.

[KBDCALLS]

PS. Lilo ist keine Lösung.

Warum nicht?

Weil es sein kann das Lilo nicht alle Dateisysteme händeln kann . Der arbeitet zwar ähnlich wie der Bootloader von Dos, da sollte ihm das Dateisystem eigentlich egal sein, aber möglich ist es trotzdem. Die nächste Frage kommt Lilo mit den UUIDs klar? (Erinnere mich noch an das HickHack um die Weiterentwicklung von Lilo, bzw. der Entfernung aus den Repositorys) . Dann kommt dazu bei jeder noch so kleinen Änderung muß der MBR neu geschrieben werden. Siehe Satz 2.

[cosmac]

hi,

Ich glaube, ich kehre reumütig zu lilo zurück.

Mach's doch einfach mal. Bin gespannt auf das Ergebnis. Ich verstehe sowieso nicht, wieso man freiwillig in die grube fährt.

die lilo-Konfiguration wird doch genau wie bei grub automatisch erzeugt (-> "do not edit") und vor allem bei jedem Kernel-Update wieder überschrieben. Mir scheint, die Probleme mit grub entstehen vor allem durch diese Automatik (vor der praktisch nicht vorhandenen Dokumentation mal abgesehen).

Funktioniert das bei lilo so viel besser als bei grub? Wegen dieser Zweifel bootet hier nur syslinux, der einzige Bootloader mit Handschaltung

[KBDCALLS]

Und wie sehen die jeweiligen fstabs aus ?

Ps. Bitte benutze Codetags, zum posten von Codeabschnitten.

[Luise]

hi,

Ich glaube, ich kehre reumütig zu lilo zurück.

Mach's doch einfach mal. Bin gespannt auf das Ergebnis. Ich verstehe sowieso nicht, wieso man freiwillig in die grube fährt.

die lilo-Konfiguration wird doch genau wie bei grub automatisch erzeugt (-> "do not edit")

Ohh - hat lilo inzwischen auch alles dahingehend verschlimmbessert??

Bis vor ca 2 Jahren, als ich zu ubuntu/debian - und damit zu grub - gewechselt bin, habe ich lilo völlig problemlos benutzt - händisch editiert. Waren dann jeweils einige Minuten -

- in den letzten Jahren habe ich mehr Zeit, Energie, Fragen in Probleme mit grub reingesteckt als in alle anderen Probleme zusammen!

Mir scheint, die Probleme mit grub entstehen vor allem durch diese Automatik (vor der praktisch nicht vorhandenen Dokumentation mal abgesehen).

Davon bin ich auch überzeugt.

Funktioniert das bei lilo so viel besser als bei grub?

Ich hoffe auf Antworten der lilo users Wenn es da inzwischen genau so ist...

Wegen dieser Zweifel bootet hier nur syslinux, der einzige Bootloader mit Handschaltung

.. kommt syslinux mit multi-boot klar?

[Luise]

Und wie sehen die jeweiligen fstabs aus ?

Ps. Bitte benutze Codetags, zum posten von Codeabschnitten.

Code: Alles auswählen

# /etc/fstab: static file system information.
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
proc            /proc           proc    defaults        0       0
/dev/sda5       /               ext2    errors=remount-ro 0       1
/dev/sdb6       none            swap    sw              0       0
/dev/sda7       /mnt/misc       ext2    defaults        0       0
/etc/fstab (END) 

Code: Alles auswählen

# /etc/fstab: static file system information.
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
proc            /proc           proc    defaults        0       0
/dev/sda4       /               ext2    errors=remount-ro 0       1
/dev/sdb6       none            swap    sw              0       0
/dev/sda7       /mnt/misc       ext2    defaults        0       0
/mount/etc/fstab (END) 

[guennid]

Dann kommt dazu bei jeder noch so kleinen Änderung muß der MBR neu geschrieben werden.

Realiter besteht das darin, dass nach jeder Änderung der lilo.conf das Kommando lilo als root ausgeführt werden muss. Ich habe nie verstanden, wie man aus dieser Banalität ein Argument für die Grube machen konnte. Mal davon abgesehen, dass dieses Kommando dir dann sagt, was du falsch gemacht hast, BEVOR es den MBR überschreibt, wenn du denn was falsch gemacht haben solltest.
Die UUID-Geschichte wird IN DIESEM ZUSAMMENHANG maßlos übertrieben. Ich kann darauf seit Jahren verzichten. Auf einem Desktop-Rechner oder Schleppi befinden sich die Betriebssystem(e) wohl in den allermeisten Fällen auf der eingebauten Festplatte. Was soll da passieren, wenn der BOOTLOADER über sdax/hdax läuft?

die lilo-Konfiguration wird [...] bei jedem Kernel-Update wieder überschrieben

Das kann man ausbremsen. lilo ist halt derart einfach zu konfigurieren, dass selbst ich damit nie Probleme hatte.

syslinux, der einzige Bootloader mit Handschaltung

das ist in der Tat ein kaum zu toppendes Argument! Mal schauen, wenn ich Zeit habe.
Festzuhalten bleibt: Was Unhandlicheres als grub dürfte schwer zu finden sein.

Grüße, Günther

[wilfried]

@ Luise
anstatt mir Gedanken darüber zu machen, einen anderen Bootloader zu benutzen,
wird ich eher versuchen, das Chaos auf deinem Rechner in den Griff zu bekommen.

wenn ich das richtig überblicke hast du 3 Betriebsysteme installiert, 1x Ubuntu mit 2. versch. Kernel, und 2x Debian.
und Grub wahrscheinlich in den MBR installiert.
wenn du dann unter dem jeweiligen System ein Update fährst, und update-grub ausgeführt wird, schreiben die in die gleiche grub.cfg.
das kann nur zu Problemen führen, und dürfte auch der Grund sein, warum unerkärliche Fehler in der grub.cfg auftauchen.

Es ging hier doch anfangs mal darum, warum sda4 drinne steht, aber sda5 benutzt wird, kann das sein?

[KBDCALLS]

Das der MBR neu geschrieben werden müßte, das wurde schon mal gerne vergessen. Was die UUID anbetrifft. Man sollte eigentlich noch in Erinnerung haben was passiert ist wie aus hda plötzlich sda wurde weil vom anfangs üblichen IDE Subsystem auf Libata gewechselt wurde. Die Verwirrung war komplett, zumal Ubuntu den Wechsel viel früher vollzogen hatte , als Debian.

[guennid]

@Wilfried
Also ich finde nur 2: lenny und squeeze. Aber in einem hast du sicherlich recht: Das System ist ziemlich unklar. Luise sollte es mal genauer beschreiben: Wieviele und welche Systeme gibt's nun tatsächlich. Was wurde wann und warum partitioniert?
Wie wurde das lenny kopiert? Ein einfaches cp reicht da sicherlich nicht.

Grüße, Günther

[wilfried]

@Günther

@Wilfried
Also ich finde nur 2: lenny und squeeze. ...
....Grüße, Günther

hatte ich glatt übersehen, 3x Debian...

Code: Alles auswählen

### BEGIN /etc/grub.d/10_linux ###
menuentry 'Debian GNU/Linux, with Linux 2.6.32-5-686' --class debian --class gnu-linux --class gnu --class os {
menuentry 'Debian GNU/Linux, with Linux 2.6.32-5-686 (recovery mode)' --class debian --class gnu-linux --class gnu --class os {
### END /etc/grub.d/10_linux ###

### BEGIN /etc/grub.d/30_os-prober ###
menuentry "Ubuntu, Linux 2.6.31-22-generic (on /dev/sda1)" {
menuentry "Ubuntu, Linux 2.6.31-22-generic (recovery mode) (on /dev/sda1)" {
menuentry "Ubuntu, Linux 2.6.31-14-generic (on /dev/sda1)" {
menuentry "Ubuntu, Linux 2.6.31-14-generic (recovery mode) (on /dev/sda1)" {
menuentry "Debian GNU/Linux, kernel 2.6.26-2-686 (on /dev/sda4)" {
menuentry "Debian GNU/Linux, kernel 2.6.26-2-686 (single-user mode) (on /dev/sda4)" {
menuentry "Debian GNU/Linux, kernel 2.6.26-2-686 (on /dev/sda5)" {
menuentry "Debian GNU/Linux, kernel 2.6.26-2-686 (single-user mode) (on /dev/sda5)" {
### END /etc/grub.d/30_os-prober ###

[KBDCALLS]

@Günther

@Wilfried
Also ich finde nur 2: lenny und squeeze. ...
....Grüße, Günther

hatte ich glatt übersehen, 3x Debian...

Code: Alles auswählen

### BEGIN /etc/grub.d/30_os-prober ###
menuentry "Ubuntu, Linux 2.6.31-22-generic (on /dev/sda1)" {
menuentry "Ubuntu, Linux 2.6.31-22-generic (recovery mode) (on /dev/sda1)" {
menuentry "Ubuntu, Linux 2.6.31-14-generic (on /dev/sda1)" {
menuentry "Ubuntu, Linux 2.6.31-14-generic (recovery mode) (on /dev/sda1)" 

Und was ist das dann hier ? Bei Debian gibts übrigens keine Kernel mit dem Zusatz generic

[guennid]

@Wilfried
Sieht doch eher so aus, als hätte ich was übersehen. (ihre grub.cfg hatte ich gar nicht überprüft, im Text erwähnt sie kein ubuntu). Also doch 1xubuntu-kernel und 2xdebian (1x lenny und 1xs queeze). Ich habe leider keine Ahnung von solch bombastischen grub-configs. Und warum der lenny-kernel zweimal eingetragen ist, einmal auf /dev/sda4 und einmal auf sda5 bleibt mir völlig schleierhaft.

Aber bevor wir weiter spekulieren, sollten wir tatsächlich Luise weiter befragen, was den nun eigentlich Sache ist auf diesem merkwürdigen Rechner.

Grüße, Günther

@KBDCALLS

Und was ist das dann hier ?

, siehe oben

[KBDCALLS]

Soweit ich das jetzt überblicke scheints alles korrekt zu sein. Um die letzte Sicherheit zu bekommen, Lenny booten, einen Kernel 2.6.26-5-486 installieren , und den 686 Kernel runterschmeißen. Andere Möglichkeit wäre einen Kernel 2.6.32 aus den Backports zu installieren. Und den 2.6.26 Kernel ebenfalls in den Orkus befördern. Dazu muß dann aber der neu installierte Kernel aktiv sein. Anschließend Squeeze booten , und die Grub.cfg neu schreiben . Dann sieht man ja was wirklich passiert. Mit mount ließe sich ja überprüfen , wo man sich denn wirklich befindet.

[Luise]

@Günther

Und was ist das dann hier ? Bei Debian gibts übrigens keine Kernel mit dem Zusatz generic

Das weiß debian bzw. grub aber anscheinend nicht