🎃 YunoHost 13.0 / Trixie spooky beta

A bit late, but


2026-02-13 12:12:48,760: WARNING - W: GPG error: https://packages.sury.org/php trixie InRelease: The following signatures were invalid: EXPKEYSIG B188E2B695BD4743 DEB.SURY.ORG Automatic Signing Key <deb@sury.org>
2026-02-13 12:12:48,762: WARNING - E: The repository 'https://packages.sury.org/php trixie InRelease' is not signed.
2026-02-13 12:12:48,764: WARNING - E: Failed to download some files
2026-02-13 12:12:48,766: WARNING - W: Failed to fetch https://packages.sury.org/php/dists/trixie/InRelease: The following signatures were invalid: EXPKEYSIG B188E2B695BD4743 DEB.SURY.ORG Automatic Signing Key <deb@sury.org>
2026-02-13 12:12:48,767: WARNING - E: Some index files failed to download. They have been ignored, or old ones used instead.
2026-02-13 12:12:50,585: ERROR - Migration 0036_migrate_to_trixie did not complete, aborting. Error: Failed to run command 'aptitude update'

implies not that Aptitude is not found, but that the command aptitude update exited with an error. The error here is that signatures for sury.org are missing/outdated.

I guess the next step would be to validate apt`s sury.org sources, and restart the migration. If I’m correct, some of the PHP and Python packages that are too outdated/unavailable on Debian, are used from Sury.

Won’t help you :frowning: , but might help someone else.

I have just run into the same problem.

yunohost:
repo: testing
version: 13.0.4
yunohost-admin:
repo: testing
version: 13.0.0
yunohost-portal:
repo: testing
version: 13.0.0
moulinette:
repo: testing
version: 13.0.0
ssowat:
repo: testing
version: 13.0.0

Selecting /Tools/Hard drives gives a 500 error.

Issue already reported & fix proposed: see Trixie: yunohost storage disk error msg · Issue #2751 · YunoHost/issues · GitHub

Has anyone had Dovecot Nginx and all PostgreSQL clusters fail after upgrade? I can access my system only at home and only on commandline. I tried apt get update/upgrade and now GRUB is failing to install?

Only thing from /var/log/yunohost/operations/20260218-124840-tools_migrations_migrate_forward.yml:

…/yunohost/operations/20260218-124840-tools_migrations_migrate_forward.yml
ended_at: 2026-02-18 14:35:08.758442
error: 'Migration 0036_migrate_to_trixie did not complete, aborting. Error: Failed
to run command ‘‘aptitude full-upgrade --show-why -o Dpkg::Options::=’’–force-co>
interface: api
operation: tools_migrations_migrate_forward
parent: null
started_at: 2026-02-18 12:48:40.378161
started_by:
success: false
yunohost_version: 12.1.39
Setting up grub-pc (2.12-9) …
grub-pc: Running grub-install …
Installing for i386-pc platform.
grub-install: error: unable to identify a filesystem in hostdisk//dev/sda; safety check can’t be performed.
grub-install failure for /dev/sda
Generating grub configuration file …
Found linux image: /boot/vmlinuz-6.12.69+deb13-amd64
Found initrd image: /boot/initrd.img-6.12.69+deb13-amd64
Found linux image: /boot/vmlinuz-6.1.0-43-amd64
Found initrd image: /boot/initrd.img-6.1.0-43-amd64
Found linux image: /boot/vmlinuz-6.1.0-42-amd64
Found initrd image: /boot/initrd.img-6.1.0-42-amd64
Warning: os-prober will not be executed to detect other bootable partitions.
Systems on them will not be added to the GRUB boot configuration.
Check GRUB_DISABLE_OS_PROBER documentation entry.
Adding boot menu entry for UEFI Firmware Settings …
done
Setting up libvpx9:amd64 (1.15.0-2.1+deb13u1) …
Processing triggers for man-db (2.13.1-1) …
Processing triggers for libc-bin (2.41-12+deb13u1) …

Hi thanks for betatesting,

Could you share the full log ? The error suggest to run a command `aptitude …` to know why the upgrade failed, could your run it and return the result ?

After debug the trixie migration and the package conflict , we could address the postgresql /python venv issue:

Automatic migration for postgresql cluster and python venv is not available for now, so you have to migrate by hand or use the code in the dedicated branch or you can also wait the migration to be integrated…

For sury error, see Yarn and Sury APT keys issues

Not a trixie specific issue i guess.

I spent a few hours trying to chase down the error log and had no success (webmin would crash everytime I’d enter the logs area) and even from terminal something was really truly and utterly broken in my system. I’ve had a lot if issues that YNH install I think due to broken permissions due to my inexperience with linux permissions.

So I decided to just spend the weekend backing up everything and doing a fresh install. It seems to work fine except for two things so far:

  1. this little bug:

  1. Missing harddrives! One of the harddrives on the server (it has a SSD with /, a 1TB HDD with /ynh.app and a 2TB with ynh.multimedia, and then another 2TB which I remember appearing during inital setup but it is now missing. I have to look into it more–from what I remember it was formatted for ext4 and trying to delete (zero out) all the data on the 4TB drive was taking FOREVER so I chose to not format (but I can’t remember if I did anything else). I assumed I could just deal with it after the install. However it is now not being detected by lsblk or fdisk.

so :thinking:

2 Likes

Additional thing that’s popped up when trying to install swingmusic: https://paste.yunohost.org/raw/vasorakiwe – I don’t see it on the regressions list yet

Now that i’ve looked a bit it looks like adding a user caused something to happen with freshrss? The user was added before the swingmusic issue above https://paste.yunohost.org/raw/orayuroqok

Can confirm this is a reproducible error. I’ve reinstalled YNH from scratch twice and it still errors out when I try to install a new application after a user is added and the freshrss error happens. Any thoughts on how to prevent it?

The issues persist, it seems:

On startup:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/moulinette/interfaces/api.py", line 430, in process
    ret = self.actionsmap.process(arguments, timeout=30, route=_route)
  File "/usr/lib/python3/dist-packages/moulinette/actionsmap.py", line 580, in process
    return func(**arguments)
  File "/usr/lib/python3/dist-packages/yunohost/service.py", line 382, in service_status
    s: _get_and_format_service_status(s, infos) for s, infos in services.items()
       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/yunohost/service.py", line 419, in _get_and_format_service_status
    raw_status, raw_service = _get_service_information_from_systemd(systemd_service)
                              ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/yunohost/service.py", line 401, in _get_service_information_from_systemd
    service_unit = manager.LoadUnit(service + ".service")
  File "/usr/lib/python3/dist-packages/dbus/proxies.py", line 72, in __call__
    return self._proxy_method(*args, **keywords)
           ~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/dbus/proxies.py", line 141, in __call__
    return self._connection.call_blocking(self._named_service,
           ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^
                                          self._object_path,
                                          ^^^^^^^^^^^^^^^^^^
    ...<3 lines>...
                                          args,
                                          ^^^^^
                                          **keywords)
                                          ^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/dbus/connection.py", line 696, in call_blocking
    reply_message = self.send_message_with_reply_and_block(
        message, timeout)
dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.

After a reboot, trying to check services/disk:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/moulinette/interfaces/api.py", line 430, in process
    ret = self.actionsmap.process(arguments, timeout=30, route=_route)
  File "/usr/lib/python3/dist-packages/moulinette/actionsmap.py", line 580, in process
    return func(**arguments)
  File "/usr/lib/python3/dist-packages/yunohost/storage.py", line 22, in storage_disk_list
    return disk_list(**kargs)
  File "/usr/lib/python3/dist-packages/yunohost/disk.py", line 90, in disk_list
    disks = Udisks2Manager(bus).get_disks()
  File "/usr/lib/python3/dist-packages/yunohost/utils/udisks2_interfaces.py", line 78, in get_disks
    for object_path, (iface, props) in parse_get_managed_objects(
                                       ~~~~~~~~~~~~~~~~~~~~~~~~~^
        (Disk, AtaDisk, NvmeDisk),
        ^^^^^^^^^^^^^^^^^^^^^^^^^^
    ...<2 lines>...
        on_unknown_member="ignore",
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^
    ).items():
    ^
  File "/usr/lib/python3/dist-packages/yunohost/utils/udisks2_interfaces.py", line 63, in parse_get_managed_objects
    return sdbus_parse_get_managed_objects(
        interfaces, managed_objects_data, on_unknown_interface, on_unknown_member
    )
  File "/usr/lib/python3/dist-packages/sdbus/utils/parse.py", line 383, in parse_get_managed_objects
    _get_class_from_interfaces(
    ~~~~~~~~~~~~~~~~~~~~~~~~~~^
        interfaces_to_class_map,
        ^^^^^^^^^^^^^^^^^^^^^^^^
    ...<2 lines>...
        use_interface_subsets,
        ^^^^^^^^^^^^^^^^^^^^^^
    )
    ^
  File "/usr/lib/python3.13/unittest/mock.py", line 1169, in __call__
    return self._mock_call(*args, **kwargs)
           ~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.13/unittest/mock.py", line 1173, in _mock_call
    return self._execute_mock_call(*args, **kwargs)
           ~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.13/unittest/mock.py", line 1234, in _execute_mock_call
    result = effect(*args, **kwargs)
TypeError: _get_class_from_interfaces() takes 3 positional arguments but 4 were given

Still getting the {} issue too:

Hi all,

I also tried the migration on my VPS server, and it failed with the following log: https://paste.yunohost.org/raw/agitefagug. Is it just one more occurrence of the problem with sury signatures?

How can I try again the migration? First the migration was not even offered anymore. I looked at/usr/lib/python3/dist-packages/yunohost/migrations/ and saw that every file, except the one I was interested in, started with an m , so I renamed 0036_migrate_to_trixie.py into m0036_migrate_to_trixie.py. Now the migration is offered again, but I’m stuck because I’m on Trixie and not Bookworm (https://paste.yunohost.org/raw/etocegodop), just like someone above in this thread.