I’m super glad to hear that backups and failed-update-protection is on the roadmap, as this is the second time I’ve “bricked” my amplipi after a major update. (Once going from 2->3 and now from 3->4.) It’s just sitting there, sad and blinking its red light at me. Which is kinda weird as I don’t heavily modify my OS or anything; just adding a NFS mount to my NAS is all I ever do.
Last time, I had to use Etcher to re-flash the controller. I presume I do this time as well. However, when I went to the Github page, I notice the instructions still need to be updated to 0.4 and there is no compiled build on the releases page for the latest version.
Is it possible to upload the latest image and update the instructions? Thank you.
Bad luck @TheCraiggers, that is annoying. My upgrade went through ok, although I did update to one of the pre-release 0.4 versions before the 0.4 release.
I’m sorry to hear the update went so poorly. We are working on updating the image to 4.3 by the end of the week, barring any unforeseen bugs during testing.
In the meantime you can still flash with the older version and then update the AmpliPi. The worry would then be if the same thing happens. I am going to send you an email and create a support ticket to try and resolve this.
In 4.4 during an upgrade we started saving the config before and after. This is likely recoverable via an ssh connection to your unit.
From the troubleshooting portion of our manual manual:
These backups are dated tarballs stored at /home/pi/backups. This tarball contains the entire /home/pi/.config/amplipi directory. To restore this backup:
Stop the AmpliPi service (systemctl stop --user amplipi as the pi user).
Unpack a backup tarball and overwrite the contents of .config/amplipi (something like tar --force-local -xvzf backups/config_2024-08-22T12:42:31-04:00_pre-fw-upgrade.tgz -C /). Here we use config_2024-08-22T12:42:31-04:00_pre-fw-upgrade.tgz as an example backup file.
Start AmpliPi again (systemctl start --user amplipi).`
