Tod Merley wrote: >On Dec 22, 2007 3:35 PM, Daniel B. Thurman <dant@xxxxxxxxx> wrote: >> For some reason log after post install of Fedora 8, the >services-loading gui screen stopped >> working. What you get just after a udev is a X11-busy-watch > flash(instead of a gnome cursor >> with a blue spinner), then it continues back in text-mode >remounting / as rw, mounting >> the local filesystems, enabling quota, and enabling the swap >partition. At that point, after >> several minutes go by, the gnome login screen appears. It >all works fine, except for the >> missing services-loading screen. >> >> At this point, I am unable to fix the services loading >screen and it appears that this screen >> attempts to get started by rhgb? I peered into the >/etc/rhgb/temp directory and found >> the xorg.log file there. The contents of this file is dumped below. >> >> Please note the first 3 lines at the top. Seems that there >is a problem there >> somehow. I think there might be a minor problem with ACPI; >selinux is avc denied >> access to the ACPI socket. Finally, the very end of this >log show a failure to find >> a 'fixed' font and the X/rhgb crashes? >> >> File: /etc/rhgb/temp/xorg.log > >Hi Daniel B. Thurman, > >Your answer may be somewhere here: > >/usr/share/doc/rhgb-0.17.6/HOW_IT_WORKS > >I think I would: > >1. Google the first lines of the xorg.log file. Take sections of the >lines which look to be likely common in all cases and add say "xorg" >or "X" or "X11". You might do well to do a "relabel on next reboot" >from System > Administration > SELinux Management. > >2. I note that there are many, many "not using" lines in the file >which speak of screen resolutions and other things. My thinking here >is that I cannot find the dpi:unscaled files ether (I am using FC7 >and that may well be why) but perhaps it would not need such a file if >another resolution was in use. You might consider making a simple >xorg.conf file and placing it at /etc/rhgb as proscribed below (from >above mentioned doc): >------------------------------------------------- >If a specific /etc/rhgb/xorg.conf configuration file for X under rhgb >is provided then it will be passed to the X command line to allow >a specific configuration for X boot. >------------------------------------------------- > >Good Hunting! Thanks for the tips! It helped me to focus better! FYI: I have run out of space for the root partition, and I have moved the /usr/share directory into a new partition and wanted to mount the share partition onto /usr/share. What I discovered was that rhgb was failing @ boot time because just after the udev step, only the read-only root partition was mounted which means my /usr/share directory was unmounted and empty. This caused rhgb to become crippled. It would be neat if I could change the /etc/rc.sysinit so that I could force a mount of the share partition to /usr/share on the read-only root(/) filesystem, but I don't think that is possible or is it? Interestingly, rhgb's /etc/rhgb/temp/xorg.log reports that it was unable to connect to acpi sockets on a read-only root filesystem, which is odd but harmless or so it seems. So armed with the above information, I had proceeded to boot my system into single user mode. Once in single user mode, I had unmounted my /usr/share directory so that the /usr/share directory is empty. I then remounted the share drive to /mnt so that once mounted, I can tar copy the minimum needed directories and files out of the /mnt/share directory into the empty /usr/share directory required for rhgb to function. I had copied over the following directories: fonts, gdm, icons, locale, rhgb, X11, xdb, xorg There are probably some other directories needed (the font and the general look of the progress bar/gui is different, but it is agreeable for now), and when I rebooted, rhgb now works! Of course, updates could become a problem. The bottom line is, I think, that rhgb ought to have its dependencies placed strategically into the root partition somewhere "permenant", probably not in /usr/share so that it is possible to allow /usr/share to be moved into another partition without consequences? I can easily see that /usr/share and /var can get full pretty quickly and that can become an administrative issue if these directories cannot be easily managed. Of course, none of this is a problem if you have a big enough drive but expect major parts of the root filesystem to become more monolithic; just don't plan to move /usr or it's subdirectories nor /var into seperate partitions without consequences, or so it seems. No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.516 / Virus Database: 269.17.6/1193 - Release Date: 12/22/2007 2:02 PM
