grub
Lutz Willek
lutz.willek at belug.de
Fre Aug 1 21:35:47 BST 2008
Luise Kunkle schrieb:
>
> Hi Thomas,
>
Hi Luise,
entschuldige die lange Wartezeit, ich hatte viel beruflich zu tun.
> Die Sache ist:
> BIOS unterstützt LBA
> Unter lilo hat es lange Jahre lang problemlos geklappt.
Na ja, das es früher funktioniert hat bedeutet nicht automatisch, das
das Bios LBA unterstützt, nur das es früher mal irgendwie funktioniert
hat. Später mehr dazu.
Vorsicht, diese Mail wird wahrscheinlich länger: Ich möchte nicht nur,
das Dein Linux wieder funktioniert, sondern auch das Du verstehst was
passiert ist und passieren wird. Also einfach laangsamer lesen ;-)
So, voran gegangen war ja die Mail über das Mapping. Soweit kann ich
Dich beruhigen, daran lag es nicht. Wenn Du Dir einmal Deine erste
Festplatte etwas genauer anschaust:
> Device Boot Start End Blocks Id System
> /dev/sda1 * 1 1798 14442403+ 83 Linux
> /dev/sda2 1799 1867 554242+ 5 Extended
> /dev/sda5 1799 1867 554211 82 Linux swap / Solaris
Es sind eigentlich nur zwei Partitionen, /dev/sda2 ist nur eine
erweiterte Partition. Übrig bleibt /dev/sda1 und /dev/sda5, Grub sagte
Dir bei der ersten Festplatte:
> Possible partitions are:
>
> Partition num: 0, Filesystem type ...
> Partition num: 4, .........
Das passt genau, da Grub bei null zu zählen anfängt.
(hd0,0) ist also /dev/sda1
(hd0,4) ist also /dev/sda5
Damit wäre dann "erwiesen" das Deine Datei device.map richtig ist:
> /boot/grub/device.map
>
> (hd0) /dev/sda
> (hd1) /dev/sdb
"Und das ist auch gut so!", würde ein Politiker hier aus der Gegend
dazu sagen...
Interessant ist jetzt nur gewesen wie Du testen kannst, ob auch alles
stimmt- Jetzt weißt Du es und alle Hintergründe darüber.
Weiter zum nächsten Thema.
Fakt ist ja, das alles irgendwann einmal funktioniert hat. Fakt ist aber
auch, das Dein Bios ein Problem hat:
> error 18: selected cylinder exceed maxium supported by BIOS
Nun, wie passt das jetzt zusammen?
Es ist ja nicht so, das Dein Bios die Platte gar nicht erkennt. Es kann
nur alle Daten über einer gewissen Größe nicht sehen, diese deswegen
nicht ansprechen. Warum das jetzt genau so ist erspare ich Dir und den
Mitlesern, dieses Wissen ist heutzutage überflüssig wie ein Kropf.
Dein Bios kann aber sehr wohl alle Daten unter dieser mysteriösen Grenze
von 1024 Zylindern sehen, schauen wir uns deshalb einmal Deine zweite
Festplatte an:
> Device Boot Start End Blocks Id System
> /dev/sdb1 1 9688 4882720+ 83 Linux
> /dev/sdb2 9689 19376 4882752 83 Linux
> /dev/... [hier gehts noch lange weiter, jetzt nicht wichtig]
Und die Fehlermeldung sagte erst etwas von "Error 18", als Sie bereits
die zweite Partition gelesen hat oder lesen wollte:
> Part num: 0, filesystem....
> Part njm: 1, danach ganz leer
> error 18: selected cylinder exceed maxium supported by BIOS
Ergo: Du kannst von Partition 1 booten, nur von allen anderen
Partitionen nicht.
Ich höre schon Deine Frage: So, und wie konnte das der Lilo? Da ging es
ja schließlich!
Lilo versteht nichts von Partitionen, Belegungen oder Dateisystemen, das
konnte das Programm noch nie. Es schaut einfach ganz genau nach, wo der
Kernel *physikalisch* auf der Festplatte liegt. Diese Lage wird dann
fest in den ersten Sektor geschrieben, beim Starten des Rechners startet
Lilo dann einfach genau diese Stelle. Lilo muss also gar eigentlich fast
gar nix wissen- in Deinem Fall war das natürlich ganz nützlich.
In weitaus mehr Fällen geht das in die Hose, wenn man mit Lilo nicht
umzugehen weiß. Aber hier geht es ja um Grub, deswegen genug von Lilo
und die wichtigste Frage:
############
# WAS TUN? #
############
Hierzu schrieb Thomas:
> [...] Wenn ja können Sie
> mit "sudo grub-install --force-lba /dev/sdX" dazu Zwingen LBA zu nutzen[...]
Ich muss gestehen das ich das noch nie getestet habe. Bis jetzt bin ich
davon ausgegangen, das Grub von sich aus LBA unterstützt wo es möglich
ist und das dieser Schalter deswegen sinnlos ist. Danke Thomas für den
Hinweis, ich werde mich in diese Richtung weiterbilden.
Ich würde gerne einen anderen Weg vorschlagen, der keine Neuinstallation
des Grub erfordert. Meine Überlegung ist folgende dazu:
* wir können komplett von /dev/sda und wahrscheinlich auch von /dev/sdb1
booten
* dem gestarteten Kernel ist es egal was das Bios denkt.
* die zu startenden Systeme sind alt, also keine Updates des Kernels
mehr zu erwarten
* ein Kernel kann irgendwo liegen, das muss nicht zwangsläufig das
eigene System sein
Es würde also reichen, wenn wir den zu startenden Kernel dort hin
kopieren, wo Grub ihn erreichen kann und die Konfigurationsdatei von
Grub anpassen, dann funktioniert alles wieder.
Dabei gelten folgende zwei Einschränkungen:
Debian und Ubuntu verwenden bei Kernelupdate eine Mischung aus
Template-Datei und den gefundenen Kerneln in /boot , um eine menu.lst zu
erzeugen. Wenn Wir die Kernel also einfach nach /boot kopieren, dann
wird beim nächsten Update eine falsche Startdatei erzeugt, was ja nicht
so schön ist. Das lässt sich jedoch umgehen.
Die zu startenden Systeme können von sich aus ohne Anpassungen keine
Kernelupdates mehr vornehmen. Das ist im Fall von Luise auch kein
Problem, ich glaube nicht, das es für Suse 7.3 noch irgendwo ein Update
existiert, oder? :-)
Ich beschreibe den Vorgang nur für Suse, für die anderen beiden Systeme
ist die Vorgehensweise jedoch analog dazu und einfach nachzumachen.
Also los: Teil 1, die Kernel und dazu passende initrd kopieren, ohne
dabei das Debian beim Update zu irritieren:
Laut menu.lst brauchst Du die beiden Dateien:
> # This entry automatically added by the Debian installer for an existing
> # linux installation on /dev/sdb5.
> title SuSE Linux 7.3 (i386) (on /dev/sdb5)
> root (hd1,4)
> kernel /boot/vmlinuz-2.4.27-2-386 root=/dev/sdb5
> initrd /boot/initrd.img-2.4.27-2-386
> savedefault
> boot
also als root folgende Kommandos:
mkdir -p /mnt/sdb5
mount /dev/sdb5 /mnt/sdb5
mkdir -p /boot/other
cp /mnt/sdb5/boot/vmlinuz-2.4.27-2-386 /boot/other/
cp /mnt/sdb5/boot/initrd.img-2.4.27-2-386 /boot/other/
Danach fügst Du in die Datei /boot/grub/menu.lst folgende neuen Zeilen
ein: und zwar genau nach folgender Passage(ziemlich weit unten)
> ### END DEBIAN AUTOMAGIC KERNELS LIST
>
> # This is a divider, added to separate the menu items below from the Debian
> # ones.
> title Other operating systems:
> root
>
das es danach so ausschaut:
> ### END DEBIAN AUTOMAGIC KERNELS LIST
>
> # This is a divider, added to separate the menu items below from the Debian
> # ones.
> title Other operating systems:
> root
>
> # Neuer booteintrag von Luise, um mit Grub auch die Suse zu starten
> title SuSE Linux 7.3
> root (hd0,0)
> kernel /boot/other/vmlinuz-2.4.27-2-386 root=/dev/hdb5
> initrd /boot/other/initrd.img-2.4.27-2-386
> savedefault
> boot
Achtung: Kein Schreibfehler: "root (hd0,0)" und "root=/dev/hdb5"
So, und weil sich die Festplattenbelegung geändert hat musst Du auch die
Datei /etc/fstab der Suse-Installation ändern:
das ist die Datei /mnt/hdb5/etc/fstab, bitte anpassen, das Sie dann so
ausschaut: (nur etwas mehr auskommentiert als vorher, sonst keine Änderung)
> #/dev/hda8 swap swap defaults 0 0
> /dev/hdb5 / ext2 defaults 1 1
> /dev/hdb2 /.crypt/opt ext2 defaults 1 1
> /dev/scd0 /cdrom auto ro,noauto,user,exec 0 0
> /dev/hdd /dvd auto ro,noauto,user,exec 0 0
> /dev/fd0 /floppy auto noauto,user 0 0
> #/dev/hda1 /dosc vfat defaults,showexec,noexec,gid=16,umask=007,quiet 0 2
> #/dev/hda6 /dosemu vfat defaults,showexec,noexec,gid=16,umask=007,quiet 0 2
> #/dev/hda7 /mnt/mp3 vfat defaults,showexec,noexec,umask=002,quiet 0 2
> /dev/hdb11 /home/sem-pa/Mail ext2 defaults 1 1
> /dev/hdb12 /temp/dev_hdb12 ext2 defaults 1 1
> proc /proc proc defaults 0 0
> # End of YaST-generated fstab lines
Du musst jetzt nur noch aufräumen und neu starten:
umount /mnt/sdb5
rmdir /mnt/sdb5
reboot
Erzähl uns wie es geklappt hat! Ich wünsche Dir viel Spaß bei Suse 7.3!
--
Freundliche Grüße / Best Regards
Lutz Willek
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~ Have you tried turning it off and on again? ~
~ Bitte denken Sie an die Umwelt bevor Sie diese Mail ausdrucken ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~