dnf always fails when used with ostree based systems instead of warning.

[m2Giles]

#2053 has landed in Fedora 40.

This ends up breaking dnf completely when being used in a CI pipeline with an ostree system. We currently use dnf for building akmods in CI.

Note, that it says it should warn a user but exits with an operation aborted. From the docstring it does not sound like the intended behavior?

[bsherman]

Adding some detail...

It looks like the CliError causes the command to return a non-zero exit status, which breaks akmods when run on ostree systems.

An akmods log snippet for quick reference:

2024/07/09 03:39:32 akmodsbuild: + exit 0
2024/07/09 03:39:32 akmods: Installing newly built rpms
2024/07/09 03:39:32 akmods: DNF detected
Dependencies resolved.
================================================================================
 Package                           Arch   Version            Repository    Size
================================================================================
Installing:
 kmod-nvidia-6.8.11-300.fc40.x86_64
                                   x86_64 3:555.58.02-1.fc40 @commandline  41 M

Transaction Summary
================================================================================
Install  1 Package

Total size: 41 M
Installed size: 41 M

*** This system is managed with ostree.  Changes to the system
*** made with dnf will be lost with the next ostree-based update.
*** If you do not want to lose these changes, use 'rpm-ostree'.

Operation aborted.
2024/07/09 03:39:32 akmods: Could not install newly built RPMs. You can find them and the logfile in:
2024/07/09 03:39:32 akmods: /var/cache/akmods/nvidia/555.58.02-1-for-6.8.11-300.fc40.x86_64.failed.log
+ exit 1

[ppisar]

@dcantrell, can you explain whether your commit intended an error or just a warning? If it were an error, how should users override the error to perform a temporary change which will be lost on next ostree-based update?

[dcantrell]

Initially it was supposed to be an error, but now consensus is that it should be a warning. I also need to update is_container() based on changes that came along later. I will get a patch for this so it is fixed up.

[YaLTeR]

Is there really no way to disable this for now? It completely breaks the workflow of temporarily installing packages with dnf for development/testing into a sudo ostree admin unlocked system (knowing and intending for all changes to be rolled back on reboot).

[travier]

We have #2110 in progress

[jmarrero]

Is the idea that even if we stop the operation on read-only systems we should exit with 0?

[jmarrero]

To be clear these reports seem to me like they are all happening in CI using a ostree/bootc container or with ostree admin unlock. If so the patch in #2110 should fix this without needing to change the exit code and message to a warning. When we find a bootc host we will exit with an error. However when running on a container or on a unlocked system, dnf should run just like before because it is not a bootc host at that point it's just another container running a build. On a read-only system dnf never has been able to modify the system, so the exit code 1 in that case makes sense to me.

[mripard]

I'm also affected by this. I was using dnf with --installroot as a debootstrap-ish tool, so the system installed was never affecting the "host" system.

I'm not sure how to fix it properly, but maybe looking at whether we affect the ostree system or not would work (like, anything under /mnt or /media would work, but /usr obviously wouldn't).

[ppisar]

We could change the check to take --installroot path into account:

• Either by requiring --installroot to be /, like this:
  os.path.isfile('/run/ostree-booted') and not os.access('/usr/', os.W_OK) and conf._get_value('installroot') == '/'
• or by extending the check with a writeability check for non-root --installroot path, like this:
  os.path.isfile('/run/ostree-booted') and not os.access('/usr/', os.W_OK) and (conf._get_value('installroot') == '/' or not os.access(conf._get_value('installroot'), os.W_OK))

I would probably place the extending conditions out of _is_bootc_host() function, or wrap the function into a new _is_bootc_installroot() function.

Another approach would be adding new tri-state option, e.g. --image-mode={true,false,auto}, defaulting to auto being equivalent to the current behavior. False would force DNF to this-is-not-a-read-only-OSTree system, while True the opposite. User would get a way to override the detection.

[ppisar]

Bootc people, Is root filesystem (/) never writable on bootc systems? I'm deliberating whether it is necessary to check that installroot differs from /.

Currently bootc system has / read-only even if usr-overlay is writable. That of course does not play well when installing packages that write out of /usr.

[ppisar]

@mripard and others using --installroot, I developed a fix in #2121. Any comments and testing are appreciated.