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*
Soweit ich mitbekommen habe ist das einzige Problem durch händisch gelöschtes /etc/mtab ggf. pacman, wenn dort die Option zur Speicherplatzprüfung eingeschaltet ist. paman zieht AFAIK für die vorhandenen Mounts eben /etc/mtab zu Rate, und wenn man diese dann quasi "unter dem Hintern wegzieht" macht pacman das anschließende Update nicht weiter.
Ansonsten kann es ggf. mit allen Tools ein kurzfristiges Problem geben, die ihre Infos zu Mounts eben aus /etc/mtab ziehen.

Bei VServern ist mir noch ein Problem durch --force aufgefallen:
Wenn dort die /etc/fstab nicht groß angepaßt ist, dann wird diese durch --force mit der aus dem Paket filesystem überschrieben. In der aktuellen Version wird allerdings /dev/pts nicht mehr per fstab sondern in der rc.sysinit gemountet. Auf VServern wird oft allerdings eine angepaßte Version der initscripts verwendet wo dieses Mounten von /dev/pts eben nicht früh erfolgt.
Ich hatte mich so z.B. von ssh-Logins "ausgesperrt", da ohne devpts-FS keine Terminals... <g>. Allerdings kann man das mittels ssh beheben, indem man z.B. /dev/pts per ssh-Befehl (braucht kein terminal) mountet oder den Eintrag an die fstab ebenfalls per ssh-Befehl wieder anhängt und dann erneut mountet/bootet.
Die sauberste Lösung ist dann allerdings das Anpassen der rc.sysinit-Skripts auf den VServern...
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.
Was auch nicht mehr zu gehen scheint: Als User eine auf Rootebene gemountete NFS-Freigabe zu unmounten. 
#/etc/fstab
server:/share/ /share nfs4 noauto,user,rw 0 0

$ mount /share/
$ umount /share/
umount.nfs4: /share: not found
umount.nfs4: /share: not found
Als root funktioniert derselbe umount-Befehl. Nur mit z.B. /mnt/share statt /share als Mountverzeichnis geht es auch als User.
Was mich beim neuen filesystem etwas stört, ist, dass bind-mounts nicht mehr so leicht ausfindig zu machen sind, die Ausgabe von mount ist da etwas verwirrend... 
/dev/sda3 on /hdd type ext4 (rw,relatime,user_xattr,acl,barrier=1,data=ordered)
/dev/sda3 on /exports/share type ext4 (rw,relatime,user_xattr,acl,barrier=1,data=ordered)
/dev/sda3 on /srv/ftp type ext4 (rw,relatime,user_xattr,acl,barrier=1,data=ordered)
/dev/sda3 on /var/abs type ext4 (rw,relatime,user_xattr,acl,barrier=1,data=ordered)
/dev/sda3 on /var/cache/pacman/pkg type ext4 (rw,relatime,user_xattr,acl,barrier=1,data=ordered)
4 Tage später
Danke für die Info, hat bei mir auch geklappt!
Habe eine Fehlermeldung bzw. der Berechtigungen bekommen:
sudo pacman -S filesystem --force
Löse Abhängigkeiten auf...
Suche nach Zwischenkonflikten...

Pakete (1): filesystem-2011.12-2

Gesamtgröße des Downloads: 0.00 MB
Gesamtgröße der zu installierenden Pakete: 0.06 MB

Installation fortsetzen? [J/n] j
(1/1) Überprüfe Paket-Integrität [######################] 100%
(1/1) Aktualisiere filesystem [######################] 100%
Warnung: Verzeichnis-Berechtigungen unterscheiden sich für home/
Dateisystem: 777 Paket: 755
Warnung: Verzeichnis-Berechtigungen unterscheiden sich für root/
Dateisystem: 700 Paket: 750
Das sind keine Fehler, sondern Warnungen (steht auch da).
Du hast nicht mal eine ungefähre Ahnung um was es dabei geht? (Erstgemeinte Frage)

//Edit: Die Berechtigung für /home solltest du dringendst korrigieren....
Edit2: Außer /home wäre ein Symlink auf irgendwas, bin mir nicht sicher ob pacman Symlinks beim Prüfen berücksichtigt...
Hallo GerBra

Eine grobe Ahnung habe ich:
home/
Dateisystem: 777 bedeutet, dass jeder alles darf, bin mir aber nicht sicher, ob ich jetzt /home oder auch für alle Unterverzeichnisse ändern muss, geschweige denn wie: 700 wäre glaube ich gut für /home, oder? Dann hätte nur ich Rechte. Oder sehe ich das falsch?
root/
Dateisystem: 700 sollte also gut sein

r = 4
w = 2
x = 1
r hat den Wert 4, w hat den Wert 2 und x hat den Wert 1.

Damit kannst Du alle Kombinationen aus r, w und x als eine Zahl zwischen 0 und 7 ausdrücken:

--- 0
--x 1
-w- 2
-wx 3 ( = 2 + 1 )
r-- 4
r-x 5 ( = 4 + 1 )
rw- 6 ( = 4 + 2 )
rwx 7 ( = 4 + 2 + 1)

rwx|rwx|rwx
Besitzer|Gruppe|Rest der Welt

aus http://nafoku.de/t/unix.htm
chmod 0755 /home
sollte genügen. Du kannst ja mit:
ls -l /home
auch nochmal deine Userzerzeichnisse in /home anschauen, diese sollten (wenn am lokalen Setup nichts dagegenspricht) jeweils 0700 sein, also absolut auf den Eigentümer beschränkt.

0777 für /home mußt du irgendwann mal gesetzt haben (zumindest passiert das nicht durch normale Installation+pacman).

Für /root hast du ja noch eine restriktivere Einstellung als das paket(filesystem) er vorsieht, ist also ok so.

Hintergrund der Warnung: Wenn pacman im Zuge der Installation auch Verzeichnisse erstellt (//Edit: was meist durch pures Entpacken des pkg.tar.bz geschiet), dann wird geprüft ob die rechte-Flags im Paket sich von einem evtl. schon vorhandenen Verzeichniss unterscheidet. Wenn ja, wird die Warnung ausgegeben. I.d.R. nimmt man das zur Notiz, schaut sich die Paket-Flags und die angezeigte Realen an und sieht recht schnell ob man besser was ändert.

Einzig wenn bei dir evtl. /home ein Symlink wäre (du hättest den Inhalt von /home z.B. auf eine andere Partition/Platte ausgelagert und verlinkt statt zu mounten, dann wären die rechte-Flags 777 nachvollziehbar. Aber wenn du so ein Setup hättest wüßtest du das ja sicher....

//Edit2:
mumpf schrieb 700 wäre glaube ich gut für /home, oder? Dann hätte nur ich Rechte. Oder sehe ich das falsch?
Das wäre nicht gut, da du damit höchstwahrscheinlich deine user(dich) von deinem $HOME ausperren würdest. Die Flags stehen immer im Zusammenhang mit der Eigentümerschaft(also UserId und GroupId), da darauf die Flaggruppen u und g abzielen. 0700 root.root hätte also nur noch root die Möglichkeit überhaupt ins Verzeichniss zu wechseln.
0755 ist der default und sinnvoll wenn - wie gesagt - die einzelnen userverzeichnisse dann 0700 haben.
Je nachdem wie User auf dem System verwaltet werden und wer ggf. alles draufzugreifen kann wäre auch root.root 0751 noch eine Möglichkeit für /home, da so außer root/root-gruppe niemand durch ein ls auf /home die vorhandenen usernamen rauskriegen kann (50% Vorraussetzung für ein nicht gewolltest Fremdlogin <g>). Macht natürlich keinen Sinn wenn die usernamen auch durch Lesen der /etc/passwd rauszukriegen sind... Aber das sind schon Spezialfälle, zeigt vielleicht sich etwas mit den Eigentümer/Rechteflags zu befassen (in /tmp z.B. kann man ja "üben"...)

Mit stat kannst du dir schnell einen Überblick verschaffen über Rechte und Art des verzeichniss/Files, z.B.
stat /home
Hallo GerBra

Vielen Dank für Deine ausführliche Antwort, obwohl ja fast schon off-topic; habe die Rechte entsprechend angepasst.

Gruss
mumpf
25 Tage später
Hallo,

bei einem pacman -S filesystem --force ergaben sich bei mir folgende Fehlermeldungen:
/usr/bin/libusb-config exists in filesystem
/usr/include/usb.h exists in filesystem
/usr/lib/libusb-0.1.so.4 exists in filesystem
/usr/lib/libusb-0.1.so.4.4.4 exists in filesystem
/usr/lib/libusb.a exists in filesystem
/usr/lib/libusb.so exists in filesystem
/usr/lib//pkgconfig/libusb.pc exists in filesystem
Hat jemand ähnliche Erfahrungen gemacht?
2 Monate später
ich habe eine ähnliches Problem. Nach einer Installation des ARCH Systems(Archbang) in einer VM wollte ich eine komplette System Aktualisierung mittels 
pacman -Syu
beginnen.
Als Fehlermeldung bekomme ich allerdings immer :
:: Synchronizing package databases...
 core is up to date
 extra is up to date
 community is up to date
:: The following packages should be upgraded first :
    pacman
:: Do you want to cancel the current operation
:: and upgrade these packages now? [Y/n] Y

resolving dependencies...
looking for inter-conflicts...

Targets (11): linux-api-headers-3.3-1 [0.58 MB]  glibc-2.15-10 [7.33 MB]
              libarchive-3.0.4-1 [0.62 MB]  pth-2.0.7-4 [0.07 MB]
              libksba-1.2.0-1 [0.11 MB]  libassuan-2.0.3-1 [0.08 MB]
              pinentry-0.8.1-3 [0.09 MB]  dirmngr-1.1.0-3 [0.16 MB]
              gnupg-2.0.19-1 [1.39 MB]  gpgme-1.3.1-4 [0.20 MB]
              pacman-4.0.2-1 [1.00 MB]

Total Download Size:    0.00 MB
Total Installed Size:   52.86 MB

Proceed with installation? [Y/n] Y
(11/11) checking package integrity                 [----------------------] 100%
(11/11) checking for file conflicts                [----------------------] 100%
error: failed to commit transaction (conflicting files)
glibc: /usr/bin/tzselect exists in filesystem
glibc: /usr/sbin/zdump exists in filesystem
glibc: /usr/sbin/zic exists in filesystem
Errors occurred, no packages were upgraded.


Pacman lässt sich aber auch nicht separat aktualiseren.
Mittels pacman -S pacman kann ich pacman nicht upgraden.

Woran könnte dies liegen ?
Das zu aktualisierende pacman Paket benötigt zwingend das ebenfalls zu aktualisierende glibc Paket.
glibc macht dir aber nun Ärger, da es dateien im Paket mitbringt die auf deinem System schon vorhanden sind aber bisher nicht zum alten glibc paket gehörten.
Du solltest mit pacman -Qo /usr/bin/tzselect prüfen, zu welchem paket (wenn üebrhaupt) diese 3 Files gehören.

Hier unter Archlinux gehören die zum Paket tzdata. Bei Archlinux gibt es zum obigen glibc Update aber auch ein neues tzdata, bei dem diese obigen Konflikte gelöst sind... (//Edit: bestimmte Binaries sind vom tzdata Paket nun ins glibc Paket gewandert...)
Also entweder bei Archbang warten bis die nachziehen oder halt dort nachfragen oder bugreport schreiben... Evtl. reicht ja ein erneutes pacman -Sy schon....
Wem gehören denn die Dateien?
for i in {/usr/bin/tzselect,/usr/sbin/zdump,/usr/sbin/zic}
do
pacman -Qo ${i}
done
?
hallo GerBra ,

>Du solltest mit pacman -Qo /usr/bin/tzselect prüfen, zu welchem paket (wenn üebrhaupt) diese 3 Files gehören. 
pacman -Qo /usr/bin/tzselect
/usr/bin/tzselect is owned by tzdata 2011m-2
@ Kinch

meintest das auch so ?
hab das Archbang Gedöhns wieder runter gehauen und mir das aktuelle original Arch installiert. Das läuft wenigstens ;-).... nur die Key Authorisierung über pacman will trotz geänderten Key Server nicht laufen :-(
6 Tage später
Nemisis schriebhab das Archbang Gedöhns wieder runter gehauen und mir das aktuelle original Arch installiert. Das läuft wenigstens ;-).... nur die Key Authorisierung über pacman will trotz geänderten Key Server nicht laufen :-(
Wenn partout die Keys nicht herunter geladen werden können, kann man sie auch per 
pacman-key -r keyid
bekommen
(Wobei es mit allen Keys ein wenig umfangreich wird. Aber bei einzelnen hat es geholfen, weil pacman z.B. bei nem Key von "seblu" sofort gemeckert hat (Scheinbar ohne den Timeout zu nutzen), dass es den Key nicht bekommt (Und das mit versch. Keyservern))

Und anscheinend gibt es ja auch die Überlegung, dahingehend nen Paket anzubieten
na die Fehlermeldung die ich beim installieren schon bekommen habe ( trotz zu voriger Änderung ) war folgende:

Nach der Umstellung wollte ich gleich sudo installieren und da fing es an.

(pacman -S sudo) (1/1) Überprüfe Paket-Integrität [######################] 100%

Fehler: sudo: key F99FFE0FEAE999BD is unknow.

Fehler: key "F99FFE0FEAE999BD" could not be looked up remotely Fehler: Konnte den Vorgang nicht durchführen (Ungültiges oder beschädigtes Paket (PGP-Signatur)) Fehler sind aufgetreten, keine Pakete wurden aktualisiert.

und so verlief es mir allen anderen Programmen die ich installieren wollte.
Daraufhin habe ich die dafür verantwortlichen Dateien wieder auf default konfiguriert und mit der Standard Installation fortgesetzt.