Hi,
Because Anaconda doesn't support my usual partitioning scheme (root on Btrfs in LVM in LUKS in LVM in GPT, /boot on Btrfs, etc.), I created the entire layout manually and tried to install Fedora using dnf. The same layout works perfectly fine in ArchLinux.
I basically followed this howto, with adjustments for s/yum/dnf/ and for EFI/GPT: http://dustymabe.com/2014/05/29/manual-linux-installs-with-funky-storage-con...
The initial filesystem installation (dnf install -y --releasever=23 --installroot=/mnt/sysimage filesystem) already got a few glitches of this form:
Non-fatal POSTIN scriptlet failure in rpm package filesystem
This^^^ happened to roughly half of the installed packages. I tried to proceed with the rest (i.e., to install @core @standard kernel grub2 grub2-efi sihm grub2-tools), but it failed with scriptlet errors that prevented a few key packages from getting installed at all:
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
Packages with those errors are reported as failed after the verify step. What I tried next:
* setenforce 0 * upgrading the installation environment and/or the sysimage with dnf and rpm from rawhide * --releasever=22 instead of 23 * ...and checking for a few other common points with this bug: https://bugzilla.redhat.com/show_bug.cgi?id=1270663 * a plain sysimage directory with no predefined Btrfs subvolumes in it * unmounting, remounting, checking that everything has seclabel on, no weirdness in dmesg, etc.
Well, nothing of the above helped; the error is still the same.
How can I diagnose this? Where can I dig out the exact reason why the scriptlets are failing?
Provided that Anaconda actually does some steps that I'm missing and can carry out the installation correctly, is there a way to *force* it to just accept whatever is mounted into /mnt/sysimage at the moment, without trying to make sense of it? I'm pretty sure dracut can handle my partition layout just fine, so the entire issue here is about getting the basic installation done somehow.
Theoretically I could create a simple-and-stupid layout that Anaconda can handle, proceed with the installation and reshuffle the partitions afterwards, but that's sooo cumbersome that I thought I'd first ask whether someone knows a workaround to the scriptlet problems.
Cheers, Andrej
On Sun, 13 Dec 2015 08:54:14 +0100, Andrej Podzimek wrote:
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.
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.
Andrej
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.
Cheers, Andrej
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
-
Andrej Podzimek -
Michael Schwendt