[HaBo]

Serow · 02.06.10, 16:41

Hi,

durch einen Flüchtigkeitsfehler habe ich den im Subject aufgeführten Befehl ausgeführt. Ich denke das gröbste hab ich schon wieder gefixt, aber wie kann ich sicher gehen? Gibt es eine Möglichkeit irgendwie alle Files mit den entsprechenden DEB Packet Infos abzugleichen und am besten noch automatisch zu korrigieren?

cu
serow

**xeno** · 02.06.10, 16:44

Zitat:

Zitat von Serow

Hi,
Gibt es eine Möglichkeit irgendwie alle Files mit den entsprechenden DEB Packet Infos abzugleichen und am besten noch automatisch zu korrigieren?

Nein, da teilweise auch Berechtigungen durch post-install-scripte gesetzt werden. Die Berechtigungen im Paket selber sind also nicht immer so wie sie später im System sind.

Ich würde sagen wenn du das als root ausgeführt hast, dann ist das wirklich übel

. Im Ernstfall das System beobachten (/var/log/* brav lesen) und die letzten Reste von Hand fixen.

Anzeige

- Anzeige -

Serow · 02.06.10, 16:48

Hi,

was soll ich denn in den Logs suchen? Hab da noch nie was bzgl File Permissions gesehn

Also dürfte ne Neuinstallation das beste sein oder?

cu
serow

**bitmuncher** · 02.06.10, 16:53

Theoretisch sollte es reichen alle Pakete nochmal mit force-Option zu reinstallieren. Welche Pakete installiert sind, kann man ja mit 'dpkg -l' ermitteln und den Output dann so weiterverarbeiten, dass sich die Reinstallation eigentlich in einem 1-Zeiler lösen lassen sollte.

Serow · 02.06.10, 16:59

Hi,

hab das mal vosichtig mit 1 Packet probiert:

Code:

ironman:~# apt-get install --reinstall nfs-kernel-server
Reading package lists... Done
Building dependency tree
Reading state information... Done
0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 0 not upgraded.
Need to get 0B/162kB of archives.
After this operation, 0B of additional disk space will be used.
Do you want to continue [Y/n]? Y
(Reading database ... 55560 files and directories currently installed.)
Preparing to replace nfs-kernel-server 1:1.1.2-6lenny1 (using .../nfs-kernel-server_1%3a1.1.2-6lenny1_amd64.deb) ...
Unpacking replacement nfs-kernel-server ...
Processing triggers for man-db ...
fopen: Permission denied
fopen: Permission denied
fopen: Permission denied
fopen: Permission denied
fopen: Permission denied
fopen: Permission denied
fopen: Permission denied
fopen: Permission denied
fopen: Permission denied
fopen: Permission denied
fopen: Permission denied
fopen: Permission denied
fopen: Permission denied
fopen: Permission denied
fopen: Permission denied
fopen: Permission denied
fopen: Permission denied
fopen: Permission denied
fopen: Permission denied
fopen: Permission denied
fopen: Permission denied
fopen: Permission denied
fopen: Permission denied
fopen: Permission denied
fopen: Permission denied
fopen: Permission denied
fopen: Permission denied
Setting up nfs-kernel-server (1:1.1.2-6lenny1) ...
Stopping NFS kernel daemon: mountd nfsd.
Unexporting directories for NFS kernel daemon....
Exporting directories for NFS kernel daemon....
Starting NFS kernel daemon: nfsd mountd.
ironman:~#

Ich hab zwar keine Ahnung von Programmierung unter Linux aber fopen war doch ein System Call oder? Klingt nicht gut dieses Permission denied ^^

cu
serow

**bitmuncher** · 02.06.10, 17:00

Offenbar konnten die Manpages nicht generiert werden, da vermutlich die Rechte dafür irgendwo nicht stimmen.

Serow · 02.06.10, 17:31

Hi,

man-db war das Packet. Ich hab jetzt mit

Code:

for i in `dpkg -l | awk '{print $2}'` do
apt-get install --reinstall -y $i
done

das ganze angestoßen. Nachdem man-db installiert wurde tauchte der Fehler nicht mehr auf.

Danke für die Hilfe!

cu
serow

Serow · 02.06.10, 20:01

Hmm Misst, scheinbar ist das fopen Problem doch nicht weg. Er hat jetzt alle Packete drüber installiert. Wie kann ich jetzt rausfinden warum das immernoch kommt?

cu
serow

**bitmuncher** · 02.06.10, 21:33

Führe mal 'mandb' manuell aus. Ich vermute mal, dass das Anlegen eines neuen Manpage-Indexes dem ganzen schon Abhilfe verschaffen könnte, da es immer ausgelöst wird, wenn Manpages generiert werden sollen. Ggf. wird durch einen defekten Manpages-Index versucht auf Dateien zuzugreifen, die nicht existieren. Stelle ausserdem sicher, dass die Manpage-Dateien alle root gehören und global lesbar sind.

Serow · 02.06.10, 21:55

Hi,

hab ich gerade gemacht. Permissions in /usr/share/man sind alle rw-r--r--. Das Problem besteht weiterhin...

cu
serow

**bitmuncher** · 02.06.10, 22:04

Hm, schade.

Dann nimm dir mal irgendein Paket aus deinem Apt-Cache, das diesen Fehler triggert (also z.B. nfs-kernel-server) und schau mal, ob das Problem beim 'dpkg -i paketdatei' auch auftritt. Wenn ja, kannst du ein 'strace' davor setzen und schauen welche Dateien da durch fopen geöffnet werden sollen.

Serow · 03.06.10, 13:51

Hi,

hier der strace Output reduziert auf Zeilen die mit "open" beginnen:

Code:

open("/etc/ld.so.cache", O_RDONLY)      = 3
open("/lib/libpthread.so.0", O_RDONLY)  = 3
open("/lib/libc.so.6", O_RDONLY)        = 3
open("/etc/selinux/config", O_RDONLY)   = -1 ENOENT (No such file or directory)
open("/proc/mounts", O_RDONLY)          = 3
open("/usr/lib/locale/locale-archive", O_RDONLY) = 3
open("/etc/dpkg/dpkg.cfg", O_RDONLY)    = 3
open("/home/mathias/.dpkg.cfg", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/var/lib/dpkg/lock", O_RDWR|O_CREAT|O_TRUNC, 0660) = 3
open("/usr/share/locale/locale.alias", O_RDONLY) = 4
open("/usr/share/locale/en_US.UTF-8/LC_MESSAGES/dpkg.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/en_US.utf8/LC_MESSAGES/dpkg.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/en_US/LC_MESSAGES/dpkg.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/en.UTF-8/LC_MESSAGES/dpkg.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/en.utf8/LC_MESSAGES/dpkg.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/en/LC_MESSAGES/dpkg.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/var/lib/dpkg/status", O_RDONLY)  = 4
open("/usr/lib/gconv/gconv-modules.cache", O_RDONLY) = 5
open("/var/lib/dpkg/updates/", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 4
open("/var/lib/dpkg/updates/0000", O_RDONLY) = 4
open("/var/lib/dpkg/updates/0001", O_RDONLY) = 4
open("/var/lib/dpkg/updates/0002", O_RDONLY) = 4
open("/var/lib/dpkg/updates/0003", O_RDONLY) = 4
open("/var/lib/dpkg/updates/0004", O_RDONLY) = 4
open("/var/lib/dpkg/updates/0005", O_RDONLY) = 4
open("/var/lib/dpkg/updates/0006", O_RDONLY) = 4
open("/var/lib/dpkg/updates/0007", O_RDONLY) = 4
open("/var/lib/dpkg/updates/0008", O_RDONLY) = 4
open("/var/lib/dpkg/updates/0009", O_RDONLY) = 4
open("/var/lib/dpkg/updates/0010", O_RDONLY) = 4
open("/var/lib/dpkg/status-new", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 4
open("/var/lib/dpkg/available", O_RDONLY) = 4
open("/var/lib/dpkg/updates/tmp.i", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 4
...

Kann ich anhand dieser Zeilen erkennen ob das open funktioniert hat? Wenn ja wie? Das sind irgendwas um die 10 Seiten Output

cu
serow

**bitmuncher** · 03.06.10, 13:58

Code:

open("/usr/share/locale/en_US.UTF-8/LC_MESSAGES/dpkg.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/en_US.utf8/LC_MESSAGES/dpkg.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/en_US/LC_MESSAGES/dpkg.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/en.UTF-8/LC_MESSAGES/dpkg.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/en.utf8/LC_MESSAGES/dpkg.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/en/LC_MESSAGES/dpkg.mo", O_RDONLY) = -1 ENOENT (No such file or directory)

Ich würde mal sagen, dass es diese Dateien sind, die Probleme machen. Wurde evtl. das dpkg-Paket nicht neu installiert?

**Chromatin** · 03.06.10, 14:29

Zitat:

chmod -R 777 /

In diesem Fall betrifft das ja nicht nur die Pakete.
Mit einer Neuinstallation bist du wesentlich besser bedient.

Btw. Ich habe auf einigen wirklich heiklen Maschinen solche Befehle durch Scripte ersetzt, die in genau so einem Fall meckern

Serow · 03.06.10, 14:34

Hi,

das Verzeichnis /usr/share/locale/ existiert noch, ab da gibts aber keine Übereinstimmung mehr mit diesen Pfaden. Das dpkg Package hab ich nochmal drübergebügelt, aber auch das hat den fopen Fehler gezeigt. Danach auch keine Besserung. Die Dateien existieren nachwievor nicht.

Zu welchem Packet gehören denn diese en_US.* Verzeichnisse?

cu
serow

Anzeige

- Anzeige -

02.06.10, 16:41	#1 (permalink)
Serow Senior Member Registriert seit: 26.03.06 Likes: 16	chmod -R 777 / Anzeige Hi, durch einen Flüchtigkeitsfehler habe ich den im Subject aufgeführten Befehl ausgeführt. Ich denke das gröbste hab ich schon wieder gefixt, aber wie kann ich sicher gehen? Gibt es eine Möglichkeit irgendwie alle Files mit den entsprechenden DEB Packet Infos abzugleichen und am besten noch automatisch zu korrigieren? cu serow

02.06.10, 16:53	#4 (permalink)
bitmuncher Moderator Registriert seit: 30.09.06 Likes: 441	Theoretisch sollte es reichen alle Pakete nochmal mit force-Option zu reinstallieren. Welche Pakete installiert sind, kann man ja mit 'dpkg -l' ermitteln und den Output dann so weiterverarbeiten, dass sich die Reinstallation eigentlich in einem 1-Zeiler lösen lassen sollte. __________________ Mein Blog - Mein Job - Diaspora Der Ring uns zu knechten besteht aus 12 Sternen auf blauem Grund. Neue Beiträge im Habo via Twitter - Das HaBo auf FB - Das HaBo bei G+

02.06.10, 17:00	#6 (permalink)
bitmuncher Moderator Registriert seit: 30.09.06 Likes: 441	Offenbar konnten die Manpages nicht generiert werden, da vermutlich die Rechte dafür irgendwo nicht stimmen. __________________ Mein Blog - Mein Job - Diaspora Der Ring uns zu knechten besteht aus 12 Sternen auf blauem Grund. Neue Beiträge im Habo via Twitter - Das HaBo auf FB - Das HaBo bei G+

02.06.10, 17:31	#7 (permalink)
Serow Senior Member Themenstarter Registriert seit: 26.03.06 Likes: 16	Hi, man-db war das Packet. Ich hab jetzt mit Code: for i in `dpkg -l \| awk '{print $2}'` do apt-get install --reinstall -y $i done das ganze angestoßen. Nachdem man-db installiert wurde tauchte der Fehler nicht mehr auf. Danke für die Hilfe! cu serow

02.06.10, 21:33	#9 (permalink)
bitmuncher Moderator Registriert seit: 30.09.06 Likes: 441	Führe mal 'mandb' manuell aus. Ich vermute mal, dass das Anlegen eines neuen Manpage-Indexes dem ganzen schon Abhilfe verschaffen könnte, da es immer ausgelöst wird, wenn Manpages generiert werden sollen. Ggf. wird durch einen defekten Manpages-Index versucht auf Dateien zuzugreifen, die nicht existieren. Stelle ausserdem sicher, dass die Manpage-Dateien alle root gehören und global lesbar sind. __________________ Mein Blog - Mein Job - Diaspora Der Ring uns zu knechten besteht aus 12 Sternen auf blauem Grund. Neue Beiträge im Habo via Twitter - Das HaBo auf FB - Das HaBo bei G+

02.06.10, 16:48	#3 (permalink)
Serow Senior Member Themenstarter Registriert seit: 26.03.06 Likes: 16	Hi, was soll ich denn in den Logs suchen? Hab da noch nie was bzgl File Permissions gesehn Also dürfte ne Neuinstallation das beste sein oder? cu serow

02.06.10, 20:01	#8 (permalink)
Serow Senior Member Themenstarter Registriert seit: 26.03.06 Likes: 16	Hmm Misst, scheinbar ist das fopen Problem doch nicht weg. Er hat jetzt alle Packete drüber installiert. Wie kann ich jetzt rausfinden warum das immernoch kommt? cu serow

02.06.10, 21:55	#10 (permalink)
Serow Senior Member Themenstarter Registriert seit: 26.03.06 Likes: 16	Hi, hab ich gerade gemacht. Permissions in /usr/share/man sind alle rw-r--r--. Das Problem besteht weiterhin... cu serow

02.06.10, 22:04	#11 (permalink)
bitmuncher Moderator Registriert seit: 30.09.06 Likes: 441	Hm, schade. Dann nimm dir mal irgendein Paket aus deinem Apt-Cache, das diesen Fehler triggert (also z.B. nfs-kernel-server) und schau mal, ob das Problem beim 'dpkg -i paketdatei' auch auftritt. Wenn ja, kannst du ein 'strace' davor setzen und schauen welche Dateien da durch fopen geöffnet werden sollen. __________________ Mein Blog - Mein Job - Diaspora Der Ring uns zu knechten besteht aus 12 Sternen auf blauem Grund. Neue Beiträge im Habo via Twitter - Das HaBo auf FB - Das HaBo bei G+

03.06.10, 14:34	#15 (permalink)
Serow Senior Member Themenstarter Registriert seit: 26.03.06 Likes: 16	Hi, das Verzeichnis /usr/share/locale/ existiert noch, ab da gibts aber keine Übereinstimmung mehr mit diesen Pfaden. Das dpkg Package hab ich nochmal drübergebügelt, aber auch das hat den fopen Fehler gezeigt. Danach auch keine Besserung. Die Dateien existieren nachwievor nicht. Zu welchem Packet gehören denn diese en_US.* Verzeichnisse? cu serow

Themen-Optionen
Druckbare Version zeigen Jemanden per E-Mail auf dieses Thema hinweisen
Ansicht
Linear-Darstellung Zur Hybrid-Darstellung wechseln Zur Baum-Darstellung wechseln

[HaBo]

chmod -R 777 /