[OPGELOST] updatemanager: segmentatiefout

[grubuntu]

Zonder enige aanleiding (ik heb niets geïnstalleerd of verwijderd) geeft Intrepid een probleem. Documenten zijn ineens alleen-lezen en de update manager, als ik die opstart in de root teminal, geeft de melding: "segmentatiefout" en sluit af.

Starten in de herstelmodus leverde geen resultaat op.
Ik heb geen idee waar ik het moet zoeken. Waarschijnlijk iets met authorisatie. Maar ik zie in Nautilus geen vreemde dingen.

[Johan van Dijk]

Welke documenten zijn 'alleen lezen'?
Waar staan die documenten?

Plaats het resultaat van het volgende commando eens op het forum:
df -h

Krijg je ook een foutmelding als je het volgende commando uitvoert?
sudo apt-get update

[grubuntu]

Het zijn Openoffice documenten die al jaren in mijn /home staan.

root@xxxxxx:/home/xxxx# df -h
Bestandssysteem            Grtte   Gebr Besch Geb% Aangekoppeld op
/dev/sda8              16G   16G     0 100% /
tmpfs                 251M     0  251M   0% /lib/init/rw
varrun                251M  228K  251M   1% /var/run
varlock               251M     0  251M   0% /var/lock
udev                  251M  2,9M  249M   2% /dev
tmpfs                 251M   12K  251M   1% /dev/shm
lrm                   251M  2,0M  250M   1% /lib/modules/2.6.27-9-generic/volatile
/dev/sda9              20G  6,1G   13G  34% /home
/dev/sda7              36G   10G   26G  29% /media/sda7
overflow              1,0M   24K 1000K   3% /tmp
/dev/sdc2              71G   16G   52G  24% /media/disk
/dev/sdc1             227G   52G  175G  23% /media/TREKSTOR__


sudo apt-get update: loopt vast en adviseert om "sudo apt-get update" te proberen.

Als ik kijk naar de top 10 (sudo du -sx /* 2> /dev/null | sort -nr | head -20):

81328231   /media
6126544   /home
3740920   /usr
759724   /opt
392004   /var
308960   /lib
71516   /boot
54640   /root
15760   /etc

Ik ga er nu wel van uit dat ergens een kanjer van een bestand in de root is geplaatst. Dat heb ik eerder gehad.
Maar waar?

[Cumulus007]

Wat doet:

Code: [Selecteer]

touch ~/test


[grubuntu]

Niets.

[Cumulus007]

Mooi zo, dan is je bestandssysteem niet read-only, zoals ik vermoedde.

[Johan van Dijk]

Code: [Selecteer]

Bestandssysteem            Grtte   Gebr Besch Geb% Aangekoppeld op
/dev/sda8              16G   16G     0 100% /
Je root partitie is vol.
Je kan tijdelijk wat ruimte vrijmaken met de volgende commando's:
sudo apt-get clean
sudo apt-get autoremove
Let wel op de pakketten die verwijderd worden. Als je sommige nodig hebt annuleer dan.

Als je weer wat ruimte hebt kan je via de "disk usage analyzer" makkelijk zien waar de grootste bestanden staan.
(applications>accessories>disk usage analyzer)

Zo te zien zijn /media/, /home/ en /usr/ erg vol.
media en home lijken mij wel OK, dus ik zou even verder kijken in /usr/

[grubuntu]

/usr laat geen bijzondere zaken zien. 3,5 GB is toch niet veel.
/home staat op een separate partitie
/media wordt veroorzaakt door een aangekoppelde partitie. Als ik die loskoppel resteert een gebruik van slechts enkele MB


sudo apt-get autoremove levert op (incl. spelfout):
Pakketlijsten worden ingelezen... Klaar
Segmentatiefoutten wordt opgebouwd... 50%

En dan stopt het.

Het installeren van een update lukt (nog steeds) niet. Ik krijg de foutmelding:

E: /var/cache/apt/archives/acroread_9.1.0-7intrepid1_i386.deb: probleem tegengekomen in buffer_write(fd) (10, ret=-1)

[Johan van Dijk]

Is je root partitie nog steeds zo vol? Dat moet je natuurlijk eerst oplossen.
Waar dat zit kan niemand je zo vertellen, dat moet je zelf opzoeken.

[grubuntu]

Maar hoe zoek ik dat dan?
Schijfgebruik zegt over mijn rootpartiitie: Cap. 15,4 GB, gebruikt 15,4 GB. Dat is duidelijk.

De detaillering echter zegt dat maar 5,1 GB gebruikt wordt, waarvan het grootste deel (3,5 GB) door /usr wordt opgesoupeerd.
Maar waar zijn die andere 10,3 GB dan gebleven? Verborgen bestanden kan ik niet vinden.

[chris.]

en als je met cntrl + h de verborgen bestanden zichtbaar maakt komt er ook geen groot log iod tevoorschijn?

[Gandyman]

Ga met nautilus naar die map:
E: /var/cache/apt/archives/acroread_9.1.0-7intrepid1_i386.deb

en gooi acroread_9.1.0-7intrepid1_i386.deb handmatig weg.

Daarna die sudo apt-get update uitvoeren in terminal

[Johan van Dijk]

Via de terminal lijkt me het makkelijkst:

Code: [Selecteer]

sudo du -sh /* --exclude=/proc --exclude=/media --exclude=/dev
Plaats het resultaat eens hier.

[grubuntu]

 sudo du -sh /* --exclude=/proc --exclude=/media --exclude=/dev

levert op:

6,3M   /bin
70M   /boot
0   /cdrom
16M   /etc
4,0K   /Google-googleearth.desktop
du: kan geen toegang krijgen tot `/home/xxxx/.gvfs': Toegang geweigerd
5,9G   /home
0   /initrd.img
0   /initrd.img.old
302M   /lib
8,0K   /mnt
742M   /opt
12K   /Recycled
11G   /root
8,4M   /sbin
4,0K   /srv
0   /sys
20K   /tmp
3,6G   /usr
445M   /var
0   /vmlinuz
0   /vmlinuz.old

Het verwijderen van acroread etc. heeft geen effect. "sudo apt-get update" geeft enekele foutmeldingen en adviseert "apt-get update" uit te voeren.

Wat mij nu opvalt: in de linkerbalk van Nautilus staat ook de Prullenbak. Maar die kan ik niet openen om te kijken wat daar in zit. De prullenbak in de menubalk bevat alleen een Ooo3 map van 150 MB (die ik overigens niet weg krijg).

[track]

...
11G   /root
...

Nou, hier hebben wij toch al iets !

Zo veel zit er normaal niet in. Blijkbaar ben je ooit druk bezig geweest met "sudo weetikwat"
en hebt er een zooitje achter gelaten.

Dus nu nog een keer met  gksu  nautilus naar de map  "/root" (= thuismap onder sudo !) en kijken wat er schuilt.
(normaal staan er maar enkele 10 kB in)  En deze keer heel voorzichtig, want als "root" mag je alles - dus ook in de soep sturen.

track

[Johan van Dijk]

Kijk inderdaad eens in /root, daar hoort niet zoveel data te staan.

Verder kan je dingen uit de prullenbak verwijderen door te gaan naar:
/home/gebruikersnaam/.local/share/Trash/
Even kijken in de files en info mappen wat daar staat en wat daar niet hoort.
Dit moet je dus ook met gksu nautilus doen.

[grubuntu]

Opgelost. Bedankt.

Terecht jullie kritische kanttekeningen. Maar zonder experimenten is de wereld zo saai....
Wat mij opvalt is:

• In de eerdere scan kwam /root met 54 MB uit de bus. Nu ineens 11 GB.(?)
  
• Inderdaad stond in /root/local een trash-bestand. Die kon ik eerder met geen mogelijkheid vinden.Verwijderd en nu weer volop ruimte.

Voor nu is alles weer helemaal voor elkaar.

Nogmaals dank.

[Johan van Dijk]

Graag gedaan. Mooi dat het weer werkt

Wat mij opvalt is:

• In de eerdere scan kwam /root met 54 MB uit de bus. Nu ineens 11 GB.(?)
  

Tsja, als je geen rechten hebt om de bestanden te zien, of zelfs geen rechten hebt om in de mappen te kijken waar die bestanden staan, dan kan je ook moeilijk bepalen hoe groot ze zijn