Toasted server: Migration 0027_migrate_to_bookworm did not complete

What type of hardware are you using: VPS bought online
What YunoHost version are you running: 11.3.0.2 (stable).
How are you able to access your server: SSH

Describe your issue

I cannot do the migration… Full log here https://paste.yunohost.org/raw/ocizupaqex I think there are conflicts/dependencies. But I am unsure if it is safe to remove some packages. Any help please?

Share relevant logs or error messages

2024-12-22 14:55:41,800: DEBUG - The following packages are RECOMMENDED but will NOT be installed:
2024-12-22 14:55:41,800: DEBUG -   libclang-rt-14-dev
2024-12-22 14:55:41,800: DEBUG - 84 packages upgraded, 40 newly installed, 56 to remove and 801 not upgraded.
2024-12-22 14:55:41,800: DEBUG - Need to get 147 MB of archives. After unpacking 210 MB will be used.
2024-12-22 14:55:41,896: DEBUG - Do you want to continue? [Y/n/?] n (stdin unavailable)
2024-12-22 14:55:41,896: DEBUG - Abort.
2024-12-22 14:55:42,898: ERROR - Migration 0027_migrate_to_bookworm did not complete, aborting. Error: Failed to run command 'aptitude full-upgrade cron rspamd- luajit- libluajit-5.1-2- --show-why -o APT::Force-LoopBreak=1 -o Dpkg::Options::='--force-confold''
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/yunohost/tools.py", line 786, in tools_migrations_run
    migration.run()
  File "/usr/lib/python3/dist-packages/yunohost/migrations/0027_migrate_to_bookworm.py", line 204, in run
    aptitude_with_progress_bar(
  File "/usr/lib/python3/dist-packages/yunohost/utils/system.py", line 315, in aptitude_with_progress_bar
    raise YunohostError(
yunohost.utils.error.YunohostError: Failed to run command 'aptitude full-upgrade cron rspamd- luajit- libluajit-5.1-2- --show-why -o APT::Force-LoopBreak=1 -o Dpkg::Options::='--force-confold''

UPDATE:

I did a manual trigger of the latest command with sudo: aptitude full-upgrade cron rspamd- luajit- libluajit-5.1-2- --show-why -o APT::Force-LoopBreak=1 -o Dpkg::Options::='--force-confold'

That forced it to go through - full log here hastebin

After that I managed to trigger the migration from the yunohost panel and now it gets stuck to “9.3% Installing ifupdown”

UPDATE 2:

In fact the entire server is not reachable after the ifupdown issue. From what I get this is the module for the network so maybe that cuts down the internet access to the server?

UPDATE 3:

I manually forced the server to reboot since I could not access it via SSH either. It got stuck. After the reboot I cannot access the server at all I get a “No route to host” error via SSH. So, toasted server :D. Luckily I have snapshots and backups but I’d like to understand what the issue is?

UPDATE 4:

After restoring a snapshot I tried to do the update and migration via SSH manually. It managed to do it all as you can see the logs hastebin and yet after rebooting the system I cannot access the server anymore same SSH error “No route to host”.

Update: This seems to be an issue with the hosting company Webdock. Our server is a “container” not KVM so perhaps we do not have full privileges and some updates fail. Or are misconfigured.

Their tech support input:

In our debian images systemd handles the network. And if YunoHost uses SysVInit for network handling then the config will be different. How to fix this is something I don’t know but the YunoHost guy’s will

If anyone knows of a solution…

YunoHost doesn’t really do anything special regarding the network, it’s just Debian under the hood and Debian uses systemd, not sysvinit

Thanks. If instead of using the Yunohost migration I would force a sudo apt-dist upgrade would that be a bad idea? I am thinking to try different methods to try and fix this issue.

Yes it would be a bad idea … the migration is essentially already a “dist-upgrade” with a bunch of tweaks to accomodate for known conflict and other issues, stuff that need to be upgraded separately etc … Your issue doesn’t seem related to the migration itself but to the network or system failing to get back online after reboot, and imho the proper way to investigate this would be to open a debug shell/ui on the VPS after it fails to get back online properly. Some VPS provider do provide such interface or “rescue mode”

Thank you! I need to think well about how to deal with this. Very unexpected.

A totally random / wild guess would be the infamous “predictive interface name”, i.e. the fact that the “old way” for network interface name was typically eth0 / wlan0, but nowadays it’s more like enp0s42, and sometimes during a major upgrade the system may switch the other way around for some reason, and then it fucks up the networking config …

But as said it’s a random guess and may be something completely different

Ugh, thanks for the idea. I may try if I find no other way around it. What do you think of this Can I restore Yunohost 11.3.0.2 to a server with Debian 12 and then do the migration? ? Install Debian 12 on a fresh new server and restore the YNH backups there. Would that work?

Yes in theory that is supposed to work

1 Like

Didn’t work :smiley: Can I restore Yunohost 11.3.0.2 to a server with Debian 12 and then do the migration? - #6 by Tio

Ran into the same issue - Failed to run command ‘aptitude full-upgrade cron’

  • standalone bare metal server in my basement
  • [YunoHost] 11.3.0.2 (stable)

my logs - https://paste.yunohost.org/raw/eqowomuwab

Solution here Can I restore Yunohost 11.3.0.2 to a server with Debian 12 and then do the migration? - #13 by Tio