Beta-stage testing for Yunohost 11.0/Bullseye and Buster->Bullseye migration

Upgraded Buster and Yunohost on an OVH vps successfully.

apps: nextcloud, rainloop, coturn element


Hello, I’m preparing to install this testing version, on a Raspberry Pi 3B, with a fresh install of Debian Bullseye (64 bits). I’ll report my feedback about this experience.

I’m just not sure if the script mentioned in the first post is also valid for ARM, or if it’s only for x86?

wget -O install_script
bash install_script -d testing

And when the final version will be released, will I have to reinstall everything from scratch, or will it be a simple update?

Thank you!

It will be a simple update.

Thank you @ljf! And I have looked into the script, I understand there are specific steps for Raspbian (as far as I understand, it’s called Raspberry Pi OS now, but I guess it isn’t important for YunoHost), so I guess the commands will work. Thanks again!

In fact, I read in the script that the check to know if the device is a RPI is the following:

function is_raspbian() {
    # On Raspbian image lsb_release is available
    if [[ "$(lsb_release -i -s 2> /dev/null)" != "Raspbian" ]] ;
        return 1
    return 0

I installed Raspberry Pi OS light 64 bits, as advised in Raspberry Pi OS – Raspberry Pi and lsb_release -a gives me the following result:

No LSB modules are available.
Distributor ID: Debian
Description:    Debian GNU/Linux 11 (bullseye)
Release:        11
Codename:       bullseye

So I guess the test above won’t find Raspbian and it won’t work (I didn’t try to avoid doing a mistake). If I change the test like this, will it work?

function is_raspbian() {
    return 0

Will it be enough? Should I change something else?

[edit]: I have done the modification above, and apparently the script understands we’re on RPI, but I get this error when I launch the script as root, after having run sudo -i:
[FAIL] The user pi should be logged out.

Using sudo su doesn’t help either. The solution is to enable the login of root over SSH (see instructions in (section Allow SSH access for root) and to login as root.

Experimenting is good but you are overthinking and making it difficult.

  1. Simply download Raspberry Pi OS Lite (64bit) Bullseye and copy it to your SD card / hard drive.

  2. You can copy the image to your SD / hard drive using the terminal or if you prefer a GUI via balena etcher or the official Raspberry imager.

  3. The benefit of the Raspberry imager is that it is able to download the image for you, can enable SSH easily within the options (a must do unless you have a screen and keyboard connected to your raspberry), and lets you choose a different name instead of pi.

  4. Put SD card inside / connect hard drive and boot it up.

  5. SSH into your server, execute the command

$ wget -O install_script
$ bash install_script -d testing

and follow the instructions. There is nothing else to it.

No need to worry about architecture or anything else. No need to change/modify/edit anything.

Some more detailed instructions by @mcb13 can be found here (pay attention, they are using Buster).

1 Like

Thanks @punkrockgirl , did you test it yourself? Did it work? Because I tested what you have written and it doesn’t work if you don’t ssh as root, as written in my message above (the detailed instructions of mcb13 are basically the same as my message).

I have installed it 4 or 5 times and I never had any issue.
Log in as pi (or whichever user you created) and execute the command. If it doesn’t work try with sudo. I’m pretty sure that’s all I did. [Do I make myself root? :thinking: I don’t remember but I don’t think so]

The times I have seen the

issue —never with YunoHost— were related to auto login. But Lite doesn’t have a desktop environment, so it shouldn’t be enabled. I guess the problem is somewhere else but just in case you can try sshing (pi) then type raspi-config go to boot > auto login > and disable.

1 Like

Th pi warning in the yunohost script just need you to log as root with su before running the script


It can’t be run with sudo from the pi user (if i remember well), because the pi user will be deleted.


Hi all,
I found solution for rspamd.service can’t start
add sid in /etc/apt/sources.list and upgrade rspamd 2.7 to 3.1
Then rspamd.service work without problem…

You did WhAt

This is as much of a fix as “I didnt have any cooking equipement for cook my meal so I dropped a nuclear bomb and now my meal is very much cooked!”

Don’t fucking switch to sid what the hell


Ouch it burns… lol…
I suspected that I was doing something stupid but as I couldn’t understand why rspamd version 2.7 did not start I tried to update it, the latest version is only available on sid, I only did this update of rspamd then removed sid from /etc/apt/sources.list
And with rspamd version 3.1 installed on armbian bullseye I was able to have rspamd.service working correctly…
Sorry, it was just to share my tests. I have a version of Armbian which runs on Beelink GT-King pro (amlogic S922X) it is not an official version and the kernel used has been modified by @flippy, there may be a problem in the kernel config but I don’t know how to find it… I installed armbian on sd card from GitHub - ophub/amlogic-s9xxx-armbian: Armbian for Amlogic s9xxx tv box. Support a311d, s922x, s905x3, s905x2, s912, s905d, s905x, s905w, s905, etc. including install to EMMC and update related functions..
I know it’s very tinkered for yunohost install but it worked well when I was under armbian buster suddenly I wanted to try under armbian bullseye
Thank @Aleks

Edit: I have some strange thing with slapd

-- Boot 2289f0325c294448ac9593beefd25532 --
mars 21 17:49:42 systemd[1]: Starting LSB: OpenLDAP standalone server (Lightweight Directory Access Protocol)...
mars 21 17:49:43 slapd[1765]: @(#) $OpenLDAP: slapd 2.4.57+dfsg-3 (May 15 2021 23:03:34) $
                                      Debian OpenLDAP Maintainers <>
mars 21 17:49:44 slapd[1939]: slapd starting
mars 21 17:49:44 slapd[1711]: Starting OpenLDAP: slapd.
mars 21 17:49:44 systemd[1]: Started LSB: OpenLDAP standalone server (Lightweight Directory Access Protocol).
mars 21 17:53:08 slapd[1939]: slap_global_control: unrecognized control:
mars 21 17:53:08 slapd[1939]: slap_global_control: unrecognized control:
mars 21 17:53:14 slapd[1939]: slap_global_control: unrecognized control:
mars 21 17:53:14 slapd[1939]: connection_read(17): no connection!
mars 21 17:54:27 slapd[1939]: slap_global_control: unrecognized control:
mars 21 17:54:27 slapd[1939]: slap_global_control: unrecognized control:
mars 21 17:54:32 slapd[1939]: slap_global_control: unrecognized control:
mars 21 17:54:42 slapd[1939]: slap_global_control: unrecognized control:
mars 21 17:55:58 slapd[1939]: slap_global_control: unrecognized control:
mars 21 18:03:37 slapd[1939]: slap_global_control: unrecognized control:
mars 21 18:03:37 slapd[1939]: slap_global_control: unrecognized control:
mars 21 18:05:53 slapd[1939]: slap_global_control: unrecognized control:
mars 21 18:05:53 slapd[1939]: slap_global_control: unrecognized control:
mars 21 18:06:11 slapd[1939]: slap_global_control: unrecognized control:
mars 21 18:19:02 slapd[1939]: slap_global_control: unrecognized control:
mars 21 18:19:51 slapd[1939]: slap_global_control: unrecognized control:
mars 21 18:19:51 slapd[1939]: slap_global_control: unrecognized control:
mars 21 18:19:57 slapd[1939]: slap_global_control: unrecognized control:
1 Like

I have weird connectivity issues with a fresh bullseye install. Sometimes it’s reachable, sometimes not, DNS propagation fails randomly on roughly half the DNS servers.
I discovered that there is a warning:

Internet connectivity (ip)

[WARNING] DNS resolution seems to be working, but it looks like you're using a custom /etc/resolv.conf.
  - The file /etc/resolv.conf should be a symlink to /etc/resolvconf/run/resolv.conf itself pointing to (dnsmasq). If you want to manually configure DNS resolvers, please edit /etc/resolv.dnsmasq.conf.

after a fresh install. I checked and /etc/resolv.conf is a symlink pointing to /etc/resolv.conf -> ../run/resolvconf/resolv.conf - so I guess there is a typo in the installation script with /run/resolvconf/ instead of /etc/resolvconf/run/? Or am I stupid? I came across the other threads and maybe it’s something with bullseyes network management - I’m using a VPS at contabo and I’m running multiple Yunohost instances successfully on buster there…
Where is the resolv.conf file actually supposed to be for Yunohost and can I just create the missing directories?

//EDIT: ok, I checked on my buster-instance and the /etc/resolvconf/run is a symlink to /run/resolvconf so nevermind me. However, there where two random(?) IPs before the entry. Editing that fixed the DNS propagation instantly, however the file warned me that manual changes will be overwritten automatically. Is the file managed by Yunohost? I will wait and see. EDIT-END//
//EDIT 2: nvm, nothing’s fixed. yunohost service restart dnsmasq just recreates the resolv.conf-entries.

On another note I get

[WARNING] It looks like apt (the package manager) is configured to use the backports repository. Unless you really know what you are doing, we strongly discourage from installing packages from backports, because it's likely to create unstabilities or conflicts on your system.

on a fresh install. Is this due to the testing branch or should I fix it somehow?


We are searching someone with a lime2 to test this fix in the migration process : [fix] Allow lime2 to upgrade even if kernel is hold by zamentur · Pull Request #1452 · YunoHost/yunohost · GitHub


Upgraded a vps at hetzner. Most seems to have gone well. It has installed

  • nextcloud
  • ghost (2x)
  • rainloop
  • trilium notes


  • In Diagnosis I do too get the error of Service php7.3-fpm is dead :( but 7.4 is just running.
  • Also, I had to restart the server to get into the new kernel, it somehow didn’t prompt me to restart, neither seemed to this on its own.
  • Finally, I thought Nextcloud was on version 23 already? It says here ‘Shipped version: 23’ Should I do something to initiate that? Is it even Bullseye related or is version 23 there for Buster too?
1 Like

Nextcloud 23 is the testing version… I have changed the default version to be the master branch to avoid confusion.

thanks, I was wondering. I’m not in hurry anyway :slight_smile: although… some self reflection, I did upgrade to Bullseye for no particular reason than thinking it was about time.

If you have been brave enough to upgrade to Bullseye, maybe you should give Nextcloud 23 upgrade a try :grin:

I’m just now having problems with my nextcloud and it’s data dir. I’m going to ask elsewhere, I doubt it’s relevant to this thread.


The update went well.
I have an error in the services about php 7.3 not starting. I tried to remove it as 7.4 should be enough and it seems my applications are already using 7.4.
But apt says it would remove depency packages of nextcloud and custom wepapps:

Les paquets suivants seront ENLEVÉS :
  my-webapp--2-ynh-deps my-webapp--3-ynh-deps my-webapp--4-ynh-deps my-webapp-ynh-deps nextcloud-ynh-deps php7.3-apcu php7.3-bcmath php7.3-bz2 php7.3-cli php7.3-common php7.3-curl php7.3-fpm php7.3-gd php7.3-gmp php7.3-igbinary
  php7.3-imagick php7.3-imap php7.3-intl php7.3-json php7.3-ldap php7.3-mbstring php7.3-mysql php7.3-opcache php7.3-readline php7.3-redis php7.3-xml php7.3-zip phpmyadmin-ynh-deps

Is there any way to update these fake packages to depend upon 7.4 or newer?
My applications are up to date.