>>> 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-targeted
>>
>>> How 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