> I got a selinux update this morning and when I rebooted my computer >it took an HOUR! The SELinux that everone says is not the cause of the >problem are full of it. The darn thing goes bonkers. I am going to turn >it off and it will stay that way forever. I do not need this crap! I got an selinux update today, too, on two different F7 machines. One is running in enforcing mode, too. The other is running in permissive. Both have run this way since installation. Bootup took the normal time on both machines. SELinux not a problem here. What's different about your machine, Karl? I don't see everyone who downloaded that update clamoring about hour-long bootups, do you? Do you think it might actually be working for everybody else? Like I said, what's different about your machine? /usr/sbin/sestatus on my home desktop box reports: [lowen@localhost ~]$ /usr/sbin/sestatus SELinux status: enabled SELinuxfs mount: /selinux Current mode: enforcing Mode from config file: enforcing Policy version: 21 Policy from config file: targeted [lowen@localhost ~]$ This home box hasn't yet had an SELinux problem, and was installed quite some time ago (in F7-time, at least!); /root/install.log carries a timestamp of 2007-06-09 Karl, how many other packages were updated today in addition to selinux-policy (note that SELinux itself, the core library part, known as libselinux, hasn't seen an update, at least on my box, since October 4; my kernel isn't the stock F7 kernel (PlanetCCRMA's kernel with the low-latency patches runs here) so my last date of update there wouldn't help any)? You can find the answer in /var/log/yum.log* How do you know it wasn't the bind updates? Or util-linux (which touches far more things than selinux does)? What was the machine doing during this hour? Would you mind posting /var/log/messages so the cause could be seen? Now, I'm not saying that it wasn't the selinux policy update that caused your problem today; but I'm also not going to jump to conclusions that it WAS the selinux policy update (again, selinux itself was not updated today, unless you got a kernel update). Karl, being a ham and a consulting broadcast engineer, I know better than jumping to conclusions; you should know better, too. If this were a radio transmitter, and the symptom was that it wouldn't make power when you change the output tube, are you going to automatically blame the tube? Could there be other issues instead that are not obvious, but that changing the tube tickles? Of course, it _could_ be a bad tube; but it also could be a marginal filament supply, bad neutralizing network in the case of a triode, weak plate supply that folds over with a good tube, etc, right? But just because it broke when you changed the tube is insufficient data to blame the tube; you have to take the time to understand the circuit and try to determine what really happened. The linux boot process isn't a simple one, and lots of things can happen that are totally unrelated to what changed; you have to try to understand the full process. You don't seem to be taking the time to do that, Karl; try treating it like a radio problem (or is this how you treat radio problems? jumping to conclusions without hard evidence?). -- Lamar Owen, KF4MYT Chief Information Officer Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 828-862-5554 www.pari.edu -- fedora-list mailing list fedora-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
