Bug 451503 - won't boot, libblkid.so missing if selinux is on
won't boot, libblkid.so missing if selinux is on
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: selinux-policy (Show other bugs)
9
x86_64 Linux
low Severity medium
: ---
: ---
Assigned To: Daniel Walsh
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-06-14 21:40 EDT by Hin-Tak Leung
Modified: 2009-05-06 11:28 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-05-06 11:28:11 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Hin-Tak Leung 2008-06-14 21:40:59 EDT
Description of problem:

I can't remember when it started. I had successfully used 
2.6.25.3-18.fc9 for days or hours, but uses 2.6.24.7-92.fc8 mostly.
Lately I found that I cannot boot fc9 kernels, and the error
is always mount: cannot find libblkid.so.1, file missing.
I have unpacked the 'initrd with gzip -dc | cpio -m -d' and it is there.
Very curious until I have to test a wireless driver under a current 
fc9 kernel and looked for an answer, and found bug 447067, and so I disable
selinux with selinux=0 - and voila, it boots.

This is the same initrd, without selinux=0, it won't boot.

Version-Release number of selected component (if applicable):
kernel-2.6.25.6-55.fc9.x86_64 mkinitrd-6.0.52-2.fc9.x86_64 .
initrd was created under kernel-2.6.24.7-92.fc8.x86_64 (I only have one 
bootable kernel until I found the selinux=0 workaround, so obviously
I have to create the other kernel's initrd using the older fc8 one). 

How reproducible:
always

Steps to Reproduce:
1. reboot system, choose kernel-2.6.25.6-55.fc9.x86_64 , and do not edit
grub options. system won't mount root fs, saying libblkid.so.1 is is missing
eventually system tries to mount root fs in read-only mode, and proceeed to
fix some policy stuff which takes ages, and still in read-only mode.
2.reboot with ctrl-alt-del, edit grub options to add selinux=0 . Now system
boots up normally.
3.
  
Actual results:
System won't mount root fs.

Expected results:
mount root fs and proceed to normal functionality.

Additional info:

AFAIK, I have not done any encryption at all (unlike in bug 447067). The system 
was a fresh install with fedora 8 and normal usage/upgrades, then upgraded to f9
using the prodecure in YumUpgradeFaq. Also, I have used 2.6.25.3-18.fc9
intermittently for hours or days. Because of bug 432280, I haven't been keeping
up with kernel updates often enough, since it means I need to build a new kernel
module, etc. 

I don't know whether it is because I built the new initrd under an f8 kernel,
but since I can only use a new kernel with selinux disabled, it doesn't look as
if I can build a new working initrd which works with selinux enabled? chicken
and egg problem.
Comment 1 Hin-Tak Leung 2008-06-26 20:55:43 EDT
I have managed to "workaround" my problem: set permissive in
/etc/sysconfig/selinux and "touch /.autorelabel" before making a new initrd and
reboot to the new kernel. One the first boot after, the system does a long
relabeling when it boots, logs a few warnings about denials with libblkid.so.1,
but keeps going, and it basically works from there, and I can set enforcing back
in /etc/sysconfig/selinux . A 2nd reboot to the new kernel is all clean and nice.

I was basically following the instructions for in
http://www.crypt.gen.nz/selinux/disable_selinux.html for *re*-enabling selinux.
It seems that what happened was that selinux wasn't really enabled/enforced
until a few kernel releases after f9, and it further wasn't helped by me
upgrading f8->f9 through yum.

this kind of workaround probably should be mentioned in the
f9 release note (or f10), and definitely be in the yumupgradefaq.
Comment 2 cje 2008-08-11 08:27:53 EDT
i got this too after a x86 network upgrade from f8 to f9.  the old f8 kernel kept working but the f9 one produced these file not found errors and kept trying to relabel the filesystem on boot.

i didn't need to make a new initrd or touch /.autorelabel - i just booted once in permissive mode.

i agree this should be written up somewhere but surely it could be fixed too?

so far this hasn't affected my other x86 system which was upgraded from f8 using the f9 dvd.
Comment 3 Daniel Walsh 2009-05-06 11:28:11 EDT
We have fixed this in newer updates.

Note You need to log in before you can comment on or make changes to this bug.