On Fri, Oct 31, 2003 at 01:17:01PM +0100, Igor Nestoroviæ wrote:
> What about Bugzilla 90036?
> Will that be solved at all? I think that too is a glibc glitch.
should fix it too, ie.:
54697 83973 85994 86032 88409 88456 88978 89448 90002
90036 90077 90301 90987 91567 97814 97828 98966 101261
101691 102709 103727 105348 107846
Date: Fri, 31 Oct 2003 06:58:21 -0500 (EST)
From: "Robert P. J. Day" <rpjday(a)mindspring.com>
To: Fedora Test List <fedora-test-list(a)redhat.com>
Subject: so ... how do i get a graphical boot?
i realize that the graphical boot has been discussed on numerous
occasions, but frankly, i've never seen one on my system (currently
running FC3). how do i get one? (at the moment, i see the standard
line-oriented boot i've seen for years).
i've verified that /etc/sysconfig/init contains
i've perused /etc/rc.sysinit and the conditions look like they'd be
satisfied. /usr/bin/rhgb is there. the file /proc/cmdline does not
contain the string "nogui". so what am i missing?
i figured it would be nice to see this graphical boot thingie at
In grub.conf look for the line;
kernel /vmlinuz-2.4.22-1.2115.nptl ro root=LABEL=/ hdd=ide-scsi
all you have to do is add rhgb to the end of the line and the graphical
boot should come up. You might have a different kernel installed but it
should look the same.
Peter Boy wrote:
> Am Do, den 30.10.2003 schrieb Andreas Sartori um 14:59:
>> i have this in my grub.conf but it is not working..
>> title Fedora Core (2.4.22-1.2111.nptl)
>> root (hd0,0)
>> kernel /vmlinuz-2.4.22-1.2111.nptl ro,rhgb root=LABEL=/
>> initrd /initrd-2.4.22-1.2111.nptl.img
>> its neither working with ro,rhgb nor ro rhgb.
>> can you please tell me the correct syntax, would be nice.
>> dont know why but it doenst seem to work, its a dumb problem i know
>> but i dont know how to solve it
> wondering about it. my grub.conf reads:
> title Fedora Core (2.4.22-1.2111.nptl)
> root (hd0,2)
> kernel /vmlinuz-2.4.22-1.2111.nptl ro rhgb
> root=/dev/Volume00/Test hdc=ide-scsi
> initrd /initrd-2.4.22-1.2111.nptl.img
> and anything works just fine.
This does not for me:
title Fedora Core (2.4.22-1.2115.nptl)
kernel /vmlinuz-2.4.22-1.2115.nptl ro rhgb root=LABEL=/
nor does: kernel /vmlinuz-2.4.22-1.2115.nptl ro root=LABEL=/ rhgb
Using the redhat-config-xfree86 gui doesn't seem to work. I think I
might have seen a reference to this earlier this week but I'm not sure.
I've tested it on two different Dell laptops and an older Gateway PIII.
Anyone else have this problem?
Date: Fri, 31 Oct 2003 02:10:35 -0500 (EST)
From: "Mike A. Harris" <mharris(a)redhat.com>
Subject: Re: OpenGL screensavers MUCH slower now
Organization: Red Hat Inc.
On Thu, 30 Oct 2003, Douglas Stewart wrote:
>Since the slew of upgrades over the past few days, I've noticed that
>OpenGL screensavers run far, far slower than they used to. Also, when
>they run, my laptop fan kicks on with far greater frequency than it
>Any ideas as to what's going on? It's a Dell Inspiron 4150 with a ATI
>Radeon Mobility 7500 (using the "radeon" driver FC ships with.)
>Should I perhaps try the ATI-provided binary driver?
Since nothing has changed in the Radeon drivers or X server,
libGL, DRI drivers, etc. whatsoever in a long time, it is highly
unlikely that any performance loss is an XFree86 driver induced
Oddly enough, Ingo Molnar, and several other people have remarked
to me this week that OpenGL performance has magically sped up
dramatically lately. I haven't changed anything which would
change performance up or down, so I'm surprised anyone sees any
difference at all. My guess is something in the kernel changed.
Personally, I see no change in performance either way.
Mike A. Harris ftp://people.redhat.com/mharris
OS Systems Engineer - XFree86 maintainer - Red Hat
I have been checking out the GL screensavers since the original release
and this last release has actually worked better. The screensavers have
been choppy but now they are are a lot better, smooth and no choppyness.
My machine is an older pIII 600 and a I810 video with 256 megs of ram.
I have "Automatically find remote shared queues" enable in printconf.
When I attempt to print to one of these automatically detected queues
from gnumeric it doesn't work. The printer/queue will show up as one of
the printers available, but nothing prints.
If I do the same thing in abiword, it work just fine.
Let me know if there is any additional information or logs I need to
Tom Cross <tomc(a)cloudnet.com>
There are four packages currently in rawhide which give up2date fits:
The fact that these are all noarch is not the problem. The problem appears to
be that there exist two different versions of each of the packages in
rawhide. If you download and install these packages manually (not up2date),
you will then be able to run up2date for the remainder.
NOTE: up2date really needs to be made more bulletproof ... it really should
not hang or give some backtrace for such an error. However, that is for the
I have not plans to bugzilla this. If asked, my RFE would be to completely
bulletproof up2date and not just address this one problem because some other
situation will cause problems.
When I boot on my fully updated FC test3 system, and select show
details, the screen shows a few lines of details and then after the
check for new hardware reverts to the summary screen with no details. I
didn't try a second click on show details to see what it does.