Samme adfærd i begge tilfælde.
Jeg fik følgende besked - og flere lignede, med et andet inode nummer:
22173,998734 Ext4-fs error: (device sda3: ext4_find_entry: 1309: inode #391681: comm getty: reading directory (block 0)
Jeg havde tilfældigvis en terminal åben, og prøvede straks at køre:
Kode: Vælg alt
sync... men
/bin/sync - No Such file or Directory
WTF?
Computeren var altså uden noget filsystem overhovedet, fordi /bin mappen er i root filsystemet, og /dev/sda3 er netop det block device (=her en primær DOS-partition), der har et ext4 filsystem som bør være monteret som root filsystemet.
Efter en brutalis slukning og tænding af computeren igen 15 sekunder senere ved sluk/tænd-knappen ved computerens strømforsyning + en frisk opstart har jeg min sync kommando tilbage igen,
Jeg har før set præcis den adfærd og efter omkring det samme stykke tid igen med nouveau device driveren når nomodeset ikke er sat som kernel parameter.
Jeg bruger ikke nomodeset fordi at det tidlige Nvidiea grafikkort ligger på en ESD pose ca 1,5 meter væk fra computeren, og et AMD Radeon HD6450 grafikkort er installeret i maskinen.
Jeg er ved at køre den udvidede udgive af smartctl på SSDen der har haft ca 53x24 timers total driftstid i hele dens levetid, men der er sikkert ikke noget lige som sidste gang kernen lavede det nummer med at fjerne root filsystemet.
Edit: Udvidet SMART test blev gennemført, og der blev ikke meldt om fejl.
Jeg har afinstallevertet nouveau driveren (purge) - det burde være nok, ellers må jeg blackliste den., eller se om der er andre X11 device drivers der kan konflikte/lave knas i det.
Lige nu venter jeg på at S.M.A.R.T.-funktionaliteten på SSDen har arbejdet færdig, og så genstarter jeg med en gennemtvingning af et tjek af alle filsystemer med (køres før genstart):
Kode: Vælg alt
sudo touch /forcefsck/Lars