Yawgmoth
14.10.03, 05:47
Ein Problem, das auf den ersten Blick nicht derart oft vorzukommen scheint *g* - so wie ich das zumindest auf meiner Suche bisher feststellen konnte (Vorher text-only Konsolenbrowser, jetzt Bezilla - immerhin etwas besser, zumindest nach meinem Geschmack *g*).
Situation:
Auf meiner Box übernahm bis heute XOSL die Rolle des Bootmanagers. Aufgrund der scheinbaren Blindheit gegenüber allen anderen Festplatten als der die root-partition von XOSL beherbergende, sehe ich mich nun gezwungen eine andere Software für diese Aufgabe einzusetzen. GRUB scheint dafür sehr geeignet zu sein, da es sich dabei um ein autarkes System handelt, welches keinerlei embedded-Attribute aufweist, wie dies bei XOSL ebenfalls der Fall war. Jedes der Betriebssysteme verfügt über einen eigenen Bootloader, das einzige was fehlt ist ein Manager. GRUB würde von daher lediglich die Aufgabe eines Pointers übernehmen, der auf die jeweiligen Partitionen verweist, welche für ihre Betriebssysteme über eigene Bootloader verfügen, die dann die restliche Arbeit übernehmen (Wie es bei XOSL der Fall war). Soweit ich das bisher erkannt habe, besteht in dieser Hinsicht der Unterschied zwischen XOSL und GRUB nur darin, dass GRUB in der Lage ist, andere Festplatten zu erkennen, allerdings scheine ich nicht in der Lage zu sein, ihn entsprechend zu konfigurieren (Bei XOSL war die Konfiguration SEHR einfach - es ist von daher auch SEHR einfach zu erkennen, was XOSL zu erkennen nicht in der Lage ist;) ). Vor ein paar Tagen las ich kurz etwas bezüglch GRUB, und gestern fing ich damit an, mich mit dem Bootmanager auseinanderzusetzen. Diverse Helpfiles sowie Texte auf diversen Seiten gaben zwar einen besseren Einblick in GRUB, sowie Informationen in Sachen Konfiguration, allerdings nicht wirklich bezüglich dem, was das Problem verursacht und wie es zu lösen ist.
Grund für den Umstieg: Gentoo Linux, das erste System in meiner Box, welches nicht auf hdb installiert ist. Begonnen mit dem Aufsetzen von Gentoo-Linux habe ich vor 3 Tagen (Es gab einige Rückschläge, wie beispielsweise Probleme mit ebuilds die sich im späteren Verlaufe von # emerge system bemerkbar machten, welche schlussendlich einen Neuanfang der Installation erzwangen - man sollte halt nicht frisches Material von der Website mit Material von der Live-CD mischen;) ).
Problem:
Die Windows-Systeme sowie BeOS auf hdb sind problemlos erreichbar. Das Problem stellt Gentoo-Linux auf hdc dar. Jegliche Zugriffsversuche anseiten von GRUB laufen auf Fehlermeldungen hinaus die besagen, dass /dev/hdc2 (hd1,1) kein valides Gerät sei.
Betriebssysteme:
-Windows 98 (/dev/hdb2 - auch der NT-Loader befindet sich auf dieser Partition. Für die Windows-Systeme ist dies Partition C)
-BeOS (/dev/hdb6)
-Windows 2000 (/dev/hdb7)
-Gentoo Linux (boot: /dev/hdc2. root: /dev/hdc6)
-Ein Linux welches später hinzukommen wird (boot: /dev/hdb1. root: /dev/hdb8)
Partitionstabelle:
-> /dev/hda: CD/DVD-ROM
-> /dev/hdb:
-hdb1 ext2fs (Wird später ext3fs) /boot eines Linux-Betriebssystems welches später hinzukommen wird.
-hdb2 FAT32 /w98 (SE)
-hdb5 FAT32 /data (Die inhaltlich etwas grundlegendere Datenpartition - seht es einfach als eine der beiden Datenpartitionen)
-hdb6 BeFS BeOS
-hdb7 NTFS /w2k
-hdb8 ext2fs (Später reiserfs vorgesehen) / (root) des später hinzukommenden Systems.
-hdb9 swap 1
-hdb10 (Zur Zeit ext3fs) <- BOOTMANAGER-PARTITION (Funktioniert mit XOSL und GRUB - nur, dass XOSL keine ersichtliche Möglichkeit bietet, andere Partitionen zu erkennen als die von hdb, und GRUB hdc grundsätzlich nicht als existent wahrhaben will).
-> /dev/hdc:
-hdc1 FAT32 /data0 (Die inhaltlich eher storage-orientierte Datenpartition - ein Windows 98 SE ist auch nocht drauf, wurde mal im Rahmen einer radikalen Problemlösung installiert und hat seinen Zweck damals erfüllt - nicht mehr weiter wichtig)
-hdc2 ext3fs /boot von Gentoo Linux
-hdc3 reiserfs Platzhalter-Partition (Wäre nicht unbedingt nötig gewesen - ich hätte auch ganz einfach 5112 MB unpartitioniert lassen können *g*).
-hdc5 swap 2
-hdc6 reiserfs / (root) von Gentoo Linux
-hdc7 reiserfs (Gerade neu dazugekommene Datenpartition für alles was auf einem Linux-orientierten Filesystem möglicherweise besser aufgehoben ist. Ich denke da ans arbeiten mit sources, etc.)
/dev/hdd: CD-R/CD-W (Brenner)
RAM: 256 (Für den Fall von Experimenten mit Game-server software könnte etwas mehr swap-space nicht schaden;) )
grub.conf: (GRUB ist auf /dev/hdb10; oder in GRUB-Terminologie auf hd0,9)
#grub.conf for GRUB
default 0
timeout 30
splashimage=(hd0,9)/boot/grub/splash/xpm.gz
title=Gentoo
root (hd1,1)
chainloader +1
title=Windows
root (hd0,1)
chainloader +1
title=Zendomlinux
root (hd0,1) #<- Oops, da ist mir grad ein Bug aufgefallen *g* - das sollte hd0,0 heissen - allerdings hat dies noch keine Auswirkungen, da dieses System ja noch nicht in Betrieb gesetzt ist.
chainloader +1
title=BeOS
root (hd0,6)
chainloader +1
title=Reinstall
root (hd0,9)
setup (hd0)
device.conf:
(fd0) /dev/fd0
(hd0) /dev/hdb
(hd1) /dev/hdc
Situation:
Auf meiner Box übernahm bis heute XOSL die Rolle des Bootmanagers. Aufgrund der scheinbaren Blindheit gegenüber allen anderen Festplatten als der die root-partition von XOSL beherbergende, sehe ich mich nun gezwungen eine andere Software für diese Aufgabe einzusetzen. GRUB scheint dafür sehr geeignet zu sein, da es sich dabei um ein autarkes System handelt, welches keinerlei embedded-Attribute aufweist, wie dies bei XOSL ebenfalls der Fall war. Jedes der Betriebssysteme verfügt über einen eigenen Bootloader, das einzige was fehlt ist ein Manager. GRUB würde von daher lediglich die Aufgabe eines Pointers übernehmen, der auf die jeweiligen Partitionen verweist, welche für ihre Betriebssysteme über eigene Bootloader verfügen, die dann die restliche Arbeit übernehmen (Wie es bei XOSL der Fall war). Soweit ich das bisher erkannt habe, besteht in dieser Hinsicht der Unterschied zwischen XOSL und GRUB nur darin, dass GRUB in der Lage ist, andere Festplatten zu erkennen, allerdings scheine ich nicht in der Lage zu sein, ihn entsprechend zu konfigurieren (Bei XOSL war die Konfiguration SEHR einfach - es ist von daher auch SEHR einfach zu erkennen, was XOSL zu erkennen nicht in der Lage ist;) ). Vor ein paar Tagen las ich kurz etwas bezüglch GRUB, und gestern fing ich damit an, mich mit dem Bootmanager auseinanderzusetzen. Diverse Helpfiles sowie Texte auf diversen Seiten gaben zwar einen besseren Einblick in GRUB, sowie Informationen in Sachen Konfiguration, allerdings nicht wirklich bezüglich dem, was das Problem verursacht und wie es zu lösen ist.
Grund für den Umstieg: Gentoo Linux, das erste System in meiner Box, welches nicht auf hdb installiert ist. Begonnen mit dem Aufsetzen von Gentoo-Linux habe ich vor 3 Tagen (Es gab einige Rückschläge, wie beispielsweise Probleme mit ebuilds die sich im späteren Verlaufe von # emerge system bemerkbar machten, welche schlussendlich einen Neuanfang der Installation erzwangen - man sollte halt nicht frisches Material von der Website mit Material von der Live-CD mischen;) ).
Problem:
Die Windows-Systeme sowie BeOS auf hdb sind problemlos erreichbar. Das Problem stellt Gentoo-Linux auf hdc dar. Jegliche Zugriffsversuche anseiten von GRUB laufen auf Fehlermeldungen hinaus die besagen, dass /dev/hdc2 (hd1,1) kein valides Gerät sei.
Betriebssysteme:
-Windows 98 (/dev/hdb2 - auch der NT-Loader befindet sich auf dieser Partition. Für die Windows-Systeme ist dies Partition C)
-BeOS (/dev/hdb6)
-Windows 2000 (/dev/hdb7)
-Gentoo Linux (boot: /dev/hdc2. root: /dev/hdc6)
-Ein Linux welches später hinzukommen wird (boot: /dev/hdb1. root: /dev/hdb8)
Partitionstabelle:
-> /dev/hda: CD/DVD-ROM
-> /dev/hdb:
-hdb1 ext2fs (Wird später ext3fs) /boot eines Linux-Betriebssystems welches später hinzukommen wird.
-hdb2 FAT32 /w98 (SE)
-hdb5 FAT32 /data (Die inhaltlich etwas grundlegendere Datenpartition - seht es einfach als eine der beiden Datenpartitionen)
-hdb6 BeFS BeOS
-hdb7 NTFS /w2k
-hdb8 ext2fs (Später reiserfs vorgesehen) / (root) des später hinzukommenden Systems.
-hdb9 swap 1
-hdb10 (Zur Zeit ext3fs) <- BOOTMANAGER-PARTITION (Funktioniert mit XOSL und GRUB - nur, dass XOSL keine ersichtliche Möglichkeit bietet, andere Partitionen zu erkennen als die von hdb, und GRUB hdc grundsätzlich nicht als existent wahrhaben will).
-> /dev/hdc:
-hdc1 FAT32 /data0 (Die inhaltlich eher storage-orientierte Datenpartition - ein Windows 98 SE ist auch nocht drauf, wurde mal im Rahmen einer radikalen Problemlösung installiert und hat seinen Zweck damals erfüllt - nicht mehr weiter wichtig)
-hdc2 ext3fs /boot von Gentoo Linux
-hdc3 reiserfs Platzhalter-Partition (Wäre nicht unbedingt nötig gewesen - ich hätte auch ganz einfach 5112 MB unpartitioniert lassen können *g*).
-hdc5 swap 2
-hdc6 reiserfs / (root) von Gentoo Linux
-hdc7 reiserfs (Gerade neu dazugekommene Datenpartition für alles was auf einem Linux-orientierten Filesystem möglicherweise besser aufgehoben ist. Ich denke da ans arbeiten mit sources, etc.)
/dev/hdd: CD-R/CD-W (Brenner)
RAM: 256 (Für den Fall von Experimenten mit Game-server software könnte etwas mehr swap-space nicht schaden;) )
grub.conf: (GRUB ist auf /dev/hdb10; oder in GRUB-Terminologie auf hd0,9)
#grub.conf for GRUB
default 0
timeout 30
splashimage=(hd0,9)/boot/grub/splash/xpm.gz
title=Gentoo
root (hd1,1)
chainloader +1
title=Windows
root (hd0,1)
chainloader +1
title=Zendomlinux
root (hd0,1) #<- Oops, da ist mir grad ein Bug aufgefallen *g* - das sollte hd0,0 heissen - allerdings hat dies noch keine Auswirkungen, da dieses System ja noch nicht in Betrieb gesetzt ist.
chainloader +1
title=BeOS
root (hd0,6)
chainloader +1
title=Reinstall
root (hd0,9)
setup (hd0)
device.conf:
(fd0) /dev/fd0
(hd0) /dev/hdb
(hd1) /dev/hdc