White screen VenusOS 3.12 guimods 8.21

[jjduke20147]

Running 3.12 large. Yesterday, updated guimods. All ran fine. Today, one of my ruuvi tags lost its connection to the VRM and the cerbo (I'm remote from the boat.)

While using remote display on VRM, I rebooted Cerbo 2x. The ruuvi did not come back on first reboot but the gui was fine. Before second reboot, I turned the Bluetooth off and on. Then rebooted. The gui did not come back this time. (White screen with buttons to right)

I did a remote update on the cerbo through the VRM to 3.20~26. This didn't fix the gui.

VRM dashboard still works. (Misbehaving Ruuvi still not working).

[kwindrem]

Note that I've seen RuuviTags take a minute or more to be rediscovered after a boot. Also make sure you have fresh batteries. I just needed to replace the batteries in mine because a couple of them were reporting low battery. Low battery can make them intermittently connect to the GX device.

Did you try a reboot after the white screen?

Can you gather logs from your Cerbo. You can use the Backup function inside PackageManger to zip all the logs to /data then scp the zip file to a computer and post here.

The most important log file is /data/log/gui/current since it should identify the problem file.

You might try uninstalling GuiMods and reinstalling it. But with a dead GUI you need to do this from the command line or a blind uninstall which requires inserting a USB stick into the GX device.

I highly recommend NOT running beta firmware on a remote system. It's your responsibility when running beta software that you have a means to recover when issues arrise.You really should have ssh access to your system and have ssh keys set up so you sidestep the issue that sometimes ssh password doesn't survive a firmware update. Shouldn't happen but there have been reports that it does.

[jjduke20147]

The ruuvi is 2 weeks old—I will be checking battery when I’m next on boat but it was offline for 6 hours before I started this. The boat is 3 hours away so probably a week from now before I have direct access. I couldn’t figure out how to reboot remotely so that’s why I tried the remote update. It was 3.12 and the only option was 3.20~26. (It doesn’t seem to be reversible from VRM). Any idea how I can reboot remotely without the GUI? I don’t know much (anything) about ssh. I am willing to figure it out though. I certainly will try to capture all logs and get them to you.  The blind uninstall will have to wait until I can get there. I’d love to do the ssh-remote. Help would be appreciated. (Windows or Mac—I have both and a pi4, too, but I’m new with it)Fully agree with the beta/remote issue. I was running 3.12 when this all happened. The beta load was an attempt to reboot the cerbo and get guimods uninstalled (it had to be re-installed after each venusOS  update before—it was a shot at recovering the gui—didn’t work)I’m not sure, but there might be a reboot function in node red. Do you think that is possible?Sent from my iPhoneOn Nov 18, 2023, at 20:11, kwindrem @.***> wrote: Note that I've seen RuuviTags take a minute or more to be rediscovered after a boot. Also make sure you have fresh batteries. I just needed to replace the batteries in mine because a couple of them were reporting low battery. Low battery can make them intermittently connect to the GX device. Did you try a reboot after the white screen? Can you gather logs from your Cerbo. You can use the Backup function inside PackageManger to zip all the logs to /data then scp the zip file to a computer and post here. The most important log file is /data/log/gui/current since it should identify the problem file. You might try uninstalling GuiMods and reinstalling it. But with a dead GUI you need to do this from the command line or a blind uninstall which requires inserting a USB stick into the GX device. I highly recommend NOT running beta firmware on a remote system. It's your responsibility when running beta software that you have a means to recover when issues arrise.You really should have ssh access to your system and have ssh keys set up so you sidestep the issue that sometimes ssh password doesn't survive a firmware update. Shouldn't happen but there have been reports that it does.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>

[jjduke20147]

Sorry about the email update/no paragraphs. Rookie to GitHub and I shouldn't have used email!!

[5teveO]

I'll jump in on the thread as I also have a white screen just occurred, have been running the system for a few years no drama (running venusos 2.9 - yes waaay overdue for updating) and today came across the white screen. Unfortunately I can't access SSH either.. no idea why as it was active and I only ever use the same variant of password.. so something else is stuffed too. Any chance you could detail how to do a blind uninstall so I can reinstall it, or at least back up the settings and start the system afresh with the latest VenusOS?

Thanks as always in advance

Steve

[kwindrem]

The blind uninstall is documented in SetupHelper's ReadMe.

A firmware update might disable ssh, requiring the password to be reset which of course you can't do because the GUI isn't running.

If you are able to recover, the logs might provide an indication of the cause.

/data/log/SetupHelper /data/log/PackageManager/current /data/log/gui/current (may not be current if start-gui is being used to run the GUI) /data/log/start-gui/current (may or may not be present. (v3.20~???)

A shortcut to getting logs is to use the PackageManager backup function which will create logs.zip on either removable media or /data depending on which option you choose in the menu.

[5teveO]

The blind uninstall is documented in SetupHelper's ReadMe.

A firmware update might disable ssh, requiring the password to be reset which of course you can't do because the GUI isn't running.

If you are able to recover, the logs might provide an indication of the cause.

/data/log/SetupHelper /data/log/PackageManager/current /data/log/gui/current (may not be current if start-gui is being used to run the GUI) /data/log/start-gui/current (may or may not be present. (v3.20~???)

A shortcut to getting logs is to use the PackageManager backup function which will create logs.zip on either removable media or /data depending on which option you choose in the menu.

Thanks for that I'll check it out. I'm sat on the boat so limited resources.. hence me asking as a prequel to getting home. I'll see what I can recover, but honestly apart from the settings which will just save me time, it's about time I updated and this has forced me to do it... So it's actually useful to combat my laziness... I'll update you once I get round to it

[kwindrem]

The procedure is to copy the venus-data-UninstallPackages.tgz file from SetupHelper's directory to a USB stick. Rename this to venus-data.tgz the put the stick in the GX device and reboot twice.

You may also be able to recover by switching to the stored backup firmware.

I have been able to duplicate this problem and it only exists with Venus OS prior to v3.0. I'm releasing SetupHelper v6.1 now to fix it.

[5teveO]

The procedure is to copy the venus-data-UninstallPackages.tgz file from SetupHelper's directory to a USB stick. Rename this to venus-data.tgz the put the stick in the GX device and reboot twice.

You may also be able to recover by switching to the stored backup firmware.

I have been able to duplicate this problem and it only exists with Venus OS prior to v3.0. I'm releasing SetupHelper v6.1 now to fix it.

Thanks for the instructions - I managed to get the gui back up briefly - tried removing and reinstalling the latest setuphelper and it kept white screening.. i suspect something else was wrong, so after a small amount of messing around i used a new card and installed 3.14 onto it.. and setuphelper ect went on no problems.. so all back up and running - probably the card dying as its been running for a good few years with no power downs or reboots

Steve

[kwindrem]

Glad you are back up. I did find a problem running Venus OS prior to v3.0 that caused a white screen. V6.1 of SetupHelper and a bump to other package versions to insure they reinstalled should have fixed it. (The white screen was due to files replaced for other versions but the bug was in SetupHelper.)

[jjduke20147]

Kevin, It appears this issue should really be with Setuphelper not GuiMods.

I have been unable to use GuiMods and/or Setuphelper since I opened this report. A blind uninstall did not "stick" in that each time I did this and re-installed Setuphelper (say, 5.9,, 5.12, 5.16. 5.18, or, now, 6.1), it would appear to be "installed" and on the next reboot, 5.06 would re-appear. It even re-appears on its own after being wiped out (rm directories with Setuphelper and GuiMods in it) when a new VenusOS update occurs.

I tried 6.1 yesterday, through the remote desktop, while following this thread. Here are screenshots from before the attempt to install 6.1 and after but before a reboot.

and...no Remote Desktop GUI after reboot.

normally, a reboot will get me back a GUI and I can uninstall it from the package manager, but normally, I have been doing this while at the boat (3 hour drive away)...until the next VenusOS update...then, Settuphelper 5.06 reinstalls itself and GuiMods 8.11 is stored (not installed)

Right now, I still get VRM, and node-red, so the Cerbo is working, but no RemoteDesktop and, I assume as I am remote from boat, no GUI.

Since I last tried to deal with this in December, I have been either laid up or working so i just accepted that I needed to get sharper on SSH and things like RPI and tailscale so that I can VPN into the Cerbo using a tailnet connection either thru the RPI which I will leave on the boat or, hopefully, using the Cerbo as an exit node (not sure if possible with VenusOS, but hopeful. I'm sorry I was unable to get you the logfiles. They may still be there, but i may have wiped them out when rm'ing the directories.

I plan to go to the boat tomorrow and either SSH into it from a macbook, or RPI to solve this by deleting anything I can to prevent the repetition of 5.06, 5.06, 5.06 . clearly, uninstalling (blind or otherwise) hasn't been working.

OR giving up and doing a fresh installation of VenusOS and reconfiguring the whole Cerbo.

[kwindrem]

It seems like you might have a blind INSTALL or a package directory on a USB stick that's still inserted in the GX device. PackageManager will check removable media for packages and install them from there regardless of auto download and install settings.

It is also easy to get confused about a blind install or uninstall because until recent betas the blind install file needed to be renamed.

If you have auto downloads and updates enabled then I'd check the branch/tag to make sure it is set to latest and not v5.6.

If you do not have auto updates turned on you need to manually install the package. Otherwise the Installed version will stay at the previous version.

BTW, removing the package directory will not uninstall the package. The active files will remain modified and the installed version will stay.

Logs are in a separate directory and any uninstall won't touch them. Also removing the package directory will not disturb them.

New versions of my packages include helper files previously only provided by SetupHelper. This minimizes reliance on a specific version of SetupHelper for package install/unsintall. This started with SetupHelper v6.0 and GuiMods v9.0. GuiMods v8.11 does not have the helper files but should function with an older SetupHelper or the latest. But will fail if you have removed the SetupHelepr directory from /data.

Let me know how it goes. Hopefully we can get this resolved without a Venus OS reimage.

[jjduke20147]

I like your hope! I really did/do lilke GuiMods and the info it gives. It was great.

The only thing I can think of is that the blind install is on the micro-sd card. I didn't think about that until you just mentioned having it on a USB stick. I am 95% sure I renamed the blind uninstall file, but that is definitely a possibility, too.

I didn't have the auto downloads and updates, though at one time I did set the branch tag to 5.xx thinking this would break the 5.06 cycle--it didn't.

I had already uninstalled both packages through the GUI before rm'ing the directories. The GUI didn't have Package Manager at the end of the Settings menu when I left the boat. I rebooted several times, too, and was on VenusOS 3.13 . SetupHelper 5.06 came back with the VenusOS 3.14 update last week, so something didn't uninstall completely.

I did attempt to install 8.11 and it failing makes perfect sense. I had rm'd those directories earlier.

I will keep you posted...hopefully with SetupHelper 6.1 and GuiMods 9.0 installed. If anything, this has been a positive experience because I have learned a ton about linux, SSH, tunneling, Raspberry Pi, wireguard, tailscale, BLE, ... Thank you

[kwindrem]

Yes, blind install and package install (via PackageManager once it is running) works from any removable media including the SD card. I have considered removing the blind install and package directories from removable media but that makes the removable media a one-shot thing so you can't go from system to system and install your standard packages. Maybe more thought is needed. But that won't help you since whatever is causing issues is still on the removable media.

If you have ssh access, you can remove stuff from removable media. Removable media appears in /media. Then there's a directory for each removable media. So something like the following should do the trick:

rm  -rf /media/*/SetupHelper*
rm  -rf /media/*/GuiMods*

Removing /data/SetupHelper will make installs and uninstalls fail. Plus any updated files in the active file system will remain. You'd need to reinstall the package then run an uninstall to actually restore the system.

Probably the best way to restore the system would be to reinstall the Venus OS firmware.

Remove anything from removable media as indicated above then:

rm -r /data/rcS.local followed by switching to the backup firmware then using the on-line update to install the current firmware.

Removing rcS.local will prevent reinstalls should there be things remaining.

The installed versions come from a file I write to /etc/venus so if you did not also remove these then that's why they are showing as installed in PackageManager.

Removing /data/SetupHelper will also cause PackageManager not to run because /service/Packagemanager/run attempts to run /data/SetupHelper/PackageManager/py and that will be missing.

[jjduke20147]

success. blind uninstall setuphelper then reinstall. now on 9.2 guimods and 6.1 setuphelper. here are the logs from the backup. logs.zip

thank you

[kwindrem]

Glad everything worked out. A quick look at the logs didn't show any errors