I have searched the existing open and closed issues: yes
Required Information
DietPi version
G_DIETPI_VERSION_CORE=9
G_DIETPI_VERSION_SUB=6
G_DIETPI_VERSION_RC=1
G_GITBRANCH=‘master’
G_GITOWNER=‘MichaIng’
Distro version | bookworm
Kernel version | Linux DietPi 6.1.0-23-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.99-1 (2024-07-15) x86_64 GNU/Linux
Architecture | amd64
SBC model |Native PC (x86_64), Intel NUC
Additional Information (if applicable)
Software title | Dietpi apt upgrade
Was the software title installed freshly or updated/migrated: updated to DietPi v9.6.1
Can this issue be replicated on a fresh installation of DietPi? N/A
← If you sent a “dietpi-bugreport”, please paste the ID here → N/A
Bug report ID | N/A
Steps to reproduce
… I ran sudo apt upgrade, in response to notice in Message of the Day.
… Once update completed (no errors I could see), I issued a reboot.
… Upon successful restart, no matter what command I issue, for example ‘sudo detpi-launcher’, I get a dialog that says "RootFS is currently set to “Read Only…etc.” . Screen shot of the dialog attached.
This exact thing happened the last time I did an ‘upgrade’, and in an effort to resolve it myself by hitting up google, I managed to make the situation much worse by, among other things, completely wiping out a 4TB drive with all my movies/shows//music on it. I didn’t want to make that mistake again, so I came here right away. (I had to re-install dietpi to recover the first time this happened)
Note that I had to issue some of these commands with sudo, otherwise I get Operation not permitted’. I assume you know this, but mentioned it just in case.
Note also that I have three external USB 3 hard drives mounted but physically disconnected from the NUC…didn’t want to risk losing data on them.
I noted above that I had several external USB drives mounted but disconnected to avoid possible data loss. But note that the issue I described in my first post occurs whether ort not the drives are physically attached.
My system is booting from eMMC. Note that the last time this problem occurred on this NUC (which was two Dietpi versions ago), I had the NUC booting from an SSD mounted inside the NUC, so on the surface, it appears that this ‘Upgrade’ problem is unrelated to what media the OS is installed on.
dietpi@DietPi:/$ sudo touch /demo.file
dietpi@DietPi:/$ ls
bin boot demo.file dev etc home lib lib64 lost+found media mnt opt proc root run sbin srv sys tmp usr var
dietpi@DietPi:/$
OK, so where does that leave me? If I ask Google what to do, it gives me a command to try to mount the rootFS, and I recall issuing that command the last time this happened, and it didn’t help.
Do you figure I’m out of luck again? Re-install Dietpi?
It actually appears that it’s all working again. Here’s the sequence of events that led to a “fix”:
Issue “sudo apt upgrade”. Appears to succeed without error. Reboot NUC (for good measure)
After restart, issue “sudo dietpi- launcher”. Error dialog, as per my first post, above.
Shut down NUC, then unplug all three of the USB drives.
Restart the NUC. Executing “sudo dietpi-” still causes the error shown in my first post.
Shut down the NUC.
Plug all three USB drives back in again, same port each was in before.
Restart NUC, and all seems OK now. I can issue commands fine.
I will report back after I’ve sorted out the drive mounts again. Crossing my fingers that the simple act of mounting one or more of those drives doesn’t wipe them clean…
Replying to self to note that the story gets a bit weirder: I rebooted the NUC once again, and now all the original USB drive mounts are restored, so I didn’t have to re-establish them using dietpi-drive_manager.
