Description of problem:
Version-Release number of selected component (if applicable):
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.
Needs /sbin/fixfiles relabel and an extra reboot.
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]
Created attachment 145593 [details]
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
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.