rpm-ostree should provide clear and accurate data for the update process

[da2ce7]

on Fedora Linux 38.20230915.0 (Silverblue)

part of:

• Bad Experience on Unreliable Connections #2560

Problem:

rpm-ostree update is an iterative process that dose not report exact progress

Only provides the progress of obtaining the objects, by number.

Inaccurate speed estimation and total data transferred.

User Experience:

Users who are on the road need to know how long an update will take. The lack of useful statistics and estimations leads to frustrations, particularly when there is important security updates that need to be obtained in a timely manner.

Leading to bad choice making.

Expected Behavior:

Updating should first obtain accurate download requirement information before continuing the download process. This should be a non-iterative process and the user should be given accurate information from the start.

• Provide accurate pre-flight information about downloads requirements for ostree updates and installs.
• Provide accurate pre-flight information for both ostree and overlays.

related issue:

• rpm-ostree should be very respectful of user bandwidth #4599

Would you like to work on the issue?

For the moment I'm working on unrelated bittorrent infrastructure.

[olafur-palsson]

I'm a new user and experiencing this right now. I have sub-par but stable internet and I am downloading Bazzite and the experience is abysmal. The only thing that keeps me from cancelling the process is the current network usage.

Pulling manifest: ostree-unverified-registry:ghcr.io/ublue-os/bazzite-nvidia:stable
Importing: ostree-unverified-registry:ghcr.io/ublue-os/bazzite-nvidia:stable (digest: sha256:0c779386100258771e5947e913348d072935e2683f8301ca5c256d4b8f44bbb0)
ostree chunk layers needed: 65 (2.6 GB)
custom layers needed: 4 (3.0 GB)

It's been like this for an hour and I would absolutely love to have any of these:

• Progress bar
• Estimated time left
• List of layers downloaded and their size
• Current total amount downloaded

Not showing anything is very odd since even I got the feeling "hey, maybe it's not working" after 5 minutes of Discover showing 99% until I checked the network usage.

If anyone points me in the right direction I'm willing to fix it myself. :)

[cgwalters]

Yeah, agree this is an annoying papercut. It's fixed in bootc...because we don't currently go through a whole DBus abstraction API to print progress.

The infrastructure here is already plumbed in the ostree-ext side (which fetches/parses containers), and that project also has code to print progress to a terminal.

Basically see around here https://github.com/containers/bootc/blob/b7f70beb6aecdf212f77b721e5111c6ae936e3d2/lib/src/deploy.rs#L138

but the layer byte progress would need to be wired up into rpm-ostree's progress infrastructure so it can be emitted via dbus, which is how clients like discover/gnome-software/cockpit/etc. consume it. bootc simply isn't a daemon offering an IPC mechanism today, so avoids that complexity.

[cgwalters]

#4962 is a step in this direction

[johnr14]

Great to see moving dots !

But I think the expected behaviour of rpm-ostree should be similar to dnf.

Since we are moving to DNF5, rpm-ostree should try mimic it's output.

In fact, I'd like rpm-ostree and dnf5 to have visual similarities and similar options.
That include having similar previews #1579 for package upgrades.

I guess that wrapping ostree-ext output to a dbus api would be a lot of work and in itself warrant major code write/rewrite ? Should this be planned for a future roadmap ?

Thanks