[F8] [SOLVED] rhgb problems @ boot time
Daniel B. Thurman
dant at cdkkt.com
Sun Dec 23 23:20:07 UTC 2007
Tod Merley wrote:
>On Dec 22, 2007 3:35 PM, Daniel B. Thurman <dant at cdkkt.com> 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:
>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.
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
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
More information about the users