fsck.ext3: unable to resolve " UUID enz" fsck died with exit status 9

[tryer]

Op andere Engelstalige sites heb ik de oorzaak gevonden van bovenstaande regels. "fsck.ext3: unable to resolve "UUID..enz"
fsck died with exit status9

Op andere sites vond ik dat dit komt als je meerdere distrubuties van Linux naast elkaar gebruikt (duo- of tripleboot), als je dan een partitie of gedeelte van een schijf formateert je bovenstaande melding krijgt, het heeft iets met de installer te maken die dan een fout doorgeeft aan een andere distrubutie.

Ook vond ik de oplossing, maar het lukt me niet deze te voltooien. Je moet 2 terminals openen: een met " blkid"  de andere met "sudo gedit /etc/fstab". Dan de foute UUID regel er uitgooien ?

Dat laatste lukt me niet. Ik start op met de live-cd van Ubuntu, In de ene terminal met " blkid" krijg ik alle UUID-regels. Vervolgens moet ik het fstab-scherm krijgen maar dat lukt me niet: waarschijnlijk moet ik dan mijn root-partitie mounten, maar hoe doe ik dat vanuit de terminal in de live-cd ? de regel begint met ubuntu@ubuntu.

Wie wil me verder helpen ??

[vanadium]

Het komt er blijkbaar op neer dat de UUID die in je /etc/fstab configuratiebestand vermeld is, niet meer klopt. Hoe je UUID voor je systeempartitie ooit zou kunnen veranderen, begrijp ik niet.

Je kan je systeempartitie mounten als volgt (voor zover die tijdens de live sessie niet automatisch werd gemount). Ik neem voor dit voorbeeld aan dat je systeempartitie /dev/sda1 is.

sudo mkdir temp
sudo mount /dev/sda1 temp

Dan moet je de juiste fstab kunnen laden met:

gksudo gedit temp/etc/fstab

[Tukcedo]

Volgens mij doet een nieuwe distributie iets met die UUIDs, met name als je distro's mixed, dus Ubuntu en Fedora bijvoorbeeld. Persoonlijk gooi ik die UUID rommel er altijd meteen uit. Gewoon de devices /dev/sda1 etc. gebruiken, dat werkt altijd. De methode die vanadium noemt om dat te doen lijkt me correct.

[vanadium]

Op sommige nieuwere hardware krijgen de harde schijven niet steeds dezelfde devicenaam toegewezen. Om dat op te vangen zijn juist de UUIDs bedoeld. Het is een eigenschap van de partitie, dus zolang de partitie niet geherformatteerd wordt, blijft de UUID dezelfde moeten blijven.

Als je een clean herinstall doet van Ubuntu met herformatteren, dan zal je Fedora achteraf je Ubuntu partitie uiteraard niet meer herkennen: logisch, want de UUID is veranderd na het herformatteren. Dan moet je inderdaad in het andere systeem de UUID updaten in fstab.

Rommel is het dus niet: het is gewoon een (veel) meer robuste manier om uniek een partitie te identificeren. Echter, als je zeker bent dat bij jou de device names nooit veranderen, dan is het best handigst in jou situatie om de device names te gebruiken.

[tryer]

Heel erg bedankt. Eindelijk het lek boven water. Ik heb al 4 maal Ubuntu opnieuw geinstalleerd, omdat ik Ubuntu niet kon opstarten ! Nu is het me wel gelukt om Ubuntu weer te kunnen laten starten.

Geweldig. Hoop nu ook voor de toekomst deze fout te kunnen weerstaan. In buitenlandse websites wordt ontzettend geklaagd dat de programmamakers deze bug er niet uit kunnen halen.

[tryer]

Toch nog even een vraag: Na "gksudo gedit temp/etc/fstab" heb ik een hekje gezet voor deze UUID, zodat deze uitgeschakeld wordt, en een hekje voor de partitie " /dev/sdb4"  gezet. Kan ik daar bij gebruik van " /dev/sdb4" geen last meekrijgen ?