Raspberry Pi4 (PI OS) met HA: Unable to mount root fs

[Rutger]

Hello mede tweakers.
Ik heb sinds 15 juli een probleem met mijn Raspberri pi 4.

Een kleine timeline:
1. Ik constateer rond 15-07 dat ik geen History meer heb in mijn Home Assistant
2. Klein onderzoek in de logs leert mij dat de database corrupt is
3. Home Assistant zelf doet het nog wel, na een korte google opdracht lijkt het vrij eenvoudig om een database opnieuw op te zetten.
4. Daar vanuit gaande ben ik er vandaag (pas) mee aan de slag gegaan
5. Echter blijkt vreemd genoeg mijn Pi zichzelf de nek omgedraaid te hebben: ik krijg namelijk geen beeld uit de Pi.
6. Na een force restart (stroom er af en er op) start hij niet meer op, met de melding:

code:

Kernel panic - not syncing: VFS: unable to mount root fs on unknown-block(8,2*)

Deze melding krijg ik niet gerepareerd helaas.

Relevante software en hardware die ik gebruik
Raspberry Pi 4 2GB
Raspberry OS op een Sandisk Ultra Fit 32GB Usb stick
Geen SD kaart

Wat ik al gevonden of geprobeerd heb
Ik heb de website van @Rouwette gevonden na een Google opdracht, met ogenschijnlijk de oplossing.

Deze oplossing heb ik geprobeerd: ik heb de originele SD kaart er terug in gestopt, en de Pi start via deze SD op nu.
Echter, de fsck command weigert dienst:

code:

\dev\sda is in use. e2fsck: cannot continue, aborting

Na wat rondzoeken blijkt dat de /dev/sda wellicht gemount is, maar het umount /dev/sda command helpt ook niet:

code:

/dev/sda is not mounted.

Overige dingen die ik heb geprobeerd:
Dit stackoverflow topic lijkt ook een oplossing te bieden. Echter, ik kom niet in de menu's die men aangeeft, als ik shift inhoudt gebeurt er in principe hetzelfde als dat ik zonder shift inhouden opstart.
Dit heb ik overigens geprobeerd zowel met de SD kaart in de Pi als niet in de Pi.
Ik heb geprobeerd mijn USB stick via Windows te benaderen, dat gaat op zich oké: Windows ziet een F:\ schijf die "boot" heet, plus een G:\ schijf die niet te benaderen is zonder te formatteren (uiteraard niet gedaan).
Als ik vervolgens in de f:\cmdline.txt ga kijken zie ik de volgende values die ik (volgens mij) zelf er in heb gezet:

code:

console=serial0,115200 console=tty1 root=PARTUUID=de64a445-02 rootfstype=ext4 fsck.repair=yes rootwait quiet splash plymouth.ignore-serial-consoles

Met de tips uit het stackoverflow topic dacht ik: laat ik random m'n root=PARTUUID aanpassen naar

code:

root=PARTUUID=de64a445-06

Maar ik mag de cmdline.txt niet overschrijven/aanpassen vanwege write protection op de USB stick. Bovendien weet ik niet of dit überhaupt het probleem zou oplossen.

Eventueel belangrijke kanttekeningen
Mijn Linux kennis is op z'n minst slecht te noemen. Ik heb alles (naar mijn gevoel) houtje-toutje in elkaar geflansd met een boel Youtube/online toturials.
Ik heb backups, maar ik heb geen backup image getrokken toen ik eenmaal tevreden was.
Ik ben bang dat als ik een nieuwe Pi OS maak en de backups terug zet, ik niet alles terug heb staan zoals ik zou willen.
Zo kon ik bijvoorbeeld mijn Home Assistant benaderen met een extern domein, ik vraag me af of ik dat goed terugkomt als ik mijn backup terug zet op een nieuwe installatie, vermoedelijk niet.
Mijn backups zijn op dit moment van:

code:

dpkg --get-selections > /home/pi/backup/Package.list
sudo cp -R /etc/apt/sources.list* /home/pi/backup/
sudo apt-key exportall > /home/pi/backup/Repo.keys
/home 
/etc 
/usr/local/etc

In een notendop
Sinds 15 juli wil mijn pi niet meer starten vanaf mijn USB stick vanwege de melding

code:

Kernel panic - not syncing: VFS: unable to mount root fs on unknown-block(8,2*)

welke ik niet weg krijg.
Ik loop vast vanwege vrij gebrekkige Linux kennis, heeft iemand suggesties of tips wat ik kan doen om dit te repareren?

[Rouwette]

Rutger schreef op zondag 31 juli 2022 @ 13:01:
Hello mede tweakers.
Ik heb sinds 15 juli een probleem met mijn Raspberri pi 4.

Een kleine timeline:
1. Ik constateer rond 15-07 dat ik geen History meer heb in mijn Home Assistant
2. Klein onderzoek in de logs leert mij dat de database corrupt is
3. Home Assistant zelf doet het nog wel, na een korte google opdracht lijkt het vrij eenvoudig om een database opnieuw op te zetten.
4. Daar vanuit gaande ben ik er vandaag (pas) mee aan de slag gegaan
5. Echter blijkt vreemd genoeg mijn Pi zichzelf de nek omgedraaid te hebben: ik krijg namelijk geen beeld uit de Pi.
6. Na een force restart (stroom er af en er op) start hij niet meer op, met de melding:

code:

Kernel panic - not syncing: VFS: unable to mount root fs on unknown-block(8,2*)

Deze melding krijg ik niet gerepareerd helaas.

Relevante software en hardware die ik gebruik
Raspberry Pi 4 2GB
Raspberry OS op een Sandisk Ultra Fit 32GB Usb stick
Geen SD kaart

Wat ik al gevonden of geprobeerd heb
Ik heb de website van @Rouwette gevonden na een Google opdracht, met ogenschijnlijk de oplossing.

Deze oplossing heb ik geprobeerd: ik heb de originele SD kaart er terug in gestopt, en de Pi start via deze SD op nu.
Echter, de fsck command weigert dienst:

code:

\dev\sda is in use. e2fsck: cannot continue, aborting

Na wat rondzoeken blijkt dat de /dev/sda wellicht gemount is, maar het umount /dev/sda command helpt ook niet:

code:

/dev/sda is not mounted.

Overige dingen die ik heb geprobeerd:
Dit stackoverflow topic lijkt ook een oplossing te bieden. Echter, ik kom niet in de menu's die men aangeeft, als ik shift inhoudt gebeurt er in principe hetzelfde als dat ik zonder shift inhouden opstart.
Dit heb ik overigens geprobeerd zowel met de SD kaart in de Pi als niet in de Pi.
Ik heb geprobeerd mijn USB stick via Windows te benaderen, dat gaat op zich oké: Windows ziet een F:\ schijf die "boot" heet, plus een G:\ schijf die niet te benaderen is zonder te formatteren (uiteraard niet gedaan).
Als ik vervolgens in de f:\cmdline.txt ga kijken zie ik de volgende values die ik (volgens mij) zelf er in heb gezet:

code:

console=serial0,115200 console=tty1 root=PARTUUID=de64a445-02 rootfstype=ext4 fsck.repair=yes rootwait quiet splash plymouth.ignore-serial-consoles

Met de tips uit het stackoverflow topic dacht ik: laat ik random m'n root=PARTUUID aanpassen naar

code:

root=PARTUUID=de64a445-06

Maar ik mag de cmdline.txt niet overschrijven/aanpassen vanwege write protection op de USB stick. Bovendien weet ik niet of dit überhaupt het probleem zou oplossen.

Eventueel belangrijke kanttekeningen
Mijn Linux kennis is op z'n minst slecht te noemen. Ik heb alles (naar mijn gevoel) houtje-toutje in elkaar geflansd met een boel Youtube/online toturials.
Ik heb backups, maar ik heb geen backup image getrokken toen ik eenmaal tevreden was.
Ik ben bang dat als ik een nieuwe Pi OS maak en de backups terug zet, ik niet alles terug heb staan zoals ik zou willen.
Zo kon ik bijvoorbeeld mijn Home Assistant benaderen met een extern domein, ik vraag me af of ik dat goed terugkomt als ik mijn backup terug zet op een nieuwe installatie, vermoedelijk niet.
Mijn backups zijn op dit moment van:

code:

dpkg --get-selections > /home/pi/backup/Package.list
sudo cp -R /etc/apt/sources.list* /home/pi/backup/
sudo apt-key exportall > /home/pi/backup/Repo.keys
/home 
/etc 
/usr/local/etc

In een notendop
Sinds 15 juli wil mijn pi niet meer starten vanaf mijn USB stick vanwege de melding

code:

Kernel panic - not syncing: VFS: unable to mount root fs on unknown-block(8,2*)

welke ik niet weg krijg.
Ik loop vast vanwege vrij gebrekkige Linux kennis, heeft iemand suggesties of tips wat ik kan doen om dit te repareren?

Leuk dat je mijn site hebt gevonden! Heb je een nieuwe werkende sd en dan de currupte er via usb aansluiten, via een usb-readertje.

sudo parted -l

En de sdb is dan de usb sd kaart, op de sdb2 zal dan het kapotte deel zijn

sudo fsck /dev/sdb2

Dan krijg je een vragenlijstje welke je met waarschijnlijk met Y moet doorlopen.

[Rutger]

Rouwette schreef op zondag 31 juli 2022 @ 16:49:
[...]


Leuk dat je mijn site hebt gevonden! Heb je een nieuwe werkende sd en dan de currupte er via usb aansluiten, via een usb-readertje.

sudo parted -l

En de sdb is dan de usb sd kaart, op de sdb2 zal dan het kapotte deel zijn

sudo fsck /dev/sdb2

Dan krijg je een vragenlijstje welke je met waarschijnlijk met Y moet doorlopen.

Thanks voor je reply!
Het probleem is dat het geen corrupte SD is maar een USB stick. Vervolgens mag ik geen fsck doen omdat fsck dan aangeeft dat de USB stick in gebruik is.

Ik ga nog even kijken of het lukt via een USB reader oid, of het een probleem is dat ie direct in de pi geprikt zit, maar ik vermoed eigenlijk van niet...

[Rutger]

Rouwette schreef op zondag 31 juli 2022 @ 16:49:
[...]


Leuk dat je mijn site hebt gevonden! Heb je een nieuwe werkende sd en dan de currupte er via usb aansluiten, via een usb-readertje.

sudo parted -l

En de sdb is dan de usb sd kaart, op de sdb2 zal dan het kapotte deel zijn

sudo fsck /dev/sdb2

Dan krijg je een vragenlijstje welke je met waarschijnlijk met Y moet doorlopen.

Hmm ik zie dat ik je niet helemaal goed heb begrepen, ik mistte de 2 aan het eind.
Ik kom nu een stapje verder, maar ook "sudo fsck /dev/sda2" pakt ie helaas niet:

code:

 fsck.ext4: Read-only file system while trying to open /dev/sda2
Disk write-protected; use the -n option to do a read-only check of the device

"sudo fsck /dev/sda2 -n" geeft op zijn beurt niet echt iets nuttigs:

code:

 rootfs: clean, xxx/xxxx files, xxxxx/xxxxxxx blocks

"sudo umount /dev/sda2" heeft ook weinig nut:

code:

 umount: /dev/sda2: not mounted.

Volgens deze website zou dit nog een optie moeten zijn:
"sudo fsck.ext4 -f /dev/sda2"
Maar helaas werkt dat ook niet met dezelfde Read-only melding.

Ik begin me ook af te vragen hoe de Pi boot op dit moment.
Met alleen de SD kaart boot hij niet, maar in een emergency mode.
Met de USB stick boot hij wel, maar lijkt hij uiteindelijk met de SD kaart te booten...

[Rouwette]

Rutger schreef op zondag 31 juli 2022 @ 16:55:
[...]


Thanks voor je reply!
Het probleem is dat het geen corrupte SD is maar een USB stick. Vervolgens mag ik geen fsck doen omdat fsck dan aangeeft dat de USB stick in gebruik is.

Ik ga nog even kijken of het lukt via een USB reader oid, of het een probleem is dat ie direct in de pi geprikt zit, maar ik vermoed eigenlijk van niet...

start de pi met een werkende sd/usb (frisse install) en plug erna, na opstarten, de corrupte erbij

[synoniem]

Rutger schreef op zondag 31 juli 2022 @ 17:28:
[...]
Ik begin me ook af te vragen hoe de Pi boot op dit moment.
Met alleen de SD kaart boot hij niet, maar in een emergency mode.
Met de USB stick boot hij wel, maar lijkt hij uiteindelijk met de SD kaart te booten...

Als op je SD kaartje de rootfs hetzelfde PARTUUID heeft als je USB stick dan is het de vraag welke van de twee gemount wordt de tweede partitie op de SD kaart op de tweede partitie op je USB stick. Zou wel kunnen verklaren dat je twee tegenstrijdige statussen krijgt van /dev/sda2.

[Rutger]

Rouwette schreef op zondag 31 juli 2022 @ 22:14:
[...]
start de pi met een werkende sd/usb (frisse install) en plug erna, na opstarten, de corrupte erbij

Goed punt, dat heb ik nog niet geprobeerd.
Ga ik later proberen!

synoniem schreef op zondag 31 juli 2022 @ 22:27:
[...]

Als op je SD kaartje de rootfs hetzelfde PARTUUID heeft als je USB stick dan is het de vraag welke van de twee gemount wordt de tweede partitie op de SD kaart op de tweede partitie op je USB stick. Zou wel kunnen verklaren dat je twee tegenstrijdige statussen krijgt van /dev/sda2.

Klinkt idd plausibel. Met het bovenstaande (volledig schone SD installatie) hoop ik dat dat dan ook verleden tijd is.

Ik meld mij weer met nieuwe resultaten, zodra ik ze heb.
Dank beide!

[ninjazx9r98]

Je krijgt het advies om /dev/sdb te gebruiken in de commando's, dat is niet voor niets
De eerste 'disk' is sda, de tweede sdb enz. Als je boot van een SD kaartje zal dat sda zijn en je USB stick is dan sdb. Op sda kun je 'niks' want daar ben je van gestart en die is in gebruik.

Dat gezegd hebbende is de kans groot dat je USB stick kapot is, been there done that. Heb zelf de ervaring dat die dingen soms USB sticks vreten en heb betere ervaringen met SD kaartjes en nog beter met SSD via USB.

[Rutger]

ninjazx9r98 schreef op maandag 1 augustus 2022 @ 09:18:
Je krijgt het advies om /dev/sdb te gebruiken in de commando's, dat is niet voor niets
De eerste 'disk' is sda, de tweede sdb enz. Als je boot van een SD kaartje zal dat sda zijn en je USB stick is dan sdb. Op sda kun je 'niks' want daar ben je van gestart en die is in gebruik.

Dat gezegd hebbende is de kans groot dat je USB stick kapot is, been there done that. Heb zelf de ervaring dat die dingen soms USB sticks vreten en heb betere ervaringen met SD kaartjes en nog beter met SSD via USB.

Fair enough. De reden dat ik stoïcijns /dev/sda blijf proberen is omdat "sudo parted -l" aangeeft dat de SD naar /dev/sdb verwijst en de "Sandisk Ultra Fit" (de USB stick) naar /dev/sda.

Vermoedelijk dus om hetgeen wat hierboven gemeldt wordt.
Ik ga het proberen door met een schone SD install te booten en dan de USB erbij te prikken.

Als de USB stick stuk is, so be it. Ik wil graag zoveel mogelijk 'salvagen'.

Om je enigszins gerust te stellen: er komt vandaag een SSD, want ik vermoedde al dat USB stick uiteindelijk geen toekomstbestendige optie is.

Waarschijnlijk heb ik sowieso m'n glazen ingegooid door zo'n Ultra Fit te kiezen, dat ding wordt echt ontiegelijk warm .

[Rouwette]

Ik denk niet dat deze volledig stuk is, ik heb met deze truck meerdere SD kaartjes een 2de leven kunnen geven.

[Rutger]

Rouwette schreef op zondag 31 juli 2022 @ 22:14:
[...]
start de pi met een werkende sd/usb (frisse install) en plug erna, na opstarten, de corrupte erbij

ninjazx9r98 schreef op maandag 1 augustus 2022 @ 09:18:
Je krijgt het advies om /dev/sdb te gebruiken in de commando's, dat is niet voor niets
De eerste 'disk' is sda, de tweede sdb enz. Als je boot van een SD kaartje zal dat sda zijn en je USB stick is dan sdb. Op sda kun je 'niks' want daar ben je van gestart en die is in gebruik.

Dat gezegd hebbende is de kans groot dat je USB stick kapot is, been there done that. Heb zelf de ervaring dat die dingen soms USB sticks vreten en heb betere ervaringen met SD kaartjes en nog beter met SSD via USB.

Helaas, geen verandering.

Als ik de USB stick er in prop krijg ik meteen de prompt:

code:

 Error mount /dev/sda2 at /media/pi/rootfs: cannot mount /dev/sda2 read-only

"sudo fsck /dev/sda2" geeft dan ook (uiteraard) dezelfde errormelding

"sudo parted -l" geeft 'm overigens ook al aan:

code:

Warning: Unable to open /dev/sda read-write (Read-only file system). /dev/sda has been opened read-only.
Model: Sandisk Ultra Fit (scsi)
Disk /dev/sda: 30.8GB

Ik heb overigens ook nog Ubuntu Gnome Disks geprobeerd.
Daarmee de boot f:\ gecontroleerd, waarna deze aangeeft dat hij corrupt is en gerepareerd moet worden.
Drie keer raden of de optie "Repair drive" grijs blijft omdat het een read-only file system is

Lijkt het dan echt op een pech gehad gevalletje? Ga terug naar start zonder startgeld?

[ninjazx9r98]

@Rutger
En dan heb je opgestart met een verse werkende SD kaart en stop je de USB er pas in als het booten helemaal klaar is?
Wat geeft een parted -l of een fdisk -l voor de USB erin gestoken is?
De mount lijkt aan te geven dat de USB al in de PI zit tijdens het booten en dat er ergens een mix oid ontstaat.
Normaal zou een mount niet zomaar uitgevoerd worden als je een USB stick er indrukt.

[ Voor 12% gewijzigd door ninjazx9r98 op 01-08-2022 19:27 ]

[Rutger]

ninjazx9r98 schreef op maandag 1 augustus 2022 @ 19:17:
@Rutger
En dan heb je opgestart met een verse werkende SD kaart en stop je de USB er pas in als het booten helemaal klaar is?
Wat geeft een parted -l of een fdisk -l voor de USB erin gestoken is?
De mount lijkt aan te geven dat de USB al in de PI zit tijdens het booten en dat er ergens een mix oid ontstaat.

Ik heb hem inderdaad er pas ingestopt nadat hij geboot is, vervolgens krijg ik de error prompt.

parted -l geeft me alleen de SD kaart:
Model: SD SU16G (sd/mmc)
disk /dev/mmcblk9: 15.9GB

fdisk -l geeft me:
/dev/ram1 t/m /dev/ram/15
/dev/mmcblk0

Het vreemde is, dat ik vervolgens wel via de file explorer in de USB stick kan navigeren, maar wederom alles is read-only. Edit: nadat ik 'm in de Pi stop wanneer de volledige boot is afgerond.

[ Voor 4% gewijzigd door Rutger op 01-08-2022 19:31 ]

[ninjazx9r98]

Ah, daar zie ik meteen mijn denkfout, stom De SD kaart wordt natuurlijk nooit een sda in dit geval, zie het nu aan de device file.
Snap alleen niet waar de mount vandaan komt, doe jij dat? Normaal gesproken gebeurt dat niet automatisch.
Met een schone installatie op SD zou er geen mount moeten plaats vinden, het klinkt allemaal een beetje vreemd wat er gebeurt.

[Rutger]

ninjazx9r98 schreef op maandag 1 augustus 2022 @ 19:39:
Ah, daar zie ik meteen mijn denkfout, stom De SD kaart wordt natuurlijk nooit een sda in dit geval, zie het nu aan de device file.
Snap alleen niet waar de mount vandaan komt, doe jij dat? Normaal gesproken gebeurt dat niet automatisch.
Met een schone installatie op SD zou er geen mount moeten plaats vinden, het klinkt allemaal een beetje vreemd wat er gebeurt.

Ik doe niks anders dan dat ding in m'n Pi priegelen
Dus hij lijkt idd een soort auto-mount te doen.

Ah, na een snelle Google en controle in de file explorer bij
Preferences > Volume Management
Staat er een checkbox aan: "Mount removable media automatically when they are inserted"
Dat uitgevinkt en hij auto-mount inderdaad niet meer.

Verandert overigens niks aan het probleem, de USB stick blijft read-only en mag niks

[Rouwette]

Rutger schreef op maandag 1 augustus 2022 @ 19:45:
[...]


Ik doe niks anders dan dat ding in m'n Pi priegelen
Dus hij lijkt idd een soort auto-mount te doen.

Ah, na een snelle Google en controle in de file explorer bij
Preferences > Volume Management
Staat er een checkbox aan: "Mount removable media automatically when they are inserted"
Dat uitgevinkt en hij auto-mount inderdaad niet meer.

Verandert overigens niks aan het probleem, de USB stick blijft read-only en mag niks

Welke melding krijg je precies? Als ik google zou "killall nautilus" of "killall nemo" iets kunnen oplossen.

[ninjazx9r98]

Dan is het zo goed als zeker een gevalletje stuk.
Hadden wij op het werk ook met twee PI's die we gebruikten voor een monitoring dashboard op twee TV's.
Diverse merken en types geprobeerd, allemaal binnen notime kapot, soms een paar keer te redden met een nieuw image maar heel snel toch kapot. Uiteindelijk daar gekozen voor PXE boot en thuis SSD via USB.

[Rutger]

Rouwette schreef op maandag 1 augustus 2022 @ 19:49:
[...]

Welke melding krijg je precies? Als ik google zou "killall nautilus" of "killall nemo" iets kunnen oplossen.

fsck weigert dienst vanwege de read-only property:
fsck.ext4: Read-only file system while trying to open /dev/sda2
Disk write-protected; use the -n option to do a read-only check of the device

killall nemo / killall nautilus schijnt slechts alle nemo en nautilus processen te killen, maar beide zijn niet actief:

code:

killall nautilus
nautilis: no process found
killall nemo
nemo: no process found

ninjazx9r98 schreef op maandag 1 augustus 2022 @ 19:50:
Dan is het zo goed als zeker een gevalletje stuk.
Hadden wij op het werk ook met twee PI's die we gebruikten voor een monitoring dashboard op twee TV's.
Diverse merken en types geprobeerd, allemaal binnen notime kapot, soms een paar keer te redden met een nieuw image maar heel snel toch kapot. Uiteindelijk daar gekozen voor PXE boot en thuis SSD via USB.

Ik ben er ook bang voor.
Inmiddels ligt er een SSD incl. enclosure naast me, lijkt helaas de volgende stap.

[Rutger]

Naar aanleiding van https://askubuntu.com/que...turn-write-protection-off nog een optie geprobeerd:

"sudo hdparm -r0 /dev/sda2"
Geeft de mooie output:

code:

/dev/sda2:
 setting readonly to 0 (off)
 readonly              = 1 (on)

De USB stick weigert mee te werken.

[Rutger]

Even een update om geen lossie eindjes achter te laten.
Well... soort van.

Ik heb het niet kunnen fixen. Ik ben dit weekend gegaan voor een nieuwe installatie op een SSD.
Ik moet nog even kijken of de backups die ik via HA maakte ook in mijn backup van de RPi terecht zijn gekomen, dan kan ik de instellingen relatief makkelijk terugzetten.

Anders is het opnieuw beginnen, wat geen regelrechte ramp is, ik had (nog) niet zo heel veel in HA geregeld.

[superduper]

Dit is toch echt de achilleshiel van de PI en dit soort oplossingen. En volgens mij ook vanwege het echt ontbreken van een poweroff.

Ik heb 2 Pis draaien: domotics (continue) and octoprint (af en toe als ik mijn 3D printer aanslinger). Meerdere keren per jaar kom je erachter dat de SD kaart stuk is en kan je weer een backup terug zetten op een nieuwe.

blijft klungelen.