Since Fedora-Rawhide-20260127.n.0 , all disk image deploy tests are failing in openQA. These are aarch64 tests, but it's *probably* not arch specific. After we boot and run through initial-setup, logging in as either the user created during i-s, or root with the password set during i-s, both fail. We don't have any logs because the root login failed. I'm betting this is caused by shadow 4.19 because it's obviously relevant, it's caused a lot of other problems, and it landed in 20260127.n.0. I'll try and fiddle with this and get some logs out from a systemd emergency console or something. Proposing as an F44 Beta blocker as a violation of "A system installed without a graphical package set must boot to a state where it is possible to log in through at least one of the default virtual consoles" for whichever of the aarch64 disk image deliverables are release blocking (I can't look it up right now because the list appears to have disappeared from docs.fp.o...)
Ah, okay, so this is an SELinux denial: Feb 02 22:13:37 localhost.localdomain org.fedoraproject.Anaconda.Modules.Users[1040]: INFO:program:Running... chpasswd -R / -e Feb 02 22:13:37 localhost.localdomain audit[1231]: AVC avc: denied { write } for pid=1231 comm="chpasswd" name="passwd" dev="vdb3" ino=38854 scontext=system_u:system_r:passwd_t:s0 tcontext=system_u:object_r:etc_t:s0 tclass=file permissive=0 ... Feb 02 22:13:37 localhost.localdomain org.fedoraproject.Anaconda.Modules.Users[1040]: OSError: Unable to set password for new user: status=1 Feb 02 22:13:37 localhost.localdomain initial-setup[994]: Initial Setup crashed due to unhandled exception: not sure what exactly changed here, though. Zdenek, can you take a look at this urgently? It breaks Rawhide disk image installs.
Hmm, scontext=system_u:system_r:passwd_t:s0 looks like it might be wrong for some reason? It looks like /usr/bin/chpasswd 's type is meant to be system_u:object_r:passwd_exec_t . Or am I reading that wrong?
ls -lZ /usr/bin/chpasswd shows system_u:object_r:passwd_exec_t when checked after this failure occurs, so I guess that scontext doesn't mean what I thought it did.
There is not much data for troubleshooting from SElinux PoV, but I guess that chpasswd wants to write to /etc/passwd file with the etc_t label. It is correct policy denies this access. What is not correct is label of the file, so this bug needs to be troubleshooted a few steps earlier: which process created the file? Which related change is in the last shadow-utils or perhaps also in some library used during installation?
Ah, hmm, I was for some reason just assuming the etc_t label was correct...d'oh. If that's the issue, it *may* be another case related to https://github.com/rhinstaller/anaconda/pull/6881 , but I'd have to figure out exactly how /etc/passwd gets created...presumably during the image build process?
`setup` package provides `/etc/passwd`, but I'm unsure as to when this package is run and how it creates the file
The previous message assumes you mean the usual installation. If you mean a chroot'ed environment, then I guess that must be part of the chroot creation
That's the question, yes. This is about deploying from the disk images produced as part of composes; the way you do that in real life is to write the image to a USB stick or SD card and boot your device from that, then initial-setup runs to customize the configuration, including creating the user account. In openQA we simulate this by attaching the disk image (with an overlay file) to a VM as a USB device and booting from that, that's the test that's failing. So I need to figure out / remember how exactly the disk images are created these days. I suspect we'll find out a chroot is involved there somewhere and so it's the shadow 4.19 change to no longer do selinux processing in chroots, but we need to confirm that.
Hmm, so an interesting wrinkle on this that I'd forgotten about. It's affecting both the Server disk image and the Minimal disk image - but those are actually built with different tools. Server is built with Kiwi, Minimal is built with image-builder. So...either they both happen to do something similar which is broken by the shadow change (presumably)...or the problem is in some common 'layer' that they share...like some package scriptlet or something that runs before initial-setup. I'm gonna grab 'before' and 'after' copies of both images and see what I can see just by mounting them and poking around.
Agh, okay, yeah, it's the shadow selinux change. In the bare image file, /etc/passwd has the correct label: [root@omnibook 44]# losetup -P -f Fedora-Minimal-Rawhide-20260127.n.0.aarch64.raw [root@omnibook 44]# mount /dev/loop1p3 /mnt/min27/ [root@omnibook 44]# ls -lZ /mnt/min27/etc/passwd -rw-r--r--. 1 root root system_u:object_r:passwd_file_t:s0 1220 Jan 26 22:40 /mnt/min27/etc/passwd So it's getting changed before the chpasswd call. I think it gets changed *right* before, when initial-setup creates a user: useradd -R / -U -d /home/test -m test I looked into the shadow code, and I'm pretty sure I see why. When changing /etc/passwd, /etc/shadow etc., shadow doesn't really edit the existing file; it copies the existing file to a backup name, then creates a new file with a temporary name and the modified content, then renames that file to the 'real' name. So it's doing something like this (not *exactly* this, obviously, but *like* this): cp /etc/passwd /etc/passwd.bak10-1i531 printf 'new contents' > /etc/passwd.new1-isdgop mv /etc/passwd.new1-isdgop /etc/passwd You can see the code at https://github.com/shadow-maint/shadow/blob/38962a5872bfa1523c0cdaed393461cc49c666a8/lib/commonio.c#L845 (it's shared between handling of /etc/passwd , /etc/shadow , /etc/group etc - that's why it's called 'commonio'). The key point is - it creates the new file under a randomized temp name then renames it, it does *not* create it with the name /etc/passwd . That means the file gets the generic label for files in /etc (etc_t), not the specific label that's associated with /etc/passwd (passwd_file_t). So what changed is the shadow 4.19 change to not fixup SELinux stuff when running with a -R argument. shadow 4.18 and earlier fixed up the label after renaming the file, but in shadow 4.19, that's skipped if -R (--root) or (-P) (--prefix) is passed to useradd: https://github.com/shadow-maint/shadow/blob/38962a5872bfa1523c0cdaed393461cc49c666a8/lib/commonio.c#L955 process_selinux will be false there when -R or -P are set (this is determined in useradd.c and passed all the way through to commonio_close). So...this specific case (in initial-setup) is obviously a bit silly because we're passing `-R /`, which is kinda pointless. We could change anaconda to not pass `-R` at all if its value would be /, or we can change shadow to go ahead and do SELinux Stuff if the value of -R is / or the value of -P is /etc , or we could do both. There is a general case here, though - when we create a user in a real install scenario, where we *do* have a system root, that'll result in /etc/passwd having the wrong context. I don't know if that gets fixed up later somehow or if it persists to the installed system, I'll have to check. It's likely the same may be the case for other files and other possible operations too, I haven't checked on all the possibilities yet.
https://github.com/rhinstaller/anaconda/pull/6886 is my proposed fix for this case.
Aha, OK, so for the install case, we have SetContextsTask which runs at the end of install and restorecons the whole of /etc (along with various other places), at least so long as restorecon got installed. So that should hide this problem for pretty much all installer use cases...hopefully. So maybe we can get away with just this patch.
FEDORA-2026-e883c84e3e (anaconda-44.20-1.fc45 and anaconda-webui-65-1.fc45) has been submitted as an update to Fedora 45. https://bodhi.fedoraproject.org/updates/FEDORA-2026-e883c84e3e
FEDORA-2026-db94b09323 (anaconda-44.20-1.fc44 and anaconda-webui-65-1.fc44) has been submitted as an update to Fedora 44. https://bodhi.fedoraproject.org/updates/FEDORA-2026-db94b09323
FEDORA-2026-db94b09323 (anaconda-44.20-1.fc44 and anaconda-webui-65-1.fc44) has been pushed to the Fedora 44 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2026-e883c84e3e (anaconda-44.20-1.fc45 and anaconda-webui-65-1.fc45) has been pushed to the Fedora 45 stable repository. If problem still persists, please make note of it in this bug report.