Add ability to power off Rasperry Pi safely via PrusaLink

[bearclaws8]

After installing PrusaLink I was unable to find a way to safely shutdown my Raspberry Pi while running PrusaLink. I did not see a way to do it via the webUI nor did the Raspberry Pi respond to "sudo shutdown now" via SSH (I swear I wasn't doing anything wrong :upside_down_face:). I understand that most users will have these up running 24/7 but I think enabling an easy way (even if buried in a settings menu) for a user to safely shut down the pi would be helpful and prevent SD card damage or corruption.

The same could be said for adding the ability to safely restart considering that sometimes the best troubleshooting step is a simple restart. And pulling the plug (or pushing the power button) each time tends to corrupt cards and OS files over time.

(maybe we could even team this up with some wake on LAN setting being enabled if someone is using a wired network. But that would be a separate issue to track.)

[bearclaws8]

Possibly related. Would a print job from PrusaLink have the ability to recover after a power outage the same way printing from the local printer SD card does? If not, is that something that could be integrated into a safe shutdown strategy? Or is that not possible because PrusaLink does not interface with the same software running on the printer display and local printer SD card (possibly similar to #844 and/or #847). This may be less related to this item and more a comment to place in one of the other issues, let me know if you want me to move this extra question.

[TojikCZ]

I want to make Power Panic work, but I might not get the time to do it. The safe power off thing is easier, i was just hoping we wouldn't need it, but i guess that went beyond the scope, we this might be a worthwhile option now

[bearclaws8]

Is it possible to not require the printer to be rebooted every time the pi with Prusa Link is restarted? When trying to install extra packages or additional hardware (e.g. RTC on pi) we have to toggle the pi's power manually which causes the connected printer to restart. I worry that this can cause unnecessary wear to the printer. Please consider this change if you are able to enable shutdown and reboot commands in the next rev.

Another thing to note for anyone trying to reboot or shutdown over SSH, your terminal will hang after you try to run these commands and you will not see an error message nor will your pi reboot or shutdown. If these commands were disabled it would be nice to get an error message instead of a hanging SSH connection.

[TojikCZ]

Hi, I have experimented with disabling the reboots temporarily, but that just puts a lot of extra wear on the eeprom in the usb communications chip. You can disable them yourself, you just need to re-enable them for firmware flashing later.

The reset / non reset mode ones https://cfl.prusa3d.com/display/PI3M3/UsbSerial+commands

I will not do anything with how SSH works, it is not really in the scope for prusalink

[TojikCZ]

Also, power panic is being implemented. Woo :partying_face: https://github.com/prusa3d/Prusa-Link/pull/896

[bearclaws8]

Hi, I have experimented with disabling the reboots temporarily, but that just puts a lot of extra wear on the eeprom in the usb communications chip. You can disable them yourself, you just need to re-enable them for firmware flashing later.

I suppose added wear on the fans at a restart when they spin up for the check is easier to repair in the long run than wear on the eeprom. Thanks for following up.

Any update on permitting PrusaLink to initiate a restart/shutdown of the pi instead of pulling the plug?

[chevdor]

I got my sdcard corrupted after 1 week of using Prusalink so I think a solution to this issue is more than required.

Ideally though, what should be done is have the / partition mounted as R/O so that a wild shutdown (ie what everybody does since there is no other option) at least does not damage the OS (as it happened in my case).

I checked the current state:

/dev/mmcblk0p2 on / type ext4 (rw,noatime)
devtmpfs on /dev type devtmpfs (rw,relatime,size=88508k,nr_inodes=22127,mode=755)
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,nodev,size=87920k,nr_inodes=819200,mode=755)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate,memory_recursiveprot)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
bpf on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,relatime,mode=700)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=30,pgrp=1,timeout=0,minproto=5,maxproto=5,direct)
mqueue on /dev/mqueue type mqueue (rw,nosuid,nodev,noexec,relatime)
sunrpc on /run/rpc_pipefs type rpc_pipefs (rw,relatime)
debugfs on /sys/kernel/debug type debugfs (rw,nosuid,nodev,noexec,relatime)
tracefs on /sys/kernel/tracing type tracefs (rw,nosuid,nodev,noexec,relatime)
fusectl on /sys/fs/fuse/connections type fusectl (rw,nosuid,nodev,noexec,relatime)
configfs on /sys/kernel/config type configfs (rw,nosuid,nodev,noexec,relatime)
/dev/mmcblk0p1 on /boot type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro)
tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=43956k,nr_inodes=10989,mode=700,uid=1000,gid=1000)

I guess prusalink needs some R/W storage for logs and stats but those should be split from the OS and the core Prusalink software so that prusalink can start no matter what and at worst, some logs/user files get corrupt. This is not great but better than having to re-burn a sdcard or worst, buy a new one...

I am managing a douzen of RPi (3B+) in R/O mode and keep keep cutting them power several times a week for year and never got an issue. But those are totally R/O except some tmpfs for whatever needs to be writtable when the RPi is on.

[chevdor]

Best option so far:

ssh jo@prusapizero -i ~/.ssh/whatever.pub "sudo shutdown -h now"

[TojikCZ]

I think that even having RO partitions on an SD card that has the wear leveling implemented wrong wouldn't save us. I heared the SD cards are sometimes moving blocks of memmory through volatile storage, when the power is cut, that block is lost, possibly corrupting the whole thing. I didn't test that, but my SD cards just refuse to die. I can add an api endpoint for safe shutdowns. Just didn't get around to it yet. Not promissing anything, but i'll try to keep it in mind

[chevdor]

I had very good results with R/O RPi only using RAM as tmpfs and being abused multiple times a week, for years.

Ideally, the printer, when detecting a brown out, should send a message (serial or GPIO) to the RPi to initiate a shutdown. I am not sure how many caps are on the Einsy board and if enough power would allow suporting the RPi until proper shutdown. If this is not enough, a simple option (although it take a bit of room) is to add a cap to the RPi to buy a bit of time.

IMO, the solution should be both. The OS + Prusalink software should be on a R/O partition. That would limit the risks already greatly. And for the rest of the data (Is there any persistent storage btw ? Does the RPi need to store anything on the sdcard after the initial setup boot ? if not, RAM tmpfs garanties zero problem).

[Charly-2]

Hi I also had to reimage my Raspberry 2W with Prusalink in my i3 MK3S/+ for two times! As I don't print all the time, I switch off the printer. This damaged the filesystem on SD-Card two times (out of maybe 30). So, a way for a clean shutdown would help very much! Btw.: All my other Raspberries seem to have a R/O-Filesystem, as I never had a problem after uncontrolled power-off (from grid).

[chevdor]

A shutdown button in prusa connect would be nice... For now, I put my ssh pub key in the RPi and I use:

prusalinkshutdown () {
    ssh jo@prusapizero -i ~/.ssh/id_rsa.pub "sudo shutdown -h now"
}

It is not ideal but I did not have an issue with SD Card corruption since I do that.