How to upgrade Fedora version inside a toolbox container?

Ask Fedora
1

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?

5 Likes
2

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

3

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
4

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
5

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
6

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

7

I think that we could open a new thread.

8

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
9

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
10

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
11

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.

12

I noticed since Fedora 41 switches to DNF5 by default, upgrading to Fdora 42 required replacing dnf with dnf4 for all of the steps

13

Not true.
With f41 I used dnf system-upgrade download --releasever=42 and it worked. I suspect though that the system-upgrade plugin may still be using dnf4 features.

14

I could not upgrade my toolbox to fedora 42 :frowning:
I can download all packages but the upgrade subcommand does not exist with dnf5

sudo dnf system-upgrade upgrade --releasever=42
Unknown argument "upgrade" for command "system-upgrade". Add "--help" for more information about the arguments.

sudo dnf5 system-upgrade --help
Usage:
  dnf5 [GLOBAL OPTIONS] system-upgrade <COMMAND> ...
                                
Commands:                       
  clean                         Remove any stored offline transaction and delete cached package files.
  log                           Show logs from past offline transactions
  reboot                        Prepare the system to perform the offline transaction and reboot to start the transaction.
  status                        Show status of the current offline transaction
  download                      Download everything needed to upgrade to a new release

So I also tried with dnf4 but I get

sudo dnf4 system-upgrade upgrade --releasever=42
trigger file does not exist. exiting quietly.

So how are we supposed to update a toolbox to a new fedora version ?

15

The system-upgrade of dnf is done via a reboot. But there is no notion of (re)booting toolboxes (or distroboxes) and it is not the usual workflow with containers. Containers are meant to be thrown away and recreated when they need updating (e.g., for a newer image, a different tag, etc.)

I suggest you simply spin up another toolbox based on F42, far easier IMHO than looking for an upgrade across versions.

1 Like
16

Yes, this is what I did in the end. But some replies in this thread made me think that it was somehow possible…

17

“somehow possible” doesn’t necessarily mean that it’s a sensible way of doing things. :wink: