Sinn & Zweck von Mounts in Etch

[AD-Admin]

Hi Leute,

bei einer Debian 4.0 (Etch Installation) von einer aktuellen Daily Image CD werden beim Systemstart folgendes gemountet:

/dev/shm tmpfs tmpfs
/lib/init/rw tmpfs tmpfs
/dev tmpfs udev

Kann mir jemand sagen ob man das irgendwie verhindern kann bzw. darf oder muss man das so lassen?
Was ist der Sinn & Zweck?

Von Debian 3.1 kenne ich nur /dev/shm...

Danke schon jetzt.

PS: Mountet Etch bei euch auch die 3 sachen?

[H4kk3r]

PS: Mountet Etch bei euch auch die 3 sachen?

Auf einem neu aufgesetzten Etch habe ich alle drei. Auf meinem Notebook, das schon länger mit Etch läuft, habe ich keinen von den drei Einträgen.

[catdog2]

Bei mir sind auch alle 3 Sachen gemountet

/dev/shm tmpfs tmpfs

Irgendwas mit shared Memory

/dev tmpfs udev

auf /dev ist ein tmpfs gemountet, in dem udev nach bedarf Gerätedateien erzeugt

/lib/init/rw tmpfs tmpfs

Würd ich auch gern wissen.

Kann mir jemand sagen ob man das irgendwie verhindern kann bzw. darf oder muss man das so lassen?

Dürfen auf jeden fall. Ich würds auch lassen, wird schon alles seinen Sinn haben.

[armin]

Kann mir jemand sagen ob man das irgendwie verhindern kann bzw. darf oder muss man das so lassen?
Was ist der Sinn & Zweck?

Die Frage ist erstmal: Aus welchem Grund solltest du es verhindern wollen?
Alle drei sind erstmal dynamische Dateisysteme, die im RAM liegen.
Alles unter /dev wird für Device-Nodes und verwandtes gebraucht.
/lib/init/rw müsste (ich kann mich irren) ein Speicherbereich sein, der beim Booten genutzt werden kann, bevor die Dateisysteme gemounted sind.

Code: Alles auswählen

Filesystem         Mount               Megs     Used    Avail %Used fs Type
tmpfs              /lib/init/rw       632.9      0.0    632.9   0%  tmpfs
udev               /dev                10.0      0.1      9.9   1%  tmpfs
tmpfs              /dev/shm           632.9      0.0    632.9   0%  tmpfs

Der genutzte Arbeitsspeicher liegt also bei null. So what?

[Spasswolf]

Das tmpfs wird vom initscript mountkernfs.sh auf /lib/init/rw gemountet, um, laut Aussage des Skriptes, ein schreibbares Dateisystem zu erhalten, bevor das rootfilesytem schreibbar gemountet wird:

Code: Alles auswählen

do_start () {
        #
        # Get some writable area available before the root is checked
        # and remounted.
        #
        RW_OPT=
        [ "${RW_SIZE:=$TMPFS_SIZE}" ] && RW_OPT=",size=$RW_SIZE"
        domount tmpfs "" /lib/init/rw tmpfs -omode=0755,nosuid$RW_OPT
        touch /lib/init/rw/.ramfs

[gms]

habe mich vor ein paar Wochen schon über das "/lib/init/rw" 'geärgert'. Hat jemand Hintergrundinformation gefunden, warum dieser eigenwillige Pfad gewählt wurde ?

Im FHS steht nicht, daß dort temporärer Müll abgeladen werden sollte :

/lib : Essential shared libraries and kernel modules"

Gruß
gms

[edit]

über Googel habe ich nicht viel interessantes gefunden, die meisten Teffer hatten aber irgendwie etwas mit Debian oder Ubuntu zu tun. Also dürfte Debian diesbezüglich die Vorreiterrolle übernommen haben

wozu es benutzt wird, findet man im checkroot.sh:

aus checkroot.sh:
# Does the root device in /etc/fstab match with the actual device ?
# If not we try to use the /dev/root alias device, and if that
# fails we create a temporary node in /lib/init/rw.

Also wenn alle Stricke schon gerissen sind, kann im profilaktisch angelegten tmpfs unter "/lib/init/rw" eine Devicenode für das Rootdevice angelegt werden. Hm, aber warum gerade dort ?

[/edit]

[AD-Admin]

Okay Danke für die Informationen. Dann weiss ich ja soweit bescheid.

Umso mehr ich mir die letzten Daily Builds von Etch bzw. Debian GNU/LINUX 4.0 anschaue umso mehr muss ich sagen, Debian 4.0 wird wirklich ein Meilenstein werden.

Das System läuft wirklich hevorragend. Habe hier einen 2.6.20-rc1 Kernel drauf laufen und die Maschine läuft absolut spitzenklasse.

Im Prinzip kann man etch jetzt eigentlich so gut wie als Stable betrachten? Dürfte ja sicher die nächsten Tage entgültig released werden.

[Teddybear]

Moin

Soweit ist ja alles geklärt..
bis auf /dev/shm

Das ist für das POSIX Shared Memory
Dies wird unter anderem gebraucht für das direkt redering ... steht auch so in den Readme Files der 3D Treiber...
Was es sonst noch explizit nutzt, kann ich nicht sagen.

Gruss Sascha

[catdog2]

Im Prinzip kann man etch jetzt eigentlich so gut wie als Stable betrachten? Dürfte ja sicher die nächsten Tage entgültig released werden.

Es gibt wohl noch zu viele RC Bugs. http://bugs.debian.org/release-critical/

Der Hauptgrund für die Verzögerung ist aber der Installer.

http://www.pro-linux.de/news/2006/10633.html

Trotz der bezahlten Arbeit hatte bereits Steve Langasek verkünden müssen, dass die Freigabe von Debian 4.0 »Etch« um einen Monat verschoben werden müsse. Als Grund nannte er die verzögerte Fertigstellung des Debian-Installers, der drei Monate hinter dem Terminplan lag. Vor der Freigabe von »Etch« muss noch ein weiterer Release-Kandidat des Installers erscheinen, der einen Update auf den Linux-Kernel 2.6.18 bringen soll.