Description of problem: Version-Release number of selected component (if applicable): How reproducible: Happens only on a Dell 1650 I run and no other hardware. Steps to Reproduce: 1. Upgrade selinux-policy and kernel. 2. Reboot. You won't have network connectivity. 3. Run /sbin/fixfiles relabel. Clear /tmp. 4. Reboot. Connectivity is restored. Actual results: Needs /sbin/fixfiles relabel and an extra reboot. Expected results: Reboot once after new kernel and it should come up, with connectivity. Additional info: Upgrading only the kernel results in normal functionality. Upgrading only selinux-policy and rebooting does reprodue this problem. Only occurs on machine running the e1000 driver. Results of lspci: 00:00.0 Host bridge: Broadcom CNB20HE Host Bridge (rev 23) 00:00.1 Host bridge: Broadcom CNB20HE Host Bridge (rev 01) 00:00.2 Host bridge: Broadcom CNB20HE Host Bridge (rev 01) 00:00.3 Host bridge: Broadcom CNB20HE Host Bridge (rev 01) 00:0c.0 VGA compatible controller: ATI Technologies Inc Rage XL (rev 27) 00:0f.0 Host bridge: Broadcom CSB5 South Bridge (rev 93) 00:0f.1 IDE interface: Broadcom CSB5 IDE Controller (rev 93) 00:0f.2 USB Controller: Broadcom OSB4/CSB5 OHCI USB Controller (rev 05) 00:0f.3 ISA bridge: Broadcom CSB5 LPC bridge 01:02.0 Ethernet controller: Intel Corporation 82544EI Gigabit Ethernet Controller (Copper) (rev 02) 01:04.0 Ethernet controller: Intel Corporation 82544EI Gigabit Ethernet Controller (Copper) (rev 02) 01:06.0 SCSI storage controller: Adaptec AIC-7899P U160/m (rev 01) 01:06.1 SCSI storage controller: Adaptec AIC-7899P U160/m (rev 01) 02:08.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5703X Gigabit Ethernet (rev 02) 02:0a.0 SCSI storage controller: Adaptec AHA-3960D / AIC-7899A U160/m (rev 01) 02:0a.1 SCSI storage controller: Adaptec AHA-3960D / AIC-7899A U160/m (rev 01)
Do you have the log files? From what you have written, I would have no idea what happened. The only time we usually need to relabel if if you jump major versionf of the OS FC5-FC6 for example.
Which log files would be most helpful? /var/log/messages?
/var/log/audit/audit.log and/or /var/log/messages
Created attachment 145592 [details] /var/log/audit/audit.log
Created attachment 145593 [details] /var/log/messages
From the log files it looks like you added a new file system mounted under /var. This was not labeled so it caused all of your problems. file_t indicates that a file system does not have any labeling on it.
So how to I prevent this sort of thing in the future? I assume some relabeling of / occurs with policy changes, but am I to assume that my /var will not be labeled? Is there a place where I can configure this behavior, or am I stuck? I would have expected it to relabel all mounted filesystems in fstab (avoiding cdroms, floppies, usbkeys, etc). I'm lucky to have this server on a networked KVM, but I may not always be so lucky.
It does not relabel on its own. (for the most part). / does not get relabeled on change of policy. The rpm tries to figure out what labeling changed between the currently installed policy and the new one. If it finds a change, it relabels only those files/directories. If you add a disk though, you need to label it properly. How this disk got unlabled I do not know. So now that everything is labeled correctly you should be all set. We have thousands of machines installed with SELinux and this is the first time I have heard of any problems, in a couple of years. I believe a disk/partition got added to this machine and was never labeled.
Even though this disk/partition has been in place since install time, in March of 2005?
All I can say, is I have no idea how it happened, and see if it happens again. The only ways that I know of this happening is the addition of a new disk/partition, or booting with selinux=0/disabled. If it happens again, we might have a kernel problem or there could be a disk problem. The xattrs should not dissappear from the disk.