Moien
(Geht um debian, kernel 2.6.11 mit initrd)
Wo genau wird /lib und /usr im Bootprozess geladen ? (/etc/rcS.d/S35mountall.sh scheint es nicht zu sein, da an der Stelle schon Dateien aus /lib gebraucht werden)
Und ab wann ist / rw gemounted ?
Danke
Moien
'n Abend,
Wo genau wird /lib und /usr im Bootprozess geladen ?
/lib sollte unbedingt im / liegen. Man kann ein paar merkwuerdige Verrenkungen machen, um das zu umgehen, aber es erscheint in keinster Weise sinnvoll, da unter /lib die Kernel-Module liegen, die evtl. benoetigt werden, um ueberhaupt weitere Dateisysteme zu mounten.
/usr ist weit weniger wichtig (obwohl gerade Debian da ein paar Dinge reinpackt, die da meiner Meinung nach nicht reingehoeren: arp z.B.) und wird, wenn ueberhaupt, durch mountall.sh gemountet.
(/etc/rcS.d/S35mountall.sh scheint es nicht zu sein, da an der
Stelle schon Dateien aus /lib gebraucht werden)
Ich gehe mal davon aus, dass Dein /lib mit im / liegt. Die Ausgabe von
$ mount
koennte Gewissheit bringen.
Und ab wann ist / rw gemounted ?
Nachdem in /etc/init.d/checkroot.sh aufgerufen wurde.
HTH,
Gruss vom Frank.
Moin
Wo genau wird /lib und /usr im Bootprozess geladen ?
/lib sollte unbedingt im / liegen. Man kann ein paar
merkwuerdige Verrenkungen machen, um das zu umgehen, aber es
erscheint in keinster Weise sinnvoll, da unter /lib die
Kernel-Module liegen, die evtl. benoetigt werden, um
ueberhaupt weitere Dateisysteme zu mounten.
Mal so als Hintergrund: mich nervt die Platte meines Laptop tierisch. Also will ich einiges was sich eh nie verändert dauerhaft (also ohne dem Kernel auch nur die Möglichkeit zum rausverfen zu geben) in den RAM laden. Die 1GB reichen aber nicht aus um alles einfachso in ein ramfs zu setzen. Als komprimier ich mit squashfs (lib 430MB => 100 MB), kopier das Image in ein ramfs und mounte das dann als /lib. /opt (auch 400MB => 100MB) und /usr (mein Problemfall, da viel, viel grösser und schlecht komprimierbar) sollen folgen, /etc und einiges aus /home kommen in ein ramfs (± 40 MB). Da müssten etwa 300-400 MB RAM (und ein komplett ruhiges System) überbleiben
In meiner initrd ist alles drin was man für den Stunt mit /lib und /opt braucht. Allerdings bin ich nicht sicher ob das System sowas auf Dauer überlebt. Sprich: was passiert wenn z.B. fsck mal einen Fehler auf / findet ? Ich muss ja schon in der initrd-phase auf / schreibend zugriefen.
/usr ist weit weniger wichtig (obwohl gerade Debian da ein
paar Dinge reinpackt, die da meiner Meinung nach nicht
reingehoeren: arp z.B.) und wird, wenn ueberhaupt, durch
mountall.sh gemountet.
Aber mountall.sh steht doch auf /. Und während des initrd-abarbeiten kann der Kernel das nicht aufrufen, es sei denn er mounted /. Wenn er aber / mounted kann kein checkfs mehr laufen (gemountets fs fsck’en ??)
(/etc/rcS.d/S35mountall.sh scheint es nicht zu sein, da an der
Stelle schon Dateien aus /lib gebraucht werden)Ich gehe mal davon aus, dass Dein /lib mit im / liegt.
… lag …
Und ab wann ist / rw gemounted ?
Nachdem in /etc/init.d/checkroot.sh aufgerufen wurde.
also wir ddoch ein ro-gemountetes fs durch fsck gejagt ?
cu
Mal so als Hintergrund: mich nervt die Platte meines Laptop
tierisch.
Irgendwo gab’s ein Laptop-HowTo. Das hast Du gelesen?
Also will ich einiges was sich eh nie verändert
dauerhaft (also ohne dem Kernel auch nur die Möglichkeit zum
rausverfen zu geben) in den RAM laden. Die 1GB reichen aber
nicht aus um alles einfachso in ein ramfs zu setzen. Als
komprimier ich mit squashfs (lib 430MB => 100 MB),
Verstehe ich das richtig: Dein /lib ist 430MB gross? Wie hast Du das denn geschafft?
frank@harbard ~ $ du -sh /lib
24M /lib
frank@harbard ~ $ du -sh /lib/modules/
17M /lib/modules/
frank@harbard ~ $
Und /lib/modules ist nur so fett, weil das LKMs von fuenf Generationen rumliegen.
kopier
das Image in ein ramfs und mounte das dann als /lib. /opt
(auch 400MB => 100MB) und /usr (mein Problemfall, da viel,
viel grösser und schlecht komprimierbar) sollen folgen, /etc
und einiges aus /home kommen in ein ramfs (± 40 MB). Da
müssten etwa 300-400 MB RAM (und ein komplett ruhiges System)
überbleibenIn meiner initrd ist alles drin was man für den Stunt mit /lib
und /opt braucht. Allerdings bin ich nicht sicher ob das
System sowas auf Dauer überlebt. Sprich: was passiert wenn
z.B. fsck mal einen Fehler auf / findet ? Ich muss ja schon in
der initrd-phase auf / schreibend zugriefen.
_Normalerweise_ kannst Du das gar nicht. Was Du da jetzt noch dran rumgebaut hast weiss ich freilich nicht.
Aber mountall.sh steht doch auf /. Und während des
initrd-abarbeiten kann der Kernel das nicht aufrufen, es sei
denn er mounted /. Wenn er aber / mounted kann kein checkfs
mehr laufen (gemountets fs fsck’en ??)
G’na. Du hast das Grundprinzip nicht verstanden. Schon der Kernel mountet / immer. Genaugenommen mountet er das device, was ihm an den zwei Bytes am offset 508 mit major und minor eingebrannt ist (man 8 rdev) oder per root=-Parameter uebermittelt wurde. Das koennen auch major/minors fuer eine ramdisk oder ein NFS-root sein. Anschliessend wird /sbin/init gestartet (linux/init/main.c fast ganz unten). Ab da ist der Kernel raus aus dem Spiel und init kuemmert sich dann um inittab und die init-Skripte. Im Falle einer ramdisk sind die Skripte eher einfach und meistens wird irgendwann ein pivot_root(8) ausgefuehrt um das rootfs zu wechseln. Man kann natuerlich auch in der ramdisk bleiben und zusaetzliche Dateisysteme ranholen. Nach dem pivot_root wird meist an das /sbin/init des neuen rootfs uebergeben. Und das remountet / irgendwann rw (nach dem fsck).
Evtl. kann Dir dieser Link gefallen: http://www.linuxdevices.com/articles/AT4540125636.html Geht zwar inhaltlich am Thema vorbei, aber der lagert auch sehr viele Dinge in ramdisk und tmpfs aus.
(/etc/rcS.d/S35mountall.sh scheint es nicht zu sein, da an der
Stelle schon Dateien aus /lib gebraucht werden)Ich gehe mal davon aus, dass Dein /lib mit im / liegt.
… lag …
Pack Dein ganzes / einschliesslich /lib in die Ramdisk.
Und ab wann ist / rw gemounted ?
Nachdem in /etc/init.d/checkroot.sh aufgerufen wurde.
also wir ddoch ein ro-gemountetes fs durch fsck gejagt ?
Natuerlich. Alles andere waere suizid.
Gruss vom Frank.
Moin
Mal so als Hintergrund: mich nervt die Platte meines Laptop
tierisch.Irgendwo gab’s ein Laptop-HowTo. Das hast Du gelesen?
Ja, klar. Das läst die Platte alle 5 min hochdrehen. Das blockiert wiederrum den Rechner für 2-3 Sekunden. Was mich wiederrum nervt. Noch schlimmer nervt mich das ständige Gesäusel der Platte. Also muss die Platte lange aus bleiben.
Verstehe ich das richtig: Dein /lib ist 430MB gross? Wie hast
Du das denn geschafft?
Da waren ein paar Modul-Sätze zuviel drin. Bin um 350 MB runter…
Und /lib/modules ist nur so fett,
weil das LKMs von fuenf Generationen rumliegen.
4 Generationen waren bei mir schon genug.
In meiner initrd ist alles drin was man für den Stunt mit /lib
und /opt braucht. Allerdings bin ich nicht sicher ob das
System sowas auf Dauer überlebt. Sprich: was passiert wenn
z.B. fsck mal einen Fehler auf / findet ? Ich muss ja schon in
der initrd-phase auf / schreibend zugriefen._Normalerweise_ kannst Du das gar nicht.
Wir reden über Linux. Geht nicht gibts nicht.
Was Du da jetzt noch
dran rumgebaut hast weiss ich freilich nicht.
Nur /sbin/init aus dem initrd-image.
G’na. Du hast das Grundprinzip nicht verstanden. Schon der
Kernel mountet / immer. Genaugenommen mountet er das device,
was ihm an den zwei Bytes am offset 508 mit major und minor
eingebrannt ist (man 8 rdev) oder per root=-Parameter
uebermittelt wurde.
Ich übermittle per Bootpara ein initrd-image. Und in dem steht ein Skript das das eigentliche / mounted. Und kurz bevor das Skript die 2 Systeme per pivot_root austauscht bau ich an / rum. Und zwar VOR dem fsck-check. Und das macht mir Sorgen.
Das koennen auch major/minors fuer eine
ramdisk oder ein NFS-root sein. Anschliessend wird /sbin/init
gestartet (linux/init/main.c fast ganz unten). Ab da ist der
Kernel raus aus dem Spiel und init kuemmert sich dann um
inittab und die init-Skripte. Im Falle einer ramdisk sind die
Skripte eher einfach und meistens wird irgendwann ein
pivot_root(8) ausgefuehrt um das rootfs zu wechseln. Man kann
natuerlich auch in der ramdisk bleiben und zusaetzliche
Dateisysteme ranholen. Nach dem pivot_root wird meist an das
/sbin/init des neuen rootfs uebergeben. Und das remountet /
irgendwann rw (nach dem fsck).
Also im Klartext: wenn ich schon beim Ausführen vom /sbin/init des initrd rw-Zugriff auf / braucht „muss“ ich das fsck vor dem pivot_root machen ? D.h. ich müsste fsck in intrd installieren oder mit chroot arbeiten. hmmm… das bekomm ich irgendwie hin.
Evtl. kann Dir dieser Link gefallen:
Ich less es bei Gelegenheit durch.
Pack Dein ganzes / einschliesslich /lib in die Ramdisk.
1GB RAM vs 8GB / … past nicht, auch nicht mit squashfs.
Nachdem in /etc/init.d/checkroot.sh aufgerufen wurde.
also wir ddoch ein ro-gemountetes fs durch fsck gejagt ?
Natuerlich. Alles andere waere suizid.
Ich dachte immer fsck’en eines gemounteten System, egal ob ro oder rw, wäre tödlich.
cu
Moin,
nur so nebenbei:
Nachdem in /etc/init.d/checkroot.sh aufgerufen wurde.
also wir ddoch ein ro-gemountetes fs durch fsck gejagt ?
Natuerlich. Alles andere waere suizid.
Ich dachte immer fsck’en eines gemounteten System, egal ob ro
oder rw, wäre tödlich.
unter BSD ist das eher der Normalfall, dank snapshots und softupdates.
Gruß,
Malte.