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
3 Likes
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 <pkg-openldap-devel@lists.alioth.debian.org>
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: 1.3.6.1.4.1.4203.666.5.16
mars 21 17:53:08 slapd[1939]: slap_global_control: unrecognized control: 1.3.6.1.4.1.4203.666.5.16
mars 21 17:53:14 slapd[1939]: slap_global_control: unrecognized control: 1.3.6.1.4.1.42.2.27.8.5.1
mars 21 17:53:14 slapd[1939]: connection_read(17): no connection!
mars 21 17:54:27 slapd[1939]: slap_global_control: unrecognized control: 1.3.6.1.4.1.4203.666.5.16
mars 21 17:54:27 slapd[1939]: slap_global_control: unrecognized control: 1.3.6.1.4.1.4203.666.5.16
mars 21 17:54:32 slapd[1939]: slap_global_control: unrecognized control: 1.3.6.1.4.1.42.2.27.8.5.1
mars 21 17:54:42 slapd[1939]: slap_global_control: unrecognized control: 1.3.6.1.4.1.42.2.27.8.5.1
mars 21 17:55:58 slapd[1939]: slap_global_control: unrecognized control: 1.3.6.1.4.1.4203.666.5.16
mars 21 18:03:37 slapd[1939]: slap_global_control: unrecognized control: 1.3.6.1.4.1.4203.666.5.16
mars 21 18:03:37 slapd[1939]: slap_global_control: unrecognized control: 1.3.6.1.4.1.4203.666.5.16
mars 21 18:05:53 slapd[1939]: slap_global_control: unrecognized control: 1.3.6.1.4.1.4203.666.5.16
mars 21 18:05:53 slapd[1939]: slap_global_control: unrecognized control: 1.3.6.1.4.1.4203.666.5.16
mars 21 18:06:11 slapd[1939]: slap_global_control: unrecognized control: 1.3.6.1.4.1.4203.666.5.16
mars 21 18:19:02 slapd[1939]: slap_global_control: unrecognized control: 1.3.6.1.4.1.4203.666.5.16
mars 21 18:19:51 slapd[1939]: slap_global_control: unrecognized control: 1.3.6.1.4.1.4203.666.5.16
mars 21 18:19:51 slapd[1939]: slap_global_control: unrecognized control: 1.3.6.1.4.1.4203.666.5.16
mars 21 18:19:57 slapd[1939]: slap_global_control: unrecognized control: 1.3.6.1.4.1.4203.666.5.16
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 127.0.0.1 (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 127.0.0.1 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
4 Likes
Upgraded a vps at hetzner. Most seems to have gone well. It has installed
- nextcloud
- ghost (2x)
- rainloop
- trilium notes
Issues:
- 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 
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 
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.
Hello,
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.
yunohost app upgrade --force APP
But some app update may still be still in testing mode waiting the release of bullseye. @ericg @tituspijean Have you some info on that ?
1 Like
Thanks, I did this for every app listed and it worked.
I have a service in failed state name user@1007.service.
This uid is my admin user.
As a consequence I cannot use systemctl --user to start a user service. Not sure if this has other impacts.
> sudo systemctl status user@1007.service
● user@1007.service - User Manager for UID 1007
Loaded: loaded (/lib/systemd/system/user@.service; static)
Active: failed (Result: exit-code) since Fri 2022-04-08 22:40:28 CEST; 46min ago
Docs: man:user@.service(5)
Process: 100397 ExecStart=/lib/systemd/systemd --user (code=exited, status=1/FAILURE)
Main PID: 100397 (code=exited, status=1/FAILURE)
CPU: 34ms
avril 08 22:40:27 lanterne.chilliet.eu systemd[100397]: pam_unix(systemd-user:session): session opened for user admin(uid=1007) by (uid=0)
avril 08 22:40:27 lanterne.chilliet.eu systemd[1]: Starting User Manager for UID 1007...
avril 08 22:40:28 lanterne.chilliet.eu systemd[100397]: Failed to determine supported controllers: No such process
avril 08 22:40:28 lanterne.chilliet.eu systemd[100397]: Failed to allocate manager object: No such process
avril 08 22:40:28 lanterne.chilliet.eu systemd[1]: user@1007.service: Main process exited, code=exited, status=1/FAILURE
avril 08 22:40:28 lanterne.chilliet.eu systemd[1]: user@1007.service: Failed with result 'exit-code'.
avril 08 22:40:28 lanterne.chilliet.eu systemd[1]: Failed to start User Manager for UID 1007.
This is not at all a Yunohost issue. This is a conflict between a system protection hardening measure in the Linux Kernel and systemd.
The easiest way to “fix” this is documented in the stackexchange thread.
1 Like
okay, so I do seem to run an old php version somehow. Am I running php 7.3? I thought the diagnosed mistake was just an error in a report, but Nextclouds logs tell me.
Error: Composer detected issues in your platform: Your Composer dependencies require a PHP version ">= 7.4.0". You are running 7.3.33-1+0~20211119.91+debian11~1.gbp618351. at /var/www/nextcloud/apps/polls/vendor/composer/platform_check.php#24
Hello, I see that there is both mailman3 and mailman2 for Yunohost.
Is there some explainations / documentation somewhere about migrating from 2 to 3 ?
RTFM @tierce … c’est dit ici GitHub - YunoHost-Apps/mailman3_ynh: Mailman - The GNU Mailing List Management System packaged for YunoHost. avec un lien qui pointe vers Migrating from Mailman 2.1 to Mailman 3 — Mailman Suite 3.3 documentation .
Merci 
1 Like
I finally got my courage up and tried the update to Debian and Yunohost 11. The only thing I can say it’s that’s… WONDERFUL !
I’ve no big issue : the only one are
-
504 time-out because I made the update from the webadmin. I don’t know if there’s a way to increase the time-out when there are large updates, like a debian migration ?
-
I had to force update the python apps to make them work after the migration, but it was just a few commands to do, without hassle.
So thank you everybody who helped for this migration, I love Yunohost so much 
3 Likes
I tried to perform the upgrade (Debian stable Cloud server at Gandi), but the migration failed with:
# yunohost tools migrations run --accept-disclaimer
Info: Running migration 0021_migrate_to_bullseye...
Error: Migration 0021_migrate_to_bullseye did not complete, aborting. Error: File does not exist: '/etc/apt/sources.list'
Info: The operation 'Run migrations' could not be completed. Please share the full log of this operation using the command 'yunohost log share 20220427-140733-tools_migrations_migrate_forward' to get help
Strangely enough, there only seems to be stuff in the subdir /etc/apt/sources.list.d and no sources.list file on that server :-/
Thanks for reporting, should be fixed by this commit
In the meantime, as a workaround, you can try to run touch /etc/apt/sources.list (this will create an empty file) and rerun the migration
1 Like