GDM start niet meer op, /dev/null verkeerde permissions

[pkwarts]

OS: Ubuntu 9.04

Vanmorgen toen ik mijn laptop opstartte kreeg ik een blauw scherm dat mijn x-server niet meer wilde opstarten. Ik switchte naar tty1 en na het inloggen kreeg ik iets van 20x op mijn scherm: -bash: permission denied: /dev/null

Ik heb daarna uiteraard even gegoogled op het probleem en het bleek dat iets tijdens het opstarten /dev/null veranderde van 0666 naar 0600. Na een chmod lijkt dat (tijdelijk voor die sessie) verholpen, maar toen ik apt-get vanaf de CLI wilde doen voor wat packages waarvan werd aangeraden een reinstall te doen, kreeg ik constant:

W: Not using locking for read only lock file /var/lib/dpkg/lock
E: Unable to write to /var/cache/apt/
E: The package lists or status file could not be parsed or opened.

Geprobeerd dat op te lossen door alles in /var/lib/apt/lists te verwijderen, maar zelfs dat kan ik niet, zowel door sudo te gebruiken als door root in te loggen:

sudo rm -vf /var/lib/apt/lists/*

rm: cannot remove `/var/lib/apt/enz enz `: Read-Only file system

en dat dan voor elke file uiteraard

Iets zit heel erg fout in mijn systeem en ik lijk van het ene probleem in het andere te vallen. Kan iemand me wellicht de goede kant op wijzen?

Alvast bedankt!

[RickPt]

Ik heb het zelf nog niet meegemaakt maar k hoorde van een vriend dat zijn harde schijf als read-only werd gemount toen zijn harde schijf bijna kapot was. Misschien kun je die richting eens kijken

[pkwarts]

RickPt schreef op dinsdag 21 april 2009 @ 12:05:
Ik heb het zelf nog niet meegemaakt maar k hoorde van een vriend dat zijn harde schijf als read-only werd gemount toen zijn harde schijf bijna kapot was. Misschien kun je die richting eens kijken

Dat klinkt eigenlijk wel logisch, alles wat ik tot nu toe ben tegengekomen eindigde met dat ik niks kon wijzigen. Het rare is wel dat ik tijdelijk /dev/null kon wijzigen van 0600 naar 0666. Dat lijkt me ook een write actie...

[Verwijderd]

/dev/null staat natuurlijk ook niet fysiek op je harde schijf. In /tmp bijv kun je denk ik ook nog wel schrijven

Als je mount -a gebruikt krijg je waarschijnlijk wel een melding als je schijf ro gemount wordt.

[pkwarts]

Ik krijg geen melding, maar het lijkt er idd op dat mijn schijf als ro gemount is. Is dit een hardware failure of is er iets mis binnen het systeem?

[zordaz]

Ik heb deze problemen ook gehad met de beta van Ubuntu 9.04. Na puzzelwerk bleek dat het rootfs niet clean geunmount was bij een shutdown. De problemen waren opgelost na het draaien van een fsck op het rootfs.

[Verwijderd]

Je kunt even kijken in je fstab hoe de schijf gemount wordt. Je zou dit aan kunnen passen met behulp van een live-cd.

[pkwarts]

zordaz schreef op dinsdag 21 april 2009 @ 12:35:
Ik heb deze problemen ook gehad met de beta van Ubuntu 9.04. Na puzzelwerk bleek dat het rootfs niet clean geunmount was bij een shutdown. De problemen waren opgelost na het draaien van een fsck op het rootfs.

Is dat in recovery mode het draaien van fsck? Dat werkte namelijk niet bij mij.

[pkwarts]

Verwijderd schreef op dinsdag 21 april 2009 @ 12:37:
Je kunt even kijken in je fstab hoe de schijf gemount wordt. Je zou dit aan kunnen passen met behulp van een live-cd.

Fstab:

UUID=blablablabla / ext3 relatime,errors=remount-ro 0 1
UUID=blablablabla none swap sw 0 0

en dan nog een externe schijf

Ik had hier eerder gekeken en kwam door het bold gedeelte tot de conclusie dat hij als ro gemount was. Kan ik dit via een live-cd gewoon weghalen?

[Jaap-Jan]

Je maakt een denkfout. /etc/fstab geeft alleen hoe schijven gemount moeten worden. In dit geval moet bij een fout de schijf read-only gemount worden. Gewoon van je fstab afblijven, mounten als read-only zorgt ervoor dat bij een inconsistent bestandssysteem niet de boel nog erger vernield wordt.

Kijk eens in je logs of je enge meldingen tegenkomt van 'DriveReady SeekComplete' enzo, bijvoorbeeld met

code:

rgrep DriveReady /var/log

. Als daar niets uitkomt is je schijf waarschijnlijk niet stuk.

Start dan op van de installatie-CD, doe een fsck test en laat fsck de fouten repareren.

[ Voor 6% gewijzigd door Jaap-Jan op 21-04-2009 12:58 ]

[pkwarts]

Jaap-Jan schreef op dinsdag 21 april 2009 @ 12:57:
Je maakt een denkfout. /etc/fstab geeft alleen hoe schijven gemount moeten worden. In dit geval moet bij een fout de schijf read-only gemount worden. Gewoon van je fstab afblijven, mounten als read-only zorgt ervoor dat bij een inconsistent bestandssysteem niet de boel nog erger vernield wordt.

Kijk eens in je logs of je enge meldingen tegenkomt van 'DriveReady SeekComplete' enzo, bijvoorbeeld met

code:

rgrep DriveReady /var/log

. Als daar niets uitkomt is je schijf waarschijnlijk niet stuk.

Start dan op van de installatie-CD, doe een fsck test en laat fsck de fouten repareren.

Er kwam niks uit iig, moet de live-cd even ophalen bij de buurman, zal over een kwartiertje een update posten.

[pkwarts]

Moet even een cd burnen, want buurman niet thuis en geen usb sticks ter plaatse. Kan je in de tussentijd misschien vertellen in welke log ik specifiek moet kijken?

[pkwarts]

Het is blijkbaar mijn ochtend, want op mijn andere PC wil de CD burner niet meer meewerken Ik kick dit topic later vandaag wel weer omhoog als ik de Live-CD weer heb.

[Jaap-Jan]

Psst, gebruik de -knop als je dingen aan je post wil toevoegen.

Verder: zulke meldingen zou je dan tegen moeten komen in je kernel.log.

Als je de schijf niet vertrouwd, kun je ook de test-tool van de fabrikant van de harde schijf downloaden. Seagate heeft Seatools, Western Digital heeft "Western Digital Data Lifeguard", enzovoort. Zoek het tooltje van de maker van jouw harde schijf en test daar eens mee.

[moto-moi]

Verwijderd schreef op dinsdag 21 april 2009 @ 12:17:
/dev/null staat natuurlijk ook niet fysiek op je harde schijf. In /tmp bijv kun je denk ik ook nog wel schrijven
Als je mount -a gebruikt krijg je waarschijnlijk wel een melding als je schijf ro gemount wordt.

Een aantal van die files zijn zelfs bij udev nog fysiek aanwezig in /dev . Wat de TS kan doen is z'n disk readwrite mounten, of f een ubuntu of andere livecd pakken en daarmee ruimte scheppen.

[pkwarts]

Ik ga toch weer een post toevoegen

Ik neem aan dat je kern.log bedoelde? Deze heeft slechts 7 entries voor vandaag. Er lijkt maar 1 soort van error tussen te zitten, namelijk

mttr: no MTRR for c000000,8000000

Maar die lijkt niet echt van toepassing te zijn, diezelfde melding kwam ook andere dagen tevoorschijn.

Ook uit de Dell Diagnostic Tools komt niks. (jaja, Dell )

Het wachten is op een live-cd

[moto-moi]

Dat is ook totaal niet relevant, je harddisk is hoogstwaarschijnlijk gewoon vol (df -h ? )

[pkwarts]

moto-moi schreef op dinsdag 21 april 2009 @ 14:44:
Dat is ook totaal niet relevant, je harddisk is hoogstwaarschijnlijk gewoon vol (df -h ? )

nope, 50 gb vrij

[zordaz]

pkwarts schreef op dinsdag 21 april 2009 @ 12:41:
[...]


Is dat in recovery mode het draaien van fsck? Dat werkte namelijk niet bij mij.

Ik heb deze problemen twee keer gehad. Een keer opgelost via de recovery mode en een keer met een live CD.
Wel vreemd dat de recovery mode niet bij je werkt trouwens....

[pkwarts]

Opzich kan ik zo een clean install doen, de machine waar het op staat is niet kritiek voor me, maar zou het graag uit mezelf willen oplossen. Lijkt me meer de Linux-way zeg maar.

[laurencevde]

wat zegt dmesg?
Zegt smartctl --all /dev/sda nog iets interessants?

En een fsck zou gewoon moeten werken op een ro-fs. Wat geeft die voor foutmelding?

[pkwarts]

smartctl is niet geinstalleerd en kan ik ook niet installeren, vanwege...

fsck: /dev/sda1: clean, zoveel files, zoveel blocks

dmesg wilde ik naar een kleine usb stick gooien, maar geen rechten en die krijg ik op dit moment ook niet veranderd. Lijkt erop dat ook mijn usb stick als read-only wordt gemount?

edit: ik zal de bovenstaande dingen alsnog doen vanmiddag, wanneer ik mijn live-cd terugheb.

[ Voor 13% gewijzigd door pkwarts op 21-04-2009 15:48 ]

[zordaz]

Ik zou ook een fsck -c doen, dan wordt er gecontroleerd op badblocks.

En ik ben het helemaal met je eens: een clean install doen hoort thuis in een andere wereld
De oude Debian bak waarvandaan ik dit nu tik draait al bijna 8 jaar zonder herinstallatie dankzij apt-get en aptitude.

[deadinspace]

pkwarts schreef op dinsdag 21 april 2009 @ 15:48:
dmesg wilde ik naar een kleine usb stick gooien, maar geen rechten en die krijg ik op dit moment ook niet veranderd. Lijkt erop dat ook mijn usb stick als read-only wordt gemount?

Je USB stick wordt waarschijnlijk helemaal niet gemount, dat gebeurt alleen automatisch als je systeem normaal werkt. Je kan hem wel handmatig mounten met bv

mount /dev/bla /mnt

Waar bla het USB device is. Welke dat is hangt van je systeem af, maar waarschijnlijk is het sdb of sdc (of sdb1 / sdc1 als je USB stick een partitietabel heeft). Welke je precies moet hebben kun je - ironisch genoeg - zien met dmesg nadat je de USB stick ingestoken hebt.

edit: ik zal de bovenstaande dingen alsnog doen vanmiddag, wanneer ik mijn live-cd terugheb.

dmesg uitvoeren als je vanaf de live-CD geboot bent heeft mogelijk niet zoveel zin; dmesg laat de laatste zoveel logmeldingen zien van je huidige OS. Als je dmesg runt vanaf de live-CD, dan zie je dus logmeldingen van je live-CD, niet van je werkelijke systeem.

Het beste kun je de dmesg output van je werkelijke systeem inspecteren. Dat is het systeem waaronder je filesystem read-only gemount wordt, dus daar is ook de kans dat er iets nuttigs in de logs staat het grootst.

Probeer bijvoorbeeld eens

dmesg | egrep -i -B4 read.only

of om makkelijk een beetje te kunnen scrollen in die tekst:

dmesg | less

[pkwarts]

De stick werd wel gemount, ik kon door de verschillende directories heenbladeren ed.

read.only greppen vanuit dmesg leverde alleen dit op:

Write protecting the kernel read-only data: 1532k

Lijkt me niet zo'n rare melding?

fsck -c leverde ook niks op.

[Borromini]

[stijn@hermes ~]$ head -1 /etc/mtab 
/dev/sda5 / ext3 rw,noatime 0 0

Heb je je syteem nu al opnieuw rw gemount? Indien niet:

# mount -o remount,rw /dev/sdxX /

En probeer dan voor de zekerheid ook es (vanop een live CD/USB install)

# fsck.ext3 -cfn /dev/sdxX

Als dat fouten oplevert, verander dan de n in een y - en hoop dat de reparatie niks naar de andere wereld helpt .

Aangezien /dev/null geen gewoon bestand is maar een character device (vandaar ook de c in crw-rw-rw-), zou ik, eerder dan permissies te wijzigen, het 'apparaat' verwijderen en opnieuw creëren:

# mknod -m 666 /dev/null c 1 3

Een handig (en compact) tooltje is UBCD, dat bevat alle diagnostische tools van de grootste fabrikanten, testsuites, burn-in tools, etc. Al wat je nodig hebt om je PC binair ondersteboven te keren . En zeg nu zelf, voor 115 MB .

[ Voor 18% gewijzigd door Borromini op 22-04-2009 00:29 ]

[sam.vimes]

Als je vermoedt dat je root-fs corrupt is, kun je een fsck forceren bij de volgende boot d.m.v. de optie '-F' bij shutdown: shutdown -Fr now. Dan heb je geen rescuedisk nodig.
Het is over het algemeen wel handig om voor dergelijke probleempjes een SystemRescueCd (http://www.sysresccd.org/) op de plank te hebben liggen. (Ook handig om de buurman met Windoos eens te helpen.)

[pkwarts]

Borromini schreef op woensdag 22 april 2009 @ 00:10:

[stijn@hermes ~]$ head -1 /etc/mtab 
/dev/sda5 / ext3 rw,noatime 0 0

Deze snap ik niet helemaal? Ik neem aan dat sda5 sda1 moet zijn? Wat eruitkomt is het volgende:

==> /etc/mtab <==
/dev/sda1 / ext3 rw 0 0

==> /dev/sda1 <==
Hier kan ik niks uit opmaken,
allerlei vage tekens komen er in beeld te staan.
Er lijkt iets mis te zijn ja :D

Borromini schreef op woensdag 22 april 2009 @ 00:10:
Heb je je syteem nu al opnieuw rw gemount? Indien niet:

# mount -o remount,rw /dev/sdxX /

Gedaan, werkte niet.

Borromini schreef op woensdag 22 april 2009 @ 00:10:
En probeer dan voor de zekerheid ook es (vanop een live CD/USB install)

# fsck.ext3 -cfn /dev/sdxX

Als dat fouten oplevert, verander dan de n in een y - en hoop dat de reparatie niks naar de andere wereld helpt .

Dit ga ik straks even doen, heb een usb stick gevonden waar zo'n rescue cd wel op past

Borromini schreef op woensdag 22 april 2009 @ 00:10:
Aangezien /dev/null geen gewoon bestand is maar een character device (vandaar ook de c in crw-rw-rw-), zou ik, eerder dan permissies te wijzigen, het 'apparaat' verwijderen en opnieuw creëren:

# mknod -m 666 /dev/null c 1 3

Dit had ik ook al geprobeerd, mocht ook niks baten helaas.

[pkwarts]

Wow, net even smartctl gedaan, en er komen heel wat pre_fails en old_age uit. (tenzij ik de tool niet goed snap, lijkt me dat dat slecht is) Ook 3 ATA error counts. Ik kreeg er ook uit dat het een Seagate disk is, dus straks even van hun er een tooltje op los laten.

edit: hier een output van smartctl, als iemand met wat verstand van zaken er even naar zou kunnen kijken zou ik dat zeer op prijs stellen:

http://aurum.student.utwente.nl/smartctl.txt

[ Voor 26% gewijzigd door pkwarts op 22-04-2009 15:43 ]

[maleadt]

Niks ergs in dat smartctl report, enkel 1 keer een probleem met de airflow cel en 3 dma read errors ergens 4000 uur geleden.

Die "head mtab" indiceert hoe je root nu gemount is, en dat is precies in read-write modus. Aangezien je blijkbaar niks kan schrijven zou ik aan filesystem corruptie gaan denken, laat idd fsck eens draaien om te zien wat die er van maakt.
Kan je bestanden aanmaken/wijzigen als je die partitie mount van op een live cd?

[ Voor 7% gewijzigd door maleadt op 22-04-2009 16:07 ]

[pkwarts]

maleadt schreef op woensdag 22 april 2009 @ 16:06:
Niks ergs in dat smartctl report, enkel 1 keer een probleem met de airflow cel en 3 dma read errors ergens 4000 uur geleden.

Die "head mtab" indiceert hoe je root nu gemount is, en dat is precies in read-write modus. Aangezien je blijkbaar niks kan schrijven zou ik aan filesystem corruptie gaan denken, laat idd fsck eens draaien om te zien wat die er van maakt.
Kan je bestanden aanmaken/wijzigen als je die partitie mount van op een live cd?

Ik kan vanuit de live cd de partitie niet mounten. edit: vanuit de GUI iig, zal het even vanaf de CLI proberen. Ik heb ook de vanuit de live cd fsck laten draaien, via deze:

# fsck.ext3 -cfn /dev/sdxX

Ik zal hem nu nog een keer draaien, met -y ipv -n

[ Voor 4% gewijzigd door pkwarts op 22-04-2009 16:26 ]

[pkwarts]

Ja, ik kan bestanden wijzigen en aanmaken vanuit de LiveCD op de partitie

[maleadt]

Hmm, vreemd. Controleer /var/log/messages en /var/log/syslog eens op errors, of pastebin ze ergens.

Om zeker te zijn: je kan dus geen bestanden aanmaken als je gewoon opstart (je zegt wel dat je FS ro gemount is en rm klaagt er over, maar vermeldt het niet specifiek)?

Wat ik vreemd vind is dat je mount options uit fstab ("relatime,errors=remount-ro") niet overgenomen worden in je mtab, meer nog: "noatime" komt tevoorschijn hoewel je dat helemaal niet gespecifieerd hebt...
Komt de UUID wel overeen met /dev/sda1? Controleer mbv "vol_id".

[Borromini]

De noatime is van mijn commando, dat was meer om te tonen hoe ie makkelijk rw/ro kan checken dan wat anders (buiten bestanden proberen aan te maken ). Ik zie in z'n output gewoon rw staan, niks meer.

Als een check geen fouten vindt (of er wel vindt maar je kan ze repareren) en je krijgt bij het booten toch nog die ro mount, dan week ik eigenlijk niet wat er mis gaat . Misschien een probleem met de opstartscripts ergens?

Het lijkt me nóg vreemder dat je niet rw zou kunnen mounten (met de remount optie), ik kan me niet herinneren dat ik dat ooit al ben tegengekomen... Probeer het es met alleen het mount point (is een tijdje geleden dat ik 't nog gedaan heb, alleen mount point lijkt voldoende te zijn):

mount -o remount,rw /

[ Voor 26% gewijzigd door Borromini op 22-04-2009 17:58 ]

[pkwarts]

Ik heb vanaf een live-cd fsck.ext3 -cfy /dev/sda1 gedaan, mocht niet baten.
Ik kan idd bij normaal opstarten niks aanmaken:

touch bla.txt
touch: cannot touch 'bla.txt': Read-only file system

Na de mount command die Borromini gaf, lukte dit wel.
Ik probeer GDM op te starten:

* Starting GNOME display Manager...
return: 24: Illegal number: Stopping

Na een restart:

touch bla.txt
touch: cannot touch 'bla.txt': Read-only file system

[pkwarts]

Die return: 24: heeft me wel weer hier naartoe geleid: http://ubuntuforums.org/showthread.php?t=1052256&page=3

Waarschijnlijk dus iets fout gegaan bij het installeren van een package. Dat zou best kunnen, de laptop gaat 's nachts meestal in suspense, dus het was alweer even dat hij een echte reboot had gekregen.

edit: splashy zou dus best eens de kwaaddoener kunnen zijn. We gaan die even vanuit single user mode opnieuw installeren

[ Voor 17% gewijzigd door pkwarts op 22-04-2009 19:38 ]

[pkwarts]

Iemand een idee hoe ik het beste een package kan installeren? Single-user mode with networking werkt niet, omdat voor het maken van een verbinding een read-write partitie nodig is. Dus nadat ik die gemount heb, hoe trigger ik het aanmaken van een verbinding?

edit: dhclient

[ Voor 3% gewijzigd door pkwarts op 22-04-2009 19:41 ]

[pkwarts]

Gelukt!

Uiteindelijk moest ik dus als read/write mounten, verbinding maken met internet, met dpkg splashy package verwijderen en dan splashy weer opnieuw installeren.

pfff, eigenlijk wilde ik van dat splashy af, maar daar duik ik in mijn eentje dan nog wel even in.

Ik wil even iedereen heel erg bedanken voor het meedenken. Ik heb weer heel wat bijgeleerd en ben erg blij het uiteindelijk te hebben kunnen fixen zonder een clean install.

Dank jullie wel!

[Borromini]

Wel ik wil je niet alleen feliciteren met je zin voor initiatief (je hebt uiteindelijk je probleem grotendeels zelf opgelost), maar ook met de mentale switch die je gemaakt hebt - het is inderdaad niet de bedoeling dat je bij het minste wissewasje zomaar er een nieuwe install op gooit . Deze keer heeft het best wat tijd gekost, maar de volgende keer heb je die bagage al .

[Jaap-Jan]

Herinstalleren kon ook met 'aptitude reinstall package' wat wat minder omslachtig is dan verwijderen met dpkg (waarom niet aptitude of apt-get ).

Dpkg heb je nauwelijk nodig, het enige waar ik het voor gebruik is dpkg -l en soms dpkg-reconfigure en ik heb op mijn server een developmentversie van Transmission-daemon geïnstalleerd, maar eigenlijk is dat af te raden, omdat je dan geen updates meer binnenkrijgt en dus mogelijk met een brakke versie komt te zitten.

[maleadt]

Borromini schreef op woensdag 22 april 2009 @ 17:54:
De noatime is van mijn commando, dat was meer om te tonen hoe ie makkelijk rw/ro kan checken dan wat anders (buiten bestanden proberen aan te maken ). Ik zie in z'n output gewoon rw staan, niks meer.

Ok, de noatime kwam inderdaad van jou, maar bij zijn mtab ontbraken toch echt de "relatime" en "errors=remount-r" opties

Nuja, goed dat je het probleem gevonden hebt Enig idee wat de achterliggende oorzaak was, corrupteerde Splashy sommige init scripts oid?

[pkwarts]

Jaap-Jan schreef op woensdag 22 april 2009 @ 23:20:
Herinstalleren kon ook met 'aptitude reinstall package' wat wat minder omslachtig is dan verwijderen met dpkg (waarom niet aptitude of apt-get ).

Dpkg heb je nauwelijk nodig, het enige waar ik het voor gebruik is dpkg -l en soms dpkg-reconfigure en ik heb op mijn server een developmentversie van Transmission-daemon geïnstalleerd, maar eigenlijk is dat af te raden, omdat je dan geen updates meer binnenkrijgt en dus mogelijk met een brakke versie komt te zitten.

Ik had wel apt-get --reinstall geprobeerd, maar kreeg steeds een dpkg error. Daarom maar de dpkg man ingedoken vandaar. Wellicht dat aptitude reinstall wel gelukt was, zal hem onthouden.

maleadt schreef op donderdag 23 april 2009 @ 00:11:
Nuja, goed dat je het probleem gevonden hebt Enig idee wat de achterliggende oorzaak was, corrupteerde Splashy sommige init scripts oid?

Een user op het Ubuntu forum zei:

I believe the problem with uninstalling splashy is that when you instal it, it runs update-initramfs. When you uninstall it, it doesn't.

Of dat ook zo is, geen flauw idee...

[ Voor 23% gewijzigd door pkwarts op 23-04-2009 00:25 ]