Just install the 4.1.x image, run this workaround Updates may fail because "Repository [...] changed its 'Suite' value from 'stable' to 'oldstable'", upgrade and you’ll be fine in 4.3.x
So there really is no way to install v4.3.4.2 on a Raspberry Pi, without having to install v4.1.7.2 first? I thought v4.3.4.2 is the “current stable release” of YunoHost. Why is there no release package for it?
Edit: sorry for the tone… edited to make it more factual.
We are understaffed volunteers, so image builds and testings can get behind the actual current version. The upgrade from 4.1 to current version takes minutes, stop overthinking it and embrace the simpleness of YunoHost.
Please pursue this discussion on your own thread if you are not actually discussing the installation and testing of YunoHost 11.0. 
3 Likes
Hello,
Sorry for my English …
I’m actually trying to build a 4.3.5 testing image for Raspberry Pi by following GitHub - YunoHost/rpi-image: Tool used to create the raspberrypi.org Raspbian images.
I’m completely noob in building image, so if it went to the end, i’ll see to share link with it (zip) and the sha256sum without any guarantee at all in any case in these files.
Edit : I’m relaunching the stuff because of a network problem on a Debian repository : some .deb couldn’t be retrieve.
Edit 2 : @frittro the link is here hubiC - OVH and active for 30 days. It’s my first build using this script and this topic is not the good place to talk about this.
By the way i’m not able to fix anything about it. It comes without any guarantee or anything else and it’s not an official release, just a try to helps. Moreover i can’t test it. Especially since the new version is under development/preparation.
It is important to note that :
- ssh is normally enable according to the default configuration of the script
- and the locale is normally en_US.UTF-8 so maybe you should reconfigure it.
After it is necessary to cross the fingers …
Edit 3 :
@frittro , the good link hubiC - OVH
ppr
Hi everyone!
Before diving into the details, let me say how much I like Yunohost and how grateful I am of your work.
I tried to upgrade my setup and I encountered some issues. I am using a virtual machine with a configuration similar to my production configuration, and Yunohost is installed in an unprivileged LXC container inside the VM.
-
fetchmail prevented packages upgrade: https://paste.yunohost.org/raw/ijuximipal
I am using fetchmail and for it to deliver email locally using dovecot lda it must run under the vmail user (so dovecot lda runs as vmail too). After the upgrade, fetchmail refuses to start because the homedir of its user (vmail) is missing, and because of that apt is failing.
This homedir is set to /home/vmail on buster, but it changed to /var/vmail on bullseye and it does not exist.
When I manually create the /var/vmail directory and chown it to vmail:mail (as on buster) fetchmail can start and the upgrade can resume. -
php7.3-fpm.service timeout on restart: https://paste.yunohost.org/raw/apuvaxiqex
Not sure what happened here. When I tried to restart the service manually, it succeeded immediately, and the upgrade can resume. -
during yunohost upgrade, I noticed this failure:
Setting up yunohost (11.0.1~alpha+202112311417) ...
postmap: fatal: open /var/cache/yunohost/regenconf/pending/postfix/etc/postfix/sasl_passwd.db: Permission denied
Could not run script: /usr/share/yunohost/hooks/conf_regen/19-postfix
This did not prevent the upgrade to succeed, but when I tried to do it manually afterwards, it failed with the same error:
root@yunohost:~# yunohost tools regen-conf postfix --force
Warning: postmap: fatal: open /var/cache/yunohost/regenconf/pending/postfix/etc/postfix/sasl_passwd.db: Permission denied
Error: Could not run script: /usr/share/yunohost/hooks/conf_regen/19-postfix
Info: The operation 'Regenerate system configurations 'postfix'' could not be completed. Please share the full log of this operation using the command 'yunohost log share 20220102-213108-regen_conf-postfix' to get help
Error: Could not regenerate the configuration for category(s): postfix
The logfile is here: https://paste.yunohost.org/raw/zajobehufa
Let me know how I can help.
1 Like
A quick note to say that since the YunoHost 11.0 install (3 weeks), I haven’t encountered any bugs 
5 Likes
Is there anything in particular that the team would like tested? I’ve installed Nextcloud, Synapse and Element Web and so far, everything I’ve tried has worked, except what I posted above.
To be honest, I was expecting to find more bugs, so now I’m trying to figure out where I’m most likely to find some for you. 
1 Like
Yeah, but we’re still going kinda slowly because the bugs have a tendency to hide themselves until we release stuff as stable 
I’m pretty confident on fresh install in Bullseye, but the most important things to test is the migration from buster to bullseye, which is also complex because you gotta setup a machine “as close as possible to real-life” with 5~10 apps etc …
I pushed a bunch of fixes to the migration procedure to address a couple issue, I’m having another round of tests, and next we’re planning for a beta release during the second half of january (“beta” as in “we encourage power user to actually migrate their production server, except a couple minor issues but should be okay to debug manually”)
4 Likes
Now i have a VirtualBox VM for testing my PyInventory project… I restored by prod app data into this VM to test PyInventory upgrade…
Because i can easy made VirtualBox snapshots, i also test switchtoUnstable also to see if PyInventory has some troubles with Bullseye (I don’t know why that should be a problem, though.)
I can confirm this. Work-a-round: tail -f /var/log/yunohost/categories/operation/* 
After all migrations done, i still have package that should be upgraded:
Is that normal?
After upgrade the system will not be restarted, but this is needed, isn’t it?
Before i have done a reboot, PyInventory seems to work fine. (Think because the already old services is still running) …But after the reboot i get only a 502 Bad Gateway because gunicorn app server didn’t start:
Think after the system upgrade (that will upgrade Python from 3.7 to 3.9) the PyInventory virtualenv must be recreated too. (This is a normal “behaviour” for python virtualenvs)
The YunoHost migrations will not reinstall the packages, isn’t it?
In case of PyInventory a forced upgrade (sudo yunohost app upgrade pyinventory --force) will fix the problem, because the venv will be recreated:
Maybe it’s good idea to force upgrade all installed packages?!?
1 Like
Yeah I’m trying to address that 
I’m having troubles with the whole php dependency mess, a classic.
Yeah we saw similar issues in the stretch->buster transition where the fact that python got upgraded to 3.7 was messing virtual envs … I’m not knowledgeable about these enough to understand why that’s causing issues … What’s weird is also that we were expecting quite a lot of people to experience these issues, but in fact not so many people complained about these in the end … I’m not sure why
1 Like
You mean all installed apps ? Uuugh I wouldn’t be so comfortable with that because some people have maaaaany apps installed and each upgrade creates a pre-upgrade safety backup and just … ugh …
If the point is to address the virtual env issues, back in the stretch->buster transition we thought we would do some sort of magic, ad-hoc detection of installed venvs and maybe do something about it (that was a random idea though, in the end we didnt do this tho)
1 Like
A generic solution about this is to have a “dist_upgrade” script in every package. So the package can handle this in case of a distro upgrade…
Magicly found all packages that used python venv and upgrade only these apps is IMHO not really easy. Because there are many ways to setup a venv…
Backup all apps before make a dist-upgrade is generally a good idea, isn’t it?
The “upgrade --force” works in case of my PyInventory package. Don’t know if that’s works with all other packages…
Maybe the safest way is:
- deinstall app apps (This always make a backup, isn’t it?)
- do the migration + dist-upgrade
- reboot
- restore all apps
Every package should support this, or?
Yes, that will take a while, but it’s safe. Better safe than sorry 
I would say not. Database-dependent apps often come with migration logic to handle app upgrades. That logic will be run when upgrading the app.
Creating a backup in one version, perform the upgrade, and restore will give an app with the old structure. Now you have to run the upgrade logic on the data by hand (or create logic that runs the migration for Yunohosters), while it was included in the original app upgrade.
That said: nothing beats backups 
1 Like
Hi all,
I just did an installation on an armbian bullseye arm64, all the installation script went well, but when I wanted to register my main domain name I encountered a problem related to the fact that metronome.service is unknown .
If you have any ideas on how to fix this …
Thank
Do you have the initial install hanging somewhere ? In /var/log/yunohostsomething maybe ?
1st attempt with a download error
https://paste.yunohost.org/okiwuwovac.scala
2nd installation attempt ok
https://paste.yunohost.org/yojofihoyu.erl
By seeing the logs I see that the problem is linked to linux-image-current-meson64
The issue may be related to the fact that metronome isn’t built yet for armhf/arm64 on bullseye … Can you try to apt install metronome ?
root@armbian:/var/log# apt install metronome
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances... Fait
Lecture des informations d'état... Fait
Aucune version du paquet metronome n'est disponible, mais il existe dans la base
de données. Cela signifie en général que le paquet est manquant, qu'il est devenu obsolète
ou qu'il n'est disponible que sur une autre source
E: Le paquet « metronome » n'a pas de version susceptible d'être installée
root@armbian:/var/log#
Yup so I need to trigger a build and then that should work
1 Like
I get a 400 Bad Request error when I try to delete a domain with an application installed on it. The complaint is, obviously, that there’s still an application installed on the domain.
I mean, I can understand why, but I figured you’d still want to know as it’s still an error, and my expectation as a user is that I’d be warned and asked if I wanted to continue. If I said yes, I would expect the app to be removed and then the domain.