Bootsector nach Partitionierung herstellen
Hallo zusammen, ich stehe mal wieder auf dem Schlauch. Sorry! Von einer CF-Card (4GB) habe ich ein komplettes Image gezogen. Also nicht nur von /dev/sdd1, sondern von /dev/sdd. Mit rsync habe ich mir ein komplettes System-Backup angelegt. Zusaetzlich habe ich die ersten 446 B von sdd und sdd1 gesichert. dd if=/dev/sdd of=/hier/bs_sdd.img bs=446 count=1 dd if=/dev/sdd1 of=/hier/bs_sdd1.img bs=446 count=1 Bisher gab es nur eine Partition /dev/sdd1 ! Jetzt habe ich die CF-Card neu partitionieren muessen und formatiert. sdd1 -> 1GB -> ext4 -> aktive Partition sdd2 -> Rest -> fat32 Wie bekomme ich die CF-Card wieder zum Booten, _OHNE_ grub_install, sondern mit dd... dd if=/hier/bs_sdd1.img of=/dev/sdd1 bs=446 count=1 ...war nicht die Loesung :-( Bitte dankend um Rat. MfG Th. Moritz -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org
On Mon, 04 Apr 2011, 17:30:52 +0200, Thomas Moritz wrote:
Hallo zusammen,
ich stehe mal wieder auf dem Schlauch. Sorry!
Von einer CF-Card (4GB) habe ich ein komplettes Image gezogen. Also nicht nur von /dev/sdd1, sondern von /dev/sdd. Mit rsync habe ich mir ein komplettes System-Backup angelegt. Zusaetzlich habe ich die ersten 446 B von sdd und sdd1 gesichert.
dd if=/dev/sdd of=/hier/bs_sdd.img bs=446 count=1 dd if=/dev/sdd1 of=/hier/bs_sdd1.img bs=446 count=1
Bisher gab es nur eine Partition /dev/sdd1 ! Jetzt habe ich die CF-Card neu partitionieren muessen und formatiert.
sdd1 -> 1GB -> ext4 -> aktive Partition sdd2 -> Rest -> fat32
Wie bekomme ich die CF-Card wieder zum Booten, _OHNE_ grub_install, sondern mit dd...
dd if=/hier/bs_sdd1.img of=/dev/sdd1 bs=446 count=1
...war nicht die Loesung :-(
Bitte dankend um Rat.
wenn du die Karte komplett neu partitioniert hast, wirst du auch den MBR wieder herstellen muessen; ein dd if=/hier/bs_sdd.img of=/dev/sdd bs=446 count=1 sollte helfen.
MfG Th. Moritz
HTH, cheers. l8er manfred -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org
Am Montag, 4. April 2011 17:37:06 schrieb Manfred Hollstein: Hallo Manfred,
wenn du die Karte komplett neu partitioniert hast, wirst du auch den MBR wieder herstellen muessen; ein
dd if=/hier/bs_sdd.img of=/dev/sdd bs=446 count=1
Hatte ich gemacht, nur nicht erwaehnt - Sorry!
sollte helfen.
Leider nein: DISK BOOT FAILURE... Mit tune2fs -l (hatte ich ebenfalls gesichert) stimmt auch das Filesystem ueberein. Filesystem magic number: 0xEF53 ist identisch Blocksize: 4096 ist identisch InodeSize: 256 ist identisch FirstInode: 11 ist identisch MfG Th. Moritz -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org
On Mon, 04 Apr 2011, 17:56:40 +0200, Thomas Moritz wrote:
Am Montag, 4. April 2011 17:37:06 schrieb Manfred Hollstein:
Hallo Manfred,
wenn du die Karte komplett neu partitioniert hast, wirst du auch den MBR wieder herstellen muessen; ein
dd if=/hier/bs_sdd.img of=/dev/sdd bs=446 count=1
Hatte ich gemacht, nur nicht erwaehnt - Sorry!
sollte helfen.
Leider nein: DISK BOOT FAILURE...
Mit tune2fs -l (hatte ich ebenfalls gesichert) stimmt auch das Filesystem ueberein.
Filesystem magic number: 0xEF53 ist identisch
Blocksize: 4096 ist identisch InodeSize: 256 ist identisch FirstInode: 11 ist identisch
hmm... /dev/sdd1 ist aktiviert?
MfG Th. Moritz
Cheers. l8er manfred -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org
Am Montag, 4. April 2011 18:11:20 schrieb Manfred Hollstein: Hallo Manfred,
hmm... /dev/sdd1 ist aktiviert?
Ja, auch! Deshalb bin ich ja so ratlos. Gerät boot. Anfang Ende Blöcke Id System /dev/sdd1 * 1 419 1051680 83 Linux /dev/sdd2 420 1563 2871440 b W95 FAT32 MfG Th. Moritz -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org
On Mon, 04 Apr 2011, 18:20:36 +0200, Thomas Moritz wrote:
Am Montag, 4. April 2011 18:11:20 schrieb Manfred Hollstein:
Hallo Manfred,
hmm... /dev/sdd1 ist aktiviert?
Ja, auch! Deshalb bin ich ja so ratlos.
Gerät boot. Anfang Ende Blöcke Id System /dev/sdd1 * 1 419 1051680 83 Linux /dev/sdd2 420 1563 2871440 b W95 FAT32
OK, dann wieder zurueck zum Anfang... Was passiert denn, wenn du bootest? Welche Fehlermeldung bekommst du? Hast du schomal versucht, von einem Rescue-System zu booten und dann per "chroot" doch eine Grub zu installieren?
MfG Th. Moritz
Cheers. l8er manfred -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org
Am Montag, 4. April 2011 18:39:51 schrieb Manfred Hollstein: Hallo Manfred,
OK, dann wieder zurueck zum Anfang... Was passiert denn, wenn du bootest? Welche Fehlermeldung bekommst du?
DISK BOOT FAILURE...
Hast du schomal versucht, von einem Rescue-System zu booten und dann per "chroot" doch eine Grub zu installieren?
Das System ist 89MB gross! Da gibt es kein perl usw. auch kein grub-install. Bei diesem Scenario geht es mir auch ums spaetere Clonen von genau diesem System. Das sollte in Kuerze per Script funktionieren. Beispiel: Neue CF-Card = 1GB Partitionierung: 200MB linux + Rest fat32 oder: Neue CF-Card =8GB Partitionierung: 1GB linux + Rest fat32 fdisk -> mkfs -> rsync -> (MBR + grub per dd) Dabei ist mir klar, dass bei abweichender InodeSize | Blocksize ein entsprechender Bootsector geclonet werden muss. Diese Sammlung muss ich noch erstellen. Erstmal sollte aber diese eine CF-Card hier booten... Was beginnt eigentlich ab offset 0x00000190? Hier: 1C 80 B6 dann 00 bis 0x000001b7 Ab offset 0x000001b8: C7 66 3F 55 CF C9 80 20 21 00 83 FA 54 E6 00 08 Ach Quatsch, ich klemme die ersten 1024B von neu und alt hinten ran. Sorry! MfG Th. Moritz
Hallo, Am Mon, 04 Apr 2011, Thomas Moritz schrieb: [..]
Erstmal sollte aber diese eine CF-Card hier booten...
Was beginnt eigentlich ab offset 0x00000190? Hier: 1C 80 B6 dann 00 bis 0x000001b7 Ab offset 0x000001b8: C7 66 3F 55 CF C9 80 20 21 00 83 FA 54 E6 00 08
Ab 0x01be beginnt die Partitionstabelle, hier ab dem 80 20 21 00 83 wobei das 83 der FS-Typ der ersten Partition ist, die bei Sektor 3F (=63) beginnt. Das davor ist der Bootcode, evtl. auch Reste von vorherigen (Grubs). Sicher weißt du das nur, wenn du die 446 Bytes mal ausnullst und dann den generischen MBR-Bootcode wieder reinschreibst (nicht den aus der Sicherung sondern neu).
Ach Quatsch, ich klemme die ersten 1024B von neu und alt hinten ran. Sorry!
Erstens: im MBR ist der Bootcode in den ersten 446 Bytes, bei einer FAT- oder NTFS Partition belegt der Bootsektor die kompletten 512 Bytes! Bei ext2/3 und wohl auch 4 ist der Bootsektor der Partition der Sektor 3 (IIRC, der mit dem 0x53 0xEF) Nur bei der erweiterten Partition und den logischen Partitionen hast du jeweils wieder eine Partitionstabelle mit jew. genau zwei Einträgen 1. der log. Partition, diese beginnt dann jew. wieder mit dem ganzen Sektor (ab Sektor 63 in der Erw. Partition) und 2. einer weiteren "erweiterten Partition". Siehe: http://en.wikipedia.org/wiki/Extended_boot_record http://en.wikipedia.org/wiki/Disk_partitioning http://en.wikipedia.org/wiki/Master_boot_record (wie gut die dt. Artikel dazu sind weiß ich nicht). Das was du angehängt hast ist jew. ein generischer BR (der die aktive Partition startet, jedenfalls kein Grub), der 2te Sektor ist der zweite Teil eines Grubs. HTH, -dnh -- Drive defensively -- buy a tank. -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org
Am Dienstag, 5. April 2011 07:38:13 schrieb David Haller: Hallo David, erstmal vielen Dank fuer die praezise Erlaeuterung!
Das was du angehängt hast ist jew. ein generischer BR (der die aktive Partition startet, jedenfalls kein Grub), der 2te Sektor ist der zweite Teil eines Grubs.
Ich klemme nun noch einmal 1024 hinten ran. Diese sind von der jetzt funktionierenden CF-Card. Hier kann ich ausser der Partitionstabelle keinen Unterschied zu dem gestrigen Versuch feststellen. Nur eben, dass diese CF jetzt rennt! MfG Th. Moritz
Hallo, Am Tue, 05 Apr 2011, Thomas Moritz schrieb:
Am Dienstag, 5. April 2011 07:38:13 schrieb David Haller:
Das was du angehängt hast ist jew. ein generischer BR (der die aktive Partition startet, jedenfalls kein Grub), der 2te Sektor ist der zweite Teil eines Grubs.
Ich klemme nun noch einmal 1024 hinten ran. Diese sind von der jetzt funktionierenden CF-Card. Hier kann ich ausser der Partitionstabelle keinen Unterschied zu dem gestrigen Versuch feststellen. Nur eben, dass diese CF jetzt rennt!
Naja, kommt halt drauf an, was im ersten Sektor der aktiven Partition steckt ;) Ist jetzt ne Linux-Partition: $ od -Ax -tx1z /dev/shm/dh/4gb_sdd.img | less 0001be 80 20 >........Çf?UÏÉ. < 0001c0 21 00 83 0d 0a 83 00 08 00 00 00 18 20 00 >!........... ...< ^^ FS-Typ Byte und ne FAT32-LBA Partition: 0001ce 00 0d >!........... ...< 0001d0 0b 83 0c fa 54 e6 00 20 20 00 00 40 57 00 >...úTæ. ..@W...< ^^ FS-Typ Byte Der generische/DOS BR interessiert sich genau gar nicht für den Folgesektor mit dem Grub-Rest, der knüppelt einfach den ersten Sektor der aktiven Partition in den Speicher und startet den darin befindlichen Code. Hat man z.B. GRUB in die Linux-Root-Partition installiert, dann startet eben der. Oder eben der BR einer FAT/NTFS Windows-Partition. Achso: guck dir mal die Ausgabe von $ od -Ax -tx1z /usr/lib/boot/master-boot-code | less an ;) $ rpm -qf /usr/lib/boot/master-boot-code master-boot-code-1.14-71.2.i586 $ od -Ax -tx1z /usr/lib/makebootfat/mbrfat.bin | less Aber in der Art schwirren noch andere durchs Netz (z.B. von freedos, IIRC). In /usr/share/syslinux/ findest du auch einige ;) HTH, -dnh -- "Die meisten Menschen pflegen im Kindesalter vom Zeigen auf Gegenstände (Mausbewegung) und 'ga' sagen (Mausklick) abzukommen, zugunsten eines mächtigeren und langwierig zu erlernenden Tools (Sprache)". -- Achim Linder in de.comp.os.unix.linux.misc -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org
Am Dienstag, 5. April 2011 11:31:21 schrieb David Haller: Hallo David,
Am Tue, 05 Apr 2011, Thomas Moritz schrieb:
Am Dienstag, 5. April 2011 07:38:13 schrieb David Haller:
Das was du angehängt hast ist jew. ein generischer BR (der die aktive Partition startet, jedenfalls kein Grub), der 2te Sektor ist der zweite Teil eines Grubs.
Ich klemme nun noch einmal 1024 hinten ran. Diese sind von der jetzt funktionierenden CF-Card. Hier kann ich ausser der Partitionstabelle keinen Unterschied zu dem gestrigen Versuch feststellen. Nur eben, dass diese CF jetzt rennt!
Naja, kommt halt drauf an, was im ersten Sektor der aktiven Partition steckt ;) Ist jetzt ne Linux-Partition:
Ich zitiere mal Deine letzte Mail: Ab 0x01be beginnt die Partitionstabelle, hier ab dem 80 20 21 00 83 wobei das 83 der FS-Typ der ersten Partition ist, die bei Sektor 3F (=63) beginnt. OK, also auch eine Linux-Partition. Alles andere haette mich auch verwundert! Ich hatte ja die zweite CF-Card neu Partitioniert und Formatiert: 1.Partition 1GB Linux/ext4 2.Partition Rest Windows/mkfs.msdos -F32
$ od -Ax -tx1z /dev/shm/dh/4gb_sdd.img | less 0001be 80 20
........Çf?UÏÉ. < 0001c0 21 00 83 0d 0a 83 00 08 00 00 00 18 20 00 >!........... ...< ^^ FS-Typ Byte
und ne FAT32-LBA Partition:
0001ce 00 0d
!........... ...< 0001d0 0b 83 0c fa 54 e6 00 20 20 00 00 40 57 00 >...úTæ. ..@W...< ^^ FS-Typ Byte
Der generische/DOS BR interessiert sich genau gar nicht für den Folgesektor mit dem Grub-Rest, der knüppelt einfach den ersten Sektor der aktiven Partition in den Speicher und startet den darin befindlichen Code. Hat man z.B. GRUB in die Linux-Root-Partition installiert, dann startet eben der.
Da ich von der "lauffaehigen" Karte (grub in Linux-Root-Partition) die ersten 446B nach /dev/sdd1 (neue CF) kopiert hatte, sollte doch grub gestartet werden koennen. Den MBR (446B) hatte ich auch nach /dev/sdd (neue CF) kopiert! Was war nun eigentlich an meiner beschriebenen Vorgehensweise falsch? *lauffaehige CF-Card (nicht eingebunden) -MBR #dd if=/dev/sdd of=/hier/mbr.img bs=446 count=1 -Bootsector / #dd if=/dev/sdd1 of=/hier/bsl.img bs=446 count=1 *CF-Card einbinden -Daten #rsync -avxXHAS /media/disk/ /hier/hin/ **neue CF-Card (nicht eingebunden) -fdisk (Partitionierung s.oben) -mkfs.ext4 /dev/sdd1 -mkfs.msdos -F32 /dev/sdd2 -dd if=/hier/mbr.img of=/dev/sdd bs=446 count=1 -dd if=/hier/bsl.img of=/dev/sdd1 bs=446 count=1 **/dev/sdd1 einbinden -rsync -avxXHAS /hier/hin/ /media/disk/ Beide Partitionen liessen sich problemlos mounten! Warum wurde grub beim Systemstart im PC104 nicht gefunden? DISK BOOT FAILURE... Ich muss das Szenario noch 2x auf verschieden-grossen CFs durchfuehren und werde dabei den HexDump beobachten! Bin gespannt, wann genau da was schief laeuft. Vielen Dank fuer die umfangreichen Infos! MfG Th. Moritz -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org
Hallo, Am Tue, 05 Apr 2011, Thomas Moritz schrieb:
Am Dienstag, 5. April 2011 11:31:21 schrieb David Haller:
Am Tue, 05 Apr 2011, Thomas Moritz schrieb:
Am Dienstag, 5. April 2011 07:38:13 schrieb David Haller:
Das was du angehängt hast ist jew. ein generischer BR (der die aktive Partition startet, jedenfalls kein Grub), der 2te Sektor ist der zweite Teil eines Grubs.
Ich klemme nun noch einmal 1024 hinten ran. Diese sind von der jetzt funktionierenden CF-Card. Hier kann ich ausser der Partitionstabelle keinen Unterschied zu dem gestrigen Versuch feststellen. Nur eben, dass diese CF jetzt rennt!
Naja, kommt halt drauf an, was im ersten Sektor der aktiven Partition steckt ;) Ist jetzt ne Linux-Partition:
Ich zitiere mal Deine letzte Mail: Ab 0x01be beginnt die Partitionstabelle, hier ab dem 80 20 21 00 83 wobei das 83 der FS-Typ der ersten Partition ist, die bei Sektor 3F (=63) beginnt.
OK, also auch eine Linux-Partition. Alles andere haette mich auch verwundert! Ich hatte ja die zweite CF-Card neu Partitioniert und Formatiert: 1.Partition 1GB Linux/ext4 2.Partition Rest Windows/mkfs.msdos -F32
Jep, das passt. Übrigens, das "aktiv"-Flag ist das erste Byte eines Partitionseintrags, wenn 0x00 ist nix, wenn 0x80 ist die Partition aktiv.
$ od -Ax -tx1z /dev/shm/dh/4gb_sdd.img | less 0001be 80 20
........Çf?UÏÉ. < 0001c0 21 00 83 0d 0a 83 00 08 00 00 00 18 20 00 >!........... ...< ^^ FS-Typ Byte
und ne FAT32-LBA Partition:
0001ce 00 0d
!........... ...< 0001d0 0b 83 0c fa 54 e6 00 20 20 00 00 40 57 00 >...úTæ. ..@W...< ^^ FS-Typ Byte
Der generische/DOS BR interessiert sich genau gar nicht für den Folgesektor mit dem Grub-Rest, der knüppelt einfach den ersten Sektor der aktiven Partition in den Speicher und startet den darin befindlichen Code. Hat man z.B. GRUB in die Linux-Root-Partition installiert, dann startet eben der.
Da ich von der "lauffaehigen" Karte (grub in Linux-Root-Partition) die ersten 446B nach /dev/sdd1 (neue CF) kopiert hatte, sollte doch grub gestartet werden koennen.
Nein! Flasch! GRUB braucht mind. 2 Sektoren (siehe Sektor 2 der CF-Karte, da steckt auch noch Grub drin, siehe meine vorigen Mails). Den ersten Sektor von GRUB erkennst du an dem String: # od -Ax -tx1z /boot/grub/stage1 |less 000180 fe 47 52 55 42 20 00 47 65 6f 6d 00 48 61 72 64 >þGRUB .Geom.Hard< 000190 20 44 69 73 6b 00 52 65 61 64 00 20 45 72 72 6f > Disk.Read. Erro< Bei ner HDD-Installation fehlt da aber dann Stage 1.5: # od -Ax -tx1z /boot/grub/e2fs_stage1_5 |less 000100 00 eb fe 4c 6f 61 64 69 6e 67 20 73 74 61 67 65 >.ëþLoading stage< 000110 31 2e 35 00 2e 00 0d 0a 00 47 65 6f 6d 00 52 65 >1.5......Geom.Re< 000120 61 64 00 20 45 72 72 6f 72 00 bb 01 00 b4 0e cd >ad. Error.»..Ž.Í<
Den MBR (446B) hatte ich auch nach /dev/sdd (neue CF) kopiert!
Ok, also den generischen Boot-Code, das war korrekt.
Was war nun eigentlich an meiner beschriebenen Vorgehensweise falsch?
Dem Grub fehlt stage1.5. Deswegen gibt's: grub-install.unsupported /dev/sdd (aber s.u.)!
*lauffaehige CF-Card (nicht eingebunden) -MBR #dd if=/dev/sdd of=/hier/mbr.img bs=446 count=1
ok, (generischen) Bootcode ausgelesen
-Bootsector / #dd if=/dev/sdd1 of=/hier/bsl.img bs=446 count=1
Hiermit liest du max. stage1 vom Grub aus.
*CF-Card einbinden -Daten #rsync -avxXHAS /media/disk/ /hier/hin/
**neue CF-Card (nicht eingebunden) -fdisk (Partitionierung s.oben) -mkfs.ext4 /dev/sdd1 -mkfs.msdos -F32 /dev/sdd2 -dd if=/hier/mbr.img of=/dev/sdd bs=446 count=1
ok, generischen Bootcode in den MBR
-dd if=/hier/bsl.img of=/dev/sdd1 bs=446 count=1
Hier fehlt dem Grub dann stage1.5 und vor allem fehlt dem dann, wo er seine menu.lst und stage2 findet. Deswegen: grub-install (aber s.u.)!.
**/dev/sdd1 einbinden -rsync -avxXHAS /hier/hin/ /media/disk/
Beide Partitionen liessen sich problemlos mounten! Warum wurde grub beim Systemstart im PC104 nicht gefunden? DISK BOOT FAILURE...
s.o.
Ich muss das Szenario noch 2x auf verschieden-grossen CFs durchfuehren und werde dabei den HexDump beobachten! Bin gespannt, wann genau da was schief laeuft.
Lies auch mal 'info grub' ;) Da steht genau drin, was wie gebooted wird. Und -- wenn du nicht per "aktiver Partition" zur FAT umschalten willst: schreib GRUB einfach in den MBR. Da du ja nicht das aktuelle System (dessen menu.lst) verwenden willst mußt du entweder ein chroot in die gemountede CF (sdd1) machen, oder GRUB ohne 'grub-install' manuell dort installieren (IIRC): # mount /dev/sdd1 /mnt/sdd1 # mount -o bind /proc /mnt/sdd1/proc # mount -o bind /dev /mnt/sdd1/sys # mount -o bind /sys /mnt/sdd1/dev # chroot /mnt/sdd1 # grub grub> setup --stage2=/boot/grub/stage2 (hd0) (hd0,0) grub> quit grub> help setup setup: setup [--prefix=DIR] [--stage2=STAGE2_FILE] [--force-lba[=off]] INSTALL_ DEVICE [IMAGE_DEVICE] Set up the installation of GRUB automatically. This command uses the more flexible command "install" in the backend and installs GRUB into the device INSTALL_DEVICE. If IMAGE_DEVICE is specified, then find the GRUB images in the device IMAGE_DEVICE, otherwise use the current "root device", which can be set by the command "root". -> Das "IMAGE_DEVICE" ist, wo GRUB dann stage2 und die menu.lst sucht. Du kannst natürlich auch weiter in die /-Partition installieren: grub> setup --stage2=/boot/grub/stage2 (hd0,0) (hd0,0) Wobei da die /boot/grub/device.map den passenden Eintrag haben muß, daß (hd0) == CF-Karte. Wenn's dann klemmt mußt du gucken, als was das device im Grub von CF-gebootet auftaucht (da hilft dann z.B. 'find /boot/grub/menu.lst' am grub-Prompt. HTH, -dnh -- It is traditional, when loading wire trolleys, to put the most fragile items at the bottom. -- Terry Pratchett, Reaper Man -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org
Am Dienstag, 5. April 2011 21:49:35 schrieb David Haller: Hallo, OK, ich habe mich in der Richtung festgefahren, dass es allein mit 'dd' klappen muss. Leider lag ich mal wieder falsch, aber nicht grundsaetzlich! Siehe unten (2).
Da du ja nicht das aktuelle System (dessen menu.lst) verwenden willst mußt du entweder ein chroot in die gemountede CF (sdd1) machen, oder GRUB ohne 'grub-install' manuell dort installieren (IIRC):
# mount /dev/sdd1 /mnt/sdd1 # mount -o bind /proc /mnt/sdd1/proc # mount -o bind /dev /mnt/sdd1/sys # mount -o bind /sys /mnt/sdd1/dev # chroot /mnt/sdd1 # grub grub> setup --stage2=/boot/grub/stage2 (hd0) (hd0,0) grub> quit
...was aber bedeutet, dass eine Linuxkiste mit 'grub' verfuegbar ist! Hier ist das kein Problem, aber die Kiste will ich in Kuerze abgeben und nicht gleich wieder auf dem Tisch haben, nur weil das System zu Clonen ist. Ich sehe 2 Moeglichkeiten, wobei mir die Variante (2) guenstiger erscheint: 1) Ich liefere einen USB-Boot-Stick mit einer Mini-Suse dazu (hab ich mit Suse-Studio mal gebaut) Dann kann ich grub per chroot installieren lassen! OhhOhh... 2) Ich mache ein 256MB _bootfaehiges_ Image fertig sdd1 -> 200MB -> System (200MB, falls spaeter noch was rein muss) sdd2 -> restMB -> vfat dd if=/dev/sdd of=/cf.img bs=32k Egal auf welche Karte das cf.img nun raufgebuegelt wird, wird es auch booten! Um den restlichen Platz auf der Karte zugaenglich zu machen, ist lediglich die vfat-Partition (ja nach Kartengroesse) zu vergroessern. Leider kann das 'resize2fs' nicht. _Idee_ zum Vergroessern (ungetestet!): [Ich hoffe, ich habe die fdisk-Tasten soweit im Kopf :-) ] ************************************************************** [...] mydev=$1 #nur zur Demo umount /mnt/$mydev2 fdisk /dev/$mydev <<EOF >/dev/null 2>&1 d 2 n p 2 t b w EOF mkfs.msdos -F32 /dev/$mydev2 tune2fs ... #fsck Zyclen setzen usw. [...] mount /dev/$mydev2 #steht ja bereits in der fstab vom img ************************************************************** Gibt es Einwaende oder Verbesserungen? Vielen Dank! MfG Th. Moritz -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org
Am Mittwoch, 6. April 2011 14:52:46 schrieb Thomas Moritz: Sorry, war zu schnell.. 2x Returen vergessen und auf Type 'c' umgestellt fdisk /dev/$mydev <<EOF >/dev/null 2>&1 d 2 n p 2 t 2 c w EOF MfG Th. Moritz -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org
Hallo, Am Wed, 06 Apr 2011, Thomas Moritz schrieb:
...was aber bedeutet, dass eine Linuxkiste mit 'grub' verfuegbar ist! Hier ist das kein Problem, aber die Kiste will ich in Kuerze abgeben und nicht gleich wieder auf dem Tisch haben, nur weil das System zu Clonen ist. Ich sehe 2 Moeglichkeiten, wobei mir die Variante (2) guenstiger erscheint:
1) Ich liefere einen USB-Boot-Stick mit einer Mini-Suse dazu (hab ich mit Suse-Studio mal gebaut) Dann kann ich grub per chroot installieren lassen! OhhOhh...
2) Ich mache ein 256MB _bootfaehiges_ Image fertig sdd1 -> 200MB -> System (200MB, falls spaeter noch was rein muss) sdd2 -> restMB -> vfat dd if=/dev/sdd of=/cf.img bs=32k Egal auf welche Karte das cf.img nun raufgebuegelt wird, wird es auch booten! Um den restlichen Platz auf der Karte zugaenglich zu machen, ist lediglich die vfat-Partition (ja nach Kartengroesse) zu vergroessern. Leider kann das 'resize2fs' nicht.
_Idee_ zum Vergroessern (ungetestet!): [Ich hoffe, ich habe die fdisk-Tasten soweit im Kopf :-) ]
************************************************************** [...] mydev=$1 #nur zur Demo umount /mnt/$mydev2 fdisk /dev/$mydev <<EOF >/dev/null 2>&1 d 2 n p 2 t b w EOF
Ich glaub nicht daß das so geht (ausserdem fehlt der FS-Typ). Für sowas nimm sfdisk oder parted.
mkfs.msdos -F32 /dev/$mydev2 tune2fs ... #fsck Zyclen setzen usw. [...] mount /dev/$mydev2 #steht ja bereits in der fstab vom img **************************************************************
Gibt es Einwaende oder Verbesserungen? Vielen Dank!
Gegenvorschlag, der ähnlich dem ist, was du jetzt hast: Schreib GRUB in den BR der Linux-Partition, dann kannst du den komplett mit dd mir ins Image der _Partition_ holen: dd if=/dev/sdd1 of=cf-linux-root.img bs=8M Dann kannst du den generischen MBR-Code, der einfach die aktive Partition startet in den MBR schreiben (nur die ersten 446 Bytes). Und wenn du die Partitionstabelle im MBR (nur die für die Linux-Partition) in den MBR schreibst wäre es sogar Partitioniert, sinnvoller ist aber evtl. auch die Linux-Partition per sfdisk/parted anzulegen. Die FAT32 Partition legst du dann einfach mit sfdisk/parted an. Sei /dev/sdk die leere CF-Karte (nur damit es jetzt nicht mit vorigen Angaben kollidiert) und in der Annahme, daß die Linux-Partition exakt 200M groß ist: $ /sbin/sfdisk -n -uS /dev/sdk <<'EOF' 64,409600,83,* 409664,,0C EOF $ dd if=cf-linux-root.img of=/dev/sdk1 bs=8M count=25 $ dd if=/usr/lib/boot/master-boot-code of=/dev/sdk bs=1 count=446 $ mkfs.msdos -F32 /dev/sdk2 $ tune2fs -c 64 /dev/sdk1 Evtl. mußt du noch Köpfe/Sektore per '-H <HEADS> -S SECTORS' angeben, zumindest bei nem Image braucht's das. Ich hab das mal getestet: $ ls -l test.img -rw-r--r-- 1 dh dh 1073741824 2011-04-06 17:58 test.img $ /sbin/sfdisk -f -H16 -S 64 -uS test.img <<'EOF' 64,409600,83,* 409664,,0C EOF Warning: test.img is not a block device Disk test.img: cannot get geometry [..] BLKRRPART: Inappropriate ioctl for device $ /sbin/sfdisk -n -uS -l test.img Disk test.img: cannot get geometry Disk test.img: 130 cylinders, 255 heads, 63 sectors/track Warning: The partition table looks like it was made for C/H/S=*/16/0 (instead of 130/255/63). For this listing I'll assume that geometry. Units = sectors of 512 bytes, counting from 0 Device Boot Start End #sectors Id System test.img1 * 64 409663 409600 83 Linux test.img2 409664 2097151 1687488 c W95 FAT32 (LBA) test.img3 0 - 0 0 Empty test.img4 0 - 0 0 Empty $ dd if=test.img count=1 | od -Ax -tx1z 1+0 records in 1+0 records out 512 bytes (512 B) copied, 3.1751e-05 s, 16.1 MB/s 000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >................< * 0001b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80 01 >................< 0001c0 01 00 83 0f c0 ff 40 00 00 00 00 40 06 00 00 01 >....Àÿ@....@....< 0001d0 41 90 0c 0f c0 ff 40 40 06 00 c0 bf 19 00 00 00 >A...Àÿ@@..À¿....< 0001e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >................< 0001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa >..............Uª< 000200 Wenn du die Sektoren addierst landest du korrekt bei exakt dem 1G ;) $ echo 'scale=5;(1687488+409600+64)*512' | bc 1073741824 Das mit dem Beginn bei 64 Sektoren, weil ich mal annehmen, daß die CF-Karte mit Blöcken hantiert, die größer als 512 Bytes sind (4K? 32K?). Ansonsten kannst du bei sfdisk auch mit anderen "units" arbeiten, guck dir auch an, was die Karte als "Geometrie" meldet (wenn überhaupt). Achso, die Eingabe für sfdisk: Generell: START,LENGTH,FSTYPE,ACTIVE [C,H,S] [C,H,S] Da ich per -uS Sektoren als Unit gewählt habe: 64,409600,83,* ### Start mit Sektor 64, Länge 409600 Sektoren, also ### exakt 200M, Typ 0x83, aktiv 409664,,0C ### Start bei Sektor 409664, soviel noch frei ### ist, Typ FAT32-LBA, inaktiv. Eigentlich müßte man ### auch den ersten Wert weglassen können, das wird ### dann als "ab nächstem unbelegten" interpretiert, ### was beim Image hier aber nicht klappt, das macht ### dann 1-63 draus, erst die dritte wird dann "der ### Rest". Ne andere Variante wäre z.B.: $ /sbin/sfdisk -n -uM /dev/sdk <<'EOF' 1,200,83,* ,,0C EOF Damit würde halt am Anfang einiges mehr verschwendet. HTH, -dnh --
(void *)'\0' Didn't you see the sign? It said VOID WHERE PROHIBITED Don't tell me you can't C. -- the Internet Oracle [#1307-01] -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org
Am Mittwoch, 6. April 2011 18:17:49 schrieb David Haller: Hallo David,
2) Ich mache ein 256MB _bootfaehiges_ Image fertig
sdd1 -> 200MB -> System (200MB, falls spaeter noch was rein muss) sdd2 -> restMB -> vfat dd if=/dev/sdd of=/cf.img bs=32k Egal auf welche Karte das cf.img nun raufgebuegelt wird, wird es auch booten! Um den restlichen Platz auf der Karte zugaenglich zu machen, ist lediglich die vfat-Partition (ja nach Kartengroesse) zu vergroessern. Leider kann das 'resize2fs' nicht.
_Idee_ zum Vergroessern (ungetestet!): [Ich hoffe, ich habe die fdisk-Tasten soweit im Kopf :-) ]
************************************************************** [...] mydev=$1 #nur zur Demo umount /mnt/$mydev2 fdisk /dev/$mydev <<EOF >/dev/null 2>&1 d 2 n p 2
t 2 c w EOF
Ich glaub nicht daß das so geht (ausserdem fehlt der FS-Typ).
Hehe, ich habe die halbe Nacht damit verbracht :-( Der FS-Typ war 'b' und ist jetzt 'c' ->toggle->2->c->write 2x CR und die Partitionsauswahl hatte ich beim Tippen unterschlagen. Meine Korrektur hatte ich vorhin nochmal gepostet und jetzt oben ins Quoting reingestrikt. Das klappt wie das Katzenrammeln :-) Ich habe es inzwischen mit mehreren verschiedenen Karten getestet.
Für sowas nimm sfdisk oder parted.
Das ist zwar interessant, aber im Vergleich zu fdisk zu aufwendig und mit zuvielen Evantualitaeten verbunden. Ich kann nicht wissen, auf welchen Typ Karte das System gebuegelt wird! Im Script muesste also bei der sfdisk-Variante _vorher_ die Geometrie des Mediums uem. abgefragt und ausgewertet werden. MfG Th. Moritz -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org
Am Mittwoch, 6. April 2011 18:17:49 schrieb David Haller: Hallo David, nun habe ich die Loesung fuer mich gefunden: grub ist nun nicht mehr in /, sondern im MBR! Mit grub in der root-Partition gab es im Test nach dem Verkleinern der Partition ein 'GRUB GEOM ERR'. Jetzt, wo grub im MBR steht, scheint es keine Probleme mehr zu geben. Das Image umfasst nun: MBR ext4 128MB fat32 120MB Das habe ich inzwischen auf verschiedene Karten gebuegelt, mit fdisk die fat32 gekillt und auf max. Groesse neu angelegt, mkfs.vfat und alles ist gut. Danke Dir nochmals fuer Deine Geduld und prima Hilfestellung!!! Schoenes Wochenende. MfG Th. Moritz -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org
Hallo, David Haller schrieb:
Am Tue, 05 Apr 2011, Thomas Moritz schrieb:
Ich muss das Szenario noch 2x auf verschieden-grossen CFs durchfuehren und werde dabei den HexDump beobachten! Bin gespannt, wann genau da was schief laeuft.
Lies auch mal 'info grub' ;) Da steht genau drin, was wie gebooted wird. Und -- wenn du nicht per "aktiver Partition" zur FAT umschalten willst: schreib GRUB einfach in den MBR.
Bedeutet das, dass man einen Boot-Sektor-GRUB (BS-GRUB) direkt vom BIOS starten lassen kann, indem man das Aktiv-Flag der Partition, in der der BS-GRUB installiert ist, setzt? Also ohne Boot-Code im MBR? Noch eine Frage, anknüpfend an die Diskussion, die wir kürzlich hatten, mit einer kurzen Vorbemerkung: Es scheint wirklich so zu sein, dass mein BIOS meine eSATA-Platte immer an die zweite Stelle hinter der Boot-Platte setzt, obwohl sie eindeutig als dritte Platte im BIOS-Setup eingereiht ist. Durch lsscsi im selben System wird die Platte auch immer an der selben Stelle angezeigt, egal ob sie schon beim Booten drin war oder erst später eingeschoben wurde: # lsscsi [3:0:0:0] disk ATA WDC WD5000BEVT-0 01.0 /dev/sdg [4:0:0:0] disk ATA OCZ-VERTEX2 3.5 1.22 /dev/sda [5:0:0:0] disk ATA ST3500630AS 3.AA /dev/sdb Also immer [3:0:0:0], mal als /dev/sda (beim Booten schon drin; unter den ATA-Geräten sogar das erste, hat aber nichts mir der Einreihung durch das BIOS zu tun), mal als /dev/sdg (ins laufende System eingesteckt). Nun die Frage: kann es sein, dass ein Aktiv-Flag in einer Partition auf der eSATA-Platte dazu führt, dass sie vom BIOS an die zweite Stelle eingereiht wird? # fdisk -l /dev/sdg Disk /dev/sdg: 500.1 GB, 500107862016 bytes 255 heads, 63 sectors/track, 60801 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Disk identifier: 0x0005df91 Device Boot Start End Blocks Id System /dev/sdg1 * 1 523 4200966 82 Linux swap / ... /dev/sdg2 524 536 104422+ 83 Linux /dev/sdg3 537 3147 20972857+ 83 Linux /dev/sdg4 3148 60801 463105755 83 Linux Verstehe eh nicht, wieso die Swap-Partition als aktiv markiert ist, ist doch überflüssig.
Da du ja nicht das aktuelle System (dessen menu.lst) verwenden willst mußt du entweder ein chroot in die gemountede CF (sdd1) machen, oder GRUB ohne 'grub-install' manuell dort installieren (IIRC):
# mount /dev/sdd1 /mnt/sdd1 # mount -o bind /proc /mnt/sdd1/proc # mount -o bind /dev /mnt/sdd1/sys # mount -o bind /sys /mnt/sdd1/dev # chroot /mnt/sdd1 # grub grub> setup --stage2=/boot/grub/stage2 (hd0) (hd0,0) grub> quit
grub> help setup setup: setup [--prefix=DIR] [--stage2=STAGE2_FILE] [--force-lba[=off]] INSTALL_ DEVICE [IMAGE_DEVICE] Set up the installation of GRUB automatically. This command uses the more flexible command "install" in the backend and installs GRUB into the device INSTALL_DEVICE. If IMAGE_DEVICE is specified, then find the GRUB images in the device IMAGE_DEVICE, otherwise use the current "root device", which can be set by the command "root".
-> Das "IMAGE_DEVICE" ist, wo GRUB dann stage2 und die menu.lst sucht.
Du kannst natürlich auch weiter in die /-Partition installieren:
grub> setup --stage2=/boot/grub/stage2 (hd0,0) (hd0,0)
Wobei da die /boot/grub/device.map den passenden Eintrag haben muß, daß (hd0) == CF-Karte.
Wieso, Du verwendest doch auch für die Root-Partition nur GRUB-Gerätebezeichner. Ich war bisher der Meinung, dass die device.map nur von grub-install[.unsupported] gebraucht wird, weil als Argumente für dieses Skript Linux-Gerätebezeichner (/dev/sdXy) übergeben werden können. Den Versuch, die Zuordnung zwischen Linux- und GRUB-Gerätebezeichnern für die device.map mit der Option --recheck 'erraten' zu lassen, halte ich inzwischen sogar nur dann für sinnvoll, wenn man das genau in dem laufenden System macht, für das man GRUB gerade installieren möchte. Installiert man GRUB aus einem z.B. von DVD gestarteten externen System für ein auf Platte installiertes System, dann sollte man das IMHO am besten in einer GRUB-shell, wie Du es oben gezeigt hast, machen. Man muss sich dann nur klar über die Reihenfolge der Laufwerke sein, die das BIOS an den GRUB das gerade laufenden Systems gemeldet hat.
Wenn's dann klemmt mußt du gucken, als was das device im Grub von CF-gebootet auftaucht (da hilft dann z.B. 'find /boot/grub/menu.lst' am grub-Prompt.
Wenn man mehrere Platten bzw. Partitionen mit GRUB drauf hat, kann man so leider das Gerät nicht identifizieren, weil find mehrere hd(x,y) findet :-( Gruß, Tom -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org
Hallo, Am Thu, 07 Apr 2011, Thomas Michalka schrieb:
David Haller schrieb:
Lies auch mal 'info grub' ;) Da steht genau drin, was wie gebooted wird. Und -- wenn du nicht per "aktiver Partition" zur FAT umschalten willst: schreib GRUB einfach in den MBR.
Bedeutet das, dass man einen Boot-Sektor-GRUB (BS-GRUB) direkt vom BIOS starten lassen kann, indem man das Aktiv-Flag der Partition, in der der BS-GRUB installiert ist, setzt? Also ohne Boot-Code im MBR?
Nein. Das BIOS liest immer schlicht den ersten Sektor des Gerätes, das in der Bootreihenfolge "vorne" ist (abhängig von den BIOS Einstellungen und evtl. manueller Wahl via Boot-Menü), in den Speicher und startet den Code dann. Der generische MBR-Bootsektor macht dann das gleiche mit dem ersten Sektor der aktiven Partition der ersten Platte.
Noch eine Frage, anknüpfend an die Diskussion, die wir kürzlich hatten, mit einer kurzen Vorbemerkung: Es scheint wirklich so zu sein, dass mein BIOS meine eSATA-Platte immer an die zweite Stelle hinter der Boot-Platte setzt, obwohl sie eindeutig als dritte Platte im BIOS-Setup eingereiht ist. Durch lsscsi im selben System wird die Platte auch immer an der selben Stelle angezeigt, egal ob sie schon beim Booten drin war oder erst später eingeschoben wurde:
# lsscsi [3:0:0:0] disk ATA WDC WD5000BEVT-0 01.0 /dev/sdg [4:0:0:0] disk ATA OCZ-VERTEX2 3.5 1.22 /dev/sda [5:0:0:0] disk ATA ST3500630AS 3.AA /dev/sdb
Also immer [3:0:0:0], mal als /dev/sda (beim Booten schon drin; unter den ATA-Geräten sogar das erste, hat aber nichts mir der Einreihung durch das BIOS zu tun), mal als /dev/sdg (ins laufende System eingesteckt).
Das hängt davon ab, in welcher Reihenfolge die SATA-Controller vom Kernel erkannt werden. Guck dir mal deine /var/log/boot.msg an. Dort wirst du in dem Fall den Controller, an der die Western Digital hängt, erst beim Anschließen erkannt wird. Wenn du mit angeschlossener WD bootest wird der Controller wohl vor den anderen erkannt. Guck mal, welcher Treiber für den zuständig ist, wenn das nicht der gleiche ist wie für den Onboard, dann kannst du das Problem lösen in dem du das Modul generell nach dem für Onboard lädst.
Nun die Frage: kann es sein, dass ein Aktiv-Flag in einer Partition auf der eSATA-Platte dazu führt, dass sie vom BIOS an die zweite Stelle eingereiht wird?
Nö.
# fdisk -l /dev/sdg
Disk /dev/sdg: 500.1 GB, 500107862016 bytes 255 heads, 63 sectors/track, 60801 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Disk identifier: 0x0005df91
Device Boot Start End Blocks Id System /dev/sdg1 * 1 523 4200966 82 Linux swap / ... /dev/sdg2 524 536 104422+ 83 Linux /dev/sdg3 537 3147 20972857+ 83 Linux /dev/sdg4 3148 60801 463105755 83 Linux
Verstehe eh nicht, wieso die Swap-Partition als aktiv markiert ist, ist doch überflüssig.
Ändere es eben. Bei mir ist gar keine Partition aktiv ;P
# grub grub> setup --stage2=/boot/grub/stage2 (hd0) (hd0,0) grub> quit
grub> help setup setup: setup [--prefix=DIR] [--stage2=STAGE2_FILE] [--force-lba[=off]] INSTALL_ DEVICE [IMAGE_DEVICE] Set up the installation of GRUB automatically. This command uses the more flexible command "install" in the backend and installs GRUB into the device INSTALL_DEVICE. If IMAGE_DEVICE is specified, then find the GRUB images in the device IMAGE_DEVICE, otherwise use the current "root device", which can be set by the command "root".
-> Das "IMAGE_DEVICE" ist, wo GRUB dann stage2 und die menu.lst sucht.
Du kannst natürlich auch weiter in die /-Partition installieren:
grub> setup --stage2=/boot/grub/stage2 (hd0,0) (hd0,0)
Wobei da die /boot/grub/device.map den passenden Eintrag haben muß, daß (hd0) == CF-Karte.
Wieso, Du verwendest doch auch für die Root-Partition nur GRUB-Gerätebezeichner.
Ich war bisher der Meinung, dass die device.map nur von grub-install[.unsupported] gebraucht wird, weil als Argumente für dieses Skript Linux-Gerätebezeichner (/dev/sdXy) übergeben werden können.
Und was meinst du, woher Grub weiß, as hd0 und was hd1 .. sein soll?
Den Versuch, die Zuordnung zwischen Linux- und GRUB-Gerätebezeichnern für die device.map mit der Option --recheck 'erraten' zu lassen, halte ich inzwischen sogar nur dann für sinnvoll, wenn man das genau in dem laufenden System macht, für das man GRUB gerade installieren möchte.
Sowieso. Ich hab das System hier im neuen Rechner vorinstalliert -- und zwar auf ne externe Platte am anderen. Dort war meine jetztige /dev/sda eben /dev/sdk. Und wenn ich dann (im BIOS-Bootmenü die Platte ausgewählt hab) war sie dann /dev/sdg und Grub fand sich nicht weil's eben nimmer hd0 sondern hd6 oder so war. Ich mußte dann auch per find die richtige Platte finden. Und im neuen System an Onboard SATA0 gehängt war sie dann eben /dev/sda.
Installiert man GRUB aus einem z.B. von DVD gestarteten externen System für ein auf Platte installiertes System, dann sollte man das IMHO am besten in einer GRUB-shell, wie Du es oben gezeigt hast, machen. Man muss sich dann nur klar über die Reihenfolge der Laufwerke sein, die das BIOS an den GRUB das gerade laufenden Systems gemeldet hat.
Vielmehr: melden wird, wenn man von der Platte startet. Aber dann mußt du AFAIK explizit '--stage2=' angeben, sonst wird das nicht klappen.
Wenn's dann klemmt mußt du gucken, als was das device im Grub von CF-gebootet auftaucht (da hilft dann z.B. 'find /boot/grub/menu.lst' am grub-Prompt.
Wenn man mehrere Platten bzw. Partitionen mit GRUB drauf hat, kann man so leider das Gerät nicht identifizieren, weil find mehrere hd(x,y) findet :-(
Mach das mal wie ich mit 11 Platten (10 intern, 1 extern), aber immerhin nur 3 Systemen (oder waren's 4?). -dnh -- "Sorry, I'm currently working with simpler life forms. Nothing with a backbone." -- "Winston Scudder Thurmad" "Oh. Can I have a middle manager then?" -- "Helix" [from "Freefall" [http://freefall.purrsia.com/ff600/fv00507.htm] -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org
Hallo David, David Haller schrieb:
Hallo,
Am Thu, 07 Apr 2011, Thomas Michalka schrieb:
David Haller schrieb:
Lies auch mal 'info grub' ;) Da steht genau drin, was wie gebooted wird. Und -- wenn du nicht per "aktiver Partition" zur FAT umschalten willst: schreib GRUB einfach in den MBR. Bedeutet das, dass man einen Boot-Sektor-GRUB (BS-GRUB) direkt vom BIOS starten lassen kann, indem man das Aktiv-Flag der Partition, in der der BS-GRUB installiert ist, setzt? Also ohne Boot-Code im MBR?
Nein. Das BIOS liest immer schlicht den ersten Sektor des Gerätes, das in der Bootreihenfolge "vorne" ist (abhängig von den BIOS Einstellungen und evtl. manueller Wahl via Boot-Menü), in den Speicher und startet den Code dann.
Wenn dann aber erst noch ein Boot-Menü kommt, wird i.Ggs. zu Deinem folgenden Text das ausgewählte gebootet.
Der generische MBR-Bootsektor macht dann das gleiche mit dem ersten Sektor der aktiven Partition der ersten Platte.
Wenn man nichts im Boot-Menü auswählt und kein Eintrag als "default" markiert ist? Startet GRUB ohne Auswahl dann nicht das System, das im ersten Eintrag steht (muss vielleicht nochmal nachlesen, aber ich glaube mich daran zu erinnern)?
Noch eine Frage, anknüpfend an die Diskussion, die wir kürzlich hatten, mit einer kurzen Vorbemerkung: Es scheint wirklich so zu sein, dass mein BIOS meine eSATA-Platte immer an die zweite Stelle hinter der Boot-Platte setzt, obwohl sie eindeutig als dritte Platte im BIOS-Setup eingereiht ist. Durch lsscsi im selben System wird die Platte auch immer an der selben Stelle angezeigt, egal ob sie schon beim Booten drin war oder erst später eingeschoben wurde:
# lsscsi [3:0:0:0] disk ATA WDC WD5000BEVT-0 01.0 /dev/sdg [4:0:0:0] disk ATA OCZ-VERTEX2 3.5 1.22 /dev/sda [5:0:0:0] disk ATA ST3500630AS 3.AA /dev/sdb
Also immer [3:0:0:0], mal als /dev/sda (beim Booten schon drin; unter den ATA-Geräten sogar das erste, hat aber nichts mir der Einreihung durch das BIOS zu tun), mal als /dev/sdg (ins laufende System eingesteckt).
Das hängt davon ab, in welcher Reihenfolge die SATA-Controller vom Kernel erkannt werden. Guck dir mal deine /var/log/boot.msg an. Dort wirst du in dem Fall den Controller, an der die Western Digital hängt, erst beim Anschließen erkannt wird. Wenn du mit angeschlossener WD bootest wird der Controller wohl vor den anderen erkannt.
So ist es: Booten mit eSATA ==> [3:0:0:0] ... ... WDC ... /dev/sda ^ eSATA nachträgl. ==> [3:0:0:0] ... ... WDC ... /dev/sdg ^ Wenn auch sehr interessant, ist das wohl etwas akademisch, denn da wurde ja schon gebootet. Bei mir war aber immer die Frage, warum beim Booten mit eingesteckter eSATA-Platte die Systeme der zweiten internen Platte nicht mehr startfähig sind. Die Erklärung, zugegebenermaßen nicht in erschöpfender Tiefe, scheint zu sein, was ich oben in meiner "Vorbemerkung" schrieb.
Guck mal, welcher Treiber für den zuständig ist, wenn das nicht der gleiche ist wie für den Onboard, dann kannst du das Problem lösen in dem du das Modul generell nach dem für Onboard lädst.
name@rechner> lsmod | grep "ata\|ahci\|micron" pata_amd 33284 0 sata_nv 46860 13 ahci 51080 1 pata_jmicron 23808 0 libata 195232 4 pata_amd,sata_nv,ahci,pata_jmicron scsi_mod 195160 5 sr_mod,usb_storage,sg,sd_mod,libata dock 29344 1 libata Sind jetzt sata_nv für die eSATA-Platte (WDC) und ahci für die anderen (internen) SATA-Geräte zuständig? Und pata_jmicron scheint für den IDE-Port zuständig zu sein. name@rechner> uname -r 2.6.25.20-0.1-default N.B. War da ahci auch schon im Kernel?
Nun die Frage: kann es sein, dass ein Aktiv-Flag in einer Partition auf der eSATA-Platte dazu führt, dass sie vom BIOS an die zweite Stelle eingereiht wird?
Nö.
Kann das BIOS nicht das zuständige Byte lesen, bzw. tut es das sicher nicht? Das könnte eine erschöpfende Erklärung für das Phänomen sein, dass bei eingeschobener eSATA-Platte beim Booten selbige immer an die zweite Stelle in der Reihenfolge tritt, anstatt sich an die von mir vorgegebene Reihenfolge zu halten (also an dritter Stelle zu bleiben).
# fdisk -l /dev/sdg
Disk /dev/sdg: 500.1 GB, 500107862016 bytes 255 heads, 63 sectors/track, 60801 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Disk identifier: 0x0005df91
Device Boot Start End Blocks Id System /dev/sdg1 * 1 523 4200966 82 Linux swap / ... /dev/sdg2 524 536 104422+ 83 Linux /dev/sdg3 537 3147 20972857+ 83 Linux /dev/sdg4 3148 60801 463105755 83 Linux
Verstehe eh nicht, wieso die Swap-Partition als aktiv markiert ist, ist doch überflüssig.
Ändere es eben. Bei mir ist gar keine Partition aktiv ;P
Genau, schon um meine obige Vermutung zu prüfen. Allerdings eine aktive brauche ich (wirklich?), um ab und zu ein Windows zu starten :-(
# grub grub> setup --stage2=/boot/grub/stage2 (hd0) (hd0,0) grub> quit
grub> help setup setup: setup [--prefix=DIR] [--stage2=STAGE2_FILE] [--force-lba[=off]] INSTALL_ DEVICE [IMAGE_DEVICE] Set up the installation of GRUB automatically. This command uses the more flexible command "install" in the backend and installs GRUB into the device INSTALL_DEVICE. If IMAGE_DEVICE is specified, then find the GRUB images in the device IMAGE_DEVICE, otherwise use the current "root device", which can be set by the command "root".
-> Das "IMAGE_DEVICE" ist, wo GRUB dann stage2 und die menu.lst sucht.
Du kannst natürlich auch weiter in die /-Partition installieren:
grub> setup --stage2=/boot/grub/stage2 (hd0,0) (hd0,0)
Wobei da die /boot/grub/device.map den passenden Eintrag haben muß, daß (hd0) == CF-Karte. Wieso, Du verwendest doch auch für die Root-Partition nur GRUB-Gerätebezeichner.
Ich war bisher der Meinung, dass die device.map nur von grub-install[.unsupported] gebraucht wird, weil als Argumente für dieses Skript Linux-Gerätebezeichner (/dev/sdXy) übergeben werden können.
Und was meinst du, woher Grub weiß, as hd0 und was hd1 .. sein soll?
Das BIOS lädt den MBR mit GRUB darin und übergibt die Reihenfolge der Platten, und GRUB nimmt die Zuordnung vor: die erste (Bootplatte) --> (hd0) die zweite --> (hd1) die dritte --> (hd2) ... Wenn GRUB aber doch die device.map nach seinem Start durch das BIOS auswertet, dann wäre das _die_ Lösung für mich. Aber ich habe keinerlei Hinweis darauf. Im Gegenteil: wenn ich mit "F8" das BIOS-Boot-Menü (noch vor GRUB) aufrufe, dann kann ich alles starten, obwohl die device.map für den MBR-GRUB derzeit völlig 'gaga' ist: name@rechner> cat /grub/boot/grub/device.map (fd0) /dev/fd0 (hd0) /dev/sde (hd1) /dev/sdf Das galt für ein Rettungssystem, in dem die SSD eben /dev/sde und die HDD /dev/sdf (hier ohne eSATA-Platte) war.
Den Versuch, die Zuordnung zwischen Linux- und GRUB-Gerätebezeichnern für die device.map mit der Option --recheck 'erraten' zu lassen, halte ich inzwischen sogar nur dann für sinnvoll, wenn man das genau in dem laufenden System macht, für das man GRUB gerade installieren möchte.
Sowieso. Ich hab das System hier im neuen Rechner vorinstalliert -- und zwar auf ne externe Platte am anderen. Dort war meine jetztige /dev/sda eben /dev/sdk. Und wenn ich dann (im BIOS-Bootmenü die Platte ausgewählt hab) war sie dann /dev/sdg und Grub fand sich nicht weil's eben nimmer hd0 sondern hd6 oder so war.
Bei mir ist das genau nicht so: Wenn ich im BIOS-Boot-Menü meine zweite Platte (HDD) als Boot-Gerät auswähle, dann kann ich im MBR-Boot-Menü (ja, auch bei der HDD habe ich für diesen Fall den MBR mit einem GRUB ausgestattet) alle mit (hd0,x) eingetragenen Boot-Sektor-GRUBs starten. Wenn diese mir dann bei einer Distri die verschiedenen Kernel anbieten, dann muss ich nach der Auswahl sogar (hd1,x) auf (hd0,x) umeditieren, weil (hd1,x) nur gilt für die HDD als zweite Platte (der Normalfall), wenn ich von der SSD (dann hd0) gebootet habe! Jetzt war ausnahmsweise aber die HDD die erste, so dass für jeden Kernel einer Distri ein "root (hd0,x)" für erfolgreiches Finden durch GRUB eingetragen sein müsste. Dieses (sehr seltene) umeditieren könnte ich mir wahrscheinlich sparen, wenn ich in der menu.lst des HDD-MBR-GRUB in jedem Eintrag (hd0) <--> (hd1) ummappen würde, was ja dann nur vorkäme, wenn ich von der HDD gebootet habe.
Ich mußte dann auch per find die richtige Platte finden. Und im neuen System an Onboard SATA0 gehängt war sie dann eben /dev/sda.
Da werde ich deshalb nicht schlau daraus, weil die Zuteilung der Linux-Gerätebezeichner doch erst durch den Kernel nach dem Laden der Treiber-Module erfolgt, wenn ich Dich weiter oben richtig verstanden habe.
Installiert man GRUB aus einem z.B. von DVD gestarteten externen System für ein auf Platte installiertes System, dann sollte man das IMHO am besten in einer GRUB-shell, wie Du es oben gezeigt hast, machen. Man muss sich dann nur klar über die Reihenfolge der Laufwerke sein, die das BIOS an den GRUB das gerade laufenden Systems gemeldet hat.
Vielmehr: melden wird, wenn man von der Platte startet.
Nö, das ist ja immer das erste Gerät, also für GRUB immer (hd0). Zum Zeitpunkt der GRUB-Installation (des setup-Kommandos) muss setup dem Kommando install das GRUB-Device mitteilen, wo install den GRUB-CODE hinschreiben soll, nicht welches GRUB-Device es beim späteren Start sein wird.
Aber dann mußt du AFAIK explizit '--stage2=' angeben, sonst wird das nicht klappen.
Ja, das muss der Pfad sein, wo stage2 zum Zeitpunkt der GRUB-Installation zu finden ist. Ich glaube, man kann sogar grub> setup --stage2=(hd1)/boot/grub/stage2 (hd1) schreiben, also GRUB-Notation und Pfad-Notation mischen. Wenn die jetzige (hd1) später als Boot-Platte die (hd0) werden soll, könnte so eine explizite Angabe nötig sein. Auch von mir nochmal ein großes Dankeschön für Deine große Beitrags- und Hilfsbereitschaft! Gruß, Tom P.S.: Hier sind wir ja doch schon ganz schön vom "programming" abgekommen, aber mei, wenn's hilft -- und man muss ja nicht päpstlicher als der Papst sein ;-) -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org
Hallo, Am Sat, 09 Apr 2011, Thomas Michalka schrieb:
David Haller schrieb:
Am Thu, 07 Apr 2011, Thomas Michalka schrieb:
David Haller schrieb:
Lies auch mal 'info grub' ;) Da steht genau drin, was wie gebooted wird. Und -- wenn du nicht per "aktiver Partition" zur FAT umschalten willst: schreib GRUB einfach in den MBR. Bedeutet das, dass man einen Boot-Sektor-GRUB (BS-GRUB) direkt vom BIOS starten lassen kann, indem man das Aktiv-Flag der Partition, in der der BS-GRUB installiert ist, setzt? Also ohne Boot-Code im MBR?
Nein. Das BIOS liest immer schlicht den ersten Sektor des Gerätes, das in der Bootreihenfolge "vorne" ist (abhängig von den BIOS Einstellungen und evtl. manueller Wahl via Boot-Menü), in den Speicher und startet den Code dann.
Wenn dann aber erst noch ein Boot-Menü kommt, wird i.Ggs. zu Deinem folgenden Text das ausgewählte gebootet.
Das Boot-Menü des BIOS (meist ne F-Taste, hier F12). Kein Grub, Lilo oder sonst ein Bootmanager.
Der generische MBR-Bootsektor macht dann das gleiche mit dem ersten Sektor der aktiven Partition der ersten Platte.
Wenn man nichts im Boot-Menü auswählt und kein Eintrag als "default" markiert ist?
Mißverständnis. "generische MBR-Bootcode" ist der, der sich wie der von DOS verhält, nämlich eben schlicht die aktive Partition zu starten.
Startet GRUB ohne Auswahl dann nicht das System, das im ersten Eintrag steht (muss vielleicht nochmal nachlesen, aber ich glaube mich daran zu erinnern)?
Andere Baustelle. Default bei Grub ist der erste Eintrag, falls kein anderer per 'default' definiert wird. Das ist aber eben Grub und nicht der generische Bootcode.
Noch eine Frage, anknüpfend an die Diskussion, die wir kürzlich hatten, mit einer kurzen Vorbemerkung: Es scheint wirklich so zu sein, dass mein BIOS meine eSATA-Platte immer an die zweite Stelle hinter der Boot-Platte setzt, obwohl sie eindeutig als dritte Platte im BIOS-Setup eingereiht ist. Durch lsscsi im selben System wird die Platte auch immer an der selben Stelle angezeigt, egal ob sie schon beim Booten drin war oder erst später eingeschoben wurde:
# lsscsi [3:0:0:0] disk ATA WDC WD5000BEVT-0 01.0 /dev/sdg [4:0:0:0] disk ATA OCZ-VERTEX2 3.5 1.22 /dev/sda [5:0:0:0] disk ATA ST3500630AS 3.AA /dev/sdb
Also immer [3:0:0:0], mal als /dev/sda (beim Booten schon drin; unter den ATA-Geräten sogar das erste, hat aber nichts mir der Einreihung durch das BIOS zu tun), mal als /dev/sdg (ins laufende System eingesteckt).
Das hängt davon ab, in welcher Reihenfolge die SATA-Controller vom Kernel erkannt werden. Guck dir mal deine /var/log/boot.msg an. Dort wirst du in dem Fall den Controller, an der die Western Digital hängt, erst beim Anschließen erkannt wird. Wenn du mit angeschlossener WD bootest wird der Controller wohl vor den anderen erkannt.
So ist es: Booten mit eSATA ==> [3:0:0:0] ... ... WDC ... /dev/sda ^ eSATA nachträgl. ==> [3:0:0:0] ... ... WDC ... /dev/sdg ^
Da wird eben wohl mit eSATA die WDC bzw. der Treiber für den Controller zuerst geladen. Und 'nachträglich' eben erst dann.
Wenn auch sehr interessant, ist das wohl etwas akademisch, denn da wurde ja schon gebootet. Bei mir war aber immer die Frage, warum beim Booten mit eingesteckter eSATA-Platte die Systeme der zweiten internen Platte nicht mehr startfähig sind.
Startet Grub noch mit korrektem Menü?
Die Erklärung, zugegebenermaßen nicht in erschöpfender Tiefe, scheint zu sein, was ich oben in meiner "Vorbemerkung" schrieb.
Guck mal, welcher Treiber für den zuständig ist, wenn das nicht der gleiche ist wie für den Onboard, dann kannst du das Problem lösen in dem du das Modul generell nach dem für Onboard lädst.
name@rechner> lsmod | grep "ata\|ahci\|micron" pata_amd 33284 0 sata_nv 46860 13 ahci 51080 1 pata_jmicron 23808 0 libata 195232 4 pata_amd,sata_nv,ahci,pata_jmicron scsi_mod 195160 5 sr_mod,usb_storage,sg,sd_mod,libata dock 29344 1 libata
Sind jetzt sata_nv für die eSATA-Platte (WDC) und ahci für die anderen (internen) SATA-Geräte zuständig? Und pata_jmicron scheint für den IDE-Port zuständig zu sein.
Eher andesrum, sata_nv für den Onboard-Controller (nForce, zeig ggfs. mal "lspci | grep 'IDE\|SATA'" nVidia .. MCP ist nForce). Und ahci wäre dann für eSATA.
name@rechner> uname -r 2.6.25.20-0.1-default
N.B. War da ahci auch schon im Kernel?
Da's bei dir mit lsmod gelistet wird: nein. Du könntest ahci aus der initrd rauswerfen, wenn der Onboard-Controller tatsächlich ein nForce ist. Dann bekämst du ne stabile Reihenfolge (immer erst sata_nv, dann ahci).
Nun die Frage: kann es sein, dass ein Aktiv-Flag in einer Partition auf der eSATA-Platte dazu führt, dass sie vom BIOS an die zweite Stelle eingereiht wird?
Nö.
Kann das BIOS nicht das zuständige Byte lesen, bzw. tut es das sicher nicht?
Ja. Das macht eben der generische Bootcode. Das BIOS startet nur den MBR.
Das könnte eine erschöpfende Erklärung für das Phänomen sein, dass bei eingeschobener eSATA-Platte beim Booten selbige immer an die zweite Stelle in der Reihenfolge tritt, anstatt sich an die von mir vorgegebene Reihenfolge zu halten (also an dritter Stelle zu bleiben).
s.o.
Ändere es eben. Bei mir ist gar keine Partition aktiv ;P
Genau, schon um meine obige Vermutung zu prüfen. Allerdings eine aktive brauche ich (wirklich?), um ab und zu ein Windows zu starten :-(
Dann sollte aber (nur) die Windows-Partition aktiv sein. [..]
Du kannst natürlich auch weiter in die /-Partition installieren:
grub> setup --stage2=/boot/grub/stage2 (hd0,0) (hd0,0)
Wobei da die /boot/grub/device.map den passenden Eintrag haben muß, daß (hd0) == CF-Karte. Wieso, Du verwendest doch auch für die Root-Partition nur GRUB-Gerätebezeichner.
Ich war bisher der Meinung, dass die device.map nur von grub-install[.unsupported] gebraucht wird, weil als Argumente für dieses Skript Linux-Gerätebezeichner (/dev/sdXy) übergeben werden können.
Und was meinst du, woher Grub weiß, as hd0 und was hd1 .. sein soll?
Das BIOS lädt den MBR mit GRUB darin und übergibt die Reihenfolge der Platten, und GRUB nimmt die Zuordnung vor: die erste (Bootplatte) --> (hd0) die zweite --> (hd1) die dritte --> (hd2) ...
Wenn GRUB aber doch die device.map nach seinem Start durch das BIOS auswertet,
Tut er nicht. Die device.map wird nur bei der Installation von Grub (in den MBR oder sonstwo) verwendet. Achso, und normal rät Grub, welches Device (/dev/sdX) zu welchem BIOS-Device (0x80, 0x81 ...) gehört. Und BTW: wenn du '(hd0)' verwendest, verwendet Grub beim booten dann eben die Platte 0x80 via INT13, siehe http://en.wikipedia.org/wiki/INT_13
dann wäre das _die_ Lösung für mich. Aber ich habe keinerlei Hinweis darauf. Im Gegenteil: wenn ich mit "F8" das BIOS-Boot-Menü (noch vor GRUB) aufrufe, dann kann ich alles starten, obwohl die device.map für den MBR-GRUB derzeit völlig 'gaga' ist:
name@rechner> cat /grub/boot/grub/device.map (fd0) /dev/fd0 (hd0) /dev/sde (hd1) /dev/sdf
Das galt für ein Rettungssystem, in dem die SSD eben /dev/sde und die HDD /dev/sdf (hier ohne eSATA-Platte) war.
Die device.map wird wohl nur für die Installation verwendet.
Den Versuch, die Zuordnung zwischen Linux- und GRUB-Gerätebezeichnern für die device.map mit der Option --recheck 'erraten' zu lassen, halte ich inzwischen sogar nur dann für sinnvoll, wenn man das genau in dem laufenden System macht, für das man GRUB gerade installieren möchte.
Sowieso. Ich hab das System hier im neuen Rechner vorinstalliert -- und zwar auf ne externe Platte am anderen. Dort war meine jetztige /dev/sda eben /dev/sdk. Und wenn ich dann (im BIOS-Bootmenü die Platte ausgewählt hab) war sie dann /dev/sdg und Grub fand sich nicht weil's eben nimmer hd0 sondern hd6 oder so war.
Bei mir ist das genau nicht so: Wenn ich im BIOS-Boot-Menü meine zweite Platte (HDD) als Boot-Gerät auswähle, dann kann ich im MBR-Boot-Menü (ja, auch bei der HDD habe ich für diesen Fall den MBR mit einem GRUB ausgestattet) alle mit (hd0,x) eingetragenen Boot-Sektor-GRUBs starten. Wenn diese mir dann bei einer Distri die verschiedenen Kernel anbieten, dann muss ich nach der Auswahl sogar (hd1,x) auf (hd0,x) umeditieren, weil (hd1,x) nur gilt für die HDD als zweite Platte (der Normalfall), wenn ich von der SSD (dann hd0) gebootet habe! Jetzt war ausnahmsweise aber die HDD die erste, so dass für jeden Kernel einer Distri ein "root (hd0,x)" für erfolgreiches Finden durch GRUB eingetragen sein müsste.
Jo. Dein BIOS scheint das per-BIOS-Menü-geänderte Boot-Device zu hd0 (BIOS: 0x80) zu machen.
Dieses (sehr seltene) umeditieren könnte ich mir wahrscheinlich sparen, wenn ich in der menu.lst des HDD-MBR-GRUB in jedem Eintrag (hd0) <--> (hd1) ummappen würde, was ja dann nur vorkäme, wenn ich von der HDD gebootet habe.
Oder je einen Eintrag mit hd0 und einen mit hd1 ;)
Ich mußte dann auch per find die richtige Platte finden. Und im neuen System an Onboard SATA0 gehängt war sie dann eben /dev/sda.
Da werde ich deshalb nicht schlau daraus, weil die Zuteilung der Linux-Gerätebezeichner doch erst durch den Kernel nach dem Laden der Treiber-Module erfolgt, wenn ich Dich weiter oben richtig verstanden habe.
Naja, der Onboard wird halt per ahci angesprochen und das ist hier fest im Kernel (sonst müßte es in die initrd) und Onboard ist halt der erste Controller vom BIOS aus gesehen. 00:11.0 SATA controller: ATI Technologies Inc SB700/SB800 SATA Controller [AHCI mode] 00:14.1 IDE interface: ATI Technologies Inc SB700/SB800 IDE Controller 02:00.0 SATA controller: JMicron Technology Corp. JMB362/JMB363 AHCI Controller (rev 03) 02:00.1 IDE interface: JMicron Technology Corp. JMB362/JMB363 AHCI Controller (rev 03) 03:00.0 SATA controller: Device 1b4b:9128 (rev 11 00:11.0 ist der Onboard-Controller der AMD SB710, 00:14.1 ist der Onboard-IDE-Controller, 02:00.0 ist Onboard-eSATA, 02:00.1 liegt brach, 03:00.0 ist der Onboard-SATA Marvell-9128 Zusatzcontroller.
Installiert man GRUB aus einem z.B. von DVD gestarteten externen System für ein auf Platte installiertes System, dann sollte man das IMHO am besten in einer GRUB-shell, wie Du es oben gezeigt hast, machen. Man muss sich dann nur klar über die Reihenfolge der Laufwerke sein, die das BIOS an den GRUB das gerade laufenden Systems gemeldet hat.
Vielmehr: melden wird, wenn man von der Platte startet.
Nö, das ist ja immer das erste Gerät, also für GRUB immer (hd0). Zum Zeitpunkt der GRUB-Installation (des setup-Kommandos) muss setup dem Kommando install das GRUB-Device mitteilen, wo install den GRUB-CODE hinschreiben soll, nicht welches GRUB-Device es beim späteren Start sein wird.
Grub muß aber auch wissen, wo es stage2 findet.
Aber dann mußt du AFAIK explizit '--stage2=' angeben, sonst wird das nicht klappen.
Ja, das muss der Pfad sein, wo stage2 zum Zeitpunkt der GRUB-Installation zu finden ist. Ich glaube, man kann sogar
grub> setup --stage2=(hd1)/boot/grub/stage2 (hd1)
schreiben, also GRUB-Notation und Pfad-Notation mischen. Wenn die jetzige (hd1) später als Boot-Platte die (hd0) werden soll, könnte so eine explizite Angabe nötig sein.
Nein, --stage2= ist der Pfad dort, wo grub bei der Installation gerade läuft. Grub wird 2-3teilig installiert: stage1 -> 512Byte in den BR (z.B. MBR) stage1.5 -> 512Byte (1 Sektor von Stage2) in BR+1 stage2 -> ~116KB Dateisystem. Aus 'info grub': `stage1' [..] All `stage1' must do is to load Stage 2 or Stage 1.5 from a local disk. Because of the size restriction, `stage1' encodes the location of Stage 2 (or Stage 1.5) in a block list format, so it never understand any filesystem structure. `stage2' This is the core image of GRUB. It does everything but booting up itself. Usually, this is put in a filesystem, but that is not required. `e2fs_stage1_5' [..] These are called "Stage 1.5", because they serve as a bridge between `stage1' and `stage2', that is to say, Stage 1.5 is loaded by Stage 1 and Stage 1.5 loads Stage 2. The difference between `stage1' and `*_stage1_5' is that the former doesn't understand any filesystem while the latter understands one filesystem (e.g. `e2fs_stage1_5' understands ext2fs). So you can move the Stage 2 image to another location safely, even after GRUB has been installed. While Stage 2 cannot generally be embedded in a fixed area as the size is so large, Stage 1.5 can be installed into the area right after an MBR, or the boot loader area of a ReiserFS or a FFS. und in stage2/builtins.c findet man in setup_func und install_func, daß die Nummer der Disk auf der stage2 liegt wenn nötig mit in stage1 geschrieben (und stage1 dann in den MBR) wird. Stage1 enthält also: - ggfs. BIOS-Nummer der Disk auf der stage2 ist - LBA-Flag - Sektornummer von Stage2 (Siehe info grub -> Internals -> Embedded data). MBR-Grub: Sektornummer Stage1.5: 01 00 00 00 /-Grub: Sektornummer Stage2: ad e0 07 00 Und Stage1.5/Stage2 laden dann via Dateisystem, die Partitionsnummer steht in stage2 mit drin. -dnh -- 189: Linux-Deathmatch CDs der alten Suse-Distributionen werden am Rand angeschliffen und per Pressluftwerfer wird versucht, damit die Gurgel des entsprechenden Delinquenten zu treffen. (Urs Traenkner) -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org
Hallo, habe das GRUB-Manual jetzt mal diagonal gelesen, in einzelnen Punkten etwas tiefer, weshalb es mit meiner Antwort etwas gedauert hat. David Haller schrieb:
Hallo,
Am Sat, 09 Apr 2011, Thomas Michalka schrieb:
David Haller schrieb:
Am Thu, 07 Apr 2011, Thomas Michalka schrieb:
David Haller schrieb:
Lies auch mal 'info grub' ;) Da steht genau drin, was wie gebooted wird. Und -- wenn du nicht per "aktiver Partition" zur FAT umschalten willst: schreib GRUB einfach in den MBR. Bedeutet das, dass man einen Boot-Sektor-GRUB (BS-GRUB) direkt vom BIOS starten lassen kann, indem man das Aktiv-Flag der Partition, in der der BS-GRUB installiert ist, setzt? Also ohne Boot-Code im MBR? Nein. Das BIOS liest immer schlicht den ersten Sektor des Gerätes, das in der Bootreihenfolge "vorne" ist (abhängig von den BIOS Einstellungen und evtl. manueller Wahl via Boot-Menü), in den Speicher und startet den Code dann. Wenn dann aber erst noch ein Boot-Menü kommt, wird i.Ggs. zu Deinem folgenden Text das ausgewählte gebootet.
Das Boot-Menü des BIOS (meist ne F-Taste, hier F12). Kein Grub, Lilo oder sonst ein Bootmanager.
Aha, bei mir ist's F8.
Der generische MBR-Bootsektor macht dann das gleiche mit dem ersten Sektor der aktiven Partition der ersten Platte. Wenn man nichts im Boot-Menü auswählt und kein Eintrag als "default" markiert ist?
Mißverständnis. "generische MBR-Bootcode" ist der, der sich wie der von DOS verhält, nämlich eben schlicht die aktive Partition zu starten.
Ok, "again what learned" (Zitat aus den Lothar-Matthäus-Sketchen in BR3), ich dachte mit "generischem Boot-Code" sei der MBR-GRUB (stage 1) gemeint. Ist der generische Boot-Code dann ein Code der schon vom Hersteller im ersten Sektor untergebracht wird, oder woher stammt der (vom Himmel fällt er wohl nicht)?
Startet GRUB ohne Auswahl dann nicht das System, das im ersten Eintrag steht (muss vielleicht nochmal nachlesen, aber ich glaube mich daran zu erinnern)?
Andere Baustelle. Default bei Grub ist der erste Eintrag, falls kein anderer per 'default' definiert wird. Das ist aber eben Grub und nicht der generische Bootcode.
Ok, alles klar.
Noch eine Frage, anknüpfend an die Diskussion, die wir kürzlich hatten, mit einer kurzen Vorbemerkung: Es scheint wirklich so zu sein, dass mein BIOS meine eSATA-Platte immer an die zweite Stelle hinter der Boot-Platte setzt, obwohl sie eindeutig als dritte Platte im BIOS-Setup eingereiht ist. Durch lsscsi im selben System wird die Platte auch immer an der selben Stelle angezeigt, egal ob sie schon beim Booten drin war oder erst später eingeschoben wurde:
# lsscsi [3:0:0:0] disk ATA WDC WD5000BEVT-0 01.0 /dev/sdg [4:0:0:0] disk ATA OCZ-VERTEX2 3.5 1.22 /dev/sda [5:0:0:0] disk ATA ST3500630AS 3.AA /dev/sdb
Also immer [3:0:0:0], mal als /dev/sda (beim Booten schon drin; unter den ATA-Geräten sogar das erste, hat aber nichts mir der Einreihung durch das BIOS zu tun), mal als /dev/sdg (ins laufende System eingesteckt). Das hängt davon ab, in welcher Reihenfolge die SATA-Controller vom Kernel erkannt werden. Guck dir mal deine /var/log/boot.msg an. Dort wirst du in dem Fall den Controller, an der die Western Digital hängt, erst beim Anschließen erkannt wird. Wenn du mit angeschlossener WD bootest wird der Controller wohl vor den anderen erkannt. So ist es: Booten mit eSATA ==> [3:0:0:0] ... ... WDC ... /dev/sda ^ eSATA nachträgl. ==> [3:0:0:0] ... ... WDC ... /dev/sdg ^
Da wird eben wohl mit eSATA die WDC bzw. der Treiber für den Controller zuerst geladen. Und 'nachträglich' eben erst dann.
Wenn auch sehr interessant, ist das wohl etwas akademisch, denn da wurde ja schon gebootet. Bei mir war aber immer die Frage, warum beim Booten mit eingesteckter eSATA-Platte die Systeme der zweiten internen Platte nicht mehr startfähig sind.
Startet Grub noch mit korrektem Menü?
Jo, ich kann auch bei dem betreffenden Eintrag x noch mit der Taste "e" (GRUB-Shell) die Zeile "root (hd1,x)" auf "root (hd2,x)" abändern, so dass dann die Boot-Sektor-GRUBs korrekt geladen werden. Ist aber so reichlich 'unelegant'.
Die Erklärung, zugegebenermaßen nicht in erschöpfender Tiefe, scheint zu sein, was ich oben in meiner "Vorbemerkung" schrieb.
Guck mal, welcher Treiber für den zuständig ist, wenn das nicht der gleiche ist wie für den Onboard, dann kannst du das Problem lösen in dem du das Modul generell nach dem für Onboard lädst.
Aber nicht das Boot-Problem, sondern das der Device-Reihenfolge. Ich müsste letzteres zwar nicht vordringlich lösen, aber mich würde natürlich interessieren, wie man die Reihenfolge des Ladens der Module bestimmt. Wie also bekomme ich ahci _nach_ sata_nv geladen?
name@rechner> lsmod | grep "ata\|ahci\|micron" pata_amd 33284 0 sata_nv 46860 13 ahci 51080 1 pata_jmicron 23808 0 libata 195232 4 pata_amd,sata_nv,ahci,pata_jmicron scsi_mod 195160 5 sr_mod,usb_storage,sg,sd_mod,libata dock 29344 1 libata
Sind jetzt sata_nv für die eSATA-Platte (WDC) und ahci für die anderen (internen) SATA-Geräte zuständig? Und pata_jmicron scheint für den IDE-Port zuständig zu sein.
Eher andesrum, sata_nv für den Onboard-Controller (nForce, zeig ggfs. mal "lspci | grep 'IDE\|SATA'" nVidia .. MCP ist nForce). Und ahci wäre dann für eSATA.
Wenn ich also meine SSD mit sata_nv anspreche, dann bremse ich sie unnötig aus, da ohne ahci kein NCQ (wenn ich mich recht erinnere). Das wird durch folgendes Zitat aus der neuesten c't 09/2011, S. 124 (Systembeschleunigung mit SSD) gestützt: "Man sollte darauf achten, dass die Ports [Anm.: die direkt am Chipsatz angebundenen SATA-Schnittstellen] im AHCI-Modus konfiguriert sind (manchmal heißt er RAID-Modus), weil SSDs nur dann das Performance-steigernde Native Command Queuing (NCQ) nutzen können." Kann ich den ahci-Treiber ausschließlich (kein sata_nv mehr!), also auch für den Onboard-Controller verwenden? Passiert das sogar automatisch, wenn es mir gelingt im BIOS-Setup den AHCI-Modus für den nVidia Corporation MCP55 SATA Controller (siehe unter lspci) einzustellen? Wäre es eine Lösung, mir einen neuen Kernel 2.6.37 oder .38 zu bauen, in dem ahci fest drin ist, oder ist das für die Performance unbedeutend, ob AHCI im Kernel oder als Modul arbeitet? name@rechner> lspci | grep 'IDE\|SATA' 00:04.0 IDE interface: nVidia Corporation MCP55 IDE (rev a1) 00:05.0 IDE interface: nVidia Corporation MCP55 SATA Controller (rev a3) 00:05.1 IDE interface: nVidia Corporation MCP55 SATA Controller (rev a3) 05:00.0 SATA controller: JMicron Technologies, Inc. JMicron 20360/20363 AHCI Controller (rev 03) 05:00.1 IDE interface: JMicron Technologies, Inc. JMicron 20360/20363 AHCI Controller (rev 03)
name@rechner> uname -r 2.6.25.20-0.1-default
N.B. War da ahci auch schon im Kernel?
Da's bei dir mit lsmod gelistet wird: nein. Du könntest ahci aus der initrd rauswerfen, wenn der Onboard-Controller tatsächlich ein nForce ist.
Wie geht das Rauswerfen aus der initrd?
Dann bekämst du ne stabile Reihenfolge (immer erst sata_nv, dann ahci).
(N.B.: Was aber, wie gesagt, nicht direkt etwas mit dem Boot-Problem zu tun hat.) Wenn ich beim Booten schon die eSATA-Platte drin habe, muss ich dann das Modul ahci erst manuell nachladen, wenn ich sie nutzen will?
Du kannst natürlich auch weiter in die /-Partition installieren:
grub> setup --stage2=/boot/grub/stage2 (hd0,0) (hd0,0)
Wobei da die /boot/grub/device.map den passenden Eintrag haben muß, daß (hd0) == CF-Karte. Wieso, Du verwendest doch auch für die Root-Partition nur GRUB-Gerätebezeichner.
Ich war bisher der Meinung, dass die device.map nur von grub-install[.unsupported] gebraucht wird, weil als Argumente für dieses Skript Linux-Gerätebezeichner (/dev/sdXy) übergeben werden können. Und was meinst du, woher Grub weiß, as hd0 und was hd1 .. sein soll?
Gute Frage, siehe unten die Folge der testweisen Änderung an der device.map.
Das BIOS lädt den MBR mit GRUB darin und übergibt die Reihenfolge der Platten, und GRUB nimmt die Zuordnung vor: die erste (Bootplatte) --> (hd0) die zweite --> (hd1) die dritte --> (hd2) ...
Stimmt schon für den GRUB-Code im MBR, aber die GRUB-Shell scheint nichts zu wissen von BIOS-Gerätenummern.
Wenn GRUB aber doch die device.map nach seinem Start durch das BIOS auswertet,
Tut er nicht. Die device.map wird nur bei der Installation von Grub (in den MBR oder sonstwo) verwendet.
Ok, dann lag ich da richtig. [Update:] Nicht nur von grub-install, sondern auch von der GRUB-Shell, wie ein eben gemachter Versuch mit zwei verschiedenen Device Identifier Mappings beweist: name@rechner> cat /boot/grub/device.map (hd0) /dev/sdb (hd1) /dev/sda grub> find /boot/grub/device.map (hd0,4) (hd0,6) (hd0,7) (hd0,8) Jetzt: name@rechner> cat /boot/grub/device.map (hd0) /dev/sda (hd1) /dev/sdb grub> find /boot/grub/device.map (hd1,4) (hd1,6) (hd1,7) (hd1,8) Das bestätigt doch, dass die GRUB-Shell auch die device.map verwendet, was mich einigermaßen erschüttert, denn ich ging bisher davon aus, dass die GRUB-Gerätebezeichner (hdX) fix an die BIOS-Gerätenummern (abhängig von der vorher gewählten Boot-Geräte-Reihenfolge) gebunden sind. Das passt auch dazu, dass im GRUB-Manual von der GRUB-Shell als "Emulator" die Rede ist: 1.1 Overview ============ [...] Zitat: "Besides the GRUB boot loader itself, there is a "grub shell" `grub' (*note Invoking the grub shell::) which can be run when you are in your operating system. It *emulates* the boot loader and can be used for installing the boot loader." Das verstehe ich so, dass von der GRUB-Shell, die man im laufenden OS starten kann, nicht zu erwarten ist, dass sie die Zuordnung zwischen BIOS-Gerätenummern (0x8Y) und GRUB-Devices (hdY) herstellen kann. Wenn man nun ein System von CD/DVD gestartet hat, wie soll man da bei zwei oder gar mehreren Platten herausfinden, wie diese den (hdY) zugeordnet sind, wenn keine davon die Boot-Platte ist und sich sogar die GRUB-Shell nur an die device.map hält? Anders gefragt: wenn man mit der device.map sogar die GRUB-Shell täuschen kann, wie kriegt man im laufenden OS heraus, welches Linux-Gerät (/dev/sdY) welche BIOS-Gerätenummer hat? Oder habe ich die Frage falsch gestellt? Kann die device.map ein (nahezu) beliebiges Mapping enthalten, weil der stage 1 auf das entsprechende *Linux-Gerät* /dev/sdY (MBR) oder /dev/sdYz geschrieben wird? Wenn das stimmt, und man (hdY) oder (hdY,z) in der GRUB-Shell verwendet, wird halt in device.map nachgesehen, welches Linux-Gerät das sein soll, oder? In einem laufenden Linux hat man ja eine eindeutige Zuordnung.
Achso, und normal rät Grub, welches Device (/dev/sdX) zu welchem BIOS-Device (0x80, 0x81 ...) gehört.
Ist das auch so, wenn man GRUB "nativ" (ohne emulierende Shell) verwendet, d.h. GRUB beispielsweise von einer CD bootet, oder kennt dieser GRUB dann die Zuordnung zwischen (hdY) und (0x8Y)? Ist das der Grund dafür, dass das GRUB-Manual in "3.2 Installing GRUB natively" das Anfertigen einer "GRUB boot disk" empfiehlt?
Und BTW: wenn du '(hd0)' verwendest, verwendet Grub beim booten dann eben die Platte 0x80 via INT13, siehe http://en.wikipedia.org/wiki/INT_13
Ich mußte dann auch per find die richtige Platte finden. Und im neuen System an Onboard SATA0 gehängt war sie dann eben /dev/sda. Da werde ich deshalb nicht schlau daraus, weil die Zuteilung der Linux-Gerätebezeichner doch erst durch den Kernel nach dem Laden der Treiber-Module erfolgt, wenn ich Dich weiter oben richtig verstanden habe.
Naja, der Onboard wird halt per ahci angesprochen und das ist hier fest im Kernel (sonst müßte es in die initrd) und Onboard ist halt der erste Controller vom BIOS aus gesehen.
00:11.0 SATA controller: ATI Technologies Inc SB700/SB800 SATA Controller [AHCI mode] 00:14.1 IDE interface: ATI Technologies Inc SB700/SB800 IDE Controller 02:00.0 SATA controller: JMicron Technology Corp. JMB362/JMB363 AHCI Controller (rev 03) 02:00.1 IDE interface: JMicron Technology Corp. JMB362/JMB363 AHCI Controller (rev 03) 03:00.0 SATA controller: Device 1b4b:9128 (rev 11
00:11.0 ist der Onboard-Controller der AMD SB710, 00:14.1 ist der Onboard-IDE-Controller, 02:00.0 ist Onboard-eSATA, 02:00.1 liegt brach, 03:00.0 ist der Onboard-SATA Marvell-9128 Zusatzcontroller.
Installiert man GRUB aus einem z.B. von DVD gestarteten externen System für ein auf Platte installiertes System, dann sollte man das IMHO am besten in einer GRUB-shell, wie Du es oben gezeigt hast, machen. Man muss sich dann nur klar über die Reihenfolge der Laufwerke sein, die das BIOS an den GRUB das gerade laufenden Systems gemeldet hat. Vielmehr: melden wird, wenn man von der Platte startet. Nö, das ist ja immer das erste Gerät, also für GRUB immer (hd0). Zum Zeitpunkt der GRUB-Installation (des setup-Kommandos) muss setup dem Kommando install das GRUB-Device mitteilen, wo install den GRUB-CODE hinschreiben soll, nicht welches GRUB-Device es beim späteren Start sein wird.
Grub muß aber auch wissen, wo es stage2 findet.
Aber dann mußt du AFAIK explizit '--stage2=' angeben, sonst wird das nicht klappen. Ja, das muss der Pfad sein, wo stage2 zum Zeitpunkt der GRUB-Installation zu finden ist. Ich glaube, man kann sogar
grub> setup --stage2=(hd1)/boot/grub/stage2 (hd1)
schreiben, also GRUB-Notation und Pfad-Notation mischen. Wenn die jetzige (hd1) später als Boot-Platte die (hd0) werden soll, könnte so eine explizite Angabe nötig sein.
Nein, --stage2= ist der Pfad dort, wo grub bei der Installation gerade läuft.
Wir haben hier keinen Dissens. Die Angabe (hd1) im obigen Pfad ist redundant, wenn -- und so war's gemeint -- die zweite Stufe von GRUB unter /boot/grub/stage2 des aktuell laufenden Systems zu finden ist. Das zweite (hd1) im Setup-Kommando lässt den GRUB im MBR der aktuell zweiten Platte installieren. Wenn man danach im BIOS die Boot-Reihenfolge so ändert, dass die eben beschriebene Platte die erste wird, dann sollte das nach meiner Erfahrung funktionieren. Es ist nur zu beachten, dass in der menu.lst für die zu startenden Systeme auf derselben Platte (hd0,x) als Partition angegeben ist -- wenn man nicht immer erst mit "e" manuell editieren möchte ;-)
Grub wird 2-3teilig installiert:
stage1 -> 512Byte in den BR (z.B. MBR) stage1.5 -> 512Byte (1 Sektor von Stage2) in BR+1 stage2 -> ~116KB Dateisystem.
Aus 'info grub':
`stage1' [..] All `stage1' must do is to load Stage 2 or Stage 1.5 from a local disk. Because of the size restriction, `stage1' encodes the location of Stage 2 (or Stage 1.5) in a block list format, so it never understand any filesystem structure.
`stage2' This is the core image of GRUB. It does everything but booting up itself. Usually, this is put in a filesystem, but that is not required.
`e2fs_stage1_5' [..] These are called "Stage 1.5", because they serve as a bridge between `stage1' and `stage2', that is to say, Stage 1.5 is loaded by Stage 1 and Stage 1.5 loads Stage 2. The difference between `stage1' and `*_stage1_5' is that the former doesn't understand any filesystem while the latter understands one filesystem (e.g. `e2fs_stage1_5' understands ext2fs). So you can move the Stage 2 image to another location safely, even after GRUB has been installed.
While Stage 2 cannot generally be embedded in a fixed area as the size is so large, Stage 1.5 can be installed into the area right after an MBR, or the boot loader area of a ReiserFS or a FFS.
und in stage2/builtins.c findet man in setup_func und install_func, daß die Nummer der Disk auf der stage2 liegt wenn nötig
Dann nötig, wenn es nicht dieselbe Disk ist?
mit in stage1 geschrieben (und stage1 dann in den MBR) wird. Stage1 enthält also:
- ggfs. BIOS-Nummer der Disk auf der stage2 ist - LBA-Flag - Sektornummer von Stage2
Die Partitionsnummer sollte doch genügen, da durch stage1.5 jetzt ein Dateisystem gelesen werden kann. Im Dateisystem der angegebenen Partition braucht stage1.5 nur nach dem Pfad boot/grub/ "zu suchen". Andernfalls dürfte man stage2 nicht an einen anderen Ort (innerhalb desselben Dateisystempfades) verschieben.
(Siehe info grub -> Internals -> Embedded data).
MBR-Grub: Sektornummer Stage1.5: 01 00 00 00 /-Grub: Sektornummer Stage2: ad e0 07 00
Und Stage1.5/Stage2 laden dann via Dateisystem, die Partitionsnummer steht in stage2 mit drin.
Verstehe ich auch nicht, denn in der menu.lst, die im selben Pfad, wie stage2 steht, kann doch alles weitere vom GRUB core gelesen werden. Gruß, Tom -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org
Am Montag, 4. April 2011 17:30:52 schrieb Thomas Moritz: Hallo zusammen, ich bin inzwischen einen anderen Weg gegangen: -altes Image zurueck auf die CF-Card -PartedMagic auf anderer Kiste gestartet -1. Part verkleinert -2. Part angelegt -CF-Card getestet und rennt! -2. Part mit fat32 formatiert und gut -BootSectoren wieder als .img gesichert :-) MfG Th. Moritz -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org
participants (4)
-
David Haller -
Manfred Hollstein -
Thomas Michalka -
Thomas Moritz