RE: [F8] [SOLVED] rhgb problems @ boot time

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

 



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
 

-- 
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [Fedora Magazine]     [Fedora News]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [SSH]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux