FC3T2: Having to downgrade Xorg 6.8.1 to 6.7.0
by ByteEnable
Hi all,
Xorg 6.8.x is not stable on my Radeon Mobility 9000. I get hangs,
display corruption, screen and font artifacts, to the point where the
system is not useable. Its random too. I went for three days, then I
had to reboot, bam, problems all day. I've bugzilla'ed at Red Hat and
Xorg. I'm not using the transparency feature either.
Summary:
Driver Symptom
------ ------------------------------------------------------
Radeon Screen and font artifacts, display corruption, hangs.
fgrlx Driver=3.12 Works fine until a 3D app is launched or
gnome-font-properties is run, bam, XServer reset.
No problems with either driver with 6.7.0.
Byte
19 years, 6 months
Re: start_udev and X crashing after latest FC3T2 update
by Clyde E. Kunkel
On Wed, 2004-09-29 at 16:16, Brian Millett wrote:
> On Wed, 2004-09-29 at 15:51 -0400, Clyde Kunkel wrote:
> > (**) Option "Device" "/dev/input/mice"
> > (EE) xf86OpenSerial: Cannot open device /dev/input/mice
> > No such file or directory.
> > (EE) Mouse0: cannot open input device
> > (EE) PreInit failed for input device "Mouse0"
>
> This is the problem. No mouse. Umm. It also looked like other /dev
> stuff was missing. Have you upgraded your kernel lately? You might
> want to try to remake the initrd. I seem to remember that this was a
> problem in the past when people upgraded a udev package with an initrd
> that did not use the new udev package. If you have, then just ignore
> me.
> IE:
> mkinitrd -f /boot/initrd-2.6.8-1.549.img 2.6.8-1.549
>
> --
> Brian Millett - [ Ombuds Wellington, "The Quality of Mercy"]
> "Anything a telepath sees while inside a defendant's mind is
> inadmissible
> evidence."
>
>
mkinitrd didn't work....something causing probs with /dev/null in the
profile scripts and atd is not starting. Don't know if there is a
relationship there or not.
Still probing...not giving up.
Recap: updated nicely working FC3T2 today before I saw the udev hold.
Couldn't startx. Fixed udev, still can't startx. Something borked when
udev failed????
19 years, 6 months
yum dependencies problem
by dustin
Greetings,
I've been using Fedora Core 2 for a while and decided to try out FC3-
test2. I got it installed with no problems and I'm writing this from it.
The problem is that I am trying to use up2date to update my system, and
I keep getting a dependency error. It is saying that linc is required to
install linc-devel. Here is the output from yum:
Requiring package is installed: linc-devel - 1.0.3-6.i386
Resolving for installed requiring package: linc-devel - 1.0.3-6.i386
Resolving for requirement: linc= 1.0.3
Mode for pkg providing linc= 1.0.3: None
Searching pkgSack for dep: linc
Potential match for linc from linc - 1.0.3-6.i386
Matched linc - 1.0.3-6.i386 to require for linc
miss = 2
conf = 0
CheckDeps = 0
Finished Dependency Resolution
Dependency Process ending
Error: missing dep: linc for pkg linc-devel
I look at that and notice that linc nor linc-devel are in the repository
from the mirror im using. I figure it's no big deal and I just download
the linc version it wants and go to install it, only to get a message
saying that it is already installed.
[root@median ~]# rpm -qa | grep linc
linc-devel-1.0.3-6
linc-1.0.3-6
[root@median ~]#
yum wants 1.0.3, but I have 1.0.3-6. This normally shouldn't matter, but
for some reason yum doesn't like this. Is anyone else experiencing this?
Does anyone know how to resolve this issue?
Thanks,
dustin
19 years, 6 months
crond + pam very noisy
by Stephen John Smoogen
My logs are getting filled with:
crond[27300]: pam_succeed_if: requirement "uid < 100" was met by user
"root"
crond[27303]: pam_succeed_if: requirement "uid < 100" was met by user
"root"
Not sure which job is doing this, but it is getting noisy.. I dont
want to think what 2000 machines will do to our central mail and log
servers :).
Any ideas how I can track this down to better bugzilla?
--
Stephen J Smoogen.
Professional System Administrator
19 years, 6 months
yum barfs at me
by Jonathan Corbet
What else should an LWN editor do on a Wednesday but try to hose his
system?
I've not succeeded in doing a "yum update" for some time, due to various
"missing dep" errors. I finally circumvented those by brute-force
upgrading some of the x11 packages, to the point that yum would actually
consent to trying to update my (x86-64) system. Here's what came next,
though:
Fedora/RPMS/kdebase-devel-3.3.0-5.x86_64.rpm: [Errno 4] IOError: HTTP Error 404: Not Found
Fedora/RPMS/kdebase-devel-3.3.0-5.x86_64.rpm: [Errno 4] IOError: HTTP Error 404: Not Found
Fedora/RPMS/kdebase-devel-3.3.0-5.x86_64.rpm: [Errno 4] IOError: HTTP Error 404: Not Found
Traceback (most recent call last):
File "/usr/share/yum-cli/yummain.py", line 139, in ?
main(sys.argv[1:])
File "/usr/share/yum-cli/yummain.py", line 122, in main
base.doTransaction()
File "/usr/share/yum-cli/cli.py", line 444, in doTransaction
problems = self.downloadPkgs(downloadpkgs)
File "/usr/lib/python2.3/site-packages/yum/__init__.py", line 267, in downloadPkgs
mylocal = repo.get(relative=remote, local=local, checkfunc=checkfunc)
File "/usr/lib/python2.3/site-packages/yum/repos.py", line 360, in get
checkfunc=checkfunc)
File "/usr/lib/python2.3/site-packages/urlgrabber/mirror.py", line 401, in urlgrab
return self._mirror_try(func, url, kw)
File "/usr/lib/python2.3/site-packages/urlgrabber/mirror.py", line 384, in _mirror_try
mirrorchoice = self._get_mirror(gr)
File "/usr/lib/python2.3/site-packages/urlgrabber/mirror.py", line 282, in _get_mirror
return gr.mirrors[gr._next]
IndexError: list index out of range
Is this the new yum's response to the "the repository doesn't have the
packages the headers say it should have" problem?
Along these lines, what are the recommended x86-64 mirrors these days?
Thanks,
jon
19 years, 6 months
Box from hell testing for FC3t2
by Alan Cox
I loaded FC3 test2 onto the box from hell which is my distribution
torture tester. It failed with flying colours
- FC3t2 base kernel would not boot in standard configuration because
someone enabled EDD support which crashes it
- The SCSI layer blew up in several ways (#133998, #134001)
- The HAL layer goes bananas (#130649)
- The 3c59x driver breaks (#134000)
- Several of the USB hubs fail to initialize (not bugzilla'd yet need to
do some debugging).
- Badness in interruptible_sleep_on from lock_down
- PS/2 mouse does not work
- hal_lpadmin is segfaulting randomly
- PCI allocation produced unhappy looking messages
Sep 28 19:27:48 localhost kernel: PCI: Failed to allocate I/O resource #0:80@b000 for 0000:05:0c.0
etc
It even managed to rename my loopback device eth0 and create devices with
names like dev1536.
To be fair its a pretty brutal test box but the results are not so good as I'd
hoped. Upgrading to a 2.6.9rc2 kernel fixes nothing but breaks r8169 and
via-velocity ethernet drivers too
Alan
19 years, 6 months
Re: Automated Mirror Selection [Re: Worst experience with Up2Date ever.]
by Fulko.Hew@sita.aero
Jeff Spaleta <jspaleta(a)gmail.com>@redhat.com on 09/29/2004 01:22:16 PM
commented:
> On Wed, 29 Sep 2004 09:56:27 -0500, Chris Adams <cmadams(a)hiwaay.net>
wrote:
>
... snip ...
> > For example, mirror.hiwaay.net is in the list, but I don't
> > mirror all the rawhide architectures (just i386 and x86_64). Does
> > up2date recognize a 404 and try another mirror? Is this action
> > remembered?
>
> I don't think there is any cleverness about remembering if mirrors
> have gone sour and removing them locally from the client. You have to
> be careful with this sort of logic. A specific mirror could fail for a
> temporary reason, so trying to be clever and remember that it failed
> could prevent you from ever using that mirror again just because it
> had a short period downtime event once.
On the other hand 'muohio' seems to be on the mirror list, and it has never
(apparently) worked, and up2date just hangs on it forever (or at least
a _very_ long time.) I end up killing up2date, and trying again.
The trouble is that up2date has a variety of stages that it goes through,
and it apparently re-picks from the list of hosts during each stage.
So even though it went to a good site in the beginning to detect that
there are new packages, it may choose to go to a bad site to fetch the
RPM headers.
The list of mirrors should/could at the very least be a package that
we can download to get the 'latest set' of behaving mirrors.
> > One problem with syncing rawhide to mirrors is that the daily build and
> > push of rawhide to the master servers takes a different amount of time
> > (and so finishes at a different time) each day. Some days, my sync
> > finishes before the push is complete, so until my mirror syncs again
> > (once a day), it will be effectively fubared.
Also the sync of headers is independent of the sync of packages.
Also the notification of packages is independent of syncing of any parts
of any mirrors.
In the end my rule of thumb is that if I see the update notification icon,
and I can't get the files now (because they're not sync'ed yet) I'll try
again in a few hours. There is no point in trying them sooner, since
syncing
mirrors takes a completely variable amount of time.
> Okay this sort of problem could maybe be preventable with small
> changes on the master server, if there was a way to implement a
> start/stop file on the master servers that mirrors could check to see
> if a rawhide push was still in process and delay starting a sync
> attempt until the rawhide push on the master server was done. But
> even if the small technical change on the master server was made, all
> the mirrors would have to write/use scripts to take advantage of the
> change and there is no way you can enforce mirror admins to do that
> across the board. Its the politics of individual mirror admins. So
> while you might use this to make your mirror more reliable... i don't
> think you can count on all admins to do it.
Can the master server check the mirrors to see if (all of) their transfers
have been completed, and only then re-add that mirror to the list of
candidates?
Sure, it would be nicer if the mirror could just 'tell' the master, rather
than
have the master poll...
> > One thing I've considered
> > doing is to change my mirroring scripts to watch for actual file syncs
> > and loop (with a small delay) until the sync runs without changing any
> > files. That would help, but there's still a period where my mirror of
> > the tree is not in sync. I guess if I synced the header.info and
> > repodata files last and then deleted, I should always have a consistent
> > tree, but scripting that will be somewhat of a PITA.
That would be the first major boon... if RPMs would be sync'ed before
headers
at least there shouldn't be a 'premature' change indication without the
files
being available.
> The heart of the problem... anything that is going to make mirrors
> significantly more reliable is going to end up being a solution that
> puts a heavy burden on the mirror admins.
> PITA scripts or extra services that communicate back or whatever. The
> maximum reliability in terms of how out of sync an invidiual mirror
> can get basically comes down to how much care and feeding individual
> mirror maintainers are willing to do. So even if you get scripts in
> place on your mirror that work to keep your mirror synced with the
> master mirror, its not clear to me that you can get equal effort from
> the other mirrors who are volunteering their bandwidth to host the
> packages.
PITA scripts should be a prerequisite to becomming a mirror, or at the very
least to be a mirror that gets put into the mirror list.
BTW. It seems to me that the mirror list is dynamically retrieved during
each run of up2date (true or false)? If false, then where is my local
mirror list stored? (so I can get rid of that damn 'muohio'!)
> And if we can't get all the mirrors to be reliable, then the only
> other way to do it, is to have some scheme that dynamically checks for
> out of synced mirrors and ranks the reliability of mirrors so that
> over time, clients who are connecting to mirrors get a preferred set
> and never set a set that is known to be out of sync. But, i have not
> seen a scheme that doesn't require an admin to run extra services or
> scripts, that is garunteed to catch a mirror being out of sync and
> prevent a client computer from contacting a mirror that is out of
> sync.
I think thats too complicated. Something that notifies when the rsync is
done is better. For the forseable future I don't think a mirror will be
'constantly' in flux. I'm sure there will be at least a few minutes of the
day when it _will_ be in sync. When we get to the point where updates
are coming out on all/any packages so quickly that clients are _always_
in the mode of fetching at least _one_ package, _all_ the time, then boy
have we either got a problem with buggy software, or _way_ too many
packages...
or not enough bandwidth. (I guess the later is always true.) :-)
19 years, 6 months
Re: Automated Mirror Selection [Re: Worst experience with Up2Date ever.]
by William Hooper
Fulko.Hew(a)sita.aero said:
>
[snip]
> The list of mirrors should/could at the very least be a package that
> we can download to get the 'latest set' of behaving mirrors.
The current system of being a text file on a web server seems to have less
maintenance involved.
[snip]
> BTW. It seems to me that the mirror list is dynamically retrieved during
> each run of up2date (true or false)?
True, but...
> If false, then where is my local
> mirror list stored? (so I can get rid of that damn 'muohio'!)
Reading /usr/share/doc/up2date-4.3.19/mirrors.txt can be enlightening.
You can have a local file if you want.
I always assumed that the default config was to get people to quit
hammering the main server and that advanced users (the ones that
configured mirrors before) would change the settings to their liking.
Isn't that the reason there are text files for different geographical
regions?
If a had a small number of machines I would go with the list of mirrors on
each machine. For a larger number of machines I would go with the mirror
list stored on a local web server so that it can be easily changed for all
(or run your own local mirror).
[snip]
> For the forseable future I don't think a mirror will be
> 'constantly' in flux.
[snip]
Rawhide not being in constant flux means that development has stopped.
Not a good sign.
--
William Hooper
19 years, 6 months
fedora kernel can't boot from sata disk
by Lars G
hi
i'm trying to run a current fedora rawhide kernel without recompiling on my
asus a7n8x-dlx mainboard with an sata reiserfs hd as the only disk.
my recompiled vanilla kernel works fine, but the stock kernel with the
fedora config can't boot.
i guess it has something todo with libata/reiserfs modules
not loading at the boot process.
is it possible to force the modules to load at the boot line or something ?
if not, is it at all possible to install/run an stock fedora kernel on an
sata hd only computer ?
thanks!
lars
19 years, 6 months