Feedback about FreedomBox setup in a Bullseye RC3 fresh install

Overall Impressions

List of things you liked

  • The project’s goals
  • apt install freedombox and it’s working!
  • Backups
  • Neat UI

List of things you disliked

  • Would love to see backups for SAMBA [1]
  • Without DEBIAN_FRONTEND=noninteractive, it was not clear to me the implications of several questions during the installation.
  • I found some issues after installation on a fresh Bullseye RC3. I’m describing them below. Let me know if you want me to fill in a bug report elsewhere.

Incorrect btrfs option in fstab caused the boot sequence to halt

The automatic FreedomBox installer used subvol=.snapshot to identify the subvolume, but that didn’t work.

UUID=44539a99-4cf0-456b-b4ec-5e94139e8f63 /.snapshots btrfs subvol=.snapshots 0 1

Proposed Solution
Using the subvolid seemed to work:
UUID=44539a99-4cf0-456b-b4ec-5e94139e8f63 /.snapshots btrfs subvolid=260 0 1

Cockpit origins not properly configured

After installation, access to Cockpit was forbidden…


Proposed Solution
Add more origins to /etc/cockpit/cockpit.conf:

Origins=https://freedombox https://freedombox.local https://localhost https://localhost:4430

Change of external SSH backup server fingerprint made any backup configuration involving that server to fail

If an external SSH backup server changes its fingerprint, any attempt to configure backups targeting that host fails. The UI shows an error message (don’t remember which, possibly it was a warning about the fingerprint mismatch) and a success message stating that the fingerprint was correctly stored. Both messages at the same time.

Trying to modify, or create new backup targets involving that host failed with an error and success message.

This is a very exceptional situation, since servers should not change fingerprints frequently. But if it happens, it doesn’t seem possible to update the known host from the UI.


  1. I configured a backup target in FreedomBox.
  2. The SSH server changes fingerprint.
  3. It is no longer possible to configure backups targeting that server from FreedomBox UI.

Proposed Solution
I had to manually remove the host from plinth’s known_hosts file.

Either the backup application or plinth logic should be reviewed in order to cover this situation.

Corrupted datagrams during Borgbackup transfer

This is probably more a problem in my hardware than a FreedomBox issue. However, it might be interesting if FreedomBox could detect this kind of issues or even set a “safe” default for network interfaces.

During a Borgbackup data transfer, the SSH connection was dropped by the server because of integrity issues.

SSH connection at client side stalled (forever).
Logs at SSH server shown the following message:

ssh_dispatch_run_fatal: Connection from user <U> port <P>: message authentication code incorrect

Proposed Solution
Switching off hardware offloading solved the issue:
ethtool -K enp1s0 rx off tx off

[1] Samba shares and backups

1 Like

Thank you for the extensive feedback.

I am not sure there is much we can do here. We are perusing making FreedomBox (and other Debian blends) appear in Debian installer using a tasksel package that is already part of Debian (freedombox-tasks). Installing using tasksel (or using Debian installer in future) will avoid these questions.

I don’t think we have encountered this before. I created an issue to investigate, please subscribe to it and provide more information if requested. snapper: Boot failed after installation (#2112) · Issues · FreedomBox / FreedomBox · GitLab

When any domian name is added in the system (Domain name, MDNS, Dynamic DNS, Tor Onion service, Pagekite) it is automatically configured in Cockpit configuration file. The list of domains that will currently work with Cockpit are also shown in the Cockpit app interface.

This scenario was missed when implementing backups application. I created an issue to implement this: backups: Handle change in remote host indentity (#2111) · Issues · FreedomBox / FreedomBox · GitLab

I believe kernel module, udev or NetworkManager are correct places to fix this issue rather than FreedomBox. Please consider reporting there.

1 Like

Thanks for the follow up @sunil! I’ll keep an eye on those issues.

I’m not acquainted with FreedomBox network model (NetworkManager I guess), but the IP address of my FreedomBox installation was statically set, and the host name defined in /etc/hosts and /etc/hostname. Additionally, I entered a static entry in my DNS to make sure the rest of the devices in the network could properly resolve the name. Shouldn’t this be enougth for Cockpit?

FreedomBox currently does not automatically pickup the domain name from /etc/hosts and perform an automatic setup of various apps (Apache site, LetsEncrypt, Cockpit, ejabberd, etc.). One needs to explicitly provide the domain name in one of the domain providing apps in FreedomBox UI (Config, DynamicDNS, Tor, Pagekite, etc.). Then, FreedomBox will trigger all the setup actions.

OK, I’ll keep that in mind. Thanks @sunil.