Clean test3 install on ppc64. dbus-daemon, gpm etc report failing to load libraries. type=AVC msg=audit(1140530882.083:39): avc: denied { search } for pid=2358 comm="gpm" name="lib64" dev=sda5 ino=979201 scontext=system_u:system_r:gpm_t:s0 tcontext=system_u:object_r:file_t:s0 tclass=dir type=SYSCALL msg=audit(1140530882.083:39): arch=80000015 syscall=5 success=yes exit=-13 a0=400000448a1 a1=0 a2=4000003a710 a3=8 items=1 pid=2358 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="gpm" exe="/usr/sbin/gpm" type=CWD msg=audit(1140530882.083:39): cwd="/" type=PATH msg=audit(1140530882.083:39): item=0 name="/lib64/libm.so.6" flags=101
This is a labeling problem. Some how you have gotten files on your system labeled as file_t? This means you either ran with selinux=0 or you added a new disk which is not labeled. YOu can try restorecon -R -v /lib64 Or relabel the entire system touch /.autorelabel reboot
It was a clean install. This is reproduceable.
Did you create /lib64 as a separate partition? Dan
No. All one partition.
rpm -qf /lib64 file /lib64 is not owned by any package I bet this is as /lib64 is created as a side effect of the first file in there. We're not seeing on x86_64 as we probably have filesystem.x86_64 whereas on ppc we have filesystem.ppc
Still happening in today's rawhide
Weren't we going to make filesystem biarch to fix this? Else anaconda can restorecon on /lib and /lib64
This one really needs to be fixed before FC5 final. The machine is fairly hosed with selinux enabled.
Bill, Jeremy views - pull in filesystem.ppc64 also on ppc distill or I can add it do the list we restorecon in anaconda...
Is it just /lib64 or is */lib64?
The restorecon is more portable (doesn't require distill hacks). Of course, it's a hack itself.
Okay, added the bad hack to anaconda to restorecon on /lib64 and /usr/lib64. Should be in rawhide tomorrow. Paul -- can we make sure to check it on the g5 tomorrow.
Why can't filesystem.ppc include /lib64 as well (similarly to how filesystem.ppc64 includes /lib)?
A pure 32-bit build shouldn't really create a /lib64 directory. The problem here seems to be that /lib64 wasn't _explicitly_ created by any RPM; it was automatically created by RPM. Why does this mean that it doesn't get labelled? Should RPM handle automatic creation of directories differently?
rawhide-20060307 still fails -- /lib64 still isn't searchable. In fact, today's rawhide seems to be a fairly significant regression in a bunch of ways. DHCP no longer works -- I can see the DHCP response on the wire (from another machine) but anaconda just goes straight back to the dialog bog asking me for IP details, instead of giving any error message or (preferably) continuing. If I set an IP address manually, the install works but then the system is unbootable. It seems that it's caused by mount-by-label -- if I boot into rescue mode and change to 'root=/dev/sda5' when it works. Otherwise I just get 'Error mounting /dev/root on /sysroot as ext3: No such file or directory'. Having fixed that up, firstboot doesn't seem to run.
Should be fixed now.