[clue-tech] Possible troubles with SELinux built into rescue kernel
?
mike havlicek
mhavlicek1 at yahoo.com
Tue Nov 18 10:16:44 MST 2008
Hello all,
Problem:
I have a RHEL AS installation where I mirrored the boot and root partitions accross two disks. I want to replace one of the disks, but have been having problems using the tools I want to use in rescue mode boots from 2 different installation CDs. I admit several deficiencies: 1) Lack of SELinux knowledge 2) Lack of mdadm savvy 3) I have not tried the exact CD #1 that was used in the initial build... (I suspect correcting #3 would lead to the same dilemma expressed herein... besides up2date has been run)
Pre-rescue:
Dumps of the system's mount points were made to an NFS mounted volume.
Rescue boot scenarios:
1) booting from CD #1 from RHEL4-U3 i386 circa 07/06 (boot: linux rescue)
enabling network and NOT enabling the search for installations...
2) booting from CD #1 from CentOS 5.0 i386 circa 08/07 (boot: linux rescue)
enabling network and NOT enabling the search for installations...
Symptoms:
In rescue boot scenario 1, I get segmentation faults with some of the network related tools ultimately leading to kernel panics. E.G. running nslookup results in a segmentation fault, and NFS mounting (via specification of the server IP) the volume which contains the above mentioned dumps ultimately results in kernel panic...
Scenario 2 led to restore failure from /etc/mdadm.conf in a dump file ( I am able to extract that file from the same dump file with an NFS mount to a third "healthy" Linux system ). The failure occurs with SELinux error messages... unfortunately I get:
# restore -xv -f file.dmp mdadm.conf
(SNIP)
restore:.:EA set security.selinux:system_u:object_r:root_t failed: Operation not supported
#
I can tell you that the mdadm.conf file extracts from a non-rescue boot environment with SELinux disabled. From my analysis thus far I am tending to believe that SELinux enabled in the distro based rescue boot mode that I have tried could be the source of some of the nuisances that I have encountered, and would not be surprised to see more gotchas with the actual mdadm procedures.
System Info: (This is the system in the operating room:)
$ cat /etc/redhat-release
Red Hat Enterprise Linux AS release 4 (Nahant Update 6)
---------------------------------------------------------------------
$ df -k
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
547409 161356 357794 32% /
/dev/md1 124323 27084 90820 23% /boot
none 258100 0 258100 0% /dev/shm
/dev/mapper/VolGroup01-LogVol00
20642428 9623252 9970600 50% /home
/dev/mapper/VolGroup01-LogVol01
20642428 11220032 8373820 58% /usr
/dev/mapper/VolGroup00-LogVol01
1773912 1011180 672620 61% /var
ike:/export/archive 41300992 23213664 17880832 57% /archive
---------------------------------------------------------------------
So, /boot is part of raid1 as is /dev/mapper/VolGroup00-LogVol00 (/dev/md0). The disks are /dev/hda and /dev/hdb. I intend to replace /dev/hdb. As will be shown below, I overlooked potential future problems when initially creating the mirrors by not exactly matching the partition tables for the mirror components. Getting ahead of myself, the replacement disk for hdb has now been partitioned with units matching hda where I think they need to ...
This is output from "fdisk -l" representing the original disk layout:
Disk /dev/hda: 120.0 GB, 120034123776 bytes
255 heads, 63 sectors/track, 14593 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/hda1 * 1 16 128488+ fd Linux raid autodetect
/dev/hda2 17 311 2369587+ fd Linux raid autodetect
/dev/hda3 312 376 522112+ 82 Linux swap
/dev/hda4 377 14593 114198052+ 8e Linux LVM
Disk /dev/hdb: 2559 MB, 2559836160 bytes
128 heads, 63 sectors/track, 620 cylinders
Units = cylinders of 8064 * 512 = 4128768 bytes
Device Boot Start End Blocks Id System
/dev/hdb1 * 1 32 128992+ fd Linux raid autodetect
/dev/hdb2 33 620 2370816 fd Linux raid autodetect
---------------------------------------------------------------------
Replacement:
Disk /dev/hdb: 13.7 GB, 13701316608 bytes
255 heads, 63 sectors/track, 1665 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/hdb1 * 1 16 128488+ fd Linux raid autodetect
/dev/hdb2 17 311 2369587+ fd Linux raid autodetect
---------------------------------------------------------------------
While running pre mirror restructure, /proc/mdstat and mdadm report:
$ cat /proc/mdstat
Personalities : [raid1]
md1 : active raid1 hdb1[1] hda1[0]
128384 blocks [2/2] [UU]
md0 : active raid1 hdb2[1] hda2[0]
2369472 blocks [2/2] [UU]
unused devices: <none>
$ sudo /sbin/mdadm --detail /dev/md0
/dev/md0:
Version : 00.90.01
Creation Time : Wed Mar 9 14:40:17 2005
Raid Level : raid1
Array Size : 2369472 (2.26 GiB 2.43 GB)
Device Size : 2369472 (2.26 GiB 2.43 GB)
Raid Devices : 2
Total Devices : 2
Preferred Minor : 0
Persistence : Superblock is persistent
Update Time : Tue Nov 18 08:31:59 2008
State : active
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0
UUID : ecc4fb96:7a48327b:e5ca87f0:126e2a29
Events : 0.15919474
Number Major Minor RaidDevice State
0 3 2 0 active sync /dev/hda2
1 3 66 1 active sync /dev/hdb2
$ sudo /sbin/mdadm --detail /dev/md1
/dev/md1:
Version : 00.90.01
Creation Time : Wed Mar 9 14:40:34 2005
Raid Level : raid1
Array Size : 128384 (125.40 MiB 131.47 MB)
Device Size : 128384 (125.40 MiB 131.47 MB)
Raid Devices : 2
Total Devices : 2
Preferred Minor : 1
Persistence : Superblock is persistent
Update Time : Sat Nov 15 19:15:38 2008
State : clean
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0
UUID : 1c9f148c:413770b5:eafd4ff9:4c3d525b
Events : 0.4957
Number Major Minor RaidDevice State
0 3 1 0 active sync /dev/hda1
1 3 65 1 active sync /dev/hdb1
---------------------------------------------------------------------
I think I have the information needed to reconstruct the mirror using the replacement drive but this is where my lack of mdadm savvy comes into play.
My gut tells me that having /etc/mdadm.conf handy in rescue mode might make things easier. My thinking is that it would be nice to have been able to have put it in place in rescue mode from an NFS mounted dump file...
Here is the content of mdadm.conf from the normally running system that is going to the operating room:
$ cat /etc/mdadm.conf
# mdadm.conf written out by anaconda
DEVICE partitions
MAILADDR root
ARRAY /dev/md0 super-minor=0
ARRAY /dev/md1 super-minor=1
I think I am getting close to collecting the pieces of the puzzle, but...
back to my suspicion with regard to how SELinux is implemented in the kernel I get to work with from the rescue mode boots ... I haven't figured out how to put SELinux in disabled mode. I should think that the fact that it is in permissive mode should mean that at most it should just bark at any attempted operations it objects to ... but ... I don't get the file I want from the restore in rescue mode.
The Read-only filesystem in rescue mode contains /etc/selinux/config with
SELINUX=permissive
SELINUXTYPE=targeted
I suppose one might be able to rig a reread of the configuration in files created elsewhere, but that type of approach seems to make the procedure a little complex.
I would like to simply turn off SELinux in the rescue mode to rule it out as a problem. On that thought I found:
boot: linux rescue selinux=0
doesn't seem to help...
Any insight would be greatly appreciated.
Thanks,
-Mike
More information about the clue-tech
mailing list