LTC Owner is: ankigarg.com LTC Originator is: ankigarg.com Problem description: If this is not an installation problem, No. Provide output from "uname -a", if possible: Linux llm49.in.ibm.com 2.6.20-0119.rt8 #1 SMP PREEMPT Thu Feb 15 15:53:15 CET 2007 x86_64 x86_64 x86_64 GNU/Linux Hardware Environment Machine type (p650, x235, SF2, etc.): LS20 Cpu type (Power4, Power5, IA-64, etc.): Dual Core AMD Opteron Is this reproducible? Setting SELINUX=enforcing and SELINUXTYPE=strict in /etc/selinux/config results in the panic on next boot. Creating an attachment (LTC id 27692) selinux panic boot log - Ankita ------------------------------------------------------- Is this related to CONFIG_CPUSETS? Do we need CONFIG_CPUSETS enabled in RHEL5-RT? - Sripathi
Created attachment 154316 [details] selinux panic boot log (LTC id 27692)
----- Additional Comments From ankigarg.com (prefers email at ankita.com) 2007-05-10 08:04 EDT ------- Found that the selinux-policy-strict is required when SELINUX=strict. This package is not installed on RHEL by default. When I tried with system-config-selinux, 'strict' option was not even present. The selinux-policy-targeted is very much installed. So, I believe I hit this issue because the strict policy is not being recognized by the system. I tried to find the mentioned rpm package for RHEL, but could not. It is not present in ftp3 also. Once I have the package, I can confirm whether I still hit the same issue with it.
----- Additional Comments From ankigarg.com (prefers email at ankita.com) 2007-05-14 07:19 EDT ------- I installed selinux-policy-strict package and got the following: audit(1179160367.947:2): enforcing=1 old_enforcing=0 auid=4294967295 security: class dccp_socket not defined in policy security: permission dccp_recv in class node not defined in policy security: permission dccp_send in class node not defined in policy security: permission dccp_recv in class netif not defined in policy security: permission dccp_send in class netif not defined in policy audit(1179160368.447:3): policy loaded auid=4294967295 audit(1179160368.447:4): avc: denied { execute } for pid=1 comm="init" name="libsepol.so.1" dev=sda1 ino=130888 scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:lib_t:s0 tclass=file Kernel panic - not syncing: Attempted to kill init! Call Trace: [<ffffffff8106d5a4>] dump_trace+0xaa/0x32a [<ffffffff8106d865>] show_trace+0x41/0x5c [<ffffffff8106d895>] dump_stack+0x15/0x17 [<ffffffff81091c8d>] panic+0xaf/0x169 [<ffffffff8101558e>] do_exit+0xb4/0x894 [<ffffffff8104a857>] cpuset_exit+0x0/0x6e [<ffffffff8104e3f4>] sys_exit_group+0x12/0x14 [<ffffffff8105f11e>] system_call+0x7e/0x83 [<0000003f85e13aa8>] So, looks like this could be related to CPUSETS !!
----- Additional Comments From ankigarg.com (prefers email at ankita.com) 2007-05-14 07:23 EDT ------- CONFIG_CPUSETS is enabled on RHEL5rt
----- Additional Comments From ankigarg.com (prefers email at ankita.com) 2007-05-14 08:38 EDT ------- Taking help from Srinivasa, who has worked in selinux related stuff!
Did you relabel the system in permissive mode? When you change from targeted to strict policy, you need to relabel in permissive mode the first time.
----- Additional Comments From ankigarg.com (prefers email at ankita.com) 2007-05-18 01:38 EDT ------- As suggested, I first booted into permissive mode and created a .autorelabel file in root filesystem to enable relabeling on the next reboot. On successive reboot into strict type, the kernel booted fine with no panic. So, the issue was with no relabeling of the filesystem.
changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |REJECTED Resolution| |NOTABUG ------- Additional Comments From ankigarg.com (prefers email at ankita.com) 2007-05-18 01:39 EDT ------- Rejecting this as NOT_A_BUG.
Based on above comment, changing status on the RH bugzilla side to closed/notabug.
changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REJECTED |CLOSED ------- Additional Comments From sripathi.com (prefers email at sripathik.com) 2007-05-23 08:20 EDT ------- Moving to CLOSED.