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

[Wolfi <publicalfa-ng@yahoo.fr>]

Am 27.08.07 18.40 schrieb Andreas Pakulat:
> 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.

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.

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

Kannst du mir verraten, ob und wo man das auch beim Gnome machen kann?

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

Ich weiß wirklich nicht genau, was Synaptic da alles gemacht hat. Für 
mich war es erstmal ausreichend, herausgefunden zu haben, daß der blöde 
Mülleimer meinen wertvollen Plattenplatz verschwendet und ich keine 
Stelle gefunden habe, das abzustellen.

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

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

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

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.
Andererseits müssen die 700kB stage-1.5 mit *.lst aber in einem 
Filesystem abgelegt werden.
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?
Und von hier aus kann Grub dann endlich nach Herzenslust seine stage-2, 
den Kernel und was-auch-immer auf "/" lesen und laden.

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

Sorry, das war mein Denkfehler, ich setzte Menu beim Booten (grub shell) 
mit Booten in Befehlsshell (Rettungssystem oder so) gleich.

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

Wird denn beim Erstellen eines Dateisystems nicht zwangsläufig die ganze 
Partition benutzt? Ist da unter Linux auch teilweise möglich?