Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.

Bug 156862

Summary: start_udev in rc.sysinit mounts /dev again, breaks selinux
Product: [Fedora] Fedora Reporter: Alexandre Oliva <oliva>
Component: mkinitrdAssignee: Peter Jones <pjones>
Status: CLOSED RAWHIDE QA Contact: David Lawrence <dkl>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: agk, avi, gczarcinski, jorton, josip, katzj, me, mingo, mpeters, notting, pjones, samuel.mutel, zaitcev
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: udev-057-4 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-05-18 21:15:06 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 136450    

Description Alexandre Oliva 2005-05-04 19:18:29 UTC
Current selinux targeted policy requires device mapper nodes to have context
system_u:object_r:fixed_disk_device_t in order for fsck to be able to check that
they're ok to mount.  Unfortunately, when we get to the fsck point, their
context is system_u:object_r:tmpfs_t.

AFAICT, vgmknodes makes no effort whatsoever to get the nodes in /dev/mapper to
have the right context, although the soft links in /dev/<VGNAME> have their
context changed to device_t before the actual node is created.  This enables the
soft-link to be followed, but doesn't affect the actual device mapper node in
any way.

I was able to restore proper functioning by adding to rc.sysinit the following line:

[ -n "$SELINUX" ] && restorecon /dev/mapper/*-* >/dev/null 2>&1

after the vgscan command, but I suppose we might be better off ensuring the
mknod syscalls issued by lvm create nodes with the correct contexts.

Comment 1 Alexandre Oliva 2005-05-04 19:48:31 UTC
Hmm...  The root cause might be that /dev has context ::tmpfs_t, so
sub-directories and files inherit this context.  I'm trying to figure out why
the restorecon -R /dev early in rc.sysinit doesn't have the intended effect.

Comment 2 Bill Nottingham 2005-05-04 19:55:24 UTC
rpm's matchpathcon was causing things to be mislabled in versions prior to
4.4.1-18.1 - that may be related.

Comment 3 Alexandre Oliva 2005-05-04 20:30:19 UTC
I don't think so.  Even after a full relabel, it still fails.  The failure is
because udev_start in rc.sysinit is mounts another /dev on top of the existing
one, so another restorecon -R /dev is needed after that.  I suppose this second
/dev is neither intended nor desirable, but I haven't still figured out why
udev_start decides it needs a new /dev.

Comment 4 Jeremy Katz 2005-05-04 21:14:41 UTC
This sounds like a udev bug

Comment 5 Alexandre Oliva 2005-05-05 04:27:55 UTC
*** Bug 156864 has been marked as a duplicate of this bug. ***

Comment 6 Alexandre Oliva 2005-05-05 05:19:57 UTC
It's more arguably a bug in mkinitrd, for having changed the mount command used
to mount /dev from:

mount -o mode=0755 -t tmpfs none /dev


mount -o mode=0755 -t tmpfs /dev /dev

when start_udev only recognizes the former.  Reverting this change and
recreating initrd fixes the problem.

Comment 7 Alexandre Oliva 2005-05-05 05:51:13 UTC
*** Bug 156860 has been marked as a duplicate of this bug. ***

Comment 8 Pete Zaitcev 2005-05-05 06:11:18 UTC
The problem is that changing those names was a very good idea.
I have all my FC3 boxes running with fstab which looks like this:

# This file is edited by fstab-sync - see 'man fstab-sync' for details
LABEL=R2                /                       ext3    defaults        1 1
none_pts                /dev/pts                devpts  gid=5,mode=620  0 0
none_shm                /dev/shm                tmpfs   defaults        0 0
none_proc               /proc                   proc    defaults        0 0
none_sys                /sys                    sysfs   defaults        0 0
none_usb                /proc/bus/usb           usbfs   defaults        0 0
none_debug              /dbg                    debugfs noauto          0 0
none_debug              /sys/kernel/debug       debugfs noauto          0 0
/dev/hda3               swap                    swap    defaults        0 0
LABEL=Q                 /q                      ext3    defaults        1 2

This way if something breaks, something better than "none" is printed.
This better be fixed in udev.

Comment 9 Alexandre Oliva 2005-05-05 06:42:41 UTC
But see, /dev is not mentioned in your /etc/fstab at all.  start_udev recognizes
the way it mounts /dev, and it shouldn't have to do more work than that.  If
someone else who's attempting to duplicate its behavior fails, it's not udev's
fault, and I don't see that it must be modified to accomodate it.

Comment 10 Bill Nottingham 2005-05-05 15:36:57 UTC
*** Bug 156776 has been marked as a duplicate of this bug. ***

Comment 11 Jeremy Katz 2005-05-05 19:09:20 UTC
Bill built a fix

Comment 12 Alasdair Kergon 2005-05-05 19:12:05 UTC
*** Bug 156956 has been marked as a duplicate of this bug. ***

Comment 13 Bill Nottingham 2005-05-05 19:29:57 UTC
Fixed in udev-057-4; udev should be keying off of the filesystem type and mount
point, not off of the magic (and arbitrary) device key passed in via mount.

Comment 14 Fred New 2005-05-06 14:55:35 UTC
Let's see if we can reduce the number of duplicate bugs opening by adding
text that most people are searching for.  This bug manifests itself for
most people with the following messages:

Starting udev: MAKEDEV: mkdir: File exists
                      [  OK  ]
Initializing hardware...

and then the system hangs.  (Other keywords - hang, freeze, freezes)

Comment 15 Bill Nottingham 2005-05-06 16:23:16 UTC
*** Bug 157019 has been marked as a duplicate of this bug. ***

Comment 16 Bill Nottingham 2005-05-06 16:23:17 UTC
*** Bug 157023 has been marked as a duplicate of this bug. ***

Comment 17 josip 2005-05-08 22:27:17 UTC
My system used to freeze at the same point using kernel-2.6.11-1.1286_FC4 (see
duplicate bug report 157019).

This problem is fixed in kernel-2.6.11-1.1287_FC4.

Comment 18 Ingo Molnar 2005-05-09 06:28:17 UTC
updated to 1287 and removed selinux=0 - the bootup works fine now. Another,
probably related xDSL problem went away too.

What's remaining is that i cannot login as root or as user from a text console,
it gives me: "No shell: Permission denied" (or something like that). Could this
be a side-effect of me running with selinux=0 for a while? (i updated a good
deal of packages while in selinux=0) Shouldnt the system have relabeled my
filesystems automatically?

Comment 19 Joe Orton 2005-05-09 09:46:22 UTC
I think you should expect to have to "touch /.autorelabel && reboot" after
running with SELinux disabled for a while, yes.  (or run restorecon or so on)

Comment 20 Ingo Molnar 2005-05-11 06:31:15 UTC
i relabeled all my filesystems (it took many hours), but the problem did not go
away. It seems to have changed in a way: logins (of root and normal users alike)
now fail only about 50% of the time. So i could do some debugging - i tried to
straced mingetty, but got this kernel crash:

Unable to handle kernel NULL pointer dereference at virtual address 00000000
 printing eip:
*pde = 08943067
Oops: 0000 [#1]
Modules linked in: deflate zlib_deflate twofish serpent blowfish sha256
crypto_null aes_i586 des xfrm4_tunnel ipcomp esp4 ah4 af_key sch_ingress cls_u32
sch_sfq sch_cbq pcspkr autofs4 md5 ipv6 n_hdlc ppp_synctty ppp_async ppp_generic
ipt_REJECT ipt_state ip_conntrack iptable_filter ip_tables dm_mod uhci_hcd
i2c_i801 i2c_core snd_cmipci gameport snd_seq_dummy snd_seq_oss
snd_seq_midi_event snd_seq snd_pcm_oss snd_mixer_oss snd_pcm snd_page_alloc
snd_opl3_lib snd_timer snd_hwdep snd_mpu401_uart snd_rawmidi snd_seq_device snd
soundcore hisax crc_ccitt isdn slhc e100 mii floppy ext3 jbd raid1
CPU:    0
EIP:    0060:[<00000000>]    Not tainted VLI
EFLAGS: 00010286   (2.6.11-1.1288_FC4)
EIP is at _stext+0x3feffdd8/0x8
eax: ea4a2000   ebx: 01200011   ecx: 00000000   edx: 00000000
esi: cc898aa0   edi: ef88fbc4   ebp: ea4a2000   esp: ea4a2fc4
ds: 007b   es: 007b   ss: 0068
Process login (pid: 26164, threadinfo=ea4a2000 task=cc898aa0)
Stack: 01202011 00000000 00000000 00000000 b7fa5a28 bfac6b38 00000000 c010007b
       c010007b 00000078 00520402 00000073 00000286 bfac6ae0 0000007b
Call Trace:
Code:  Bad EIP value.

Comment 21 Ingo Molnar 2005-05-11 06:34:30 UTC
it was with 2.6.11-1.1288_FC4, and all the latest devel packages.

i couldnt get to the "no shell: permission denied" failure via the strace, it
seemed to crash earlier than that. These are the last strace lines i got:

27821 rt_sigaction(SIGHUP, {SIG_IGN}, {SIG_DFL}, 8) = 0
27821 ioctl(0, TIOCNOTTY)               = 0
27821 --- SIGHUP (Hangup) @ 0 (0) ---
27821 --- SIGCONT (Continued) @ 0 (0) ---
27821 rt_sigaction(SIGHUP, {0x8049bd0, [], 0}, NULL, 8) = 0
27821 rt_sigaction(SIGTERM, {0x8049bd0, [], 0}, {SIG_DFL}, 8) = 0
27821 close(3)                          = 0
27821 clone(child_stack=0,
= 2794227821 close(0)                          = 0
27821 close(1)                          = 0
27821 close(2)                          = 0
27821 rt_sigaction(SIGQUIT, {SIG_IGN}, NULL, 8) = 0
27821 rt_sigaction(SIGINT, {SIG_IGN}, NULL, 8) = 0
27821 wait4(-1,  <unfinished ...>
27942 +++ killed by SIGSEGV +++

Comment 22 Ingo Molnar 2005-05-11 08:33:16 UTC
more details: sshing to the box does not work at all - i'm always getting the
"/bin/bash: Permission denied" message. Stracing sshd gives a similar early
kernel crash.

Comment 23 Joe Orton 2005-05-11 08:35:31 UTC
Ingo, you should probably file a new bug on the problems you're seeing.

Comment 24 Ingo Molnar 2005-05-11 08:45:06 UTC
These problems started all at once. I had a fully working system (tracking
-devel for months) with a complex workload (it's my main desktop box), before
this started. It started as the xDSL problem, then morphed into the /dev
problem, and now it's the login problem. It was all triggered by the update ~2
weeks ago (which updated initscripts, and maybe some selinux policies, iirc). It
could be multiple independent bugs, but the timing is still suspicious.

In any case, this is a showstopper on this box, and as usual, selinux=0 solves
the problem - which was a cure for all the other symptoms as well.

Comment 25 Ingo Molnar 2005-05-11 08:47:30 UTC
(reopening the bug - my original filing from a week ago got duplicate-marked
into this entry so the bug history is here.)

Comment 26 Harald Hoyer 2005-05-11 14:44:04 UTC
start_udev in rc.sysinit mounts /dev again, breaks selinux is solved...

Comment 27 Peter Jones 2005-05-18 21:15:06 UTC
Ingo, I think this is a separate issue.  Please file it as a different bug if
it's still occurring.