LILO zweite Platte als /root mounten lassen.

[wayne]

Moin,

ich habe einen Server mit einer Minimal-Installation von Debian. Diese möchte ich gerne beibehalten und mit einem anderen Kernel, der die zweite Festplatte als Root-Partition mountet arbeiten.

Den Kernel habe ich, auf dem Minimal-System, in /boot kopiert und die lilo.conf wie folgt bearbeitet und hinterher lilo ausgeführt, was auch ohne Probleme durchlief.

Code: Select all

boot=/dev/sda
root=/dev/sda2
map=/boot/map
delay=50
vga=normal
default=LinuxMIN

image=/boot/vmlinuz
        label=LinuxMIN
        read-only
        initrd=/boot/initrd.img
        vga=0x314

image=/boot/vmlinuz-srv2
        label=LinuxSRV2
        read-only
        root=/dev/sdb1
        initrd=/boot/initrd-srv2.img
        vga=0x314

Das Laden des Kernels funktioniert soweit auch, aber der Zugriff auf die zweite Platte schlägt fehl.

Der Bootvorgang bricht mit folgender Meldung ab:

Cannot open root device "811" or unknown block (8,17)
Please append a correct /root= boot option
Kernel Panic - not syncing: VFS: unable to mount root fs on unknown-block (8,17)

Hat jemand einen Tipp für mich, wo mein Fehler liegt?

[aubergine]

Code: Select all

boot=/dev/sda
map=/boot/map
delay=50
vga=normal
lba32

image=/boot/vmlinuz
        label=LinuxMIN
        read-only
        initrd=/boot/initrd.img
        vga=0x314
        root=/dev/sda2

image=/boot/vmlinuz-srv2
        label=LinuxSRV2
        read-only
        root=/dev/sdb1
        initrd=/boot/initrd-srv2.img
        root=/dev/sda2
        vga=0x314
        optional

Müsste funktionieren

[mattiass]

Müsste funktionieren

Oder gleich einen ordentlichen Bootloader nutzen? Grub ist vielleicht nicht ganz pflegeleicht, hat aber eine wartungsfreundlichere Systax der Konfigurationsdateien. Liegen alle Kernel auf der gleichen Partition wie der Bootloader und ist die Bootpartition EXT2/3, ist auch Extlinux eine gute Wahl.

LILO sux!

[flo]

LILO sux!

Ich hab mich auch lange gegen Grub gewehrt - aber bei den neuen Servern mit Rettungskonsole kann man eigentlich bei einer verpfuschten Config nur per Grub wieder ins Originalsystem kommen ohne deswegen Rettungssystem, chroot, lilo usw. durchführen zu müssen - Bei Lilo überwiegen gerade bei RemoteServern die Nachteile.

- Das Schreiben des Bootloaders ist anfällig für Vergessen-werden
- keine Shell, um direkt Einstellungen zu ändern
- eventuell (je nach Alter des Lilo) kommt noch die 1024er Grenze als Hürde dazu - d.h. Bootpartition am Anfang

flo.

[mattiass]

Ich hab mich auch lange gegen Grub gewehrt - aber bei den neuen Servern mit Rettungskonsole kann man eigentlich bei einer verpfuschten Config nur per Grub wieder ins Originalsystem kommen ohne deswegen Rettungssystem, chroot, lilo usw. durchführen zu müssen

Oder man nimmt Extlinux. Ist schlanker als Grub, hält kaum Überraschungen bereit, ist idiotensicher für die serielle Konsole konfiguriert, muss nicht ständig neu geschrieben werden, bootet aber nur Kernel von der Partition auf die er geschrieben wurde.

Da ich viel mit Isolinux und mit Pxelinux mache, stelle ich auch die Server unter meiner Obhut nach und nach auf Extlinux um.

[flo]

Da ich viel mit Isolinux und mit Pxelinux mache, stelle ich auch die Server unter meiner Obhut nach und nach auf Extlinux um.

Ist beides nicht relevant für mich, denn ich bruache kein eigenes Rettungssystem und von Netboot in meinen Umgebungen halte ich auch nichts - grub tut was es soll und hilft Ärgernissen ab, aber extlinux ist natürlich vom Bootkonzept her sehr flexibel.



flo.

[Joe User]

PXE und El Torito unterstützt grub ebenfalls ;)

[mattiass]

PXE und El Torito unterstützt grub ebenfalls ;)

Ja, aber mach mal bootfähige Heft-DVDs in 400.000er-Auflage einmal mit Grub und einmal mit Isolinux. Dann zähle die Leser, deren kaputtes BIOS Probleme macht. Bei Grub hast Du etwa zehnmal soviele Problemfälle wie bei Isolinux -- selbst wenn mit allen Regeln der Kunst (sort.txt) die Grub-Bootdateien nah genug beienander sind.

Seither gilt bei mir auch:

GRUB sux!

[Joe User]

Hmm, wie machen es denn dann Distributoren wie etwa Novell? Die verkaufen durchaus über 1.000.000 DVDs/CDs mit grub als Bootloader und haben solche Probleme nicht...

[wayne]

Code: Select all

boot=/dev/sda
map=/boot/map
delay=50
vga=normal
lba32

image=/boot/vmlinuz
        label=LinuxMIN
        read-only
        initrd=/boot/initrd.img
        vga=0x314
        root=/dev/sda2

image=/boot/vmlinuz-srv2
        label=LinuxSRV2
        read-only
        root=/dev/sdb1
        initrd=/boot/initrd-srv2.img
        root=/dev/sda2
        vga=0x314
        optional

Müsste funktionieren

Vielen dank schonmal. Ich werde es testen. Nur dem Verständnis halber:
Sind die zwei root-Einträge unter dem zweiten image Absicht, gar der eigentliche Clou oder ein Copy'n'Paste-Fehler? ;)

[mattiass]

Hmm, wie machen es denn dann Distributoren wie etwa Novell? Die verkaufen durchaus über 1.000.000 DVDs/CDs mit grub als Bootloader und haben solche Probleme nicht...

Das Problem trifft vor allem bei sehr großer TOC auf. Ein paar tausend Dateien reichen nicht. Bei Heft-DVDs, wo oft noch eine HTML-Navigation 10.000 Dateien draufpackt (frag mich nicht warum...), wird es dann kritisch. CHIP 11/06 hat beispielsweise 21.000 Dateien.

Wahrscheinlich ist das mit ein Grund dafür, dass fast alle großen Distributoren ISOLINUX als DVD-Bootloader verwenden und oft zusätzlich ein weiteres Medium so präparieren, dass davon die Installation von DVD angestossen werden kann. Früher war das bei Suse die CD2 aus dem CD-Set...

[aubergine]

Vielen dank schonmal. Ich werde es testen. Nur dem Verständnis halber:
Sind die zwei root-Einträge unter dem zweiten image Absicht, gar der eigentliche Clou oder ein Copy'n'Paste-Fehler? ;)

Paste Fehler, natürlich nur die richtige Partition anwählen. Sorry