Grub: kein chainload aus geklonter Partition :-(

Loki.Linuxfan · 23 Juli 2009

Hallo allerseits,

mein GRUB zeigt ein Verhalten, das ich nicht verstehe - ich hoffe, Ihr mögt mir helfen.

Kurz gesagt: Ich habe meine Root-Partition mit gparted kopiert, dem GRUB einen entsprechenden Eintrag verpaßt, aber er startet trotzdem immer nur die Originalpartition. Woran kann das liegen ?

Die Details:
Partitionen:
hda5: GRUB (Aufruf aus MBR)
hda6: swap
hda7: /root (Original mit "lokaler" GRUB-Inst., die auf hda7 verweist)
hda8: /home
hda9: /root (Kopie mit "lokaler" angepaßter GRUB-Inst., die auf hda9 verweist)

In hda7 (und somit auch hda9) ist nochmal GRUB (aus der Standard-SUSE-Installation) in /boot/grub installiert.
(Idee dahinter: Erspart mir beim multi-boot-System das Kontrollieren der menu.lst nach Kernelupdate via YAST - die "lokale" menu.lst im aktiven /boot/grub wird korrekt angepaßt, die Verweise auf alternative Systeme liegen weiter auf hda5/boot/grub.)
hda9 ist eine Kopie von hda7 per gparted, /etc/fstab und /boot/grub/menu.lst habe ich anschließend manuell angepaßt.

1. Boot aus MBR führt zu GRUB in sda5
2. Dort setze ich rootnoverify (hd0,6) bzw. (hd0,8) und starte mit chainloader +1
3. Die Variante (hd0,6) führt wie gewünscht zum lokalen Bootmenu, startet und läuft problemlos
4. Die Variante (hd0,8) führt ebenfalls zum lokalen Bootmenu aus Partition7, das dann auch startet und problemlos läuft (die "lokalen" menu.lst sind unterschiedlich, daran erkenne ich, wohin die Reise geht, und "df" meldet dann auch brav hda7 als /root)

Auszüge aus den menu.lst-Dateien:

hda5/boot/grub/menu.lst:

Code:

title openSUSE 11.1 Chainload
    rootnoverify (hd0,6)
    chainloader +1

title openSUSE 11.1 Backup Chainload
    rootnoverify (hd0,8)
    chainloader +1

hda7/boot/grub/menu.lst:

Code:

title openSUSE 11.1 Portable - 2.6.27.23-0.1
    root (hd0,6)
    kernel /boot/vmlinuz-2.6.27.23-0.1-pae root=/dev/disk/by-id/ata-SAMSUNG_SP2514N_S08BJ1TL400169-part7 resume=/dev/disk/by-id/ata-SAMSUNG_SP2514N_S08BJ1TL400169-part6 splash=silent showopts vga=0x31a PROFILE=FfM
    initrd /boot/initrd-2.6.27.23-0.1-pae

hda9/boot/grub/menu.lst:

Code:

title openSUSE 11.1 Portable - 2.6.27.23-0.1
    root (hd0,8)
    kernel /boot/vmlinuz-2.6.27.23-0.1-pae root=/dev/disk/by-id/ata-SAMSUNG_SP2514N_S08BJ1TL400169-part9 resume=/dev/disk/by-id/ata-SAMSUNG_SP2514N_S08BJ1TL400169-part6 splash=silent showopts vga=0x31a PROFILE=FfM
    initrd /boot/initrd-2.6.27.23-0.1-pae

Habe ich etwas übersehen, eine Datei anzupassen vergessen, einen grundsätzlichen Denkfehler gemacht ?

Danke im voraus für Eurer Interesse und Eure Hilfe.

Tooltime · 23 Juli 2009

Loki.Linuxfan schrieb:
Kurz gesagt: Ich habe meine Root-Partition mit gparted kopiert, dem GRUB einen entsprechenden Eintrag verpaßt, aber er startet trotzdem immer nur die Originalpartition. Woran kann das liegen ?

Ich gehe mal davon aus, das das Problem nur die Partition 9 betrifft. Nun der Bootrecord von Grub arbeitet Positionsabhängig. Das bedeutet er kennt keine Partitionen oder Filesysteme, sondern adressiert einfach die Datenblocknummer auf der Platte z.B. der Datenblock (512 Byte) 160792. Wenn du also den Bootrecord von Partition 7 auf 9 kopierst, so lädt er immer noch die Grub-Komponenten von Partition 7, die von dort die entsprechende Menu.lst und ... laden.

Der Bootrecord für Partition 9 muss neu eingerichtet werden

Loki.Linuxfan · 23 Juli 2009

Hallo Tooltime,

sowas hatte ich befürchtet.
Verstehe Deine Antwort so richtig, daß mein GRUB auf hda5 zwar korrekt den GRUB aus der (kopierten) hda9 aufruft, dieser aber nicht mitbekommen hat, daß er jetzt nicht mehr auf hda7 liegt, sondern brav die originale Datenblocknummer verwendet und deshalb die menu.lst aus hda7 verwendet ?

Ich hatte schon versucht, von dem System auf hda7, (hda9 läßt sich ja auch nicht über DVD booten, wenn ich nicht was übersehen habe), über YAST2 den Bootloader neu in hda9 zu installieren ("benutzerdefinierte Bootpartition", da habe ich hda9 ausgewählt, ansonsten nur "aus erweiterter Partition booten", alles andere nicht ausgewählt), aber das hat nichts gebracht. :-(
Daraufhin habe ich dann ins Forum gepostet.

Auf
http://www.gentoo.de/doc/de/handbook/handbook-amd64.xml?part=1&chap=10#doc_chap2
habe ich zum Thema Bootrecord Folgendes gesichtet (schon auf meine Verhältnisse angepaßt):

Code:

grub> root (hd0,8)    (Angabe wo sich Ihre /boot Partition befindet)
grub> setup (hd0,8)     (Installiere GRUB im MBR)
grub> quit            (Verlasse die GRUB Shell)

Wär's das, d.h. könnte ich vom allerersten GRUB (der dann per chainload die anderen aufruft) diese Befehle ausführen und damit meine hda9 bootbar machen ?
Ich frage mal lieber vorher, bevor ich endgültig was zerschieße ... (mal sehen, wie lange ich meinen Spieltrieb kontrollieren kann ... ;-))

Danke !

josef-wien · 23 Juli 2009

Loki.Linuxfan schrieb:
grub> root (hd0,8)
grub> setup (hd0,8)

Genau so paßt es. Die Fehlermeldungen betreffend "embed" kannst Du ignorieren. Im übrigen ist es belanglos, von welchem System Du das machst, jedes Linux mit GRUB an Bord ist geeignet.

Loki.Linuxfan schrieb:
Ich hatte schon versucht, von dem System auf hda7 ...

Das kann nicht klappen, YaST kann nur für das gerade laufende System den Bootloader einrichten. Du hast damit den bestehenden Zustand neuerlich festgelegt: Der Bootsektor von Partition 9 zeigt auf Partition 7. Der Bootsektor von Partition 7 bleibt dadurch natürlich erhalten, dort hast Du ja nichts verändert.

P.S. Durch das Kopieren haben beide Partitionen nicht nur denselben Label, sondern auch dieselbe UUID. Das solltest Du (bei einem Ext3-Dateisystem mit tune2fs) ändern.

Loki.Linuxfan · 24 Juli 2009

Hallo josef-wien,

danke für die Bestätigung, so musste die Neugierde dann doch nicht die Vorsicht überwinden ("curiosity killed the cat" ;-)), sondern ich konnte mich beruhigt ans GRUB-Werk machen.
Also vom laufenden hd7-System aus per console als root:

Code:

grub> root (hd0,8)
grub> setup (hd0,8)

Anschließend hoffnungsvoller Neustart - und erstmal Freude, als der menu.lst-Eintrag der hda9-Version auftauchte. Also weiter, und tatsächlich: Ein System startete.
Allerdings dann der Schreck:
"df" zeigt mir, daß als / immer noch hda7 gemountet ist. :-(

Dabei steht doch in der menu.lst ganz klar und deutlich:

Code:

title openSUSE 11.1 Portable FfM Backup - 2.6.27.23-0.1
    root (hd0,8)
    kernel /boot/vmlinuz-2.6.27.23-0.1-pae root=/dev/disk/by-id/ata-SAMSUNG_SP2514N_S08BJ1TL400169-part9 resume=/dev/disk/by-id/ata-SAMSUNG_SP2514N_S08BJ1TL400169-part6 splash=silent showopts vga=0x31a PROFILE=FfM
    initrd /boot/initrd-2.6.27.23-0.1-pae

und genau das wird beim Booten auch angezeigt.
Auch die fstab sieht so aus, wie ich dachte, daß sie aussehen müsste:

Code:

/dev/disk/by-id/ata-SAMSUNG_SP2514N_S08BJ1TL400169-part9 /                    ext3       acl,user_xattr        1 1
/dev/disk/by-id/ata-SAMSUNG_SP2514N_S08BJ1TL400169-part8 /home                ext3       acl,user_xattr        1 2
/dev/disk/by-id/ata-SAMSUNG_SP2514N_S08BJ1TL400169-part6 swap                 swap       defaults              0 0

Wieso kommt die Kiste denn nun trotzdem noch auf die Idee, hda7 als / zu mounten ??? :-?

Tooltime · 24 Juli 2009

Bin mir jetzt auch nicht absolut sicher. Probiere mal folgendes:

1. System auf Partiton 7 starten.
2. Partition 9 auf /mnt mounten.
3. grub aufrufen
- setup --stage2=/mnt/boot/grub/stage2 --force-lba (hd0,8) (hd0,8)
  quit

Rainer Juhser · 24 Juli 2009

Um derartigen Problemen von vorne herein aus dem Weg gehen, sieht meine Konfiguration wie folgt aus:

Code:

sda1  SWAP
sda2  /      (Arbeitssystem)
sda3  /home  (Arbeitssystem)
sda4 erweiterte Partition mit:
sda5  /      (Testsystem)
sda6  /home  (Testsystem)

Arbeitssystem ist zur Zeit ein OS 11.1 mit KDE 3.5.10, Testsystem ein OS 11.1 mit KDE 4.2.
Bei beiden Systemen ist Grub in den Bootsektor der Root-Partition installiert. Somit sind beide Installationen sauber voneinander getrennt, und die Grubs kommen sich nicht gegenseitig ins Gehege. Damit das Ganze dann auch noch bootfähig ist, benutze ich den GAG (http://gag.sourceforge.net/) als übergeordneten Bootmanager.

Ich habe das seit Anfang 2008 so eingerichtet (anfangs auch mit einem Windows XP und 2 Linuxen).
Seitdem habe ich keinen Ärger mehr mit Grubs verschiedener Linux-Distributionen, die sich verselbständigen wollen.

josef-wien · 24 Juli 2009

Loki.Linuxfan schrieb:
Wieso kommt die Kiste denn nun trotzdem noch auf die Idee, hda7 als / zu mounten ?

Das weiß ich im Augenblick auch nicht, bei mir funktioniert das problemlos. Bist du ganz sicher, daß der Inhalt der Dateien menu.lst und fstab von der Partition 9 stammt? Wie sehen die ganzen Dateien und wie sehen die Dateien /boot/grub/device.map und /etc/fstab von Partition 7 (alle vier Dateien einschließlich des Anzeige-Befehls cat zeigen) aus? Wieso sprichst Du von hda7 und nicht von sda7 (Dein Kernel gehört zu 11.1, und seit 10.3 wird libata verwendet, da gibt es kein hda mehr)?

Ändere die UUID von Partition 9 (tune2fs -U random /dev/sda9), führe die GRUB-Installation noch einmal durch und zeige die gesame Ausgabe von "root (hd0,8)" bis "Done."

An Tooltime: Das bewirkt auch nichts anderes.

An Rainer Juhser: Das ist eine mögliche Vorgangsweise, mehrere Systeme zu starten, aber das hat mit dem Problem der kopierten Partition nichts zu tun.

Rainer Juhser · 24 Juli 2009

josef-wien schrieb:
An Rainer Juhser: Das ist eine mögliche Vorgangsweise, mehrere Systeme zu starten, aber das hat mit dem Problem der kopierten Partition nichts zu tun.

Das weiß ich!

Rainer Juhser schrieb:
Um derartigen Problemen von vorne herein aus dem Weg gehen, sieht meine Konfiguration wie folgt aus:

Ich finde nur, dass es manchmal besser ist, durch ein offenes Fenster einzusteigen, anstatt sich an der verschlossenen Tür den Schädel einzurennen.

Loki.Linuxfan · 25 Juli 2009

Hallo alle,

erstmal danke, daß Ihr mich bei der Lösung meines Problems unterstützt.

Um derartigen Problemen von vorne herein aus dem Weg gehen, sieht meine Konfiguration wie folgt aus:

Meine ist ja ganz ähnlich:

Code:

Alles in einer erweiterten Partition:
sda5    (primärer Grub, der per chainload oder direkt dann die Betriebssystempartitionen startet)
sda6    swap
sda7 /  (Arbeitssystem)
sda8 /home (Arbeitssystem)
sda9 / (Backupsystem)
sda10 /home (Backupsystem, aber bisher nirgendwo eingebunden)

Unterschiede also:

Alles in einer erweiterten Partition
Grub statt GAG zum Primärstart

Sollte doch eigentlich keinen so großen Unterschied machen ... :-?

Bist du ganz sicher, daß der Inhalt der Dateien menu.lst und fstab von der Partition 9 stammt?

Bei menu.lst ja, denn die beiden Dateien sind auf den Partitionen unterschiedlich: sda7 hat mehrere Einträge (SUSE-Standard mit Hauptsystem, Failsafe und Diskette), auf sda9 habe ich bis auf das Hauptsystem alle gelöscht. Wenn ich also nur einen Eintrag angezeigt bekomme, ist die verwendete menu.lst definitiv von sda9.
Bei fstab bin ich mir nicht sicher, wie könnte ich das feststellen ? Wenn das sda7-System gebootet ist (über den Grub von sda9) sehe ich unter /etc/fstab eindeutig die von sda7. :-(

Wie sehen die ganzen Dateien und wie sehen die Dateien /boot/grub/device.map und /etc/fstab von Partition 7 (alle vier Dateien einschließlich des Anzeige-Befehls cat zeigen) aus?

OK, Du hast es gewollt ... ;-)
Habe sda7 gestartet, sda9 gemountet und "cat"e jetzt fleißig:

sda7, /boot/grub/menu.lst:

Code:

>cat /boot/grub/menu.lst
# Modified by YaST2. Last modification on Mi Jul 22 22:30:18 CEST 2009
default 0
timeout 5
gfxmenu (hd0,6)/boot/message

###Don't change this comment - YaST2 identifier: Original name: linux###
title openSUSE 11.1 Portable FfM - 2.6.27.23-0.1
    root (hd0,6)
    kernel /boot/vmlinuz-2.6.27.23-0.1-pae root=/dev/disk/by-id/ata-SAMSUNG_SP2514N_S08BJ1TL400169-part7 resume=/dev/disk/by-id/ata-SAMSUNG_SP2514N_S08BJ1TL400169-part6 splash=silent showopts vga=0x31a PROFILE=FfM
    initrd /boot/initrd-2.6.27.23-0.1-pae

###Don't change this comment - YaST2 identifier: Original name: linux###
title openSUSE 11.1 - 2.6.27.23-0.1
    root (hd0,6)
    kernel /boot/vmlinuz-2.6.27.23-0.1-pae root=/dev/disk/by-id/ata-SAMSUNG_SP2514N_S08BJ1TL400169-part7 resume=/dev/disk/by-id/ata-SAMSUNG_SP2514N_S08BJ1TL400169-part6 splash=silent showopts vga=0x31a
    initrd /boot/initrd-2.6.27.23-0.1-pae

###Don't change this comment - YaST2 identifier: Original name: failsafe###
title Failsafe -- openSUSE 11.1 - 2.6.27.23-0.1
    root (hd0,6)
    kernel /boot/vmlinuz-2.6.27.23-0.1-pae root=/dev/disk/by-id/ata-SAMSUNG_SP2514N_S08BJ1TL400169-part7 showopts ide=nodma apm=off noresume nosmp maxcpus=0 edd=off powersaved=off nohz=off highres=off processor.max_cstate=1 x11failsafe vga=0x31a
    initrd /boot/initrd-2.6.27.23-0.1-pae

###Don't change this comment - YaST2 identifier: Original name: floppy###
title Diskette
    rootnoverify (fd0)
    chainloader +1

sda9 /boot/grub/menu.lst

Code:

>cat /mnt/temp/boot/grub/menu.lst
# Modified by YaST2. Last modification on Tue Jul 14 07:51:36 CEST 2009
default 0
timeout 5
gfxmenu (hd0,8)/boot/message

###Don't change this comment - YaST2 identifier: Original name: linux###
title openSUSE 11.1 Portable FfM Backup - 2.6.27.23-0.1
    root (hd0,8)
    kernel /boot/vmlinuz-2.6.27.23-0.1-pae root=/dev/disk/by-id/ata-SAMSUNG_SP2514N_S08BJ1TL400169-part9 resume=/dev/disk/by-id/ata-SAMSUNG_SP2514N_S08BJ1TL400169-part6 splash=silent showopts vga=0x31a PROFILE=FfM
    initrd /boot/initrd-2.6.27.23-0.1-pae

sda7 /etc/fstab:

Code:

>cat /etc/fstab
/dev/disk/by-id/ata-SAMSUNG_SP2514N_S08BJ1TL400169-part7 /                    ext3       acl,user_xattr        1 1
/dev/disk/by-id/ata-SAMSUNG_SP2514N_S08BJ1TL400169-part8 /home                ext3       acl,user_xattr        1 2
/dev/disk/by-id/ata-SAMSUNG_SP2514N_S08BJ1TL400169-part6 swap                 swap       defaults              0 0
/dev/disk/by-id/ata-SAMSUNG_SP2514N_S08BJ1TL400169-part5 /Grub_Master         ext3       defaults              1 2
proc                 /proc                proc       defaults              0 0
sysfs                /sys                 sysfs      noauto                0 0
debugfs              /sys/kernel/debug    debugfs    noauto                0 0
usbfs                /proc/bus/usb        usbfs      noauto                0 0
devpts               /dev/pts             devpts     mode=0620,gid=5       0 0

sda9 /etc/fstab:

Code:

>cat /mnt/temp/etc/fstab
/dev/disk/by-id/ata-SAMSUNG_SP2514N_S08BJ1TL400169-part9 /                    ext3       acl,user_xattr        1 1
/dev/disk/by-id/ata-SAMSUNG_SP2514N_S08BJ1TL400169-part8 /home                ext3       acl,user_xattr        1 2
/dev/disk/by-id/ata-SAMSUNG_SP2514N_S08BJ1TL400169-part6 swap                 swap       defaults              0 0
/dev/disk/by-id/ata-SAMSUNG_SP2514N_S08BJ1TL400169-part5 /Grub_Master         ext3       defaults              1 2
proc                 /proc                proc       defaults              0 0
sysfs                /sys                 sysfs      noauto                0 0
debugfs              /sys/kernel/debug    debugfs    noauto                0 0
usbfs                /proc/bus/usb        usbfs      noauto                0 0
devpts               /dev/pts             devpts     mode=0620,gid=5       0 0

sda7 /boot/grub/device.map:

Code:

>cat /boot/grub/device.map
(fd0)   /dev/fd0
(hd0)   /dev/disk/by-id/ata-SAMSUNG_SP2514N_S08BJ1TL400169

sda9 /boot/grub/device.map:

Code:

>cat /mnt/temp/boot/grub/device.map
(fd0)   /dev/fd0
(hd0)   /dev/disk/by-id/ata-SAMSUNG_SP2514N_S08BJ1TL400169

Sieht für mich alles völlig OK aus, deshalb bin ich ziemlich erstaunt ... :-?

Wieso sprichst Du von hda7 und nicht von sda7 (Dein Kernel gehört zu 11.1, und seit 10.3 wird libata verwendet, da gibt es kein hda mehr)?

Richtig, ich habe da sozusagen die "gemischte" Bezeichnung verwendet: Grub ("hda" statt "sda") und SUSE (Partitionszahl statt Partitionszahl-1). Aber da scheint schon alles OK zu sein:

Code:

df
Dateisystem          1K‐Blöcke   Benutzt Verfügbar Ben% Eingehängt auf
/dev/sda7             20161172   4152992  14984040  22% /
udev                    510756       376    510380   1% /dev
/dev/sda8             40313964   8132952  30133128  22% /home
/dev/sda5                23300     11131     10966  51% /Grub_Master
/dev/sda9             20161172   4148000  14989032  22% /mnt/temp

Der Vollständigkeit halber:

Code:

>mount
/dev/sda7 on / type ext3 (rw,acl,user_xattr)
/proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
debugfs on /sys/kernel/debug type debugfs (rw)
udev on /dev type tmpfs (rw)
devpts on /dev/pts type devpts (rw,mode=0620,gid=5)
/dev/sda8 on /home type ext3 (rw,acl,user_xattr)
/dev/sda5 on /Grub_Master type ext3 (rw)
fusectl on /sys/fs/fuse/connections type fusectl (rw)
securityfs on /sys/kernel/security type securityfs (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
/proc on /var/lib/ntp/proc type proc (ro)
/dev/sda9 on /mnt/temp type ext3 (rw)

Ändere die UUID von Partition 9 (tune2fs -U random /dev/sda9), führe die GRUB-Installation noch einmal durch und zeige die gesame Ausgabe von "root (hd0,8)" bis "Done."

Du meinst, die UUID wurde von gparted mitkopiert und deshalb gerät der GRUB auf sda9 durcheinander ? OK, das teste ich jetzt gleich mal und bin gespannt, was passiert ...

Loki.Linuxfan · 25 Juli 2009

Du meinst, die UUID wurde von gparted mitkopiert und deshalb gerät der GRUB auf sda9 durcheinander ? OK, das teste ich jetzt gleich mal und bin gespannt, was passiert ...

:-(

Code:

# tune2fs -U random /dev/sda9
tune2fs 1.41.1 (01-Sep-2008)


# grub


    GNU GRUB  version 0.97  (640K lower / 3072K upper memory)

 [ Minimal BASH-like line editing is supported.  For the first word, TAB
   lists possible command completions.  Anywhere else TAB lists the possible
   completions of a device/filename. ]
grub> root (hd0,8)
root (hd0,8)
 Filesystem type is ext2fs, partition type 0x83
grub> setup (hd0,8)
setup (hd0,8)
 Checking if "/boot/grub/stage1" exists... yes
 Checking if "/boot/grub/stage2" exists... yes
 Checking if "/boot/grub/e2fs_stage1_5" exists... yes
 Running "embed /boot/grub/e2fs_stage1_5 (hd0,8)"... failed (this is not fatal)
 Running "embed /boot/grub/e2fs_stage1_5 (hd0,8)"... failed (this is not fatal)
 Running "install /boot/grub/stage1 (hd0,8) /boot/grub/stage2 p /boot/grub/menu.lst "... succeeded
Done.
grub> quit
quit

Reboot ...
menu.lst von sda9 wird angezeigt (nur ein Eintrag), also los ...
System wird gestartet, login und ...

Code:

# df
Dateisystem          1K‐Blöcke   Benutzt Verfügbar Ben% Eingehängt auf
/dev/sda7             20161172   4153100  14983932  22% /
udev                    510756       444    510312   1% /dev
/dev/sda8             40313964   8132572  30133508  22% /home
/dev/sda5                23300     11131     10966  51% /Grub_Master

Oder auch:

Code:

# mount
/dev/sda7 on / type ext3 (rw,acl,user_xattr)
/proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
debugfs on /sys/kernel/debug type debugfs (rw)
udev on /dev type tmpfs (rw)
devpts on /dev/pts type devpts (rw,mode=0620,gid=5)
/dev/sda8 on /home type ext3 (rw,acl,user_xattr)
/dev/sda5 on /Grub_Master type ext3 (rw)
fusectl on /sys/fs/fuse/connections type fusectl (rw)
securityfs on /sys/kernel/security type securityfs (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
/proc on /var/lib/ntp/proc type proc (ro)

Wieso denn immer noch sda7 als / ??? :-?
Mein System gehorcht mir nicht ... :-(

Loki.Linuxfan · 25 Juli 2009

Mal eine ganz andere Idee ... könnte es sein, daß das System nur glaubt, auf / sei sda7, und in Wirklichkeit ist es doch sda9 ?
Test: Ich lege eine Datei auf / an (nach Grub-Boot mit sda9-Auswahl von eben, reboote in sda7 und schaue nach, ob sie noch da ist ...
(Stay tuned for more ... ;-))

Loki.Linuxfan · 25 Juli 2009

Test: Ich lege eine Datei auf / an (nach Grub-Boot mit sda9-Auswahl von eben, reboote in sda7 und schaue nach, ob sie noch da ist ...

Traurig, aber wahr: Wo sda7 gemeldet wird, ist auch sda7 drin.
Soll heißen, die Testdatei war auch beim Boot der "anderen" Partition noch da. So einfach ist die Lösung also nicht ...
:-(

Jetzt gehe ich erstmal frustriert schlafen. ;-)

Rainer Juhser · 25 Juli 2009

Loki.Linuxfan schrieb:
Unterschiede also:

Alles in einer erweiterten Partition
Grub statt GAG zum Primärstart

Sollte doch eigentlich keinen so großen Unterschied machen ... :-?

Der entscheidende Unterschied (der mir das Leben leichter macht) liegt hier:

Grub statt GAG zum Primärstart

Meine Partitionierung hatte ich eigentlich nur der Vollständigkeit halber mit angegeben.

josef-wien · 25 Juli 2009

Loki.Linuxfan schrieb:
Sieht für mich alles völlig OK aus

Dieser Meinung bin ich auch.

Zeige mir einmal die Datei /var/log/boot.msg nach einem "mißlungenen" Start von sda9, aber bitte so: http://www.linux-club.de/viewtopic.php?f=3&t=101323

P.S. Die UUID wird beim Formatieren festgelegt und ist daher in einer Kopie unverändert enthalten. GRUB macht nichts mit der UUID (außer in der modifizierten Version von Ubuntu & Co.), ich wollte nur, daß Du nicht zwei identische UUID hast, irgendwann könntest Du sonst Probleme bekommen.

Anonymous · 25 Juli 2009

Recht interessantes Phänomen. Um dieses genau zu untersuchen bräuchte man wirklich die ganze log vom boot.
Was ich jedoch vermute, das ganze hängt mit der initrd zusammen. Die initrd kennt das Orginalrootsystem und hat mehrere "Fall back" Prozeduren, das heißt wenn was nicht stimmt mit dem Root- oder Resum-System dann kann es unter Umständen automatisch auf die default Werte der initrd zurückfallen. Dazu gibt es welche die auf der Bootkonsole bestätigt werden wollen und welche die funktionieren stillschweigend. Aus diesem Grunde funktioniert auf 11.1 zB auch so ein Booteintrag hier völlig ohne Probleme.

Code:

###Don't change this comment - YaST2 identifier: Original name: linux###
title openSUSE 11.1 - 2.6.27.21-0.1
    root (hd0,0)
    kernel /vmlinuz-2.6.27.21-0.1-pae splash=silent showopts vga=0x314
    initrd /initrd-2.6.27.21-0.1-pae

Innerhalb der initrd handiert er in den neuen Versionen nur noch mit udev. Das macht es nicht besonders leicht dort genau herauszubekommen was er jetzt genau sucht, oder besser ausgedrückt auf welchem Device er was wann sucht, dem was in den initrd eingetrage ist oder dem was bei den Kerneloptionen mitgegeben wird. Müsste man sich wohl selbst so eine Konstellation zusammenbauen und austesten.

Ich würde mal versuchen für das 2. System eine eigene "modifizierte" initrd zu erstellen. Ich zeigt dir das mal anhand meines Systems, also die Namen usw müsstest du bei dir entsprechend selbst anpassen.
Das Auspacken:

Code:

dhcppc0:/boot # cd /boot
dhcppc0:/boot # ls -l initrd*
lrwxrwxrwx 1 root root      24 May 21 22:17 initrd -> initrd-2.6.27.21-0.1-pae
-rw-r--r-- 1 root root 5760218 May 21 22:17 initrd-2.6.27.21-0.1-pae
dhcppc0:/boot # cp initrd-2.6.27.21-0.1-pae /tmp/initrd-2.6.27.21-0.1-pae.gz
dhcppc0:/boot # cd /tmp
dhcppc0:/tmp # gunzip /tmp/initrd-2.6.27.21-0.1-pae.gz
dhcppc0:/tmp # mkdir initrd
dhcppc0:/tmp # cd initrd
dhcppc0:/tmp/initrd # cpio -imd < ../initrd-2.6.27.21-0.1-pae
22998 blocks
dhcppc0:/tmp/initrd # ls
bin  boot  bootsplash  config  dev  etc  init  lib  mkinitrd.config  proc  root  run_all.sh  sbin  sys  tmp  usr  var
dhcppc0:/tmp/initrd # cd config/
dhcppc0:/tmp/initrd/config # ls
block.sh  mount.sh  splash.sh  start.sh  storage.sh  udev.sh  usb.sh
dhcppc0:/tmp/initrd/config # cat mount.sh storage.sh
[ "$rootdev" ] || rootdev='/dev/disk/by-id/scsi-SFUJITSU_MAS3735NC_A034P39005M5-part2'
[ "$rootfsck" ] || rootfsck='/sbin/fsck.ext3'
[ "$fallback_rootdev" ] || fallback_rootdev='/dev/disk/by-id/scsi-SFUJITSU_MAS3735NC_A034P39005M5-part2'
[ "$rootdev" ] || rootdev='/dev/disk/by-id/scsi-SFUJITSU_MAS3735NC_A034P39005M5-part2'
[ "$resumedev" ] || resumedev='/dev/disk/by-id/ata-ST38421A_3BD13HFW-part2'
dhcppc0:/tmp/initrd/config #

Diese beiden Dateien müsstest du anpassen und dort jeweils bei rootdev und fallback_rootdev und eventuell auch bei resumedev die Parititionen ändern.
Dann wieder einpacken

Code:

dhcppc0:/tmp/initrd/config # cd /tmp/initrd
dhcppc0:/tmp/initrd # find . | cpio -oc | gzip -9n > /boot/initrd-2.6.27.21-0.1-pae_modify
23002 blocks
dhcppc0:/tmp/initrd # cd /boot
dhcppc0:/boot # ls initrd*
initrd  initrd-2.6.27.21-0.1-pae  initrd-2.6.27.21-0.1-pae_modify

und dann auf den neuen initrd-namen in der menu.lst ändern. Wir haben also hier eine neue modifizierte initrd angelegt.

PS
Ich muss jetzt aber erst mal selbst rebooten, ob das auch so funktioniert.

Also die Fehler beim Zusammenbauen sind jetzt raus, die modifizierte initrd wird also solche sauber erkannt und funktioniert einwandfrei.

robi

josef-wien · 25 Juli 2009

Falls beim Erstellen der initrd der Parameter "-d" verwendet wurde, sind auch in den Dateien mkinitrd.config (die ist hier wohl belanglos) und config/start.sh "Device"-Angaben enthalten. Mit und ohne Parameter kommt noch die Datei run_all.sh hinzu.

Statt dem Entpacken, Ändern und Einpacken ist es einfacher, bei der Erstellung der initrd die "Device" anzugeben:
mkinitrd -d /dev/disk/by-id/ata-SAMSUNG_SP2514N_S08BJ1TL400169-part9

Bei mir ist es völlig gleichgültig, welche "Device" enthalten ist, es funktioniert jede initrd zum Starten des Kernel gemäß Kernel-Parameter "root". Auch mit einer für RAID1 ausgelegten initrd kann ich jede normale Partition starten. Ich denke, daß die "Device" in der initrd nur dann zum Zug kommt, wenn in der menu.lst der Kernel-Parameter "root" fehlt. Aber warum soll der PC von Loki.Linuxfan nicht anders agieren als meiner, einen Versuch ist es wert.

Loki.Linuxfan · 26 Juli 2009

Wow, jetzt geht es aber richtig in Linux-Tiefen, eigene initrd habe ich noch nie erstellt. Sehr schön, gleich wieder was gelernt ...

Leider kann ich Eure guten Hinweise erst in 1 oder zwei Woche in die Tat umsetzen, da ich erst dann wieder an meinem eigentlichen, betroffenen Rechner sein werde (dienstlich unterwegs + Urlaub

). Auch /var/log/boot.msg kann ich erst dann nach entsprechendem Bootversuch posten.

Die Platte habe ich aber gerade auf einem anderen Rechner (von dem aus ich das hier auch schreibe) im Zugriff (extern über USB), so daß ich gleich mal die initrd ausgepackt und die Dateien wie beschrieben angeschaut habe. (Ist schon praktisch, wenn man nebenbei auch noch eine kleine Puppylinux-Partition hat ... ;-))

Wie von Euch vermutet steht sowohl in mount.sh als auch in storage.sh ein "hardcoded" Verweis auf sda7:

Code:

# cd config/
# cat mount.sh storage.sh 
[ "$rootdev" ] || rootdev='/dev/disk/by-id/ata-SAMSUNG_SP2514N_S08BJ1TL400169-part7'
[ "$rootfsck" ] || rootfsck='/sbin/fsck.ext3'
[ "$fallback_rootdev" ] || fallback_rootdev='/dev/disk/by-id/ata-SAMSUNG_SP2514N_S08BJ1TL400169-part7'
[ "$rootdev" ] || rootdev='/dev/disk/by-id/ata-SAMSUNG_SP2514N_S08BJ1TL400169-part7'
[ "$resumedev" ] || resumedev='/dev/disk/by-id/ata-SAMSUNG_SP2514N_S08BJ1TL400169-part6'

Und in der Tat, auch hier versteckt sich ein weiterer absoluter Verweis auf sda7:

Code:

# cat run_all.sh | grep 7
[ "$RESOLVED_INITRD_MODULES" ] || RESOLVED_INITRD_MODULES='processor thermal pata_amd ata_generic amd74xx ide_pci_generic fan jbd ext3 edd'
[ "$fallback_rootdev" ] || fallback_rootdev='/dev/disk/by-id/ata-SAMSUNG_SP2514N_S08BJ1TL400169-part7'
[ "$rootdev" ] || rootdev='/dev/disk/by-id/ata-SAMSUNG_SP2514N_S08BJ1TL400169-part7'
[ "$rootdev" ] || rootdev='/dev/disk/by-id/ata-SAMSUNG_SP2514N_S08BJ1TL400169-part7'

Das nimmt ja gar kein Ende ... ;-)

(Das heißt dann in Konsequenz aber auch, ein mit tar gesichertes System kann man - ohne Anpassungen - auch nur auf die originale Partition zurückspielen ?)

Am Rechner hier kriege ich von dieser Platte kein boot hin (auch nicht wenn ich sie einbaue, da gibt es dann "invalid root filesystem"), daher kann ich dann erst nach Rückkehr meine eigene initrd basteln und testen, ob es klappt.
Falls es wirklich an der initrd liegt, könnte es auch etwas damit zu tun haben, daß ich eine durch das "portable"-Skript gepatchte Version laufen habe - das könnte Unterschiede im Verhalten zu Euren Rechnern erklären.
Hintergrund ist (deshalb sitze ich heute auch an einem anderen Rechner), daß ich Wochenendpendler bin, und gerne via "portable"-Skript nur noch eine identische SUSE-Version auf beiden Rechnern werktags wie am Wochenende hätte. (Am liebsten dann boot von einer externen 2,5"-Platte - falls ich das an meinen alten Kisten jemals hinbekomme - und Backup auf den lokalen Rechner. Daher mein Interesse an diesem Thema. ;-))Halber Installations- und Pflegeaufwand rechtfertigt evtl. den Aufwand bis es läuft ... und außerdem lerne ich dabei wieder viel, was ja auch schön ist.

Jetzt also erstmal ein paar Tage Funkstille von meiner Seite (Forum lesen kann ich aber evtl.über öffentlich zugängliche Rechner von unterwegs). Sobald ich zurück bin werde ich mich an die initrd machen und Euch über Erfolg oder Mißerfolg informieren.
Bis dahin schon- und nochmal vielen Dank für Eure Hilfe !

Grub: kein chainload aus geklonter Partition :-(

Loki.Linuxfan

Newbie

Tooltime

Advanced Hacker

Loki.Linuxfan

Newbie

josef-wien

Ultimate Guru

Loki.Linuxfan

Newbie

Tooltime

Advanced Hacker

Rainer Juhser

Moderator

josef-wien

Ultimate Guru

Rainer Juhser

Moderator

Loki.Linuxfan

Newbie

Loki.Linuxfan

Newbie

Loki.Linuxfan

Newbie

Loki.Linuxfan

Newbie

Rainer Juhser

Moderator

josef-wien

Ultimate Guru

Anonymous

Gast

josef-wien

Ultimate Guru

Loki.Linuxfan

Newbie