Re: FC 8 re-install

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

 



Terry - Fedora Core wrote:
Finally gave up on my first install of FC 8 and did a second install. Since This was the second time around, I knew what to look for and wasn't as nervous and checked out ALL of the options. Found out that I pretty much did everything right the first time around. The only thing I did differently this time was to customize the packages installed. This allowed me to install KDE right up front instead of having to do so afterwards. Also got to check out other packages for initial installation. That was the only thing that I did diferently. As I said, Ihad done everything right the first time around.

This reminded me of FC 5 - I had to install FC 5 3 or 4 times to get a good installation or at least a workable installation. On FC 5 I ended up doing 95% of new program installs and upgrades from source because the rpm program continually corrupted its own database.

What I did like about the FC installation process - I CAN install everything right at the beginning instead of having to do so piece by piece as I discover I need it and then need to spend hours searching through documentation trying to find out which package is needed and where to get it. Getting everything right up front is a lot better and considerably less frustrating.

What I didn't like about the installation process - after I marked everything I wanted for installation, a window opens and says that the installation is starting and that this could "take a few minutes". The few minutes turned into 35 minutes using a high speed DSL network connection at over 3 mb/sec. Now I'm not complaining about the 35 minutes, what really bothered me was wondering for 35 minutes if the process had hung. A little visual feedback at that point would really, really be appreciated. If the initialization process takes only "a few minutes" then the feedback wouldn't be there long, but 35 minutes is a long time to be left hanging and wondering and wondering and wondering .........

After the reboot, a notification came up and said that xxx security updates needed to be done. I decided not to do that immediately. I first used the "add/remove software" program (pirut??) to download and install "apcupsd". Then remembered gnucash, Booted the program again and tried to install gnucash. Everything worked fine until it came time to download the packages. The downloading process hung. After 20 minutes, I tried to close the window and was informed that the process was not responding and so I "terminated" the process. Tried again and after a some time a window opened and informed me that the process had encountered a fatal error. I clicked on the "save" button to save the information to a file to send to bugzilla, but could never find the file to send. Don't think a file was ever created with the information to send.

Then tried to apply the security updates. Same thing happened. So the updating and add/remove program is hanging and never completing.

This is probably "pirut" for both???

I tried to log out. KDE would not do so. Bring up the log out dialog, click on "logout" and nothing happens. Everything is still running. I can change desktops and activate programs, just could not logout. Tried multiple times - same result.

Finally had to hit the hardware reset button.

KDE logout worked after the h/w reboot, but the program to update things still hangs.

Is there anyway to get program update and add/remove s/w to complete??

Should I re-install pirut??

If so how do I go about doing that. I can use the command line and have done so for over 20 years, but am not an expert on programs that I only need every 5 or 10 years.

Ok - I don't know exactly what is happening, but there are a few details I totally forgot about above dealing with SELinux. I forgot simply because the error messages said to notify my System Administrator and since I am that person and since I was/am totally ignorant about what the error messages were talking about, I disregarded - probably should not have, but I didn't have the time to spend hours learning at the time. So I totally forgot about the messages.

The error messages were something about gdm and requested services denied. After that I could no longer access any hard drives.

Also, I when I was able to log out, I got a black screen and a window popped up that the X Window system could not access something or other and that 'gd' (there's that gdm again) was involved. Had to do a three-fingered salute to re-boot the machine.

Had an idea as I was going to sleep last night and remembered it this morning. Booted Fedora and looked for SELinux. Found it. First opened the troubleshooting window. There are 4 trouble reports there. I have copied the reports below for anybody that knows enough to decipher them.

I then opened the SELinux manager. Tried to disable SELinux and got a dire warning about having to reboot and if I wanted to turn it back on I would have to relabel hard disks and that I should change to "permissive mode" instead. That stopped me and I canceled the action and switched to "permissive mode".

then executed:

su -c 'yum update'

on the command line. That command had quit with the journal io error before.

With SELinux set to permissive mode, the yum update went to completion. Informed me that 453 packages needed to be updated and 20 installed with a total download of 870 M. Answered 'y' and download commenced.

The first download had caused the previous journal io error after 25% of the first package had downloaded. So I waited with baited breath until the download got to 40% then 50% and then was confident that the update would go to completion.

The download completed, then the testing and then the actual update:

894 packages/files updated.

It took as long to update as it did to download.

All in all the whole process took about 4 to 5 hours. I totally refuse to think how long the download would have taken on my old dial-up line. Of course, the update process would still have taken the same time.

So here are the SELinux error reports:

Summary SELinux is preventing gdm (xdm_t) "execute" to <Unknown> (rpm_exec_t). Detailed Description SELinux denied access requested by gdm. It is not expected that this access is required by gdm and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. Allowing Access Sometimes labeling problems can cause SELinux denials. You could try to restore the default system file context for <Unknown>, restorecon -v <Unknown> If this does not work, there is currently no automatic way to allow this access. Instead, you can generate a local policy module to allow this access - see http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385 Or you can disable SELinux protection altogether. Disabling SELinux protection is not recommended. Please file a http://bugzilla.redhat.com/bugzilla/enter_bug.cgi against this package. Additional Information Source Context Target Context Target Objects Affected RPM Packages Policy RPM Selinux Enabled Policy Type MLS Enabled Enforcing Mode Plugin Name Host Name Platform Alert Count First Seen Last Seen Local ID Line Numbers Raw Audit Messages avc: denied { execute } for comm=gdm dev=sda7 name=rpm pid=3107 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tclass=file tcontext=system_u:object_r:rpm_exec_t:s0 system_u:system_r:xdm_t:s0-s0:c0.c1023 system_u:object_r:rpm_exec_t:s0 None [ file ] selinux-policy-3.0.8-44.fc8 True targeted True Enforcing plugins.catchall_file Home-Net Linux Home-Net 2.6.23.1-42.fc8 #1 SMP Tue Oct 30 13:55:12 EDT 2007 i686 i686 7 Wed 06 Feb 2008 01:50:35 PM EST Thu 07 Feb 2008 10:26:00 AM EST 41e3c4c1-b5da-4c6a-8917-01b4013c448f

Summary SELinux is preventing gdm (xdm_t) "getattr" to /bin/rpm (rpm_exec_t). Detailed Description SELinux denied access requested by gdm. It is not expected that this access is required by gdm and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. Allowing Access Sometimes labeling problems can cause SELinux denials. You could try to restore the default system file context for /bin/rpm, restorecon -v /bin/rpm If this does not work, there is currently no automatic way to allow this access. Instead, you can generate a local policy module to allow this access - see http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385 Or you can disable SELinux protection altogether. Disabling SELinux protection is not recommended. Please file a http://bugzilla.redhat.com/bugzilla/enter_bug.cgi against this package. Additional Information Source Context Target Context Target Objects Affected RPM Packages Policy RPM Selinux Enabled Policy Type MLS Enabled Enforcing Mode Plugin Name Host Name Platform Alert Count First Seen Last Seen Local ID Line Numbers Raw Audit Messages avc: denied { getattr } for comm=gdm dev=sda7 egid=0 euid=0 exe=/bin/bash exit=-13 fsgid=0 fsuid=0 gid=0 items=0 path=/bin/rpm pid=3107 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 sgid=0 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 suid=0 tclass=file tcontext=system_u:object_r:rpm_exec_t:s0 tty=(none) uid=0 system_u:system_r:xdm_t:s0-s0:c0.c1023 system_u:object_r:rpm_exec_t:s0 /bin/rpm [ file ] rpm-4.4.2.2-3.fc8 [target] selinux-policy-3.0.8-44.fc8 True targeted True Enforcing plugins.catchall_file Home-Net Linux Home-Net 2.6.23.1-42.fc8 #1 SMP Tue Oct 30 13:55:12 EDT 2007 i686 i686 13 Wed 06 Feb 2008 01:50:35 PM EST Thu 07 Feb 2008 10:26:00 AM EST 845ddb2e-69a4-6f67-5508-83456c0bff19

Summary SELinux is preventing sh (loadkeys_t) "search" to <Unknown> (home_root_t). Detailed Description SELinux denied access requested by sh. It is not expected that this access is required by sh and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. Allowing Access Sometimes labeling problems can cause SELinux denials. You could try to restore the default system file context for <Unknown>, restorecon -v <Unknown> If this does not work, there is currently no automatic way to allow this access. Instead, you can generate a local policy module to allow this access - see http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385 Or you can disable SELinux protection altogether. Disabling SELinux protection is not recommended. Please file a http://bugzilla.redhat.com/bugzilla/enter_bug.cgi against this package. Additional Information Source Context Target Context Target Objects Affected RPM Packages Policy RPM Selinux Enabled Policy Type MLS Enabled Enforcing Mode Plugin Name Host Name Platform Alert Count First Seen Last Seen Local ID Line Numbers Raw Audit Messages avc: denied { search } for comm=sh dev=sda7 egid=0 euid=0 exe=/bin/bash exit=-13 fsgid=0 fsuid=0 gid=0 items=0 name=home pid=4986 scontext=system_u:system_r:loadkeys_t:s0 sgid=0 subj=system_u:system_r:loadkeys_t:s0 suid=0 tclass=dir tcontext=system_u:object_r:home_root_t:s0 tty=(none) uid=0 system_u:system_r:loadkeys_t:s0 system_u:object_r:home_root_t:s0 None [ dir ] selinux-policy-3.0.8-44.fc8 True targeted True Enforcing plugins.catchall_file Home-Net Linux Home-Net 2.6.23.1-42.fc8 #1 SMP Tue Oct 30 13:55:12 EDT 2007 i686 i686 2 Wed 06 Feb 2008 04:52:48 PM EST Wed 06 Feb 2008 04:52:48 PM EST 54a23c38-b925-4467-aa0e-5d3fdcc5d799

Summary SELinux is preventing sh (loadkeys_t) "search" to <Unknown> (unconfined_home_dir_t). Detailed Description SELinux denied access requested by sh. It is not expected that this access is required by sh and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. Allowing Access Sometimes labeling problems can cause SELinux denials. You could try to restore the default system file context for <Unknown>, restorecon -v <Unknown> If this does not work, there is currently no automatic way to allow this access. Instead, you can generate a local policy module to allow this access - see http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385 Or you can disable SELinux protection altogether. Disabling SELinux protection is not recommended. Please file a http://bugzilla.redhat.com/bugzilla/enter_bug.cgi against this package. Additional Information Source Context Target Context Target Objects Affected RPM Packages Policy RPM Selinux Enabled Policy Type MLS Enabled Enforcing Mode Plugin Name Host Name Platform Alert Count First Seen Last Seen Local ID Line Numbers Raw Audit Messages avc: denied { search } for comm=sh dev=sda7 name=terry pid=4986 scontext=system_u:system_r:loadkeys_t:s0 tclass=dir tcontext=unconfined_u:object_r:unconfined_home_dir_t:s0 system_u:system_r:loadkeys_t:s0 unconfined_u:object_r:unconfined_home_dir_t:s0 None [ dir ] selinux-policy-3.0.8-44.fc8 True targeted True Enforcing plugins.catchall_file Home-Net Linux Home-Net 2.6.23.1-42.fc8 #1 SMP Tue Oct 30 13:55:12 EDT 2007 i686 i686 22 Wed 06 Feb 2008 04:52:48 PM EST Wed 06 Feb 2008 04:52:48 PM EST 04bec695-038f-408d-bf7a-fa3c5f6e2812


They mean little to nothing to me. Maybe they will prove worthwhile to somebody that knows about SELinux.

I just find it more than strange that the default SELinux settings would caused such trouble and lock me out of using the computer. I just hope that the above error reports can prevent the same from happening to somebody else in the future.

Terry


[Index of Archives]     [Current Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux