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.
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.
rpm's matchpathcon was causing things to be mislabled in versions prior to 4.4.1-18.1 - that may be related.
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.
This sounds like a udev bug
*** Bug 156864 has been marked as a duplicate of this bug. ***
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 to: mount -o mode=0755 -t tmpfs /dev /dev when start_udev only recognizes the former. Reverting this change and recreating initrd fixes the problem.
*** Bug 156860 has been marked as a duplicate of this bug. ***
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.
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.
*** Bug 156776 has been marked as a duplicate of this bug. ***
Bill built a fix
*** Bug 156956 has been marked as a duplicate of this bug. ***
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.
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)
*** Bug 157019 has been marked as a duplicate of this bug. ***
*** Bug 157023 has been marked as a duplicate of this bug. ***
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.
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?
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)
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: 00000000 *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.
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, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0xb7fd6a28) = 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 +++
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.
Ingo, you should probably file a new bug on the problems you're seeing.
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.
(reopening the bug - my original filing from a week ago got duplicate-marked into this entry so the bug history is here.)
start_udev in rc.sysinit mounts /dev again, breaks selinux is solved...
Ingo, I think this is a separate issue. Please file it as a different bug if it's still occurring.