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

[Andreas Pakulat <apaku@gmx.de>]

On 27.08.07 17:21:44, Wolfi wrote:
> Am 27.08.07 16.10 schrieb Andreas Pakulat:
> >On 27.08.07 15:16:19, Wolfi wrote:
> >>Am 27.08.07 13.20 schrieb Andreas Pakulat:
> >>>On 27.08.07 12:33:58, Wolfi wrote:
> >>>>Eigentlich will ich dieser extra Partition (Endziel: 1Cyl=7MB) *nur* GRUB, 
> >>>>seine stage-1.5 FS Treiber und seine Config.lst oder wie die heißt. Alles 
> >>>>andere, insbesondere die Kernels, sollen in die Rootpartition. Laut 
> >>>>GRUB-Beschreibung soll das "problemlos" machbar sein.
> >>>Jepp, wo der Kernel liegt ist reichlich egal, solange Grub das findet.
> >>Ja, und in meinem speziellen Fall ist der kleinen GRUB-Partition unterhalb 
> >>der 1024Cyl einfach kein Platz für den Kernel samt seinem BU und der 
> >>zusätzlich Platz fressenden alten Version in Trash, wenn Systemupdates 
> >>eingespielt werden.
> >>Immerhin soviel hab' ich inzwischen schon herausgefunden ;-)
> >>Allerdings noch nicht, wo/wie ich die Trash Sicherheitsverwahrung 
> >>gelöschter/überschriebener Dateien auf einer Partition verhindern kann,
> >Was meinst du mit Trash? 
> Wenn ich hier in Ubuntu 7.10 tribe5 etwas in Nautilus loschen mochte, heißt 
> das "Move to Trash".
> Wann immer ich ein im oberen Desktop Panel per Icon angezeigtes Software-Update 
> durchführte, wurde i.d.R. auch der Kernel aktualisiert. Daxu wurde offenbar 
> der aktuelle in *.bak umbenannt, der alte *.bak in den Trash-Ordner des 
> betreffenden LW's kopiert und genau diese "Trash-Sicherungskopie" tat mir auf 
> meiner kleinen damals 24MB großen /boot Partition ganz böse weh. Dadurch 
> reichte dann nämlich der Platz für den neuen Kernel nicht mehr.
> 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.

> Es gab einmal Zeiten, in denen etwas, das gelöscht wurde auch weg war und 
> nicht nur in einen Ordner namens "dies ist jetzt angeblich weg" verschoben 
> wurde.

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).

> >Wenn ein neuer Kernel installiert wird bleibt
> >natuerlich der alte erhalten, damit man nicht ohne bootbares System
> >(weil der neue Kernel kaputt ist) dasteht. 
> 
> Ja, das mußte dann der *.bak kernel sein.

Nicht wirklich. Was ich meinte ist wenn man 

linux-image-2.6.22 installiert und vorher linux-image-2.6.21 installiert
war bleibt das alte erhalten. Wenn man allerdings linux-image-2.6.22 von
Version 1.0 auf 2.0 updated wird der existierende Kernel geloescht
(jedenfalls war das so vor ca. 2 Jahren, als ich das letzte Mal nen
Debian-Kernel-Image benutzt habe)

> >Das gilt aber nur fuer neue
> >Kernelversionen, nicht wenn ein Update eines bereits installierten
> >Kernels eingespielt wird.
> 
> Was Synaptic da genau wie macht, weiß ich (noch) nicht.

Synaptic ist nur ein Frontend, das macht beim Installieren eines Paketes
erstmal nicht viel. Genau genommen macht es nichts weiter als dpkg -i
<paketname>.deb aufzurufen (und das fuer alle zu
installierenden/erneuernden Pakete). dpkg wiederum pakt das .deb aus,
kopiert einige der enthaltenen Dateien an ihre Position im System und
fuehrt ein paar Skripte aus die im .deb enthalten sind. Diese Skripte
koennen das alte kernel image in *bak umbenennen und ein existierendes
*bak vorher loeschen. Dies wird aber ueber die Unix-Kommandos mv und rm
gemacht und die interessieren sich nicht fuer irgendein
Trash-Verzeichnis.

> >Da kommen nur "verlorene" Daten rein, also
> >z.B. Dateien die vor einem nicht-ordnungsgemaessen Abschalten nicht mehr
> >auf die Platte rausgeschrieben wurden. Bei einem Kernel update werden da
> >keine Dateien reingeschoben. Wenn du also genug Platz fuer den
> >Grub-Kram, die config und ein Kernel image hast auf der Boot Partition
> >ist das kein grosses Problem.
> 
> Doch, weil eben genau diesen Platz *nicht* hatte (immer mein eigentliches Ziel 
> vor Augen, Linux auf die andere Kiste zu installieren). Inzwischen habe ich 
> diese Partition auf hier auf meinem Testrechner vorübergehend auf 39MB 
> erhöht, um nicht an 100 Fronten gleichzeitig anzuecken :-(

Kommt mir hoechst spanisch vor. Ich wuerde dir empfehlen den
Ubuntu-Muell wegzuschmeissen und die ersten 2 Etch-CD's zu besorgen. Das
ist zwar nicht ganz so anfaenger-freundlich, macht aber auf der anderen
Seite nicht solchen Muell.

>  >>>> Nur fand ich bisher noch nirgends, wie dies Partition dann heißen
> >>>>muß/kann/soll. /boot kann es ja wohl nicht werden.
> >>>Die root-Partition ist "/", ich weiss nicht ganz wass du mit "heissen
> >>>soll" meinst. 
> >>Nicht '/', sondern meine kleine Grub Boot-Hilfspartition.
> >Na wenn grub seinen Kram da reinschreiben soll ists /boot, keine Ahnung
> >ob man das aendern kann. 
> 
> Nein, das geht nicht, denn dann schreibt Grub alles, auch die Kernels da hin 
> und das ist ja gerade, was ich nicht brauchen kann.

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.

> >>Für mich sind mount points und deren Erstellung noch immer ein verwirrend 
> >>neues Konzept (ich wuchs im Zeitalter von Laufwerksbuchstaben auf, woran auch 
> >>die Einführung von LVM vor knapp 10 Jahren nichts grundlegendes geändert 
> >>hat) ;-)
> >Ich bin auch damit "aufgewachsen", dennoch gefaellt mir das
> >mount-Konzept viel besser. Bin aber auch noch jung, da lernt man sowas
> >schneller ;)
> 
> >>Normalerweise würde ich vermuten, die braucht gar keinen Mountpoint und GRUB 
> >>weiß dann selbst, wo es weitergeht. Die Angabe bei der GRUB-Installation, 
> >>daß er nach (hd0,4) soll, sollte reichen, aber ich bin mir da noch nicht 
> >>recht sicher.
> >Ich muss zugeben, dass ich grub noch nicht mit separater /boot Partition
> >betrieben habe. Da muss ich jetzt erstmal passen, sprich ich bin mir
> >nicht sicher ob man dann kernel (hd0,4)/vmlinuz angeben muss (wenn der
> >Kernel auf der Boot-Partition liegt, was der Fall ist wenn man ein
> >Kernel-Paket installiert) oder trotzdem noch ein (hd0,16)/boot/vmlinuz
> >macht. Ich vermute aber ersteres.
> 
> In der Ecke verstehe ich bisher auch nur Bahnhof. Wenn ich mich recht erinnere 
> war da auch noch irgendwas *.gz und eine initrd.nochwas. Was es mit denen dann 
> auf sich hat ist bisher auch noch jenseits meines Horizontes.

*gz?? Hab ich nicht, aber eine initrd gibts fuer die Kernel jeweils. Die
ist bei den Distri-Kerneln notwendig weil man nicht alle Treiber fuer
die 10000 Chips da draussen fest in den Kernel bauen kann. Deswegen ist
fast alles als Kernel-Modul gebaut. Beim Booten jedoch gibts dann ein
Henne-Ei-Problem, weil der Kernel die Module laden muss um auf Platten
(IDE-Treiber) und Dateisysteme (ext2-Treiber, JFS Treiber usw.)
zugreifen zu koennen. Das dumme ist nur: Diese Module liegen auf einer
Platte in einem Dateisystem. Also packt man solche Basismodule
(IDE-Treiber, Dateisysteme, SCSI-Treiber) in eine sog. initial ramdisk
(der ramdisk-Treiber wird fest in den Kernel einkompiliert) und von dort
kann der Kernel diese Treiber dann laden. Damit kann er das /-FS mounten
und den Rest laden.

Es gibt ausserdem noch config-<version> in der die
Konfigurationsoptionen des Kernels abgelegt sind. Damit kriegt man raus
wie der Kernel konfiguriert wurde. Oder sind die gzip'ed bei
Distri-Kerneln?

Hoffe das war ausfuehrlich genug :) 

> >Insofern wuerde ich sagen brauchst du die Partition wirklich nicht
> >weiter, sprich ne 512K Partition wuerde reichen, so dass Grub nur seinen
> >Bootloader da reinschreibt. 
> 
> Plus die benötigten stage-1.5-FS Treiber. Sonst komm er auf "/" nicht weiter, 
> wenn er seine stage-2 und den Kernel lesen will. Oder liege ich da falsch?

Ich denke nicht. Entweder Grub laedt die stage-1.5-FS Treiber beim
Booten anhand fester Positionen die er sich merkt (also wo die Rohdaten
genau liegen) oder aber er pakt das irgendwie mit in den Bootsektor
(waere aber ganz schoen reichlich, die sind naemlich fast 30K gross).

> Genau. So versuchte ich es beim letzten Mal, wußte dann aber nicht recht 
> weiter, da der Installer dann abbrach, da ja kein Bootloader erfolgreich 
> installiert war, auch wenn Kernel und stage-1.5 Treiberdateien kopiert worden 
> waren. Ich glaube, es lag nur an der mißlungenen Erstellung der menu.lst oder 
> wie auch immer sonst Grub's Konfig-Datei genau heißt.

Die wird eigentlich auch nur kopiert und dann wird ein "update-grub"
laufen gelassen, das die title/kernel/root Teile erzeugt aus den Kerneln
die in /boot liegen. 

> >>>>Was muß ich dann während der Installation in Bezug auf zu Installierenden 
> >>>>Bootloader machen? GRUB von dort in (hd0,4) (eben diese kleine 
> >>>>Bootpartition) zu installieren, schlägt trotz dort FS=ext2|3 fehl.
> >>>Ja, weil grub-install wohl ein Problem damit hat ein JFS zu benutzen
> >>>fuer die Partitionen auf denen die Kernel liegen. Deswegen sollst du das
> >>>von einer Grub shell aus machen. 
> >>Aha! Jetzt scheinen wir weiterzukommen ;-) Interessant, grub-install und GRUB 
> >>shell sind also 2 Paar Stiefel ;-)
> >Yeap. grub-install ist ein Skript und die Grub-Shell wirklich wie z.B.
> >Bash or ksh eine Shell mit einer Handvoll Befehlen - diesselbe Shell
> >sieht man wenn man ein Menu beim Booten haben will.
> 
> Aha. Das ist ein weitere Bahnhof, da mir die meisten Linux shell Befehle bisher 
> auch noch nicht geläufig sind und die wenigsten wie bei DOS/OS/2 /Windoof 
> heißen.

Grub-Shell != *nix Shell. Die Grub-Shell ist nur zum Steuern von Grub
gedacht, da gibts so sachen wie ls/rm usw. gar nicht. Aber da musst du
mal ins Grub-Handbuch schauen http://www.gnu.org/software/grub/manual/

> >Neue Devices kann man mit dem MAKEDEV Skript das ueblicherweise auch in
> >/dev liegt erstellen oder mit mknod. Mit mknod ginge das fuer hda17 so
> >(in /dev ausfuehren):
> >mknod hda17 b 3 17
> >Wobei 3 die Major Nummer fuer hda ist (vgl. auch ls -l /dev/hda1
> >/dev/hda2) und 17 ist die Partitionsnummer.
> 
> 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.

Andreas

-- 
Never commit yourself!  Let someone else commit you.