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

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

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

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

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

> Oder meinst du lost+found? 

Nein, definitiv nicht. Das waren ja verlorengegangene Cluster nach einem 
Chkdsk Lauf oder wie das bei Linux auch immer heißt.

> 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 :-(

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

/boot muß mit auf "/".

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

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

Dann bleibt das /boot Verzeichnis auf der /-Partition.

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.

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

> > > Starte einfach mal "grub" von einer
> > > Shell aus. Dort kannst du dann die notwendigen Befehle absetzen, welche
> > > das sind findest du im Internet (hab sowas noch nicht machen muessen,
> > > deswegen weiss ich das so auch nicht).
> > > Wichtig ist das die menu.lst etwa so aussieht:
> > > title Ubuntu
> > > root (hd0,15)
> > > kernel /deinkernel
> > > Wobei, wenn du eines der Kernel Images von Ubuntu installierst landen
> > > die Kernel eh in /boot (also auf hd0,4)
> > Nee, ganz falsch! Dort hab'ich ja keinen Platz (nur 7MB=1Cyl). /boot muß 
> > zusammen mit "/" auf /dev/hda16(+). Auf (hd0,4) darf nur der GRUB selbst  im 
> > PBR, seine stage-1.5-FS Dateien und die menu.lst oder wie sonst seine 
> > Konfig-Datei heißt, sein.
>
> Uhm, also meine /boot hat (mit nur 1 kernel drauf) grade mal 4.5-5 MB
> Belegung.

Wie gesagt, nach oder besser während dem automatischen Paketupdate per 
Synaptik hatte ich *.bak und einen alten *.bak in "Trash".

> > Was hat es eigentlich bei den F6 Boot Options mit dem "--" am Ende von
> > "file=/cdrom/preseed/ubuntu.seed boot=casper initrd=/casper/initrd.gz quiet 
> > splash --" auf sich?
>
> Keine Ahnung. Hab das letzte Mal Sarge installiert und da war der d-i
> noch viel juenger und "einfacher" :)
>
> > > Wenn ich mir info grub/Configuration mal so fix durchschaue willst du
> > > wohl
> > > root (hd0,15)
> > > setup (hd0,4)
> > > aus der Grub Shell ausfuehren.
> > Solange ich diese Partitionen >15 nicht benutzen kann, komme ich hier mit den 
> > anderen vorgeschlagenen Maßnahmen nicht recht weiter.
>
> Es wuerde mich stark wundern, wenn du unter einem Debian-Installer diese
> Partitionen nicht nutzen kannst, ausser natuerlich die Devices
> existieren nicht unter /dev (schau doch mal wieviele hdaXX du da hast).

hda, hda1.....hda16. Es sollte also alles da sein, nur das mounten 
klappt wohl nicht. Wennich wenigstens mit der openSuse Installation 
weiter als diese blöde "CD-1 einlegen" Aufforderung käme, wurde ich ja 
sehen, ob mein /home auf /dev/hda16 dort gemounted wird.

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