Re: debian-installer versagt bei GrUB, wenn FS ungleich ext2|3

[Andreas Pakulat <apaku@gmx.de>]

On 28.08.07 01:04:21, Wolfi wrote:
> Am 27.08.07 18.40 schrieb Andreas Pakulat:
> >On 27.08.07 17:21:44, Wolfi wrote:
> >>Wo und wie stelle ich also diese "Sicherheitskopie" 
> >>gelöschter/überschriebener Dateien für eine Partition ab?
> >Das hoert sich reichlich merkwuerdig an. Selbst wenn Ubuntu in seinen
> >Kernel-Image Paketen solch eine Umbenennung in *bak vornimmt, duerfte
> >ein rm foo.bak nicht ueber den Trash gehen. Die Pakete sind vollkommen
> >unabhaengig von Gnome und deswegen greift dessen Trash-Kram auch nicht.
> >Das kommt mir aeusserst komisch vor was du da beschreibst. Davon
> >abgesehen: Bei jedem Software-Update ein neuer Kernel? Wie oft hast du
> >das denn gemacht? Normalerweise gibts eine neue Version eines
> >Kernelpakets nicht sooo haeufig.
> 
> Während der letzten 4 oder 5 Tage, bevor ich nach ein paar 
> Partitionsmodifikationen die Ubuntu 7.10 Tribe5 probierte, gab es praktisch 
> jeden Tag eine Update-Info, die ich auch meistens vornahm, zumindest soweit es 
> ging. Der Platzmangel auf meiner kleinen 24MB /boot verhinderte dann gegen 
> Schluß Kernelupdates aufgrund der beschriebenen Trash und BU Geschichten.

Noch mehr Gruende warum mir kein Ubuntu ins Haus kommt (ja ich weiss das
hilft dir jetzt nichts). Das mit den taeglichen Updates finde ich
merkwuerdig, so viel sollte es da bei einem "stable" Release dann auch
nicht geben...

> >Ja, die gibts immernoch, man darf nur nicht so eine
> >Kinder-Desktopumgebung benutzen die einen bevormundet ;) (Ich weiss auch
> >KDE hat den Trash-Bin genau wie Windows, aber da kann man konfigurieren
> >dass per Default geloescht und nicht verschoben wird).
> 
> Kannst du mir verraten, ob und wo man das auch beim Gnome machen kann?

Nee, keine Ahnung. Ich nutze sowieso recht selten einen
GUI-Dateimanager und Gnome nutze ich so ziemlich gar nicht.

> Irgendwer oder irgendwas muß aber einen Narren am Mülleimer gefressen haben 
> ;-)

Offensichtlich.

> >Grub schreibt keine Kernel irgendwohin. Grub schreibt beim Aufruf von
> >"setup" nur seinen eigenen Bootloader in the boot record. Alles andere
> >laedt Grub dann beim Starten direkt vom Dateisystem auf der es liegt.
> >Die Kernel werden aus dem Kernel Paket nach /boot extrahiert, wenn man
> >das Kernel-Paket installiert.
> 
> Wer oder was kümmert sich dann um Grub's stage-1.5 und stage-2 Dateien sowie 
> die menu.lst?
> Und damit sind wir wieder beim springenden Punkt.
> Nachdem was ich mir über die letzten 3+ Monate dazu angelesen habe, ist der 
> große Vorteil von Grub ja, daß er weitgehend nicht mehr mit festen 
> Sektoraddressen operieren muß, sondern weit flexibler mit Dateinamen für 
> seine weiteren Stufen arbeitet. Dazu muß er aber das entsprechende Ziel-FS 
> lesen können => erforderliche stage-1.5-FS-Treiber in der Partition, in der 
> Grub im PBS residiert.
> 
> Wenn ich mich recht erinnere, hatte ich so um die 700kb and *.lst und stage-1.5 
> Dateien in meiner /boot Partition. Nur, um den Kernelkram und die stage-2 und 
> die was-noch-immer Dateien auf '/" zu halten, darf ich keine extra /boot 
> mounten.

Aehm, zunaechst mal muss Grub nur die stage-1.5 Treiber irgendwo ablegen
die er auch braucht, sprich das sind meistens nur 10KByte und die
menu.lst ist im Normalfall nur ein paar hundert Byte gross. Das ganze
Grub-Verzeichnis ist hier 900K gross und der groesste Teil davon ist
Stage 2.

Davon abgesehen macht Grub das so wie ich es vermutet habe: Er merkt
sich die Position der Stage 1.5 bzw. 2 (grad im Grub Manual
nachgeschaut) und packt das mit ins Stage 1 Image das im Bootsektor
liegt. Er benutzt dazu wohl einfach nur den Block-Abstand zwischen
Bootsektor und Stage 1.5/2. Bei ReiserFS und FFS legt er Stage 1.5 in
den bootloader bereich am Anfand des FS.

Kurz: root(hd0,14) und setup (hd0,4) sollten genau das sein was du
willst und /boot bleibt auf hda15 (sprich /).

> Ergo:  meine kleine (hd0,4) darf nicht mehr /boot heißen, muß aber wegen der 
> Bugs mit nichts anderem als ext2|3 formatiert werden und muß dabei, damit das 
> Ganze auch irgendwie anprechbar wird, dann doch auch als irgenwas gemounted 
> werden, oder nicht?

s.o. deine hda5 ( hd0,4 == hda5, nur zur Sicherheit das wir uns da
verstehen) muss gar kein FS haben, prinzipiell wuerde eine 512 Byte
grosse Partition schon reichen, weil das fuer die Stage 1 genug ist.

> >>Erzeugt das dann die logische Entsprechung eines physikalische Gerätes, das 
> >>dann per mount dorthin gebunden werden kann?
> >>Oder was passiert dabei genau und wozu?
> >Das erzeugt das eine Datei mit der man direkten Zugriff auf das "Geraet"
> >17. Partition auf der Master-Platte am primaeren IDE Anschluss hat.
> >Diese spezielle Datei kann dann mit mount /dev/hda17 /some/mountpoint
> >gemountet werden, sofern sich auf der Partition (am Anfang der
> >Partition) ein Dateisystem befindet.
> 
> Wird denn beim Erstellen eines Dateisystems nicht zwangsläufig die ganze 
> Partition benutzt?

Beim Erstellen: Ja (mal abgesehen vom Bootblock der nicht angetastet
wird). Aber....

> Ist da unter Linux auch teilweise möglich?

Es ist moeglich ein Dateisystem nachtraeglich zu verkleinern, wenn man
das richtige FS waehlt (XFS kann das nicht, das kann nur wachsen) und
dann haette man auf der Partition am Ende noch Platz. Auf diese Weise
kann man wunderbar nebeneinander liegende Partitionen neu aufteilen.
Einfach auf der zu grossen das FS verkleinern, die Partition loeschen
und dann neu anlegen mit einer kleineren Groesse. Dann die zu kleine
loeschen mit dem neuen Platz neu erzeugen und das Dateisystem darauf
vergroessern. Man muss natuerlich aufpassen die Partition nicht kleiner
als das Dateisystem zu machen, das gibt sonst Probleme. Und man sollte
sowas nicht unbedingt mit nem GUI Tool erledigen, ausser dieses ist
speziell dafuer ausgelegt (sonst loescht das zusaetzlich zur Partition
auch noch das FS). Hab ich schon ein paar mal so gemacht.

Andreas

-- 
A few hours grace before the madness begins again.