Upgrade to Bullseye

my ejabberd attachments are not working

message on client states failed to connect to port 5443

any thoughts?

Did you have the unattended upgrade to Bullseye too?

@Avron:
My radicale also has hick-ups, had to create 2 new calendars, error 500. That is surely a different topic. (This happend prior to the upgrade, about 2-3 weeks ago).
And also Syncthing is not running, since 4-6 weeks, I guess. Hope this resolves with the upgrade.

PS: see my EDIT2 in the first post with the broken file. That might be the cause of the failing upgrade.

In Bullseye, python-django-common is now a virtual package provided by python3-django.

On my box (already upgraded to Bullseye), the file /var/lib/dpkg/info/python-django-common.list is empty.

# ls -al /var/lib/dpkg/info/python-django-common*
-rw-r--r-- 1 root root   0 Aug 15 12:52 /var/lib/dpkg/info/python-django-common.list
-rwxr-xr-x 1 root root 195 Jun 14  2020 /var/lib/dpkg/info/python-django-common.postrm

And this package is not installed:

# apt policy python-django-common
python-django-common:
  Installed: (none)
  Candidate: (none)
  Version table:
     1:1.11.29-1~deb10u1 -1
        100 /var/lib/dpkg/status

So the best way is to do a re-install with Bullseye?

I think this problem is related to this comment

When can we expect new images to download for Bullseye? I am running on LIME(1).

Joseph is working updating the build infrastructure to create new stable images. Images should be available in a few days.

Great, I will run a new new install with Bullseye then. It was easy the last time I did.
We have to improve reliability of the FreedomBox in order to make it “mainstream” feasible. What could be the cause of the failure of the upgrade? Did it work for anyone flawlessly? It might be a faulty µSD card on my side which crashed the python-django-common.list file. Therefore, I would like to understand if more users had issues or not with the upgrade.

I did have issues, but not sure if it was the upgrade or maintenance work from my cable provider, which happened around the same time. I was locked out on my box via domain name. TOR and IP still worked, but http only. I went to the GnuDIP page and updated my settings, which did the job. Miraculously my ejabberd config was somehow cured after the update as well.

My pioneer box seems fully functional after upgrade to Bullseye but:

  • cockpit reports that calible content server failed to start (I have not clue what this is)
  • the sources seem to refer to bullseye and some packages are indicated as upgradable:
root@fbox:/etc/apt# cat sources.list

deb tor+http://deb.debian.org/debian stable main
deb-src tor+http://deb.debian.org/debian stable main

deb tor+http://deb.debian.org/debian stable-updates main
deb-src tor+http://deb.debian.org/debian stable-updates main

deb tor+http://security.debian.org/debian-security/ stable-security main
deb-src tor+http://security.debian.org/debian-security/ stable-security main

root@fbox:/etc/apt# cat sources.list.d/*                
# This file is managed by FreedomBox, do not edit.
# Allow carefully selected updates to 'freedombox' from backports.

deb tor+http://deb.debian.org/debian bullseye-backports main
deb-src tor+http://deb.debian.org/debian bullseye-backports main

root@fbox:/etc/apt# apt list --upgradable
Listing... Done
freedombox/stable 21.4.4 all [upgradable from: 21.4.4~bpo10+1]
guile-2.2-libs/stable 2.2.7+1-6 armhf [upgradable from: 2.2.4+1-2+deb10u1]
sshfs/stable 3.7.1+repack-2 armhf [upgradable from: 2.10+repack-2]
tor-geoipdb/stable-security 0.4.5.10-1~deb11u1 all [upgradable from: 0.4.5.9-1]
tor/stable-security 0.4.5.10-1~deb11u1 armhf [upgradable from: 0.4.5.9-1]
root@fbox:/etc/apt# 

Should I try “apt upgrade” in command line?
What is version 21.4.4~bpo10+1 of the freedombox package as compared to 21.4.4?

About reinstall everything from a bullseye image: I don’t know how to restore all the accounts and data from my backups on a fresh image, and whether I should use a backup from before the upgrade to Bulleye or just from now.

It is this issue: calibre: Service tries to start before app is installed (#1982) · Issues · FreedomBox / FreedomBox · GitLab
If you don’t use Calibre, then you can just ignore it.

21.4.4~bpo10+1 is nearly identical to 21.4.4, but 21.4.4 will try to replace fuse with fuse3. (freedombox and sshfs being upgraded at the same time should cause this replacement.)

Before using the command line, have you tried the “Manual Update” feature on the System → Update page of FreedomBox interface?

The following happened in the early morning today (before I tried manual upgrade):
This is from /var/log/unattended-upgrades/unattended-upgrades.log

2021-08-24 06:04:40,653 INFO Starting unattended upgrades script
2021-08-24 06:04:40,669 INFO Allowed origins are: origin=Debian,codename=bullseye,label=Debian, origin=Debian,
codename=bullseye,label=Debian-Security, origin=Debian,codename=bullseye-security,label=Debian-Security, o=Deb
ian Backports,a=bullseye-backports,l=Debian Backports
2021-08-24 06:04:40,673 INFO Initial blacklist: 
2021-08-24 06:04:40,676 INFO Initial whitelist (not strict): 
2021-08-24 06:05:28,615 INFO Packages that will be upgraded: tor tor-geoipdb
2021-08-24 06:05:28,618 INFO Writing dpkg log to /var/log/unattended-upgrades/unattended-upgrades-dpkg.log
2021-08-24 06:08:25,916 ERROR Lock file is already taken, exiting
2021-08-24 06:15:32,505 INFO All upgrades installed
2021-08-24 06:15:36,646 INFO Package freedombox is kept back because a related package is kept back or due to 
local apt_preferences(5).
2021-08-24 06:15:36,820 INFO Package guile-2.2-libs is kept back because a related package is kept back or due
 to local apt_preferences(5).
2021-08-24 06:15:38,645 INFO Package sshfs is kept back because a related package is kept back or due to local
 apt_preferences(5).

The “ERROR Lock file is already taken” appears only once in the log file, so this is new. I did not try anything new yesterday (besides looking into cockpit). Apparently, the tor package was upgraded.

I just tried the manual update in the web interface, the same packages are still upgradable, cockpit now says that freedombox-manual-upgrade.service failed to start.

I could try the command line update but I am a bit worried by the “Lock file is already taken”.

This typically means that another update process is running.

I think you can try the command line update. If the lock file is still taken, it will not do anything, but will let you know about this.

“apt -s upgrade” says it will not upgrade 3 packages.

I tried “apt -s install packageX” for each upgradable package

  • freedombox: will remove fuse
  • sshfs: will remove fuse
  • guile-2.2-libs: will remove libgc1c2

I understand from your previous answer that removal of fuse is ok.
Is the removal of liggc1c2 ok?

Should I do “apt upgrade --with-new-pkgs” to avoid marking them as manually installed if I ask to install them? (what I think I understood from searching for such kind of situation)

The problem is that this only installs one package at a time.

The way the fuse → fuse3 transition was handled, requires freedombox and sshfs to both be upgraded at the same time.

It’s ok to remove fuse, as long as fuse3 is getting installed in its place.

I’m not as familiar with libgc1c2, but I think it’s ok to remove, as long as libgc1 is getting installed in its place.

I successfully did the upgrade of the 3 packages with a single “apt install” command.
I now have v21.7 of freedombox.

Thanks !

During the upgrade, apt complained several times about locales, with messages such as:

Failed to set locale. Fix your system.
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
	LANGUAGE = (unset),
	LC_ALL = (unset),
	LC_TIME = "fr_FR.UTF-8",
	LC_MONETARY = "fr_FR.UTF-8",
	LC_ADDRESS = "fr_FR.UTF-8",
	LC_TELEPHONE = "fr_FR.UTF-8",
	LC_NAME = "fr_FR.UTF-8",
	LC_MEASUREMENT = "fr_FR.UTF-8",
	LC_IDENTIFICATION = "fr_FR.UTF-8",
	LC_NUMERIC = "fr_FR.UTF-8",
	LC_PAPER = "fr_FR.UTF-8",
	LANG = "fr_FR.UTF-8"
    are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory

I have the web interface in French, formatting according to conventions in France and the logs/system messages in English, and these are exactly my preferences.

Should I do something to avoid the “no such file or directory” that sounds a little worrying?

I think these locale errors are harmless. If you want to avoid them, you can run sudo dpkg-reconfigure locales and select the locale(s) you want to generate.

https://wiki.debian.org/Locale#Standard

I had the same problem and ran the following command:

$ sudo apt remove fuse && sudo apt install fuse3 && sudo apt upgrade

Although I got the same warnings about locales, everything went smoothly, so I ran unattended-upgrade:

$ sudo unattended-upgrade -d

As a result, libntfs-3g883 was removed, and several packages are kept back.

Package at-spi2-core has a higher version available, checking if it is from an allowed origin and is not pinned down.
Package batctl has a higher version available, checking if it is from an allowed origin and is not pinned down.
Package cockpit has a higher version available, checking if it is from an allowed origin and is not pinned down.
Package cockpit-bridge has a higher version available, checking if it is from an allowed origin and is not pinned down.
Package cockpit-networkmanager has a higher version available, checking if it is from an allowed origin and is not pinned down.
Package cockpit-packagekit has a higher version available, checking if it is from an allowed origin and is not pinned down.
Package cockpit-pcp has a higher version available, checking if it is from an allowed origin and is not pinned down.
Package cockpit-storaged has a higher version available, checking if it is from an allowed origin and is not pinned down.
Package cockpit-system has a higher version available, checking if it is from an allowed origin and is not pinned down.
Package cockpit-ws has a higher version available, checking if it is from an allowed origin and is not pinned down.
Package freedombox-doc-en has a higher version available, checking if it is from an allowed origin and is not pinned down.
Package freedombox-doc-es has a higher version available, checking if it is from an allowed origin and is not pinned down.
Package guile-2.2-libs has a higher version available, checking if it is from an allowed origin and is not pinned down.
Package guile-2.2-libs is kept back because a related package is kept back or due to local apt_preferences(5).
Package libatspi2.0-0 has a higher version available, checking if it is from an allowed origin and is not pinned down.
Extracting content from /var/log/unattended-upgrades/unattended-upgrades-dpkg.log since 2021-09-02 14:21:30

Nevertheless, it appears I am now running v. 21.7. Should there be any cause for concern?

My Pioneer FreedomBox is not upgrading beyond 21.4.4~bpo10+1 though it managed to dist-upgrade to Bullseye successfully.

The following packages have been kept back:
  freedombox guile-2.2-libs sshfs zile

I wonder if this is also related to fuse3.