#18

It’ll probably be more like a month - I’ve got a few projects I need to bang out that don’t involve containers.

#19

I have been running into this issue from time to time as well, this time I am getting

Resolving dependencies... Forbidden base package replacements:
  libgomp 8.2.1-5.fc29 -> 8.2.1-4.fc29 (updates)

Can this be affected by the number/type of layered packages I install. Maybe related to the rpm sources of my layered packages and the silverblue upstream not in sync?

The last time the problem just disappeared (so I am thinking of some sort of “not on sync” issue) but I would love to get some pointers to investigate or better avoid this issue.

This is the list of layered packages I have:

chromium docker gcc git i3 i3lock jq keychain mysql neovim npm pavucontrol postgresql pv python3-neovim redis the_silver_searcher tmux xautolock xclip yubioath-desktop zsh and I also have one local package (rofi-1.5.1-2.x86_64).

#20

I recall using rpm -q --whatrequires package, though it wasn’t always perfect.

#21

Thanks, now I know it is due to the layered gcc which is probably not that uncommon on dev environments I suppose?

#22

did you try to use fedora-toolbox instead of layering packages for dev “stuff”?

#23

Not yet but thank you for the pointer! Our project setups still rely on docker-compose and so docker so it will probably be hard to move these into containers I suppose. I would love to be able to get rid of most of these overlays but one step at a time.

#24

FWIW if you’re doing app development, you can also do stuff inside a Flatpak SDK (you can enter one via flatpak run --filesystem=home org.freedesktop.Sdk or flatpak run --filesystem=home org.gnome.Sdk). If you’re using GNOME Builder it’ll automatically take care of building inside a Flatpak.

2 Likes
#25

I need the GCC for native library bindings (in ruby and in go). As of today the issue no longer exists and I can just run rpm-ostree upgrade without any issues.

Would still like to find out what the root cause of all this is and if issues like this one will occur frequently. Not big of a deal though.

1 Like
#26

How did you determine these were the issues?

I am on a fresh install of Fedora IoT. The first thing I did was “rpm-ostree upgrade” and “systemctl reboot.” Then I tried “rpm-ostree install gcc” and I get the following error…

"

Checking out tree c9b381a… done
Enabled rpm-md repositories: fedora-modular updates updates-modular fedora

<…Shortened, as I’m typing this out…>

Forbidden base package replacements:
libxcrypt 4.4.4-1.fc29 -> 4.4.4-2.fc29 (updates)
Resolving dependencies… done
error: Some base packages would be replaced

"

The output from “rpm-ostree status” is:

ostree://fedora-iot:fedora/stable/x86_64/iot
Version: 29.20190317.0 (2019-03-17T12:02:20Z)
Commit: c9b381…
GPGSignature: Valid signature by C2A3FA9DC…

ostree://fedora-iot:fedora/stable/x86_64/iot
Version: 29.20181206.0 (2018-12-06T16:57:28Z)
Commit: 12c4e6…
GPGSignature: Valid signature by C2A3FA9DC…

I don’t require you to debug this for me. I’d like to do the same debug method you did to get gcc installed on a fresh Fedora IoT install. Before doing “rpm-ostree install” I tried this on the 12c4e6 tree and had even more conflicts than just for libxcrypt. I’ve done “rpm-ostree cleanup -m” as suggested here as well with no effect.

#27

In this case you should probably rpm-ostree install toolbox and then use toolbox for your development environment.

#28

Removed comment. I thoroughly messed up my environment. Please do not follow my lead using “rpm-ostree override”. I didn’t realize the repercussions of my actions until I understood the rpm-ostree deployment strategy.

#29

In general, stuff like gcc goes a bit better running inside toolbox, which sets up a normal Fedora Workstation environment inside a container.

#30

Can you provide a link that describes the best known methods of use for Fedora IoT? I am rebuilding the kernel and adding some other hardware capabilities that weren’t originally enabled.

I’d like to get a better understanding of what to deploy on Fedora IoT host and what is best to deploy to containers. I haven’t found that distinction spelled out succinctly yet.

#31

If you watch out for it, there is an article about using Fedora Iot coming up on the Fedora magazine site about using K3s Kubernettes (containers) on Fedora Iot using a Raspberry Pi I think.

#32

I am getting the same issue with SB 30.

“rpm-ostree cleanup -m” didn’t help either. Any ideas?

1 metadata, 0 content objects fetched; 569 B transferred in 2 seconds
Checking out tree 07e5727… done
Enabled rpm-md repositories: updates fedora rpmfusion-nonfree-nvidia-driver
Updating metadata for ‘updates’… done
rpm-md repo ‘updates’; generated: 2019-05-25T00:40:35Z
Updating metadata for ‘fedora’… done
rpm-md repo ‘fedora’; generated: 2019-04-25T23:49:41Z
Updating metadata for ‘rpmfusion-nonfree-nvidia-driver’… done
rpm-md repo ‘rpmfusion-nonfree-nvidia-driver’; generated: 2019-05-19T14:14:42Z
Importing rpm-md… done
⠁
Forbidden base package replacements:
mesa-libglapi 19.0.5-1.fc30 -> 19.0.4-1.fc30 (updates)
mesa-libGL 19.0.5-1.fc30 -> 19.0.4-1.fc30 (updates)
Resolving dependencies… done
error: Some base packages would be replaced

Also, here is my status for reference:

State: idle
AutomaticUpdates: disabled
Deployments:
● ostree://fedora:fedora/30/x86_64/silverblue
Version: 30.20190521.0 (2019-05-21T00:41:04Z)
BaseCommit: c77995efc63ab706…
GPGSignature: Valid signature by F1D8EC98…
RemovedBasePackages: firefox-66.0.5-1.fc30.x86_64
LayeredPackages: docker fedora-workstation-repositories kmod-nvidia xorg-x11-drv-nvidia

ostree://fedora:fedora/30/x86_64/silverblue
Version: 30.20190520.0 (2019-05-20T00:34:36Z)
BaseCommit: 7059cc8508f5d9a00374f43667a4…
GPGSignature: Valid signature by F1D8EC98…
RemovedBasePackages: firefox-66.0.5-1.fc30.x86_64
LayeredPackages: docker fedora-workstation-repositories kmod-nvidia xorg-x11-drv-nvidia

#33

At a glance the version conflict is coming from the nvidia drivers, if you wait a day or two then you should be able to upgrade again.

#34

I kinda assumed it was nvidia related, but I couldn’t find any dependent packages, and the error message communicated “base packages” which seems to contradict.

I deployed the Nvidia packages over 10 days ago, and I check for updates almost everyday without issues, so I am a little confused.

But yea, there is a high likelihood it will resolve itself in a few days.

#35

Maybe some context might help a bit: AFAIK this happens when the latest version of a package available in the repos differs from latest version that’s part of the base image. Since the version in the base image can’t be implicitly modified, rpm-ostree bails.

1 Like
#36

Just tried again. Already working now! :ok_hand:

1 Like
#37

This is problem (and others) are covered in the troubleshooting section of the Silverblue docs:

https://docs.fedoraproject.org/en-US/fedora-silverblue/troubleshooting/

(Thanks for the explanation; just posting for visibility :wink:)

2 Likes