Upgrade to 22.04 from 20.04 ends with dbus installation asking for a reboot

Yikes, does it actually *stop* at that point? That's .. not ideal.

Thanks

Here's the postinst I've got for that package. Maybe the reload_dbus_config() could use a --reply-timeout=5000 or something?

Thanks

$ cat /fst/trees/ubuntu/main/d/dbus/dbus_1.12.20-2ubuntu4/debian/dbus.postinst
#!/bin/sh
# Copyright © 2003 Colin Walters <email address hidden>
# Copyright © 2006 Sjoerd Simons <email address hidden>

set -e

MESSAGEUSER=messagebus
MESSAGEHOME=/var/run/dbus
LAUNCHER=/usr/lib/dbus-1.0/dbus-daemon-launch-helper

# This is what the init script would do, but it's simpler (and less
# dependent on sysvinit vs. Upstart vs. etc.) if we do it directly.
reload_dbus_config() {
    [ -S /var/run/dbus/system_bus_socket ] || return 0

    dbus-send --print-reply --system --type=method_call \
        --dest=org.freedesktop.DBus \
        / org.freedesktop.DBus.ReloadConfig > /dev/null || true
}

if [ "$1" = triggered ]; then
    reload_dbus_config
    exit 0
fi

if [ "$1" = configure ]; then
    adduser --system \
            --quiet \
            --home /nonexistent \
            --no-create-home \
            --disabled-password \
            --group "$MESSAGEUSER"

    if ! dpkg-statoverride --list "$LAUNCHER" >/dev/null; then
        dpkg-statoverride --update --add root "$MESSAGEUSER" 4754 "$LAUNCHER"
    fi

    # This is idempotent, so it's OK to do every time. The system bus' init
    # script does this anyway, but you also have to do this before a session
    # bus will work, so we do this here for the benefit of people starting
    # a temporary session bus in a chroot
    dbus-uuidgen --ensure
fi

if [ "$1" = configure ] && [ -n "$2" ]; then
    # On upgrades, we only reload config, and don't restart (restarting the
    # system bus is not supported by upstream). The code added by
    # dh_installinit -r creates a start action, below.

    # Recommend a reboot if there is a dbus-daemon running in the same root
    # as us. Deliberately not using anything init-related here, to be
    # init-agnostic: if we get a false positive (at least one dbus-daemon
    # is running but it isn't the system bus) that isn't the end of the
    # world, because it's probably a session bus, so the user needs to
    # log out and back in anyway.
    #
    # Debian has /usr/bin/dbus-daemon, Ubuntu has /bin/dbus-daemon.
    # Look for both.
    if pidof -c /bin/dbus-daemon /usr/bin/dbus-daemon >/dev/null; then
        echo "A reboot is required to replace the running dbus-daemon." >&2
        echo "Please reboot the system when convenient." >&2

        # trigger an update notification that recommends a reboot
        # (used by unattended-upgrades etc.)
        touch /var/run/reboot-required || true

        if ! grep -Fqsx dbus /run/reboot-required.pkgs; then
            echo dbus >> /run/reboot-required.pkgs || true
        fi

        # same thing for the older update-notifier interface
        [ -x /usr/share/update-notifier/notify-reboot-required ] && \
            /usr/share/update-notifier/notify-reboot-required || true
    fi

    # Clean up old compatibility symlinks that were used to upgrade from
    # Debian 8 to Debian 9. This can be dropped after Debian 10 is released.
    for bus in system session; do
        conf="/etc/dbus-...

This may be a duplicate of https://launchpad.net/bugs/1969162

It can very well be a duplicate of that - I did not keep an eye on all of those updates. This would explain why some upgrades went through and some "paused" at that point, I just was not patient enough, although there was no indication of this wait time.

At very least this is a bit confusing message and less experienced users might just go and reboot assuming it is a safe thing to do.

I just did a:

sudo update-manager -d

On a very normal 21.10 system, and received the same message. What is a little shocking is that the terminal portion of the window opens, *asking* you to reboot, and just sits there for 3, 4, 5 minutes at that message. I fear many users today and in the weeks to come who do this procedure will not wait and will do what the system asks, breaking their systems.

Status changed to 'Confirmed' because the bug affects multiple users.

The message appeared (a reboot is required to replace dbus-daemon) and I almost restarted my computer. Luckily I checked this forum. After 5 or more minutes it continued with the installation.

Yep. I'm getting the same and I'm stuck with a semi-upgraded install... :(

UPDATE: after waiting about 10 or 15 minutes it carried on with the upgrade.
But, yeah, telling people to reboot in the middle of an upgrade isn't great... :/

I also get this message, I did try to reboot and with reboot and it does inhibit and provide a reason but almost followed systemctrl reboot.

My system took slightly longer than 5 mins to continue, but thankfully it did :-)

Can confirm #10 works for me too. Can be confusing, but luckily I checked for this bug first. The upgrade will block on the message "Please reboot your system..." but after waiting some time it unblocked on its own.

I tested an upgrade from Impish to Jammy today in a virtual machine and from what I could tell (I didn't watch the whole process) the upgrade did not stop when dbus was installed although the message posted in the screenshots was display. Looking at my /var/log/dist-upgrade/main.log we can see that the total upgrade took only 16 minutes so it's unlikely that 10 of that was spent waiting.

2022-04-28 10:17:16,728 DEBUG quirks: running StartUpgrade
2022-04-28 10:17:16,728 DEBUG running Quirks.StartUpgrade
2022-04-28 10:17:16,728 DEBUG skipping 'README' (no '.')
2022-04-28 10:17:16,728 DEBUG killing update-notifier
2022-04-28 10:17:16,735 DEBUG killing kblueplugd kbluetooth4
2022-04-28 10:17:16,744 INFO cache.commit()
2022-04-28 10:31:57,413 DEBUG cache.commit() returned None
2022-04-28 10:31:57,542 DEBUG openCache()
2022-04-28 10:31:59,650 DEBUG Comparing 5.13.0-19 with
2022-04-28 10:31:59,650 DEBUG Comparing 5.13.0-30 with 5.13.0-19
2022-04-28 10:31:59,650 DEBUG Comparing 5.13.0-40 with 5.13.0-30
2022-04-28 10:31:59,650 DEBUG Comparing 5.15.0-27 with 5.13.0-40
2022-04-28 10:31:59,751 DEBUG /openCache(), new cache size 71806
2022-04-28 10:31:59,751 DEBUG quirks: running jammyPostUpgrade
2022-04-28 10:31:59,751 DEBUG running Quirks.jammyPostUpgrade

I also did an upgrade from Focal to Jammy and recorded the upgrade process using script and there was no long pause on dbus. I'll attach both the timing file and recording.

One could watch the upgrade using `scriptreplay dist-upgrade-timing dist-upgrade` and pass the `-d` argument if you don't want to watch it in real time.

In case anyone rebooted (like me) and ended up with a message like:

"Kernel Panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)"

Just go to the grub menu, select Advanced Options > pick a previous kernel and boot, once you get the terminal, type:

sudo dpkg --configure -a

Or: Advanced Options > pick a previous kernel (in recovery mode), get a root terminal from the menu, run:

dpkg --configure -a

The upgrade process should continue. Once it's completed just reboot and the system should be updated.

Has anybody encountered this recently when upgrading a fully update to date Focal system to Jammy?

@Brian Murray:
Yes, today i ran into this issue on 2 servers. The install stalled after "A reboot is required to replace the running dbus-daemon.", and then the installer resumed after 10 minutes.

The first server i upgraded I've been caught by the misleading "Please reboot the system when convenient." and just rebooted after a few minutes because the installer was doing nothing.

This misleading reboot message still occurs in Sep 2022. I try to upgrade from hirsute to jammy. Not sure how many minutes my upgrade stuck, but thankfully it was resumed while I read this thread.

This bug STOPS 22.04.1 version - all generic - include 5.15.0.52 \ booting process from completing. It gets stuck "loading d-bus message" (package ?? ) - in infinite loop....

How do I downgrade to WORKING Ubuntu version when I cannot get the boot process to complete ?????

I have two Ubuntu partitions (22.04.1) and they both fail SAME way.
I have older Ubuntu versions /partitions and they boot as expected ....

I do need to recover the faulty 22.04.1 and keep the partitions they are in INTACT.

PS I think this is a wrong place to ask for help... but I would appreciate held without being told where to ask....

How do I downgrade Ubuntu version which won't even fully boot /load??