Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
mount zeigt nicht alle mounts?!
11 views
Skip to first unread message
bna...@web.de
Apr 24, 2012, 2:52:54 AM4/24/12
to
Hi,
ich versteh mein System nicht :-(
Mein Rechner hat zwei Platten. Auf sda ist alles bis auf /srv, das ist auf
sdb. Und alles läuft wie es soll. Das ist fein, aber ich wüsste gerne warum
die Anzeige so ist wie sie ist.
# cat /etc/fstab | grep ^/dev
/dev/sda1 swap swap defaults 0 0
/dev/sda2 / ext3 acl,user_xattr 1 1
/dev/sda4 /tmp ext3 acl,user_xattr 1 2
/dev/sda3 /var ext3 acl,user_xattr 1 2
/dev/sdb1 /srv ext3 acl,user,nofail 0 0
#
# mount | grep ^/dev
/dev/sda2 on / type ext3 (rw,acl,user_xattr)
/dev/sda4 on /tmp type ext3 (rw,acl,user_xattr)
/dev/sda3 on /var type ext3 (rw,acl,user_xattr)
Nanu? Wo ist denn sdb1? Ein Anzeigefehler bei mount? Versuchen wir etwas
anderes:
# df -h | grep ^/dev
/dev/sda2 5,0G 2,4G 2,4G 50% /
/dev/sda4 1020M 34M 934M 4% /tmp
/dev/sda3 3,0G 344M 2,5G 12% /var
Hmm, auch hier nix. Ist denn /srv tatsächlich da?
# du -sh /srv
33G /srv
Ja, es ist da. Wenn es nicht gemounted wäre, hätten auf dem schon halbvollen
/ von nur 5GiB Grösse keine weiteren 33GiB Platz. Auch kann ich auf alle
Daten zugreifen ...
Warum zeigt mount und df /srv nicht an?
Fragt
Bernd
ich versteh mein System nicht :-(
Mein Rechner hat zwei Platten. Auf sda ist alles bis auf /srv, das ist auf
sdb. Und alles läuft wie es soll. Das ist fein, aber ich wüsste gerne warum
die Anzeige so ist wie sie ist.
# cat /etc/fstab | grep ^/dev
/dev/sda1 swap swap defaults 0 0
/dev/sda2 / ext3 acl,user_xattr 1 1
/dev/sda4 /tmp ext3 acl,user_xattr 1 2
/dev/sda3 /var ext3 acl,user_xattr 1 2
/dev/sdb1 /srv ext3 acl,user,nofail 0 0
#
# mount | grep ^/dev
/dev/sda2 on / type ext3 (rw,acl,user_xattr)
/dev/sda4 on /tmp type ext3 (rw,acl,user_xattr)
/dev/sda3 on /var type ext3 (rw,acl,user_xattr)
Nanu? Wo ist denn sdb1? Ein Anzeigefehler bei mount? Versuchen wir etwas
anderes:
# df -h | grep ^/dev
/dev/sda2 5,0G 2,4G 2,4G 50% /
/dev/sda4 1020M 34M 934M 4% /tmp
/dev/sda3 3,0G 344M 2,5G 12% /var
Hmm, auch hier nix. Ist denn /srv tatsächlich da?
# du -sh /srv
33G /srv
Ja, es ist da. Wenn es nicht gemounted wäre, hätten auf dem schon halbvollen
/ von nur 5GiB Grösse keine weiteren 33GiB Platz. Auch kann ich auf alle
Daten zugreifen ...
Warum zeigt mount und df /srv nicht an?
Fragt
Bernd
Juergen P. Meier
Apr 24, 2012, 4:22:17 AM4/24/12
to
bna...@web.de <bna...@web.de>:
Swapspaces misbraucht.
Filesysteme an, die z.B. bei Linux in /etc/mtab eingetragen wurden.
> Nanu? Wo ist denn sdb1? Ein Anzeigefehler bei mount? Versuchen wir etwas
> anderes:
Wenn Z.B. beim mounten von /srv die /etc/mtab nicht schreibbar war, tritt
sowas auf.
> # df -h | grep ^/dev
> /dev/sda2 5,0G 2,4G 2,4G 50% /
> /dev/sda4 1020M 34M 934M 4% /tmp
> /dev/sda3 3,0G 344M 2,5G 12% /var
Auch df verlaesst sich auf die Korrektheit des Inhalts der /etc/mtab
> Hmm, auch hier nix. Ist denn /srv tatsächlich da?
>
> # du -sh /srv
> 33G /srv
Klarheit schafft z.B. unter Linux ein blick in /proc/mounts, aus dem
du eine kaputte mtab rekonstruieren kannst (cat /proc/mounts >/etc/mtab)
> Warum zeigt mount und df /srv nicht an?
Weil bei dir beim Mounten was schief ging (und zwar der letzte
schritt: das anpassen der /etc/mtab).
Juergen
--
Juergen P. Meier - "This World is about to be Destroyed!"
end
If you think technology can solve your problems you don't understand
technology and you don't understand your problems. (Bruce Schneier)
> ich versteh mein System nicht :-(
>
>
> # cat /etc/fstab | grep ^/dev
> /dev/sda1 swap swap defaults 0 0
> /dev/sda2 / ext3 acl,user_xattr 1 1
> /dev/sda4 /tmp ext3 acl,user_xattr 1 2
> /dev/sda3 /var ext3 acl,user_xattr 1 2
> /dev/sdb1 /srv ext3 acl,user,nofail 0 0
Die fstab wird unter vielen Unixoiden auch zur Deklaration des
> /dev/sda1 swap swap defaults 0 0
> /dev/sda2 / ext3 acl,user_xattr 1 1
> /dev/sda4 /tmp ext3 acl,user_xattr 1 2
> /dev/sda3 /var ext3 acl,user_xattr 1 2
> /dev/sdb1 /srv ext3 acl,user,nofail 0 0
Swapspaces misbraucht.
>
> # mount | grep ^/dev
> /dev/sda2 on / type ext3 (rw,acl,user_xattr)
> /dev/sda4 on /tmp type ext3 (rw,acl,user_xattr)
> /dev/sda3 on /var type ext3 (rw,acl,user_xattr)
Mount zeigt nur die tatsaechlich und sauber als Filesystem gemounteten
> # mount | grep ^/dev
> /dev/sda2 on / type ext3 (rw,acl,user_xattr)
> /dev/sda4 on /tmp type ext3 (rw,acl,user_xattr)
> /dev/sda3 on /var type ext3 (rw,acl,user_xattr)
Filesysteme an, die z.B. bei Linux in /etc/mtab eingetragen wurden.
> Nanu? Wo ist denn sdb1? Ein Anzeigefehler bei mount? Versuchen wir etwas
> anderes:
sowas auf.
> # df -h | grep ^/dev
> /dev/sda2 5,0G 2,4G 2,4G 50% /
> /dev/sda4 1020M 34M 934M 4% /tmp
> /dev/sda3 3,0G 344M 2,5G 12% /var
> Hmm, auch hier nix. Ist denn /srv tatsächlich da?
>
> # du -sh /srv
> 33G /srv
du eine kaputte mtab rekonstruieren kannst (cat /proc/mounts >/etc/mtab)
> Warum zeigt mount und df /srv nicht an?
schritt: das anpassen der /etc/mtab).
Juergen
--
Juergen P. Meier - "This World is about to be Destroyed!"
end
If you think technology can solve your problems you don't understand
technology and you don't understand your problems. (Bruce Schneier)
Juergen P. Meier
Apr 24, 2012, 4:27:40 AM4/24/12
to
Ingrid:
oft subtil unterschiedlich: z.B. hinterlaesst jeder loopback-mount
(crypto-volume etc.) seine Verwaltungsdaten (welche Datei auf welches
loopback-device gemappt ist) in /etc/mtab, diese Information fehlt
aber in /proc/mounts - daher funktiniert nach so einer reparatur ein
crypt-umount nicht mehr fehlerfrei!
Auch ist der / mountpoint in /proc/mount ein virtueller alias.
Ansonsten funktioniert dieser Trick idR. ganz gut.
>
> Klarheit schafft z.B. unter Linux ein blick in /proc/mounts, aus dem
> du eine kaputte mtab rekonstruieren kannst (cat /proc/mounts >/etc/mtab)
Warnung: Bei Linsux sind die Inhalte von /etc/mtab und /proc/mounts
> Klarheit schafft z.B. unter Linux ein blick in /proc/mounts, aus dem
> du eine kaputte mtab rekonstruieren kannst (cat /proc/mounts >/etc/mtab)
oft subtil unterschiedlich: z.B. hinterlaesst jeder loopback-mount
(crypto-volume etc.) seine Verwaltungsdaten (welche Datei auf welches
loopback-device gemappt ist) in /etc/mtab, diese Information fehlt
aber in /proc/mounts - daher funktiniert nach so einer reparatur ein
crypt-umount nicht mehr fehlerfrei!
Auch ist der / mountpoint in /proc/mount ein virtueller alias.
Ansonsten funktioniert dieser Trick idR. ganz gut.
bna...@web.de
Apr 24, 2012, 4:52:36 AM4/24/12
to
Juergen P. Meier wrote:
> bna...@web.de <bna...@web.de>:
>> ich versteh mein System nicht :-(
>>
>> # cat /etc/fstab | grep ^/dev
>> /dev/sda1 swap swap defaults 0 0
>> /dev/sda2 / ext3 acl,user_xattr 1 1
>> /dev/sda4 /tmp ext3 acl,user_xattr 1 2
>> /dev/sda3 /var ext3 acl,user_xattr 1 2
>> /dev/sdb1 /srv ext3 acl,user,nofail 0 0
>
(...)
> bna...@web.de <bna...@web.de>:
>> ich versteh mein System nicht :-(
>>
>> # cat /etc/fstab | grep ^/dev
>> /dev/sda1 swap swap defaults 0 0
>> /dev/sda2 / ext3 acl,user_xattr 1 1
>> /dev/sda4 /tmp ext3 acl,user_xattr 1 2
>> /dev/sda3 /var ext3 acl,user_xattr 1 2
>> /dev/sdb1 /srv ext3 acl,user,nofail 0 0
>
>
>> Warum zeigt mount und df /srv nicht an?
>
> Weil bei dir beim Mounten was schief ging (und zwar der letzte
> schritt: das anpassen der /etc/mtab).
Ah ja, in /proc/mounts ist der Eintrag vorhanden.
>> Warum zeigt mount und df /srv nicht an?
>
> Weil bei dir beim Mounten was schief ging (und zwar der letzte
> schritt: das anpassen der /etc/mtab).
Müsste ich dann nicht eine Meldung in dmesg oder /var/log/messages finden?
So a la: Could not write to /etc/mtab?
Oder welche Möglichkeiten habe ich um dem näher zu kommen?
Thx
Bernd
bna...@web.de
Apr 24, 2012, 8:18:23 AM4/24/12
to
Wie oben zu lesen steht in der entsprechendne Zeile in der fstab ein
'nofail' was bewirken soll, das ein Problem beim Mounten des Devices in
dieser Zeile keine Fehlermeldung auslösen soll.
>>> /dev/sdb1 /srv ext3 acl,user,nofail 0 0
/dev/sdb1 /srv ext3 acl,user_xattr 1 2
Und damit erscheint dann auch der Mount-Point in der Ausgabe des Befehls:
mount.
# mount | grep ^/dev
/dev/sda2 on / type ext3 (rw,acl,user_xattr)
/dev/sda4 on /tmp type ext3 (rw,acl,user_xattr)
/dev/sda3 on /var type ext3 (rw,acl,user_xattr)
#
Offenbar bewirkt die Angabe der Option 'nofail' dass der Mountpoint nicht in
die /etc/mtab geschrieben wird (obwohl es dafür eine eigene Option --no-mtab
gibt), was dann das Nichterscheinen des Eintrags bei der Verwendung des
Befehls 'mount' -wie von Jürgen beschrieben- zur Folge hatte.
Bye
Bernd
Bastian Blank
Apr 25, 2012, 4:16:26 AM4/25/12
to
Juergen P. Meier wrote:
> Warnung: Bei Linsux sind die Inhalte von /etc/mtab und /proc/mounts
> oft subtil unterschiedlich:
Das stimmt schon länger nicht.
> Warnung: Bei Linsux sind die Inhalte von /etc/mtab und /proc/mounts
> oft subtil unterschiedlich:
| lrwxrwxrwx 1 root root 12 Dez 3 2008 /etc/mtab -> /proc/mounts
> z.B. hinterlaesst jeder loopback-mount
> (crypto-volume etc.) seine Verwaltungsdaten (welche Datei auf welches
> loopback-device gemappt ist) in /etc/mtab
> Auch ist der / mountpoint in /proc/mount ein virtueller alias.
| $ grep " / " /proc/mounts
| rootfs / rootfs rw 0 0
| /dev/xvda / ext3 rw,relatime,errors=continue,barrier=1,data=ordered 0 0
Bastian
Martin Vaeth
Apr 25, 2012, 12:45:32 PM4/25/12
to
Bastian Blank <use...@waldi.eu.org> schrieb:
Das aber auch aus den beschriebenen Gründen (mount kann einige
Zusatz-Informationen nicht mehr nach /etc/mtab schreiben) in
komplexeren Szenarios zu subtilen Problemen führen.
> Juergen P. Meier wrote:
>> Warnung: Bei Linsux sind die Inhalte von /etc/mtab und /proc/mounts
>> oft subtil unterschiedlich:
>
> Das stimmt schon länger nicht.
>
>| lrwxrwxrwx 1 root root 12 Dez 3 2008 /etc/mtab -> /proc/mounts
Einige Distributionen/Administratoren machen das vielleicht so.
>> Warnung: Bei Linsux sind die Inhalte von /etc/mtab und /proc/mounts
>> oft subtil unterschiedlich:
>
> Das stimmt schon länger nicht.
>
>| lrwxrwxrwx 1 root root 12 Dez 3 2008 /etc/mtab -> /proc/mounts
Das aber auch aus den beschriebenen Gründen (mount kann einige
Zusatz-Informationen nicht mehr nach /etc/mtab schreiben) in
komplexeren Szenarios zu subtilen Problemen führen.
Thomas 'PointedEars' Lahn
Apr 25, 2012, 12:54:28 PM4/25/12
to
$ ls -l /etc/mtab
-rw-r--r-- 1 root root 1186 25. Apr 13:40 /etc/mtab
$ diff -u /etc/mtab /proc/mounts | grep '^[+-]' | wc -l
37
$ uname -srvmo
Linux 3.3.1-pe #1 SMP Sun Apr 15 22:44:43 CEST 2012 i686 GNU/Linux
$ cat /etc/debian_version
6.0.4
--
PointedEars
Please do not Cc: me. / Bitte keine Kopien per E-Mail.
Juergen P. Meier
Apr 25, 2012, 11:33:19 PM4/25/12
to
Bastian Blank <use...@waldi.eu.org>:
Oder hat das der Admin verbrochen?
>> z.B. hinterlaesst jeder loopback-mount
>> (crypto-volume etc.) seine Verwaltungsdaten (welche Datei auf welches
>> loopback-device gemappt ist) in /etc/mtab
>
> Die stehen inzwischen in /run/mount/utab.
/run/mount: no such file or directory
man losetup | grep -c /run/mount
0
Wie meinen?
>> Auch ist der / mountpoint in /proc/mount ein virtueller alias.
>
> Auch das ist falsch.
Nein.
>| $ grep " / " /proc/mounts
>| rootfs / rootfs rw 0 0
^^^^^^
remount von / mit Optionsaenderung genau /fehlerfrei/ funktioneren soll.
Es gibt gute Gruende, *keinen* Symlink von /proc/mount in /etc/mtab zu
machen. Und selbst beim Kopieren muss man haendisch nachpflegen.
Wer das nicht macht, handelt grob fahrlaessig und gefaehrdet
systematisch die Stabilitaet des Systems. Ja, es gibt auch unter
Distributions-Paketierern Vollspacken die sowas nicht kapieren, auch
bei Basispaketen. Aber das ist nun wirklich keine neue Erkenntnis.
HTH,
> Juergen P. Meier wrote:
>> Warnung: Bei Linsux sind die Inhalte von /etc/mtab und /proc/mounts
>> oft subtil unterschiedlich:
>
> Das stimmt schon länger nicht.
>
>| lrwxrwxrwx 1 root root 12 Dez 3 2008 /etc/mtab -> /proc/mounts
Welche kaputte Linsux-Distribution macht solch einen SCheiss?
>> Warnung: Bei Linsux sind die Inhalte von /etc/mtab und /proc/mounts
>> oft subtil unterschiedlich:
>
> Das stimmt schon länger nicht.
>
>| lrwxrwxrwx 1 root root 12 Dez 3 2008 /etc/mtab -> /proc/mounts
Oder hat das der Admin verbrochen?
>> z.B. hinterlaesst jeder loopback-mount
>> (crypto-volume etc.) seine Verwaltungsdaten (welche Datei auf welches
>> loopback-device gemappt ist) in /etc/mtab
>
> Die stehen inzwischen in /run/mount/utab.
man losetup | grep -c /run/mount
0
Wie meinen?
>> Auch ist der / mountpoint in /proc/mount ein virtueller alias.
>
> Auch das ist falsch.
>| $ grep " / " /proc/mounts
>| rootfs / rootfs rw 0 0
>| /dev/xvda / ext3 rw,relatime,errors=continue,barrier=1,data=ordered 0 0
Und jetzt erklaere mal genau, wie mit diesem Doppeleintrag ein
remount von / mit Optionsaenderung genau /fehlerfrei/ funktioneren soll.
Es gibt gute Gruende, *keinen* Symlink von /proc/mount in /etc/mtab zu
machen. Und selbst beim Kopieren muss man haendisch nachpflegen.
Wer das nicht macht, handelt grob fahrlaessig und gefaehrdet
systematisch die Stabilitaet des Systems. Ja, es gibt auch unter
Distributions-Paketierern Vollspacken die sowas nicht kapieren, auch
bei Basispaketen. Aber das ist nun wirklich keine neue Erkenntnis.
HTH,
Boris Kirkorowicz
Apr 26, 2012, 1:44:46 AM4/26/12
to
Hallo,
Am 26.04.2012 05:33, schrieb Juergen P. Meier:
>> | lrwxrwxrwx 1 root root 12 Dez 3 2008 /etc/mtab -> /proc/mounts
>
> Welche kaputte Linsux-Distribution macht solch einen SCheiss?
SuSE 12.1:
lrwxrwxrwx 1 root root 17 27. Jan 14:58 /etc/mtab -> /proc/self/mounts
So besser?
--
Mit freundlichem Gruß Best regards
Boris Kirkorowicz
Am 26.04.2012 05:33, schrieb Juergen P. Meier:
>> | lrwxrwxrwx 1 root root 12 Dez 3 2008 /etc/mtab -> /proc/mounts
>
> Welche kaputte Linsux-Distribution macht solch einen SCheiss?
lrwxrwxrwx 1 root root 17 27. Jan 14:58 /etc/mtab -> /proc/self/mounts
So besser?
--
Mit freundlichem Gruß Best regards
Boris Kirkorowicz
Michael Meyer
Apr 26, 2012, 4:35:49 AM4/26/12
to
*** Thomas 'PointedEars' Lahn wrote:
> Martin Vaeth wrote:
> > Bastian Blank <use...@waldi.eu.org> schrieb:
> Martin Vaeth wrote:
> > Bastian Blank <use...@waldi.eu.org> schrieb:
> >>| lrwxrwxrwx 1 root root 12 Dez 3 2008 /etc/mtab -> /proc/mounts
> >
> > Einige Distributionen/Administratoren machen das vielleicht so.
> > Das aber auch aus den beschriebenen Gründen (mount kann einige
> > Zusatz-Informationen nicht mehr nach /etc/mtab schreiben) in
> > komplexeren Szenarios zu subtilen Problemen führen.
>
> ACK.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=494001
> >
> > Einige Distributionen/Administratoren machen das vielleicht so.
> > Das aber auch aus den beschriebenen Gründen (mount kann einige
> > Zusatz-Informationen nicht mehr nach /etc/mtab schreiben) in
> > komplexeren Szenarios zu subtilen Problemen führen.
>
> ACK.
Micha
Stefan Reuther
Apr 26, 2012, 12:46:07 PM4/26/12
to
Juergen P. Meier wrote:
> Bastian Blank <use...@waldi.eu.org>:
>>Juergen P. Meier wrote:
>>>Warnung: Bei Linsux sind die Inhalte von /etc/mtab und /proc/mounts
>>>oft subtil unterschiedlich:
>>
>>Das stimmt schon länger nicht.
>>
>>| lrwxrwxrwx 1 root root 12 Dez 3 2008 /etc/mtab -> /proc/mounts
>
> Welche kaputte Linsux-Distribution macht solch einen SCheiss?
> Oder hat das der Admin verbrochen?
Linux kann per-process mounts. Wenn man vorhat, dieses Feature zu
> Bastian Blank <use...@waldi.eu.org>:
>>Juergen P. Meier wrote:
>>>Warnung: Bei Linsux sind die Inhalte von /etc/mtab und /proc/mounts
>>>oft subtil unterschiedlich:
>>
>>Das stimmt schon länger nicht.
>>
>>| lrwxrwxrwx 1 root root 12 Dez 3 2008 /etc/mtab -> /proc/mounts
>
> Welche kaputte Linsux-Distribution macht solch einen SCheiss?
> Oder hat das der Admin verbrochen?
nutzen, bleibt einem kaum was anderes übrig als das, weil man ja dennoch
nur eine /etc/mtab hat.
Der Symlink /etc/mtab -> /proc/mounts ist ansonsten vor gefühlt
Jahrzehnten schon für bestimmte Einsatzzwecke empfohlen worden. Dann
muss man nämlich nicht bei jedem Boot nach /etc schreiben.
Stefan
Bastian Blank
Apr 27, 2012, 12:32:49 PM4/27/12
to
>>| lrwxrwxrwx 1 root root 12 Dez 3 2008 /etc/mtab -> /proc/mounts
> Welche kaputte Linsux-Distribution macht solch einen SCheiss?
Ich sehe da keinen "SCheiss".
> Welche kaputte Linsux-Distribution macht solch einen SCheiss?
>>> z.B. hinterlaesst jeder loopback-mount
>>> (crypto-volume etc.) seine Verwaltungsdaten (welche Datei auf welches
>>> loopback-device gemappt ist) in /etc/mtab
>> Die stehen inzwischen in /run/mount/utab.
> /run/mount: no such file or directory
| -rw-r--r-- 1 root root 531 Apr 26 15:56 /run/mount/utab
> man losetup | grep -c /run/mount
> 0
>>| $ grep " / " /proc/mounts
>>| rootfs / rootfs rw 0 0
> ^^^^^^
>>| /dev/xvda / ext3 rw,relatime,errors=continue,barrier=1,data=ordered 0 0
>
> Und jetzt erklaere mal genau, wie mit diesem Doppeleintrag ein
> remount von / mit Optionsaenderung genau /fehlerfrei/ funktioneren soll.
kannst. Hint: es gibt keinen, nachdem das richtige Root dort ist.
Der Kernel liefert die reale Sicht auf die gemounteten Filesysteme.
Diese können sich überlagern, wobei kein Zugriff auf das weiter unten
liegende möglich ist. Der Kernel weiss schon, welcher Mount gemeint ist,
nähmlich der vom aktuellen Prozess erreichbare.
> Es gibt gute Gruende, *keinen* Symlink von /proc/mount in /etc/mtab zu
> machen. Und selbst beim Kopieren muss man haendisch nachpflegen.
> Wer das nicht macht, handelt grob fahrlaessig und gefaehrdet
> systematisch die Stabilitaet des Systems. Ja, es gibt auch unter
> Distributions-Paketierern Vollspacken die sowas nicht kapieren, auch
> bei Basispaketen. Aber das ist nun wirklich keine neue Erkenntnis.
Bastian
Juergen P. Meier
Apr 29, 2012, 11:07:21 PM4/29/12
to
Bastian Blank <use...@waldi.eu.org>:
/etc/mtab nicht wie vorgesehen und ueblich alleine von mount/umount pflegen
zu lassen, sondern durch das Abbild der Mount-LIste des Kernels (/proc)
zu ersetzen.
Wer losetup kennt, wird das hingegen verstehen.
> Der Kernel liefert die reale Sicht auf die gemounteten Filesysteme.
Allerdings nur die fuer ihn (ausreichende) Information. Und fuer diese
Angaben gibt es /proc/mounts. Die /etc/mtab Datei hat *eine* *andere*
Semantik. Das ist eben genau *nicht* Die Sicht des Kernels, sondern
die Verwaltungsdaten von mount und umount.
> Diese können sich überlagern, wobei kein Zugriff auf das weiter unten
Koennen, tun es aber idR. nicht.
> liegende möglich ist. Der Kernel weiss schon, welcher Mount gemeint ist,
> nähmlich der vom aktuellen Prozess erreichbare.
Ich habe versucht zu erklaeren, welches Szenario zum Beispiel *mehr*
Information in /etc/mtab ablegt, als der Kernel kennt. Es ist aber
nicht das einzige.
>> Es gibt gute Gruende, *keinen* Symlink von /proc/mount in /etc/mtab zu
>> machen. Und selbst beim Kopieren muss man haendisch nachpflegen.
>
> Welche?
Ich habe einen hinreichend guten Grund aufgefuehrt. Wenn dir das nicht
reicht, dann murkse bitte weiter mit symlinks nach /proc herum,
beschwer dich dann aber nicht, wenn deine Systemwerkzeuge auf die
Fresse fallen.
> Juergen P. Meier wrote:
>> Bastian Blank <use...@waldi.eu.org>:
>>>| lrwxrwxrwx 1 root root 12 Dez 3 2008 /etc/mtab -> /proc/mounts
>> Welche kaputte Linsux-Distribution macht solch einen SCheiss?
>
> Ich sehe da keinen "SCheiss".
>
>> Bastian Blank <use...@waldi.eu.org>:
>>>| lrwxrwxrwx 1 root root 12 Dez 3 2008 /etc/mtab -> /proc/mounts
>> Welche kaputte Linsux-Distribution macht solch einen SCheiss?
>
> Ich sehe da keinen "SCheiss".
>
>> man losetup | grep -c /run/mount
>> 0
>
> Was hat losetup mit mtab zu tun? Nichts.
Das erklaert, warum du nicht verstehst warum es eine Dumme Idee ist,
>> 0
>
> Was hat losetup mit mtab zu tun? Nichts.
/etc/mtab nicht wie vorgesehen und ueblich alleine von mount/umount pflegen
zu lassen, sondern durch das Abbild der Mount-LIste des Kernels (/proc)
zu ersetzen.
Wer losetup kennt, wird das hingegen verstehen.
> Der Kernel liefert die reale Sicht auf die gemounteten Filesysteme.
Angaben gibt es /proc/mounts. Die /etc/mtab Datei hat *eine* *andere*
Semantik. Das ist eben genau *nicht* Die Sicht des Kernels, sondern
die Verwaltungsdaten von mount und umount.
> Diese können sich überlagern, wobei kein Zugriff auf das weiter unten
> liegende möglich ist. Der Kernel weiss schon, welcher Mount gemeint ist,
> nähmlich der vom aktuellen Prozess erreichbare.
Information in /etc/mtab ablegt, als der Kernel kennt. Es ist aber
nicht das einzige.
>> Es gibt gute Gruende, *keinen* Symlink von /proc/mount in /etc/mtab zu
>> machen. Und selbst beim Kopieren muss man haendisch nachpflegen.
>
> Welche?
reicht, dann murkse bitte weiter mit symlinks nach /proc herum,
beschwer dich dann aber nicht, wenn deine Systemwerkzeuge auf die
Fresse fallen.
Werner Flamme
May 10, 2012, 4:47:45 AM5/10/12
to
Juergen P. Meier [30.04.2012 05:07]:
wie Boris schon zeigte, wird dort standardmäßig versymlinkt?
Nicht alles, was Debian macht, hat Vorbildfunktion.
Und wenn Du sagst, dass irgendwelche Programme irgendwas nach /etc/mtab
schreiben *können*, was die /proc/mounts nicht verträgt, dann ist es
doch Sache der Distri, dafür zu sorgen, dass alle Programme, die eine
der Dateien lesen, damit zurechtkommen - entweder schreiben die
Programme dann nichts Verqueres, oder die lesenden Programme können
damit umgehen.
Werner
--
> Bastian Blank <use...@waldi.eu.org>:
>> Juergen P. Meier wrote:
>>> Bastian Blank <use...@waldi.eu.org>:
>>>> | lrwxrwxrwx 1 root root 12 Dez 3 2008 /etc/mtab -> /proc/mounts
>>> Welche kaputte Linsux-Distribution macht solch einen SCheiss?
>>
>> Ich sehe da keinen "SCheiss".
[...]
>> Juergen P. Meier wrote:
>>> Bastian Blank <use...@waldi.eu.org>:
>>>> | lrwxrwxrwx 1 root root 12 Dez 3 2008 /etc/mtab -> /proc/mounts
>>> Welche kaputte Linsux-Distribution macht solch einen SCheiss?
>>
>> Ich sehe da keinen "SCheiss".
>
>>> Es gibt gute Gruende, *keinen* Symlink von /proc/mount in /etc/mtab zu
>>> machen. Und selbst beim Kopieren muss man haendisch nachpflegen.
>>
>> Welche?
>
> Ich habe einen hinreichend guten Grund aufgefuehrt. Wenn dir das nicht
> reicht, dann murkse bitte weiter mit symlinks nach /proc herum,
> beschwer dich dann aber nicht, wenn deine Systemwerkzeuge auf die
> Fresse fallen.
>
> Juergen
Welche Systemwerkezeuge fallen bei openSUSE denn auf die Fresse - denn
>>> Es gibt gute Gruende, *keinen* Symlink von /proc/mount in /etc/mtab zu
>>> machen. Und selbst beim Kopieren muss man haendisch nachpflegen.
>>
>> Welche?
>
> Ich habe einen hinreichend guten Grund aufgefuehrt. Wenn dir das nicht
> reicht, dann murkse bitte weiter mit symlinks nach /proc herum,
> beschwer dich dann aber nicht, wenn deine Systemwerkzeuge auf die
> Fresse fallen.
>
> Juergen
wie Boris schon zeigte, wird dort standardmäßig versymlinkt?
Nicht alles, was Debian macht, hat Vorbildfunktion.
Und wenn Du sagst, dass irgendwelche Programme irgendwas nach /etc/mtab
schreiben *können*, was die /proc/mounts nicht verträgt, dann ist es
doch Sache der Distri, dafür zu sorgen, dass alle Programme, die eine
der Dateien lesen, damit zurechtkommen - entweder schreiben die
Programme dann nichts Verqueres, oder die lesenden Programme können
damit umgehen.
Werner
--
Rolf Muth
May 11, 2012, 6:01:49 AM5/11/12
to
Boris Kirkorowicz wrote:
> Hallo,
>
> Am 26.04.2012 05:33, schrieb Juergen P. Meier:
>>> | lrwxrwxrwx 1 root root 12 Dez 3 2008 /etc/mtab -> /proc/mounts
>>
>> Welche kaputte Linsux-Distribution macht solch einen SCheiss?
>
> SuSE 12.1:
> lrwxrwxrwx 1 root root 17 27. Jan 14:58 /etc/mtab -> /proc/self/mounts
>
War bei meiner SUSE LINUX 10.1 auch schon so.
> Hallo,
>
> Am 26.04.2012 05:33, schrieb Juergen P. Meier:
>>> | lrwxrwxrwx 1 root root 12 Dez 3 2008 /etc/mtab -> /proc/mounts
>>
>> Welche kaputte Linsux-Distribution macht solch einen SCheiss?
>
> SuSE 12.1:
> lrwxrwxrwx 1 root root 17 27. Jan 14:58 /etc/mtab -> /proc/self/mounts
>
--
Herzliche Grüße!
Rolf Muth
Meine Adressen duerfen nicht fuer Werbung verwendet werden!
PGP Public Key:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xF8DC41935544C89A
fingerprint: C025 3071 8E56 F8F1 250A 5624 F8DC 4193 5544 C89A
Reinhard Tchorz
May 11, 2012, 7:49:39 AM5/11/12
to
Am 11.05.2012 12:01, schrieb Rolf Muth:
> Boris Kirkorowicz wrote:
>
>> Hallo,
>>
>> Am 26.04.2012 05:33, schrieb Juergen P. Meier:
>>>> | lrwxrwxrwx 1 root root 12 Dez 3 2008 /etc/mtab -> /proc/mounts
>>>
>>> Welche kaputte Linsux-Distribution macht solch einen SCheiss?
>>
>> SuSE 12.1:
>> lrwxrwxrwx 1 root root 17 27. Jan 14:58 /etc/mtab -> /proc/self/mounts
>>
> War bei meiner SUSE LINUX 10.1 auch schon so.
Ja, und mit systemd als Init-System ist das sogar ein Muss.
> Boris Kirkorowicz wrote:
>
>> Hallo,
>>
>> Am 26.04.2012 05:33, schrieb Juergen P. Meier:
>>>> | lrwxrwxrwx 1 root root 12 Dez 3 2008 /etc/mtab -> /proc/mounts
>>>
>>> Welche kaputte Linsux-Distribution macht solch einen SCheiss?
>>
>> SuSE 12.1:
>> lrwxrwxrwx 1 root root 17 27. Jan 14:58 /etc/mtab -> /proc/self/mounts
>>
> War bei meiner SUSE LINUX 10.1 auch schon so.
MfG Reinhard
--
Gentoo Kernel 3.2.12 X-Server 1.11.2 KDE 4.8.1
Asus M2A-VM AMD Athlon X2 4450e Nvidia 7300LE
Thomas Rachel
May 11, 2012, 9:00:21 AM5/11/12
to
Am 10.05.2012 10:47 schrieb Werner Flamme:
> Welche Systemwerkezeuge fallen bei openSUSE denn auf die Fresse - denn
> wie Boris schon zeigte, wird dort standardmäßig versymlinkt?
Derzeit wohl keines.
> Welche Systemwerkezeuge fallen bei openSUSE denn auf die Fresse - denn
> wie Boris schon zeigte, wird dort standardmäßig versymlinkt?
Früher war es so, daß etwa ein automatischer Loop-Mount dort registriert
wurde, so daß´er nach dem umount wieder aufgelöst werden konnte.
Mit ein wenig Recherche habe ich herausgefunden, daß /bin/mount nun die
Fähigkeit besitzt, diese Information in einer (offenbar seit 2.6.37
existierenden?) Struktur namens Mount-Kontext (?) zu speichern und das
Speichern in /etc/mtab daher nicht mehr erforderlich ist. (Wenn ich
jetzt nicht allzuviel durcheinandergeworfen habe.)
Ich weiß jetzt niht, ob es nicht noch andere, ähnliche Situationen gab,
wo in mtab was Spezielles reingeschrieben wurde, aber ich denke, das
könnte dann so ähnlich gelöst worden sein.
Thomas
0 new messages