Fedora 41 template

[marmarek]

Fedora 41 (https://fedorapeople.org/groups/schedule/f-41/f-41-key-tasks.html) is planned for end of October 2024. Tasks below should start after mass rebuild (planned for July/August).

Tasks:

• [x] build all packages
• [ ] fix: The current post-upgrade hook is not able to reset the updates-available feature after successful upgrades
• [ ] update rpmfusion to final released version
• [ ] build the template
• [ ] document
• [ ] upload to testing repo
• [ ] migrate to stable repo
• [ ] announce

If any issue affects Fedora 41 specifically (build failures, things that worked fine before etc.), please add reference to this issue too.

[alimirjamali]

@marmarek dnf5 complains if --downloadonly, --allowerasing or --best is provided for search action. I submitted a patch.

I have to find the right option to disable ANSI highlighting for search action

p.s.: Looking at dnf5 help & source code, I did not find any option to disable ANSI highlighting. The only option that comes to mind would be avoiding script to emulate a TTY in qubes-dom0-update

[alimirjamali]

The current post-upgrade hook is not able to reset the updates-available feature after successful upgrades on Fedora 41 templates. The upgrades-status-notify script still works well.

[marmarek]

When building F41 template in F40 dispvm, the setfiles call fails with:

[  373.180307] audit: type=1400 audit(1727264039.419:2004): avc:  denied  { mac_admin } for  pid=20954 comm="setfiles" capability=33  scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=capability2 permissive=0
[  373.180359] audit: type=1401 audit(1727264039.419:2004): op=setxattr invalid_context="system_u:object_r:systemd_mountfsd_exec_t:s0"
[  373.317409] audit: type=1400 audit(1727264039.556:2005): avc:  denied  { mac_admin } for  pid=20954 comm="setfiles" capability=33  scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=capability2 permissive=0
[  373.317460] audit: type=1401 audit(1727264039.556:2005): op=setxattr invalid_context="system_u:object_r:systemd_nsresourced_exec_t:s0"

(and few others) IIUC the setfiles applying labels based on policy from F41 fails on types that do not exist in F40. Any ideas how to solve this?

[marmarek]

qubes-vm-update is not happy with Fedora 41 tests (DNF5?):

2024-09-30 05:16:55,902 Running update agent for test-inst-vm1
2024-09-30 05:16:55,905 Transferring files to destination qube: test-inst-vm1
2024-09-30 05:16:56,136 The agent is starting the task in qube: test-inst-vm1
2024-09-30 05:16:59,781 Command '('/usr/bin/python3', '/run/qubes-update/agent/entrypoint.py', '--log', 'INFO', '--no-progress')' returned non-zero exit status 24.
2024-09-30 05:16:59,646 [Agent] agent out: Installed packages:
2024-09-30 05:16:59,646 [Agent] agent out: None
2024-09-30 05:16:59,646 [Agent] agent out: Updated packages:
2024-09-30 05:16:59,646 [Agent] agent out: None
2024-09-30 05:16:59,646 [Agent] agent out: Removed packages:
2024-09-30 05:16:59,646 [Agent] agent out: None
2024-09-30 05:16:59,646 [Agent] agent out: 
2024-09-30 05:16:59,851 Remove /run/qubes-update/
2024-09-30 05:16:59,927 agent exit code: 24

I'm debugging this

[marmarek]

The current post-upgrade hook is not able to reset the updates-available feature after successful upgrades on Fedora 41 templates. The upgrades-status-notify script still works well.

The python plugins seems to be not supported in DNF5. But there is an "actions" plugin already that seems to allow plugging the notification call: https://dnf5.readthedocs.io/en/stable/libdnf5_plugins/actions.8.html

[alimirjamali]

The python plugins seems to be not supported in DNF5.

The python3-libdnf5-python-plugins-loader is useless in this case. It only supports DNF5 specific plugins.

[Minimalist73]

I installed the latest fedora-41-xfce template build and it seems that the cvt package is not installed by default, which breaks the in-qube screen layout since qubes.SetMonitorLayout depends on it. It should probably be set as a required dependency of qubes-gui-agent?

[aronowski]

• Clicking on the qui-domains widget and selecting the "Run Terminal" option spawns xterm instead of ptyxis
• Ptyxis isn't allowlisted as a menu entry - proposed solution: https://github.com/QubesOS/qubes-builder-rpm/pull/139
• Looks like some Qt5 applications are affected by https://github.com/QubesOS/qubes-issues/issues/9457 - VLC is, KeePassXC isn't (further investigation related to the exact Qt versions needed).

[rustybird]

The rpmfusion and google-chrome repos now have enabled=1 in their main repo definitions, overridden to enabled=0 in /etc/dnf/repos.override.d/99-config_manager.repo. It's an artifact of the DNF5 version of config-manager that's used by qubes-builder-rpm. Not necessarily a problem, I just found it confusing.

[marmarek]

On Sat, Nov 09, 2024 at 03:30:18AM -0800, Rusty Bird wrote:

The rpmfusion repos now have enabled=1 in their main repo definitions, overridden to enabled=0 in /etc/dnf/repos.override.d/99-config_manager.repo. It's an artifact of the DNF5 version of config-manager that's used by qubes-builder-rpm. Not necessarily a problem, I just found it confusing.

Yes, that's how config-manager works in DNF5. Old DNF didn't support repo.override.d dirs so it wasn't possible and it modified original file. IMO the new behavior is better as it doesn't conflicts with repo file updates (modified file would not be updated and new version would be saved in .rpmnew file).

-- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab

[rustybird]

IMO the new behavior is better as it doesn't conflicts with repo file updates (modified file would not be updated and new version would be saved in .rpmnew file).

Makes sense.

Should the new behavior get a mention in template announcement? Because I'm guessing other people might also be confused about how to enable the rpmfusion / google-chrome repos.

[rapenne-s]

I can't get package installation to work using salt, any idea? I'm surprised as dnf5 compatibility should be fixed in salt?

[root@dom0 ~]# qubesctl --show-output --targets fedora-41-clone-1 --skip-dom0 pkg.install mercurial
fedora-41-gui:
      ----------
      retcode:
          1
      stderr:
          /var/tmp/.root_dd8a91_salt/pyall/salt/ext/tornado/util.py:246: SyntaxWarning: invalid escape sequence '\d'
            """Unescape a string escaped by `re.escape`.
          Error running 'pkg.install': Error occurred installing package(s). Additional info follows:
          
          changes:
              ----------
          errors:
              - Running as unit: run-r404849f07f904856b3f64885fdee64a1.scope; invocation ID: eaa70155ec404e2ea3b662bed9dfb9c4
                Unknown argument "--allowerasing" for command "dnf5". Add "--help" for more information about the arguments.
      stdout:

edit: looks like it was fixed in July 2023 https://github.com/saltstack/salt/issues/64532

[alimirjamali]

I can't get package installation to work using salt, any idea?

Interesting. Looking at the salt source code, I can find one instance of --allowerasing option before the install or update command. dnf5 is extremely sensitive to the order of CLI commands and options. That would fail. Maybe you could test it and retry to see if that fixes the issue. Move cmd.append after cmd= ["y"]

I'm surprised as dnf5 compatibility should be fixed in salt?

I am not. If this was forum, I could have waffled (verb) a lot.

[rapenne-s]

I can't get package installation to work using salt, any idea?

Interesting. Looking at the salt source code, I can find one instance of --allowerasing option before the install or update command. dnf5 is extremely sensitive to the order of CLI commands and options. That would fail. Maybe you could test it and retry to see if that fixes the issue. Move cmd.append after cmd= ["y"]

This should have been fixed upstream in salt a while ago, it was reported in July 2023 https://github.com/saltstack/salt/issues/64532 and quickly fixed with this PR https://github.com/saltstack/salt/pull/64675 , I understand the change was to order --allowerasing differently depending if the dnf binary is dnf or dnf5. I don't understand we have this error.

[marmarek]

I can't get package installation to work using salt, any idea? I'm surprised as dnf5 compatibility should be fixed in salt?

Is it maybe old template used for default-mgmt-dvm ?

[lubellier]

The qubes-app-shutdown-idle package is missing.

With dnf5 search, I can't find the qubes-app-shutdown-idle package for this template. And in the fc41 repository, the rpm is not present, where it is available in the fc40 repository.

[alimirjamali]

I can't get package installation to work using salt, any idea? I'm surprised as dnf5 compatibility should be fixed in salt?

Is it maybe old template used for default-mgmt-dvm ?

The version of salt Qubes provides is salt-3006.9.tar.gz. If you extract it and inspect yumpkg.py within it, you will see that the patch @rapenne-s mentioned is not included.

Source link: https://yum.qubes-os.org/r4.3/current-testing/vm/fc41/rpm/salt-3006.9-2.fc41.src.rpm

[marmarek]

Indeed, this looks to be included only in 3007.1 release, not any 3006.x

[marmarek]

There is salt 3007.1 package for F42: https://src.fedoraproject.org/rpms/salt. I wonder if it will get published to F41 too.

[marmarek]

https://bugzilla.redhat.com/show_bug.cgi?id=2279304 suggests it will be.

[marmarek]

The qubes-app-shutdown-idle package is missing.

It's in current-testing now

[Minimalist73]

I'm not sure why I didn't see this before, but all my qubes running on Fedora 41 have memory issues. They are all stuck at the initial memory and won't bump to the maximum memory.

[user@disp2462 ~]$ free -mh
               total        used        free      shared  buff/cache   available
Mem:           445Mi       272Mi        18Mi       268Ki       165Mi       172Mi
Swap:          1.0Gi        39Mi       984Mi

I see that in the logs:

disp2462 audit[684]: AVC avc:  denied  { read } for  pid=684 comm="qrexec-agent" name="meminfo-writer.pid" dev="tmpfs" ino=791 scontext=system_u:system_r:local_login_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_run_t:s0 tclass=file permissive=0
disp2462 audit[684]: AVC avc:  denied  { read } for  pid=684 comm="qrexec-agent" name="meminfo-writer.pid" dev="tmpfs" ino=791 scontext=system_u:system_r:local_login_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_run_t:s0 tclass=file permissive=0
disp2462 audit[684]: AVC avc:  denied  { read } for  pid=684 comm="qrexec-agent" name="meminfo-writer.pid" dev="tmpfs" ino=791 scontext=system_u:system_r:local_login_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_run_t:s0 tclass=file permissive=0
disp2462 kernel: audit: type=1400 audit(1732034995.035:110): avc:  denied  { read } for  pid=684 comm="qrexec-agent" name="meminfo-writer.pid" dev="tmpfs" ino=791 scontext=system_u:system_r:local_login_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_run_t:s0 tclass=file permissive=0
disp2462 audit[684]: AVC avc:  denied  { read } for  pid=684 comm="qrexec-agent" name="meminfo-writer.pid" dev="tmpfs" ino=791 scontext=system_u:system_r:local_login_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_run_t:s0 tclass=file permissive=0
disp2462 kernel: audit: type=1400 audit(1732035025.188:113): avc:  denied  { read } for  pid=684 comm="qrexec-agent" name="meminfo-writer.pid" dev="tmpfs" ino=791 scontext=system_u:system_r:local_login_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_run_t:s0 tclass=file permissive=0
disp2462 audit[684]: AVC avc:  denied  { read } for  pid=684 comm="qrexec-agent" name="meminfo-writer.pid" dev="tmpfs" ino=791 scontext=system_u:system_r:local_login_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_run_t:s0 tclass=file permissive=0
disp2462 kernel: audit: type=1400 audit(1732035301.880:126): avc:  denied  { read } for  pid=684 comm="qrexec-agent" name="meminfo-writer.pid" dev="tmpfs" ino=791 scontext=system_u:system_r:local_login_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_run_t:s0 tclass=file permissive=0

Setting SELinux globally to permissive seems to bring all my qubes back to maximum memory, so I guess that's related to those denied selinux rules.

[marmarek]

I see that in the logs:

The issue is fixed in https://github.com/QubesOS/updates-status/issues/5240. I'll rebuild remaining templates once https://github.com/QubesOS/qubes-builder-rpm/pull/139 is done.

[Minimalist73]

I see that in the logs:

The issue is fixed in QubesOS/updates-status#5240. I'll rebuild remaining templates once QubesOS/qubes-builder-rpm#139 is done.

Is there any manual action we can do to fix an already installed template, or do we need to reinstall from this new template?

[marmarek]

Is there any manual action we can do to fix an already installed template, or do we need to reinstall from this new template?

Try removing /.qubes-relabeled in the template and restarting it - it should fix labels on startup; it may take some time, might require increasing qrexec_timeout property.

[Minimalist73]

Is there any manual action we can do to fix an already installed template, or do we need to reinstall from this new template?

Try removing /.qubes-relabeled in the template and restarting it - it should fix labels on startup; it may take some time, might require increasing qrexec_timeout property.

I tried it a few times at first, but it didn't work for any of my templates. It seems I had to reinstall all the selinux related packages first and then proceed with relabeling for it to work. Probably some of them were half installed, no idea. Anyway, thanks!

[marmarek]

All template flavors are rebuilt now and should have the SELinux issue fixed.

[marmarek]

@andrewdavidwong no new issues are found, I think it's stable enough to announce it. Can you prepare the announcement?

[ImBearChild]

There is salt 3007.1 package for F42: https://src.fedoraproject.org/rpms/salt. I wonder if it will get published to F41 too.

Fedora uses a patch to fix this issue on Fedora 41. Maybe QubesOS should ship salt 3006.X with this patch, too.

https://src.fedoraproject.org/rpms/salt/blob/f41/f/64675.patch

[marmarek]

This patch is not applied in F41 package anymore: https://github.com/QubesOS/qubes-issues/issues/9244#issuecomment-2550354164 (I guess somebody forgot, either to apply, or to remove the patch file).

Anyway, 3007.1 is in our current-testing repositories already: https://github.com/QubesOS/updates-status/issues/5334