Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 222669 - Kernel upgrade/selinux-policy upgrade requires reboot->fixfiles relabel->reboot
Kernel upgrade/selinux-policy upgrade requires reboot->fixfiles relabel->reboot
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: selinux-policy (Show other bugs)
6
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Walsh
Ben Levenson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-01-15 11:45 EST by Gwyn Ciesla
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-01-15 13:57:02 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
/var/log/audit/audit.log (1.21 MB, application/octet-stream)
2007-01-15 12:35 EST, Gwyn Ciesla
no flags Details
/var/log/messages (117.37 KB, application/octet-stream)
2007-01-15 12:35 EST, Gwyn Ciesla
no flags Details

  None (edit)
Description Gwyn Ciesla 2007-01-15 11:45:57 EST
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)
Comment 1 Daniel Walsh 2007-01-15 12:05:39 EST
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.
Comment 2 Gwyn Ciesla 2007-01-15 12:15:37 EST
Which log files would be most helpful?  /var/log/messages?
Comment 3 Daniel Walsh 2007-01-15 12:22:55 EST
/var/log/audit/audit.log and/or /var/log/messages
Comment 4 Gwyn Ciesla 2007-01-15 12:35:15 EST
Created attachment 145592 [details]
/var/log/audit/audit.log
Comment 5 Gwyn Ciesla 2007-01-15 12:35:50 EST
Created attachment 145593 [details]
/var/log/messages
Comment 6 Daniel Walsh 2007-01-15 12:44:07 EST
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.
Comment 7 Gwyn Ciesla 2007-01-15 12:52:55 EST
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.
Comment 8 Daniel Walsh 2007-01-15 13:57:02 EST
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.
Comment 9 Gwyn Ciesla 2007-01-15 14:00:42 EST
Even though this disk/partition has been in place since install time, in March
of 2005?
Comment 10 Daniel Walsh 2007-01-15 14:33:23 EST
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.

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