Hi @dgj ,
I did all things above AND changed the firewalld-settings mentioned in https://discuss.freedombox.org/t/debian-12-bookworm-release-and-upgrading/2591/7.
It worked on two boxes.
Cheers Uli
1 Like
Yes, changing to “DefaultZone=external” in /etc/firewalld solved it.
I can access Plinth and ran Diagnostics. Everything has passed!
Thanks, everyone 
P.s. Nice to see some familiar names popping up in the forum again.
2 Likes
Yes, changing to “DefaultZone=external” in
/etc/firewalldsolved it.I can access Plinth and ran Diagnostics. Everything has passed!
The change in /etc/firewalld/firewalld.conf of DefaultZone=external to DefaultZone=public seemed suspicious since, according to my notes, I had never touched that file. Choosing to accept the packager maintainer’s version when I attempted the manual upgrade (selecting Y at the conffile prompt) seems to have been the wrong choice for me. That said, I noticed that one of my FreedomBoxes that did successfully automatically upgrade without any issue (besides a minor Mediawiki hiccup) ended up with DefaultZone=external in its firewalld.conf file.
The box that had a successful automatic upgrade from Bullseye to Bookworm (originally spun up 2022-09-01) now has 3 files in /etc/firewalld/:
firewalld.confwithDefaultZone=external. Modified 2023-06-11.firewalld.conf.oldwithDefaultZone=public. Modified 2023-01-06.firewalld.conf.dpkg-oldwithDefaultZone=external. Modified 2022-08-17.
The FreedomBox that had the failed upgrade to from Bullseye to Bookworm (originally spun up on 2022-05-09) and which I reverted to an evening backup had in its backup image:
firewalld.confwithDefaultZone=external. Modified 2022-05-09.firewalld.conf.oldwithDefaultZone=public. Modified 2021-02-01.
When I next attempt an upgrade, I’ll try making sure DefaultZone=external remains in /etc/firewalld/firewalld.conf.
2 Likes
I have now been without my Freedombox for four days. I feel I have tried most of the above (I am confused about this Firewall stuff - is that the original problem).
I just want it to work like it did on Saturday… been following the step by steps (I appreciate the suggestions) but I am getting this:
**matthew@freedombox**:**~**$ sudo DEBIAN_FRONTEND=noninteractive apt-get dist-upgrade
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
1 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n] y
Setting up initramfs-tools (0.142) ...
update-initramfs: deferring update (trigger activated)
Processing triggers for initramfs-tools (0.142) ...
update-initramfs: Generating /boot/initrd.img-6.1.0-9-armmp-lpae
W: Possible missing firmware /lib/firmware/imx/sdma/sdma-imx7d.bin for built-in driver imx_sdma
W: Possible missing firmware /lib/firmware/imx/sdma/sdma-imx6q.bin for built-in driver imx_sdma
zstd: error 70 : Write error : cannot write block : No space left on device
E: mkinitramfs failure zstd -q -9 -T0 70
update-initramfs: failed for /boot/initrd.img-6.1.0-9-armmp-lpae with 1.
dpkg: error processing package initramfs-tools (--configure):
installed initramfs-tools package post-installation script subprocess returned error exit status 1
Errors were encountered while processing:
initramfs-tools
E: Sub-process /usr/bin/dpkg returned an error code (1)
Any idea what I should do next?
My current thought is get rid of the Freedombox and go back to a hosted Matrix server or use Telegram and stop trying to be all ethical and open source - but hopefully that passes.
Hello, I’m no expert, but I believe this line might indicate that your boot partition might not have enough space to complete the operation.
Maybe you could try to run sudo apt autoremove and see if removes some of the old kernels. I believe you can target specific packages with sudo apt autoremove --purge <kernel-package-name>, but personally I would just try the previous command.
As I said, I’m no expert. Follow this advice at your own risk. I’d recommend that you do your due diligence before attempting this.
After freeing space in your boot partition, run the upgrade process again.
1 Like
You are right, I had the same issue (and mentioned it). I had 4 kernels and initrd files in /boot so I ran “sudo apt remove” for the two oldest ones. @matthewguy you can check the package names by running e.g. dpkg -l “linux*”
After this, you can manually launch the upgrade again (sudo apt update, sudo apt upgrade, sudo apt full-upgrade). After it is finished, you may still have the firewall issue (default zone set to public, need to change it to external). Hopefully everything will work then.
I managed to get the bookworm update installed (refreshing app list didn’t work due to an expired repo key), later the boot partition was full which I cleared. No my freedombox is at v23.6.2. The forums says 23.11 is the most recent. Is that version still not in stable and thus is it correct that that version is not yet installed?
I also have 23.6.2 after migrating to bookworm.
The post about 23.11 mentions experimental. According to https://packages.debian.org, 23.11 is still only in experimental (not even in unstable = sid). https://wiki.debian.org/DebianExperimental says that “experimental isn’t a complete distribution, it can work only as an extension of unstable.”
So to me it looks normal that we don’t have this version now.
1 Like
Update - I am back with a working Pioneer FreedomBox.
Thank you for your help everyone. I deleted the files causing my boot disk to be full, ran the update - all looked good and then it would not boot. I may have fiddled around too much and broke something in my attempts to make it all work. It was a busy week at work and I did not have the time (or patience) to sit down and be more forensic in my efforts.
In the end I got a blank microSD card and started again from scratch. It seemed the simpler option at that point.
I think ultimately it was the firewall issue that was messing with me but did not really understand that at the time. It has rather dented my faith in using the FB as anything but a chat server for the family.
I will try to ensure I do not end up in this position again when I have time (backups etc) but I am a little disappointed at the update process this time.
3 Likes
And another question, is the firewalld.conf with DefaultZone=public necessary to be changed back to DefaultZone=external ? I use wireguard vpn to access the VPN from the outside my LAN. Without VPN, the freedombox should not be reachable from outside the LAN. Everything seems to be working fine however.
My only issue on my raspberry pi for the upgrade was with Apache not starting due to this error:
Cannot load /usr/lib/apache2/modules/libphp7.4.so into server
Solved this problem by running:
sudo a2dismod php7.4
sudo systemctl restart apache2
All is well with Apache now and I can get to the website interface.
Unfortunately, this also applies to me. My sister had just asked how I could get her setup with a similar home server a couple months ago, and I am more hesitant now than I was before to recommend a FreedomBox.
That said, I love this project, I love self-hosting my data, and I would be interested in focusing on how to improve the upgrade experience for the future. Some open questions: What led to such a problematic upgrade? What needs to be done so it never happens again? How can we the community help?
2 Likes
I am not sure upgrade problems can be avoided in general.
A way to mitigate upgrade problems could be:
- by default freedombox are not migrated automatically to a new stable Debian version
- the migration is only attempted by users with some experience and willingness to deal with problems
- these users report problems, try finding solutions, document them and write sufficient (and reasonably easy) guidance to fix all the detected problems
- when that is ready, users are invited to check the guidance and upgrade
Some coordination may be useful, this forum is already a nice tool to share problems and solutions. If we want to do more than, that requires volunteers and and some kind of organization.
I am not sure how long would be needed until upgrade by everyone, perhaps one or two months?
3 Likes
Hello,
I find myself in full agreement with the idea you’ve put forward to mitigate upgrade problems in future Debian releases. The strategy you suggested - to initially limit the migration process to experienced users who are prepared to troubleshoot issues - seems like a very sensible approach.
Perhaps, FreedomBox could include a toggle option for ‘Advanced Users’ within the interface. Selecting this option would allow the distribution upgrade to proceed as normal for those users. Those who do not select the option would have their upgrade process delayed until all known issues have been identified and resolved. Users could be notified about the pending distribution upgrade and assured that it will be performed automatically in the near future once it’s safe to proceed.
As a platform built on Debian, FreedomBox has a reputation for stability, which is one of the main reasons users like us have trusted it to host and manage our sensitive information at home. Encountering issues during the upgrade process can understandably be disheartening, but it’s essential to remember that the upgrade issues are not a reflection of FreedomBox’s long-term performance or stability.
To share a bit of my own experience, I ended up performing the upgrade manually and was back up and running rather quickly. However, I did experience around five days of downtime while waiting for the unattended upgrade to do its work, which unfortunately didn’t transpire. This interruption significantly impacted my work and home organization routines, highlighting how integral my FreedomBox has become in my day-to-day activities.
But I’d like to encourage everyone who’s currently feeling frustrated - keep going. Yes, these upgrade issues are inconvenient, but remember, they are a part of a major update that comes every two years. The platform continues to improve, and it’s worth staying the course.
Looking forward to hearing more thoughts on this.
3 Likes
I would definitely say that distribution upgrades not be done by default or be a separate option with a big flag warning as to the potential downtime.
An alert on the webgui to notify that a new distro-upgrade is available would be good. For advanced users or those with downtime requirements, it would be a chance to backup and kick off a clone to run while the upgrade is going.
2 Likes
Add me to the list of users whose system is not responding/ down.
It boots to a “debian 12” gui screen with an old user name I haven’t seen for a while. Not sure if I’ve ever used it - maybe when I set up the box in the beginning?
I tried a few passwords, which it soundly rejected. ctrl-alt-f1 finally got me to a text based login that revealed my local IP. So I got on another machine easier to use and SSH into it remotely - I found a password combination that at least isn’t rejected right away - so maybe that’s the right one?
But sadly, it times out after about 3 or 4 minutes.
Can I conclude that I’m on day 3 of an upgrade? I’d like to not lose my server. Any ideas on getting to a terminal screen so I can try “autoremove”, as maybe my machine’s memory is full, as some have mentioned above?
Thank you!
What led to such a problematic upgrade? What needs to be done so it never happens again? How can we the community help?
It is clear that the release upgrade procedure wasn’t tested properly and was rushed. I see no reason why it had to be performed as soon as Bookworm was made stable, since Bullseye will remain old stable until July 2024. There are also unresolved issues on the Git issue tracker such as this and this and this.
Ubuntu has a nice tool/package called ubuntu-release-upgrader-core which eases the process of such upgrades. Rewriting the tool for Debian and using it to perform the release upgrades would be much better for FreedomBox.
The safest way to upgrade to Bookworm is probably to backup all the apps on Bullseye and restore them on a fresh installation of Bookworm.
2 Likes
That’s what I chose to do when my pi4 got stuck on boot. Didnt want to lose time and just went ahead with a clean install. Luckily, I had a good backup set on a seperate drive so Im not too harshly impacted by the process. FBX backup does a good job of backing up your app data and configuration. I will write a seperate post on my experience with this. I would recommend a good seperate backup to everybody (FBX or not) if they’re running their own server.
3 Likes
I have made a new thread to discuss ideas to mitigate upgrade problems:
Please feel free to use this thread to propose further ideas.
3 Likes