error: %prein(selinux-policy-targeted-3.13.1-157.fc23.noarch) scriptlet failed, exit status 126 Error in PREIN scriptlet in rpm package selinux-policy-targetedHow can I diagnose this? Where can I dig out the exact reason why the scriptlets are failing?Once you know a specific package that fails like that, you could query its scriptlets section and try to reproduce manually: rpm -q --scripts selinux-policy-targeted At the top find the %prein section. It doesn't do much, but it may run some external commands.Thanks a lot for the hint. So I tried looking at the very first package that had any failure at all (albeit nonfatal), during the initial filesystem installation. That was glibc. :-( It was a POSTIN failure. "rpm -q --scripts glibc" tells me that "postinstall program" is set to /usr/sbin/glibc_post_upgrade.x86_64. This binary is both in the installation environment and in the sysimage (even twice, perhaps hardlinked, in /sbin and /usr/sbin). When I chroot into the sysimage, I can run the glibc_post_upgrade.x86_64 binary just fine and its exit code is 0. Yet upon glibc (re)installation, I'm getting that non-fatal error message saying that its exit code was 126. So the question is why glibc_post_upgrade.x86_64 can't be run by/from rpm. Does rpm try to execute the postinstall oneliner using a shell that could be missing? Executing simply "sh" in the sysimage chroot works fine though... Could someone please point me to the sources of rpm/dnf/whatever where the "postinstall program" command gets executed? It seems that I can't reproduce the failure manually. And it's probably not worth looking into all the subsequent failures until I know more about the very first one.OK, I think solved this. It was partially a human error and partially a tiny glitch in the blogpost linked from my original post. But I'll post the answer nonetheless, hoping that it could once help someone. Short answer: First, you must "mount -o bind /sys/fs/selinux /mnt/sysimage/sys/fs/selinux". Second, also mount /mnt/sysimage/proc *before* attempting to install 'filesystem'. That's it. That's all. How I found out where the problem was: 1) I installed 'strace' into the installation environment (pretty straightforward). Not sure if you need network access for that, but I did have it, so I think I got it from updates or the like. 2) I took the very first package with non-fatal errors, 'glibc', and reinstalled it under strace: "strace -f dnf install -y --releasever=23 --installroot=/mnt/sysimage glibc 2>/tmp/strace" 3) In /tmp/strace, I grep'd for whatever could be related to a child exiting with code 126. And indeed, I found 2 messages saying that a process exited with code 126 (corresponding to 2 benign errors). 4) In the strace messages of the failing child process, there were ~3 unsuccessful file accesses. Two were unsuccessful /proc accesses and the third one failed to open /sys/fs/selinux/enforce. 5) And bingo! Indeed, /sys/fs/selinux/enforce (or anything else in /sys/fs/selinux) was simply not there, because "mount -o bind /sys ..." doesn't apply to mountpoints nested deeper in the directory. So I wiped out the new root, recreated my complex structure of subvolumes, creating and mounting /sys, /sys/fs/selinux and /proc manually *before* the initial 'filesystem' package installation. Otherwise things seemed to start breaking from that point on. The 'filesystem' package errors were non-fatal and therefore it could well be the case that the missing /sys/fs/selinux mount was the only culprit that caused my first installation attempt to fail. But to be on the safe side, next time I'll set up /proc, /sys, and /sys/fs/selinux manually. OK, this is it. Bypassing Anaconda and doing a custom partition layout is perfectly feasible. :-) It just doesn't have a sufficient coverage in the documentation.
I'm updating this thread for future readers' convenience. Manual installation as described above is still feasible with Fedora 26, but in addition to all the bind mounts already mentioned, you must also bind mount the efivars filesystem. If you don't, you won't be able to (re)install EFI GRUB properly (which happens upon installation of the appropriate packages) and you also won't be able to generate the GRUB configuration. So, on the host live system, look up the efivars subdirectory of /sys and bind mount it into your new chroot installation.
Further glitches include SELinux labeling of mount point directories and Btrfs subvolume directories, both implicitly mounted and explicitly mounted. You need to make sure that the directories have the correct SELinux contexts, preferably using restorecon. If you mount e.g. Btrfs subvolumes explicitly (which I mostly do, because I have e.g. /fedora_root and /fedora_home subvolumes, so that one and the same FS can be shared among multiple distros), you need to make sure that /fedora_home on the root filesystem has the same SELinux context as /fedora_root/home, its run-time mount point. Also, my /var and /etc directories happen to be subvolumes (implicitly mounted directly in /fedora_root/{etc,var}) and those also need an explicit restorecon before one can successfully boot with enforcing enabled. For some reason /.autorelabel doesn't do the trick for them. I think these directories would get set up properly if dnf was creating them from scratch, but that's not the case with custom layouts and subvolumes.
Andrej
Attachment:
smime.p7s
Description: Elektronicky podpis S/MIME
_______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
