Yup so I need to trigger a build and then that should work
Alpha-stage testing for YunoHost 11.0 on Debian Bullseye (and migration that will be shipped in Yunohost 4.4.x)
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.
thanks for wonderful YH work!
I’m testing new alpha and it installed without problem.
I’m having issue creating the let’s encrypt cert. I created only the main domain and the process to create ssl fails because the script is using the stub domain “maindomain.tld” instead of using my domain (that is x.lisa.eu.org)
here the log:
Eeeh I’m not sure what you mean ? Note that
maindomain.tld is related to the automatic redacting of private information when sharing logs … it’s not using literally
Ah… thanks, I understood. Well… so something went wrong to create let’s encrypt cert for the main domain. For the others domains it worked well.
Yes I think I built metronome for arm64/bullseye since then
I tried the second one:
- RaspberryPi OS Lite Buster for ARM64 + YunoHost. Installed Rainloop and Plume. Tried to migrate.
- GUI seemed to be stuck and after 3 hours I refreshed the page. According to logs the migration completed within 25 minutes.
- But two services failed: PHP and rspamp (?). Rebooted the server to see if they would start automatically again.
- The server is not available anymore. Router panel says the server is not connected so no SSH or GUI.
Ugh, anyway to maybe connect an HDMI screen + keyboard ?
If you really want me to, I could. Otherwise, since it’s a testing server, I will move on and reinstall everything.
I did it. I’m seeing a big YUNOHOST banner and
- Local IP: (no IP detected?)
- Local SSL fingerprint
- SSH fingerprints
- And it’s prompting for login
Hmokay, are you able to login using admin (or root) and the admin password ?
ip a shows ?
What happens if you run
dhclient eth0 (or replace eth0 with the name of your wired interface)
§ ip a 1: l0: (LOOPBACK,UP ,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 br 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_ift forever preferred_ift forever 2: etho: (BROADCAST,MULTICAST› mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether ma:ca:dd:re:ss bra ff:ff:ff:ff:ff:ff 13: wlano: (BROADCAST,MULTICAST› mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether ma:ca:dd:re:ss brd ff:ff:ff:ff:ff:ff
RTNETLINK answers: Operation not permitted. Tried again with sudo: nothing. Tried again: RTNETLINK answers: File exists
ip link set eth0 up ? Does that changes anything in the output of
ip a ?
Yes, eth0 goes up and router shows it has an IP assigned. However, I cannot connect to the server (tried SSH and GUI).
When I reboot the server, eth0 is down once again.
RaspberryPi 4, running RaspiOS Lite ARM64
YunoHost: 11.0.1~alpha+202201172317 (unstable)
My third try:
- install script: Are you sure you want to proceed with the installation of Yunohost? ← even though it’s not visible here there are two spaces between “want” and “to”.
- rspamd service is always down and it fails to start [Buster → Bullseye or Bullseye from start]
- Admin panel shows Bullseye migration is pending even if YunoHost has been installed on top of Debian 11. Trying to execute the migration fails.
- Diagnostics complain about /etc/resolv.conf. I believe there was a command to fix this. Is
ln -s /etc/resolvconf/run/resolv.conf /etc/resolv.confstill relevant and/or advisable?
grep: /run/resolvconf/resolv.conf: No such file or directory
when trying to add a new subdomain, but they seem to work.
Not sure if this is a Yunohost error, or one with my host, but… in Diagnosis, I get a warning that the CAA record is set to 0 issue letsencrypt.org where it expects 128 issue letsencrypt.org. My host allows editing of the records directly through freeDNS, but freeDNS only allows the value 0 or 1 here (the critical flag), both of which Yunohost flags as not recommended. It doesn’t allow me to type in a number like it does elsewhere. Is this really supposed to be set to 128 (not 1/0) or is there a bug in freeDNS not allowing this to be set correctly?
Hmpf no it’s no big deal if this is 128 or 0 … Honestly I’m just considering trashing this CAA record recommendation, it’s confusing everybody, not all registrar supports it, and the gain of having it is just way not worth all the trouble it brings …
Also it has no relation with Bullseye
OK. I reported here as I ran into this on the Bullseye install I’m testing to try and help out. Thanks for the advice. I’ll set to ignore.
Thanks for everybody’s feedback !
We’re now entering beta-stage: Beta-stage testing for Yunohost 11.0/Bullseye and Buster->Bullseye migration