How to upgrade Fedora version inside a toolbox container?

Hi :slight_smile:

After update of Fedora Workstation to version 33 I wanted to also update the toolbox container to version 33 (from 32). I tried running:

$ sudo dnf system-upgrade download --releasever=33
$ sudo dnf system-upgrade reboot

but the last command returned:

System has not been booted with systemd as init system (PID 1). Can't operate.

I guess this is because the container does not run systemd and is not booted in the same way as the host?

I managed to update the packages though by using:

$ sudo dnf system-upgrade upgrade --releasever=33

But the problem I have now is that the filesystem package didn’t get upgraded and sudo dnf upgrade filesystem always fails with:

Error: Transaction failed

Also the rpm operations are printing warnings:

warning: Found bdb Packages database while attempting sqlite backend: using bdb backend.

I tried to fix it with sudo rpmdb --rebuilddb but I get:

error: failed to replace old database with new database!
error: replace files in /var/lib/rpm with files from /var/lib/rpmrebuilddb.7504 to recover

I also can’t manually copy the files. I guess because this is part of the container image?

Otherwise everything seems to work OK, but it doesn’t look like a clean upgrade. What I want to ask is if there is a normal way to upgrade Fedora inside a container or maybe just swap the base image with a new one?
Or is the only option to create a new container with F33 as base and reinstall the packages from the old container?

4 Likes

Huh, you’re the top result and only relevant thing I saw on google, so I guess nobody has a better way!

I encountered this similar issue trying to switch from CentOS 8 to CentOS Stream 8 inside an LXC container.

echo "%_netsharedpath /sys:/proc" >> /etc/rpm/macros.dist; dnf -y update

1 Like

Doesn’t work for Silverblue

$ sudo echo "%_netsharedpath /sys:/proc" >> /etc/rpm/macros.dist; sudo dnf -y update
bash: /etc/rpm/macros.dist: Permission denied

Also, even getting as far as the previous upgrade apparently doesn’t work twice in a row as now I get:

$ sudo dnf system-upgrade upgrade --releasever=35
trigger file does not exist. exiting quietly.

Maybe there should be a bug report for this

1 Like

Look. Here you are using sudo to echo that string. Not to redirect the string to the file.
Use

echo "%_netsharedpath /sys:/proc" | sudo tee -a /etc/rpm/macros.dist

instead.

1 Like

Huh, this seems to no longer work to fix the F35 → F36 upgrade

I think that we could open a new thread.

No worries, I was able to get around it, not sure which was the necessary step but I did:

  • dnf autoremove
  • dnf list --installed | rg fc35
  • dnf remove fc35 packages
  • remove the /etc/rpm/macros.dist file

Just for searchability, others looking for this answer will see a different error lately, Failed to reboot system via logind: Access denied as shown below:

Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Complete!
Transaction saved to /var/lib/dnf/system-upgrade/system-upgrade-transaction.json.
Download complete! Use 'dnf system-upgrade reboot' to start the upgrade.
To remove cached metadata and transaction use 'dnf system-upgrade clean'
The downloaded packages were saved in cache until the next successful transaction.
You can remove cached packages by executing 'dnf clean packages'.
usernamehere@toolbox:/var/home/usernamehere $ sudo dnf system-upgrade reboot
Failed to reboot system via logind: Access denied

But the workaround works great sttill:

usernamehere@toolbox:/var/home/usernamehere $ sudo dnf system-upgrade upgrade --releasever=38
Last metadata expiration check: 0:04:00 ago on Wed Apr 26 15:01:03 2023.
Screen blanking can't be disabled: [Errno 13] Permission denied: '/dev/tty0'
Dependencies resolved.

…and the upgrade continues.

Siednote, you do have to attempt the reboot first, otherwise you’ll get this error:


usernamehere@toolbox:/var/home/usernamehere $ sudo dnf system-upgrade upgrade --releasever=38
trigger file does not exist. exiting quietly.
1 Like

One more update for Google-ability: the error has once again been changed and now users will see:

$ sudo dnf system-upgrade reboot
Call to Reboot failed: Access denied

For me updating just worked?

But as a container best would be to rebase to the new toolbox image, and keep / reapply the installs of the packages.