Limesurvey has known issues.
https://dash.yunohost.org/appci/app/limesurvey
Uuuh yeah but whatâs the relation with nginx restarting during upgrades âŠ?
1 Like
I just migrated an existing YH instance from Debian 10 and everything worked smoothly! I used this instance for testing before, only Dotclear, IFM and Rainloop were installed and they all still work fine. I installed YesWiki and it works fine as well. Keep on the good work!
(As @Aleks mentioned, the update log stops (or hangs) after a while in the webadmin, so you keep wondering when it will be finished, as you will never know, this is the only issue I encountered)
I did a migration from 10 to 11 on a VPS (DigitalOcean) with Nextcloud, Calibre-web, and Transmission installed.
When I try to access Nextcloud from the SSO I got this message:
PHP module zip not installed.
Please ask your server administrator to install the module.
PHP modules have been installed, but they are still listed as missing?
Please ask your server administrator to restart the web server.
Anybody encountered this? Or know of a fix?
So I re-installed YNH_11 in a fresh VPS.
First thing, I have run the diagnosis.
Apart from the usual not yet configured setting errors, I get in systĂšme de base:
Il semble qu'apt (le gestionnaire de paquets) soit configuré pour utiliser le dépÎt des rétroportages (backports). A moins que vous ne sachiez vraiment ce que vous faites, nous vous déconseillons fortement d'installer des paquets provenant des rétroportages, car cela risque de créer des instabilités ou des conflits sur votre systÚme.
and in Connectivité Internet
La résolution DNS semble fonctionner, mais il semble que vous utilisez un /etc/resolv.conf personnalisé.
Edit: Letâs Encrypt certificat fails : https://paste.yunohost.org/raw/hegulogove
the only thing I have set in my DNS settings is the A recordâŠ
Edit2: I have deactivated XMPP in domain config settings and rerun Letâs Encrypt certificate with the same error. https://paste.yunohost.org/raw/dexaviqisu
Yeah I had the same issue. Itâs well understood from the fact that Yunohost automagically reconfigures all php7.3 apps to use php7.4, but it doesnât install the new php7.4-* dependencies, it keeps the old php7.3-* dependencies (because thereâs no code handling that, but maybe we should add some)
Whatâs really puzzling is why did we not had that issue with previous stretch->buster transitions âŠ
1 Like
Yunohost in LXC container up to date. Apps installed : roundcube, nextcloud, netdata, calibreweb.
Migration launched from the cli failed :
So Iâm just attempting an install the alpha via SSH on a new test VPS with Bullseye, but Iâm getting the following message:
This CPU lacks support for the Supplemental Streaming SIMD Extensions 3 (SSSE3) instruction set that is required to execute programs linked against hyperscan.
Really install package?
Does this mean that Yunohost wonât install on this VPS, or can I safely install/skip this?
EDIT: I tried just saying no to installation, but that made the install script abort. From the logs:
Preparing to unpack .../libhyperscan5_5.4.0-2_amd64.deb ...
Aborting installation because of missing SSSE3 extension.
dpkg: error processing archive /var/cache/apt/archives/libhyperscan5_5.4.0-2_amd64.deb (--unpack):
new libhyperscan5 package pre-installation script subprocess returned error exit status 1
Errors were encountered while processing:
/var/cache/apt/archives/libhyperscan5_5.4.0-2_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)
[FAIL] Installation of Yunohost packages failed
Uuuuh wokay I have no idea what that lib is and why the system would want to install it âŠ
I donât know if that helps:
Hyperscan is a high-performance multiple regex matching library.
# apt-cache rdepends --recurse libhyperscan5
libhyperscan5
Reverse Depends:
libhyperscan-dev
suricata
suricata
rspamd
libhyperscan-dev
Reverse Depends:
suricata
Reverse Depends:
suricata-oinkmaster
suricata-oinkmaster
fever
fever
rspamd
Reverse Depends:
fbx-all
yunohost
opensmtpd-filter-rspamd
suricata-oinkmaster
Reverse Depends:
fever
Reverse Depends:
fbx-all
Reverse Depends:
yunohost
Reverse Depends:
moulinette
yunohost-admin
opensmtpd-filter-rspamd
Reverse Depends:
moulinette
Reverse Depends:
yunohost
yunohost-admin
Reverse Depends:
yunohost
1 Like
AlsoâŠ
sudo yunohost domain cert-install MYDOMAIN.TLD
gives:
Warning: 'yunohost domain cert-install' is deprecated and will be removed in the future
So, uh⊠how do we install ssl certs now, or has this been made automatic?
1 Like
It has merely been reworded:
# yunohost domain cert install --help
usage: yunohost domain cert install [domain_list ...] [-h] [--force] [--no-checks] [--self-signed] [--staging]
Install Let's Encrypt certificates for given domains (all by default).
positional arguments:
domain_list Domains for which to install the certificates
optional arguments:
-h, --help show this help message and exit
--force Install even if current certificate is not self-signed
--no-checks Does not perform any check that your domain seems correctly configured (DNS, reachability) before attempting to install. (Not
recommended)
--self-signed Install self-signed certificate instead of Let's Encrypt
--staging Use the fake/staging Let's Encrypt certification authority. The new certificate won't actually be enabled - it is only intended to test
the main steps of the procedure.
2 Likes
OK, no deprecation warning, butâŠ
sudo yunohost domain cert install MYDOMAIN.TLD
just gives:
Error: 'NoneType' object has no attribute 'get'
The result is the same whether I use my primary domain or a secondary domain that was successfully used to install Nextcloud. If I donât specify a domain I get two sets of this error message (I have two domains). Both domains still show as self signed using cert status.
EDIT: I was able to create an SSL cert eventually by accepting the warning message about the self signed cert for my admin domain. From there the web gui worked fine for creating the letâs encrypt cert. Thereâs definitely an issue with the cli cert install though. It looks like the domain name just isnât being passed to it correctly.
1 Like
So⊠would it help to post an issue for this on Github, or is posting it here enough?
By the way, I also managed to get a crash by installing Synapse (which installed perfectly) on a subdomain, and then selecting âMake defaultâ (which caused a crash with backtrace). 100% reproducible.
**Error**: `"500" Internal Server Error`
**Action**: `"PUT" /yunohost/api/apps/synapse/default`
**Error message:**
Unexpected server error
**Traceback**
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/moulinette/interfaces/api.py", line 494, in process
ret = self.actionsmap.process(arguments, timeout=30, route=_route)
File "/usr/lib/python3/dist-packages/moulinette/actionsmap.py", line 579, in process
return func(**arguments)
File "/usr/lib/python3/dist-packages/yunohost/log.py", line 419, in func_wrapper
result = func(*args, **kwargs)
File "/usr/lib/python3/dist-packages/yunohost/app.py", line 1081, in app_makedefault
if "/" in app_map(raw=True)[domain]:
KeyError: 'SUBDOMAIN.MYAWESOMEDOMAIN.TLD'
1 Like
Yes, posting on Github could help (ideally with a full stacktrace, if thereâs any available)
Hmyeah that one may not be specific to bullseye, I think itâs more related to the fact that Synapse is not a webapp and therefore it doesnt make sense to âmake it defaultâ, hence it crashes. The fix would be that we just do not display this UI bit for non-webapp as itâs not relevant
1 Like
It doesnât seem to successfully create a log when this error occurs, unless Iâm missing it.
Does anyone here know, or is able to make an educated guess, on a release date for YunoHost v11 as a complete install for production use? As you probably know by now from my discussion thread, I am a new YNH user, who is preparing for a new installation in the New Year. I am planning to start with v4.3.4.2 which, I believe, is the current stable version available.
I could wait for this new v4.4.x before I begin my install, and then upgrade to v11 from there. Alternatively, I could wait until v11 ships, and do a complete clean install of it, without having to do the upgrade from v4.4.x at all. I am in a good position right now to make such a decision. I just need to get some idea of how far back this would push my installfest start date.
- YunoHost v4.3.4.2 installfest â can begin immediately
- YunoHost v4.4.x installfest â t.b.a
- YunoHost v11 installfest â t.b.a
Somebody asked a similar question and imho you should just stop procrastinating and go for it ÂŻ\_(ă)_/ÂŻ 
On one hand, migrating major debian version is always a bit delicate, and at the same time, we try to make it as smooth as possible. Usually thereâs a couple of rough edges in the migration in the early days right after we release it as stable, but then it gets smoother. Apart from maybe a couple cases, I never heard of any miserably epic failure for the migration that resulted in an unsolvable, unfixable setup ⊠In the worst case scenario, just come to the support chatroom or forum, provide logs, be patient and methodical, and weâll find a way to fix whatever went wrong.
Considering that we still need to release a beta then the stable, i wouldnât expect a stable bullseye before at least mid-february. Donât waste six weeks just waiting for Bullseye.
4 Likes
Wise words, thanks for that. From my perspective, this project has already been delayed by about 10-20 years! 
Iâm in no hurry. I want to do this right and make it as bulletproof as possible. Over the years I have slowly improved my
This is particularly encouraging, thanks for this reassurance. Iâm good to go then, installing v4.3.4.2 starting on 1-Jan-2022. Iâm looking forward to it!
3 Likes
I spent the day today trying to get Debian 10 Buster installed on my test raspi, so that I could install YunoHost v4.3.4.2 directly. Encountered several issues (see my discussion thread for details) and had to abandon it.
At present it is looking like I may have to alter my sights, and begin with installing YunoHost v4.1.7.2, and then do the upgrade to v4.3.4.2, as it seems that I cannot install Debian 10 Buster as the base, as had been recommended. Unless someone can provide a solution that helps me get v4.3.4.2 installed, I will start again tomorrow, with v4.1.7.2 instead. Thanks.
Sorry, I really think v4.3.4.2, as the current stable, should be the priority here. Can we please get that working as a complete installable package, with its base OS in place, just as v4.1.7.2 already is?