Read-only file system still in effect and locked (Originally: Doesn't work with sudo password with whitespace in it)

[Zebrazilla]

Had to change sudo password to run this as the one I had contained a whitespace, which caused a failure when the script checked that the sudo password was correct. A minor nuisance since all I had to do was change the password, but still an issue.

[ryanrudolfoba]

I tried to replicate i reset my sudo password to have a whitespace and the script still parses it correctly

[Zebrazilla]

Very strange. I changed the password and it now clears the checking phase, but now it seems to fail in disabling read-only for the filesystem.

[Zebrazilla]

An update to this: I've rebooted several times with the new password, still the same issue. I've also tried doing sudo steamos-readonly disable, checking status with sudo steamos-readonly status, and setting back. I've tried changing passwords again to something different, simple ones with just a letter or two, or a few letters and numbers. Still the same issue.

I don't know how this connects to the initial password not working. That first password had a whitespace at the end of it. It might've been this issue all along, whatever this issue is. Quite strange.

I could go about doing the changes manually, but I really want the service and the QOL that this script brings.

[ryanrudolfoba]

can u share the steps how u are to replicate it?

[Zebrazilla]

can u share the steps how u are to replicate it?

Just following the process as laid out in the installation steps:

1. opening konsole
2. cloning the repo
3. chmod for execute on the install script
4. running the script
5. entering the password
6. choosing refresh rate setting

It succesfully creates the files in /home/deck, but anything needing sudo fails, despite the script having checked and verified that the password is correct.

I just attempted to manually run one of the early commands in the script requiring sudo access which should just work, but the result is bewildering to me:

The password is correct, otherwise it would have said so, but it seems I'm still not being granted proper sudo access. Very strange.

Regarding sudo, my deck is stock besides having installed Decky Loader, which also needed sudo access. While that was a while back now, it worked at the time, and I haven't touched the desktop system since really.

Whatever the issue is, it's clearly not related to the script at least. Why I'm not getting proper sudo access is beyond me atm. though..

[Zebrazilla]

I finally found the culprit to be Tailscale, which I had temporarily forgotten that I had installed recently.

I had to issue the command sudo systemd-sysext unmerge in order to temporarily disable it (re-enabling it later with sudo systemd-sysext merge), which allowed changes to the filesystem at /bin/, and as such the script now works. I've verified and 70 hz now works like a charm.

Thank you for the script, this feels amazing for my eyeballs and braincells!

In case anyone else stumbles upon this issue, it may also be applicable to TunnelDeck (OpenVPN) if installed via Decky Loader. See this issue on their repo.

[Zebrazilla]

Still curious why the initial issue was that my original password didn't work, I changed it back and re-ran the script, and ran into the original issue of the script not being able to verify it.

To be clear, my original password ended with a whitespace. I tried changing password to one with a whitespace in the middle somewhere, and that worked fine. So it may very well be that the script can't handle passwords with whitespaces at the end.

If you can double-check that, it may help others who also are mad enough to have whitespaces at the end of their passwords 😅

(Sorry about the mess of an issue that this issue turned out to be. I swear issues on Github don't usually turn out like this for me)

[ryanrudolfoba]

no worries. Im able to replicate the whitespace issue in password. It only happens if the whitespace is at the end of the line.

quick fix is to add IFS=