You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Audio playback (spotify to a single zone was tested) still works after reboot.
Then upgraded to a 64-bit kernel by putting arm_64bit=1 in /boot/config.txt. Stuff still works! So now there's a 64-bit kernel and 32-bit system, and everything is up-to-date.
Finally upgraded to the latest Raspberry Pi OS (from Debian Bullseye), first changed buster->bullseye in /etc/apt/sources.list and /etc/apt/sources.list.d/raspi.list. Then:
sudo apt update
sudo apt upgrade
At this point I tried to run sudo apt full-upgrade but ran into the error
libc6-dev : Breaks: libgcc-8-dev (< 8.4.0-2~) but 8.3.0-6+rpi1 is to be installed
At this point AmpliPi stopped working... And the config script doesn't recognize that we're on an armv7 architecture, which is correct. Now the kernel is running as aarch64, so the config script needs to be updated to recognize that. I temporarily forced the config script to accept that we are on an arm system and ran configure.py --os-deps --python-deps. Now everything is happy and AmpliPi works again! I suspect the switch from Python3.7->Python3.9 messed up the virtual environment.
Forgive me if I sound dumb for asking, but what exactly is left to do here? I see "The system is still 32-bit", but I'm not sure what all would need to be done to resolve this.
@stoppablemurph, "system is 32-bit" means all userspace packages are still 32-bit. Turns out trying to change an entire running OS from 32-bit to 64-bit on-the-fly is tricky and error-prone 😆
The other option for ending up with a 64-bit system would require flashing an entire pre-made image on the Pi through the service USB port, like we do at MicroNova before shipping. Not impossible, but certainly a lot more annoying than pressing a button.
Activity
Lohrer commentedon Jun 3, 2022
Tested running:
Audio playback (spotify to a single zone was tested) still works after reboot.
Then upgraded to a 64-bit kernel by putting
arm_64bit=1in/boot/config.txt. Stuff still works! So now there's a 64-bit kernel and 32-bit system, and everything is up-to-date.Finally upgraded to the latest Raspberry Pi OS (from Debian Bullseye), first changed buster->bullseye in
/etc/apt/sources.listand/etc/apt/sources.list.d/raspi.list. Then:At this point I tried to run
sudo apt full-upgradebut ran into the errorAttempting to resolve:
At this point AmpliPi stopped working... And the config script doesn't recognize that we're on an armv7 architecture, which is correct. Now the kernel is running as aarch64, so the config script needs to be updated to recognize that. I temporarily forced the config script to accept that we are on an arm system and ran
configure.py --os-deps --python-deps. Now everything is happy and AmpliPi works again! I suspect the switch from Python3.7->Python3.9 messed up the virtual environment.TODO: The system is still 32-bit.
stoppablemurph commentedon Oct 23, 2022
Forgive me if I sound dumb for asking, but what exactly is left to do here? I see "The system is still 32-bit", but I'm not sure what all would need to be done to resolve this.
linknum23 commentedon Oct 24, 2022
The CM3 module has a 64-bit pi on it that we are running a 32-bit OS on.
There are 2 mains tasks to do a 64-bit upgrade:
The complicated part if finding an upgrade path that works and isn't too cumbersome for the user..
Lohrer commentedon Oct 25, 2022
@stoppablemurph, "system is 32-bit" means all userspace packages are still 32-bit. Turns out trying to change an entire running OS from 32-bit to 64-bit on-the-fly is tricky and error-prone 😆
The other option for ending up with a 64-bit system would require flashing an entire pre-made image on the Pi through the service USB port, like we do at MicroNova before shipping. Not impossible, but certainly a lot more annoying than pressing a button.