%prein(selinux-policy-targeted-3.13.1-157.fc23.noarch) scriptlet failed, exit status 126
>> Error in PREIN scriptlet in rpm package selinux-policy-targeted
>> How can I diagnose this? Where can I dig out the exact reason why the scriptlets
> 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
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.