# Aufräumen nach Sys-Rettung

## Max Steel

Leute, ich habe ein Problem…

Ich war dabei einen verdammt lange nicht-upgedateten Rechner upzudaten.

Dabei hab ich mich zwischendurch von außerhalb auf den Rechner über Handy (rel. kleines Display) per GPRS auf meinen Rechner und letztlich auf die Maschine zu verbinden.

Das klappte, dort bemerkte ich das mal wieder /var/tmp/portage überlaufen ist und gab rm -rf /var/ tmp/portage ein.

Damit nahm das Übel seinen lauf.

Egal, jedenfalls möchte ich aus verschiedenen Gründen nicht einfach das ganze System neu installieren, vorallem wegen Einstellungsspezifischen Gründen.

Jedenfall baut auf diesem System wieder erneut @system.

(mit der Hilfe durch meinen Rechner per distcc (+ Crosscompiling).)

Jetzt ist meine eigentliche Frage. Gibt es einen relativ einfachen Weg Dateien die nicht in den /var/db/pkg/*/*/CONTENTS Dateien aufgeführt sind zu löschen (lässt sich möglicherweiße qlist dafür verwenden?)?...

Natürlich außer die Daten in /home, /dev, /proc, /sys, /var, /vol1, /mnt /media und /etc (unter anderem für CONFIG_PROTECT)?

Und wie sieht dieser Weg aus?

----------

## mv

Ungetestet: 

```
find /usr /opt -depth -exec /bin/sh -c 'for i

do if ! qfile -e -- "${i}" >/dev/null 2>&1

  then echo Removing "${i}"

  #  rm -rfv --  "${i}"

  else echo Keeping "${i}"

  fi

done' sh '{}' '+'
```

/usr und /opt ggf. um weitere Directories erweitern und nach einem Testdurchlauf den Kommentar vor rm entfernen...

Edit: '!' eingefügt.

Noch'n edit: -depth und -exec (statt den vorherigen Typos). Danke an Max Steel für den Hinweis.Last edited by mv on Sat Oct 29, 2011 3:45 pm; edited 2 times in total

----------

## Max Steel

Garnicht so schlecht bisher. Was mir leider garnicht gefällt ist:

```
Keeping /usr/share/doc/libassuan-2.0.2/README

Keeping /usr/share/doc/libassuan-2.0.2/NEWS

Removing /usr/share/doc/libassuan-2.0.2/AUTHORS.bz2

Removing /usr/share/doc/libassuan-2.0.2/TODO.bz2

Removing /usr/share/doc/libassuan-2.0.2/THANKS.bz2

Removing /usr/share/doc/libassuan-2.0.2/NEWS.bz2

Keeping /usr/share/doc/libassuan-2.0.2/ChangeLog

Removing /usr/share/doc/libassuan-2.0.2/ChangeLog.bz2

Keeping /usr/share/doc/libassuan-2.0.2/THANKS

Removing /usr/share/doc/libassuan-2.0.2/README.bz2

Keeping /usr/share/doc/libassuan-2.0.2/AUTHORS

Keeping /usr/share/doc/libassuan-2.0.2/TODO

Removing /usr/share/doc/libassuan-2.0.2

Removing /usr/share/doc/

```

Auf der einen Seite behält er libassuan, auf der anderen Seite löscht er Dateien und /usr/share/doc (den Ordner hab ich gerade als einziges ausgewählt) löscht er auch... das wäre nicht so toll.

----------

## mv

Das verstehe ich nicht: Bei mir findet qfile auch "höhere" Directories, so dass diese keiner expliziten Ausnahme bedürfen. Beispiel: 

```
qfile -e -- "/usr/share/doc/" >/dev/null 2>&1; echo $?
```

 gibt bei mir 0 aus (egal ob mit oder ohne "/" am Schluss). Vielleicht verhalten sich ältere Versionen als portage-utils-0.6 anders?

----------

## Christian99

hab ich auch grad ausprobiert. ich denke das problem ist folgendes: Rückgabewert 0 = Erfolg = true in diesem fall.

deswegen gehören nur die beiden if zweige vertauscht oder die bedingung negiert.

----------

## mv

 *Christian99 wrote:*   

> deswegen gehören nur die beiden if zweige vertauscht oder die bedingung negiert.

 

Stimmt, die gehören vertauscht (habe gerade ein "!" im Script eingefügt).

----------

## Christian99

ich hab das spaßeshallber auch mal bei mir laufen lassen, um zu sehen ob noch müll rumliegt. dabei ist mir aufgefallen, dass wohl von eselect angelegte symlinks auch keinen besitzer haben. lässt sich das irgendwie filtern?

Außerdem werden eine ganze reihe *.pyc und *.pyo dateien mit gelistet, die auch keinen Besitzer haben. die dazugehörigen *.py dateien die es gibt wurden aber zur selben Zeit angelegt. Also scheinen die wohl auch von portage erzeugt worden zu sein. aber wieso gehören die dann nicht mit zum paket?

PS: sorry max, fürs thread hijacken  :Wink: 

----------

## mv

 *Christian99 wrote:*   

> ich hab das spaßeshallber auch mal bei mir laufen lassen, um zu sehen ob noch müll rumliegt. dabei ist mir aufgefallen, dass wohl von eselect angelegte symlinks auch keinen besitzer haben. lässt sich das irgendwie filtern?

 

Schwierig. Mir ist gerade eingefallen, dass es mal ein paar "findcruct"-Pakete mit einer entsprechenden Datenbank  gab. Ein solcher Thread steht hier.

 *Quote:*   

> Also scheinen die wohl auch von portage erzeugt worden zu sein. aber wieso gehören die dann nicht mit zum paket?

 

Die werden in "postinst" kompiliert.

----------

## Christian99

ok, das mit eselect hab ich mir schon gedacht, dass das problematisch wird die per Hand zu filtern.

Die andere Frage wäre aber: kann man die symlinks nicht zum paket gehören lassen? ich meine doch, die symlinks sind immer die gleichen, egal was man gerade eselected hat. wieso kann man die dann nicht zum entsprechenden paket gehören lassen? Das würde doch auch absichern, dass die von einem fehlerhaften ebuild überschrieben werden.

Ähnliche überlegung würde für .pyc und pyo dateien gelten. wieso sollen die nicht zum paket gehören? (ich hab auch gemerkt, dass einige wenige pakete .pyc dateien in ihrem CONTENTS haben...)

----------

## mv

 *Christian99 wrote:*   

> ok, das mit eselect hab ich mir schon gedacht, dass das problematisch wird die per Hand zu filtern.

 

eselect ist da bei weitem nicht das Einzige: Es gibt da etliche Kataloge (info-Files in verschiedenen Directories, font-File-Kataloge für X, der ganze docbook-Ranz), kdm erzeugt seine Config-Files semiautomatisch aus den vorherigen, TeX macht naturgemäß 'ne Menge (allerdings nur in /var und /etc), einige wrapper-Scripte werden nur lokal erzeugt (das gilt auch für einige eselect-Dinge with python) usw. Das gilt generell für alle Files, die lokal erst nach der Installation erzeugt werden.

 *Quote:*   

> Die andere Frage wäre aber: kann man die symlinks nicht zum paket gehören lassen?

 

Man kann nicht mal eben irgendein File "zu einem Paket gehören lassen": Wenn ein File zu einem Paket gehört, muss es vor dessen Installation erzeugt worden sein. Bei einigen Paketen wissen vielleicht nicht einmal die Gentoo-Maintainer, welche Files erst zur Laufzeit erzeugt werden, bei anderen ist es aufwändig, sie eher zu erzeugen, bei einigen gar unmöglich. Letzteres beispielsweise, wenn das File Daten enthält die vom lokalen System abhängen (denn erzeugte Pakete werden ja möglicherweise als Binary *.tbz2-Files verteilt und würden dann Ärger machen, wenn sie von der Konfiguration des Systems abhingen, auf dem sie erzeugt worden wären).

Bei Python und Perl-Paketen hat man so z.B. das Problem, dass die Binärpakete implizit von der auf dem lokalen System erzeugten Python-Version abhingen, obwohl diese Dependency nicht explizit angegeben ist. Dieses Problem würde erst verschwinden, wenn man für jedes Python-Paket USE-Flags mit der entsprechenden Python-Version hätte, für die die Binaries erstellt werden sollen, aber dies ist für den Benutzer auch nicht ganz unproblematisch zu verwalten.

----------

## Christian99

ok, mir war nicht bewusst, dass das teilweise so kompliziert werden kann...

----------

## Max Steel

 *Christian99 wrote:*   

> PS: sorry max, fürs thread hijacken 

 

Kein Problem, es scheinen wohl mehrere dieses Thema zu hinterfragen ^^

DAs neue Skript werde ich morgen ausprobiern, danke für die Mühe mv =)

Eine Frage noch, wie kann ich denn einzelne Unterordner von der Suche ausschließen? als Beispiel /usr/local (wenn ich in /usr das Skript laufen lasse.

----------

## Josef.95

 *Max Steel wrote:*   

> ...
> 
> dort bemerkte ich das mal wieder /var/tmp/portage überlaufen ist und gab rm -rf /var/ tmp/portage ein.

 

Argh..., was für ein "böser" Fehler...

Das heisst dein /var/ ist weg... Ich glaub das wäre ein Punkt wo ich das System wegschmeißen, bzw ein Backup einspielen würde. (allein auch schon wegen dem Datenverlust)

Ich kann mir kaum vorstellen das man so ein System wieder sauber hinbekommt - sprich, wenn kein Backup vorhanden ist würde ich vermutlich ein neues System aufsetzen.

----------

## mv

 *Josef.95 wrote:*   

> sprich, wenn kein Backup vorhanden ist würde ich vermutlich ein neues System aufsetzen.

 

Das hat er ja i.W. getan, nur eben nicht das alte System vorher gelöscht. M.E. ist das schon ein realistisches Vorgehen: Auch auf einem nicht neu aufgesetzten System sollte man ab und an die Liste der in keinem Paket vorhandenen Files durchgehen, um den Müll zu entfernen. So ist halt einmalig eine etwas größere Liste zu durchforsten - das sollte nicht mehr als 30 Minuten konzentrierten Lesens benötigen, und falls es kein extrem kritisches System ist, sind Fehler dabei auch nicht gerade fatal.

----------

