Ich habe den Post erst nach dem Update gelesen. Beim Update habe ich einfach die Verlinkung nach /etc/mtab_bkp verschoben. Die Verlinkung wurde beim Update aber wieder erstellt. Könnte das jetzt zu Problemen führen?
deadshox schriebIch habe den Post erst nach dem Update gelesen. Beim Update habe ich einfach die Verlinkung nach /etc/mtab_bkp verschoben. Die Verlinkung wurde beim Update aber wieder erstellt. Könnte das jetzt zu Problemen führen?
Seltsam, sollte das nicht eigentlich unmöglich sein? Ich hatte das auch versucht, allerdings funktionierte Pacman im Anschluß nicht mehr, weshalb ich das Backup der Datei wieder hergestellt hatte und dann mit pacman -Sfu das Update erzwungen habe.

Keine Probleme bisher.
Dieb /etc/mtab ist eine dynamische, variable Datei in der die *aktuellen* Mounts drinstehen (mtab = Mount Tabelle). mount aktualisiert diese Datei (+ ggf. Kernel/Userland/fuse-Module).

Bisher war das eine reguläre Datei, die dazu noch zu keinem Archlinux-Paket gehörte (sie wird ja dynamisch erzeugt). Das erforderte aber auch einen schreibenden Zugriff auf /etc, was oftmals unerwünscht ist. Außerdem macht die verwendung einer regulären Datei Probleme auf z.B. VServern, chroot, fast alles paravirtualiserte etc.

Das neue filesystem führt nun eine Verlinkung nach /proc/self/mounts ein, was genau die gleichen Informationen enthält (mount tabelle). Aber eben auf einem anderen Filesystem (proc eben). Sofern muß zumindest durch Vorgänge der programme in initscripts nicht mehr auf /etc (somit das Root-FS) schreibend zugegriffen werden. Und die Datei/der Symlink /etc/mtab gehört hnun zum initscript //Edit: filesystem Paket.

Es ist alles ok wenn:
a) /etc/mtab als Symlink auf /proc/self/mounts zeigt
b) pacman -Qo /etc/mtab das filesystem Paket anzeigt. 
gerhard@ws01 ~ % ls -l /etc/mtab
lrwxrwxrwx 1 root root 17 19. Dez 18:44 /etc/mtab -> /proc/self/mounts
gerhard@ws01 ~ % pacman -Qo /etc/mtab
/etc/mtab ist in filesystem 2011.12-2 enthalten
@Thorsten: pacman -Sfu ist eine ganz blöde Idee, deshalb schreibt die News ja auch: pacman -S filesystem --force.

//Edit: der Vorgang des Prozederes:
a) pacman -Syu (das führt zur Fehlermeldung: filesystem: /etc/mtab existiert im Dateisystem etc.
b) Obige News lesen und verstehen <g>
c) pacman -S filesystem --force
d) pacman -Su (reguläres Update fortsetzen)
//Edit2:
e) Reboot und den Erfolg in diesem Thread https://forum.archlinux.de/viewtopic.php?id=17939 vermerken ;-)
GerBra schrieb @Thorsten: pacman -Sfu ist eine ganz blöde Idee, deshalb schreibt die News ja auch: pacman -S filesystem --force.
Nur aus Interesse (ich will ja nicht dumm sterben): warum, bzw. wo ist der Unterschied?
Weil -Sfu alle Pakete mit der force Option aktualisieren wird. Das kann gut gehen, dir aber auch Dateien löschen, die du gerne behalten würdest.
pacman -S filesystem --force updatet NUR das Paket filesystem.
-Sfu ezwingt ein --force auf *alle* zum Update anstehenden Pakete (was je nach Paketquelle unnötig und gefährlich sein kann).

-S paketname --force erzwingt hingegen nur für das eine Paket ein Abschalten der Integritätsüberprüfung.

(Beispiel: Ein anderes Paket hat z.B. /bin/mount mit Schadcode drin. Mit -Sfu würde jetzt dieses fehelrhafte /bin/mount (mount gehört eigentlich zum Paket util-linux) ohne Prüfung unter bestimmten Bedingungen ersetzt werden.)

//Edit Kurz: wenn ein --force notwendig sein sollte ist das ein DEUTLICHES Anzeichen das etwas mit der Paketverwaltung nicht stimmt. Das "Problem" dann durch die Holzhammermethode beseitigen zu wollen ist ähnlich wie z.B. wenn man Kratzspuren am Fenster entdeckt - dann öffnet man ja auch nicht noch die haustür <g>
Deswegen gibt es ja die News, die explizit ein bestimmtes Vorgehen anraten.
Ah, danke für die Erklärung. Dann war es in meinem Fall ja nicht schlimm, filesystems war das einzige Update. Aber für die Zukunft gut zu wissen.
Thorsten Reinbold schriebIch hatte das auch versucht, allerdings funktionierte Pacman im Anschluß nicht mehr
archlinux.org schrieb It is strongly advised to avoid the --force or -f switch as it is not safe. However, in this particular case it is needed as deleting /etc/mtab manually would break pacman.
das 
deleting /etc/mtab manually would break pacman
ist bei der übersetzung untergegangen
Danke für die Info GerBra. 🙂
deadshox schriebDanke für die Info GerBra. 🙂
Und den anderen natürlich auch, die halfen!

Noch etwas "Hintergrund" (da ich grad Zeit+Lust habe)...
Am Speicherort einer Datei kann man auf unixoiden Systemen ja meist die "Aufgabe" schon erkennen (/etc, /bin, /usr, ...).
Von der Art gehört /etc/mtab eigentlich nach /var, da diese ja eben variable, sich ändernde Inhalte enthält.

Die mtab ist weder etwas Archlinux-spezifisches, noch Linux-spezifisches. Es war früher die (AFAIK einzige) Möglichkeit zum Auslesen: welche Dateisysteme sind wie wohin eingehängt. (/proc hatte diese Info früher AFAIK noch nicht verfügbar).
Da beim Bootvorgang recht früh ein Zugriff (rw) auf eben diese Datei nötig ist fiel der Ablageort /var weg, da /var oder /usr ja in vielen Umgebungen erst viel später separat eingehängt werden. Deshalb mußte diese Datei ins Root-FS (eben nach /etc).

Als /proc auch die Infos über aktuelle Mounts mitbrachte gab es eine Redudanz an Daten (beides zeigten die gemounteten dateisysteme an, /proc/self/mounts allerdings mit mehr Infos und oftmals auch zuverlässiger da /proc "näher am Kernel dran ist" als eine reguläre Datei...
Es ist also sinnvoll das "Relikt" /etc/mtab auf den aktuellen Zustand zu ändern, etcliche andere Distributionen haben das sicher schon.

Beim chroot ist der eine odere andere evtl. (z.B. ggf. bei mkinitcpio oder grub install) auf die möglichen Probleme gestoßen:
im (chroot)/etc/mtab (reguläre Datei!) standen noch die Infos vom letzten, regulären Boot drin. Diese deckten sich dann nichtmehr mit dem aktuellen Zustand (Boot über externes medium, Blockdevice mit Root-FS für chroot eingehängt auf /mnt) und führten zu Problemen. Deshalb mußte man fürs chroot oft /etc/mtab ebenfalls nach z.B. /mnt/etc/mtab kopieren oder halt gleich anch /proc/self/mounts verlinken. Dieser Stolperstein fällt nun weg (sofern /proc als Bindmount ins chroot-System eingebunden ist...)

Ebenfalls kann zukünftig eher / (inkl. /etc) regulär read-only gemountet werden, was der Sicherheit dienen kann. Read/Write müßte es dann nur noch für Updates/Konfiguration re-mountet werden. Das wäre der Idealfall....

//Edit: Und /proc nun als Ablageort für diese Info ist eigentlich ideal, da /proc ja über "virtuelle Dateien"(unter Linux ist "alles" eine Datei) ja genau den *aktuellen* Zustand des Systems abbildet - zum Auslesen und ggf. auch Verändern.
Durch die Einführung von /sys (und sysfs) geht ja seit einiger Zeit eine Änderung vor sich um eben Systemrelevantes mehr ins - ebenfalls virtuelle - sysfs abzubilden. Sowas wie die Mounts wird irgendwann wohl auch eher in /sys zu finden sein, wohingegen /proc (wieder) eher nur den Zustand der Prozesse abbilden wird.

//Edit2: (Muß mich das ganze Gelabber von mir jetzt interessieren wenn ich *einfach nur Sudoku spielen* will ?) SCNR ;-)
GerBra schrieb //Edit2: (Muß mich das ganze Gelabber von mir jetzt interessieren wenn ich *einfach nur Sudoku spielen* will ?) SCNR ;-)
Auf jeden Fall sind das interessante Infos, die dem Verständnis der Architektur dienen und evtl. auch bei anderen Problemen hilfreich sein könnten.

Vielen Dank jedenfalls für die sogar für mich gut verständliche Abhandlung. 🙂
Vielen Dank für die Info, kaum die Fehlermeldung gekriegt, schon hier die Antwort gefunden -- Archlinux ist Spitze
Falls noch jemand nfs benutzt und mit den neuen Filesystem ein Problem hat: Der Pfad des nfs device (e.g. server:/home/user/) in der fstab muss jetzt zwingend mit / enden, sonst ist ein unmounten mit user rechten nicht mehr möglich.
GerBra schrieb //Edit2: (Muß mich das ganze Gelabber von mir jetzt interessieren wenn ich *einfach nur Sudoku spielen* will ?) SCNR ;-)
Gnome-Sudoku geht nach Python-Update immer noch nicht^^ *scnr*

Ansonsten vielen dank für diesen Thread!



Gruß
Jochen
ich habe das mit dem filesystem erst später gelesen und die /etc/mtab umbenannt. Bisher hat das keine Schwierigkeiten gemacht, und pacman macht weiter Updates.
Ich habe jetzt eine mtab-old, einen mtab Link nach /proc/self/mounts und eine mtab.fuselock.
Die mtab-old kannst du unbesorgt rausschmeißen.
Kinch schriebFalls noch jemand nfs benutzt und mit den neuen Filesystem ein Problem hat: Der Pfad des nfs device (e.g. server:/home/user/) in der fstab muss jetzt zwingend mit / enden, sonst ist ein unmounten mit user rechten nicht mehr möglich.

Danke.
5 Tage später
Hallo Zusammen!

Ich hab die News mal leider zu spät gelesen und die /etc/mtab einfach gelöscht. Das Update lief dann ohne zu murren durch.
Funktioniert auch alles wie gehabt.
In den News wird aber dringend davon abgeraten die Datei zu löschen. Hab ich jetzt ein Problem????

Viele Grüße und einen Guten Rutsch!

Ingo
Böbbele schrieb Funktioniert auch alles wie gehabt.
Böbbele schrieb Hab ich jetzt ein Problem????
Definitiv. Ein System das einfach funktioniert ist ja tot langweilig *scnr*