Re: install problem with fc devel as of dec 10

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Dec 13, 2005 at 11:13:53AM -0500, Jeremy Katz wrote:
> On Mon, 2005-12-12 at 21:33 -0500, G.Wolfe Woodbury wrote:
> > On Mon, Dec 12, 2005 at 05:59:17PM -0800, Patrick Mansfield wrote:
> > .....
> >  
> > > The main thing I notice is this dmesg output:
> > > 
> > > audit(1134461372.947:68): avc:  denied  { execmem } for  pid=9577 comm="grub" scontext=system_u:system_r:anaconda_t:s0 tcontext=system_u:system_r:anaconda_t:s0 tclass=process
> > > 
> > > I would think something would have been output to the gui or serial line
> > > if grub failed to run/install.
> 
> Remember, anaconda runs in permissive mode.  So any "denials" are just
> "this would have been denied", not "this was denied".  Mostly because
> we're in a very strange environment and things would blow up horribly
> otherwise ;)   But we have to have policy somewhat loaded as otherwise,
> the file contexts aren't known to the kernel for setting the xattrs.
> 
> > No, selinux is interfering with the reboot because no contexts have been
> > yet set for the system(?)
> 
> selinux=0 is needed because the policy package didn't have correct
> requirements on things it ran in its scripts.  I've hopefully got that
> fixed up today, but Chris saw something else weird when he tried an
> install a little bit ago.  So we'll be taking a look at that.

I haven't been able to tell if selinux=0 worked or not on that x86
netfinity box (have to check on the console of that machine when/if I go
into the office+lab today).

In the meantime, I tried a ppc install to a system (blade, JS20) where I
can actually do a network install and more easily use a serial line
(though the serial over LAN on it is often painful).

Same there, it did not reboot (more precisley, it did not shutdown).

Seems that a parent anaconda process never goes away, maybe it is held in
place by the forked process that opens the shell?

Looks like anconda should use "!child" so the parent process is the main
process, though I don't understand how anaconda initiates shutdown.

I don't know why others (on this thread) didn't hit this problem.

That is (untested):

diff -uprN -X /home/patman/dontdiff anaconda-10.90.16/anaconda child-anaconda-10.90.16/anaconda
--- anaconda-10.90.16/anaconda	2005-12-08 19:11:38.000000000 -0800
+++ child-anaconda-10.90.16/anaconda	2005-12-13 10:18:05.000000000 -0800
@@ -977,7 +977,7 @@ if display_mode == 'g' and flags.usevnc:
 		   vncconnecthost=vncconnecthost,
 		   vncconnectport=vncconnectport)
     child = os.fork()
-    if (child):
+    if (!child):
 	while 1:
 	    print _("Press <enter> for a shell")
 	    sys.stdin.readline()

After killing the one remaining anaconda process, the shutdown proceeded
as expected, and first boot worked fine, without selinux=0.

I am fairly impressed, everything seems ok on this JS20:

Fedora Core release 4 (Rawhide)
Kernel 2.6.14-1.1756_FC5 on an ppc64

elm3a229 login: root
Password:
[root@elm3a229 ~]# uname -a
Linux elm3a229 2.6.14-1.1756_FC5 #1 SMP Mon Dec 12 14:43:09 EST 2005 ppc64
ppc64 ppc64 GNU/Linux

Guess I'll try some iscsi stuff on it instead, rather than using the old
netfinity box.

-- Patrick Mansfield

-- 
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux