test September 2004

test@lists.fedoraproject.org

304 participants
452 discussions

FC3T2: Having to downgrade Xorg 6.8.1 to 6.7.0
by ByteEnable 30 Sep '04

30 Sep '04

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

2 1

Re: start_udev and X crashing after latest FC3T2 update
by Clyde E. Kunkel 30 Sep '04

30 Sep '04

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????

2 5

yum dependencies problem
by dustin 30 Sep '04

30 Sep '04

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

4 4

crond + pam very noisy
by Stephen John Smoogen 29 Sep '04

29 Sep '04

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

4 4

yum barfs at me
by Jonathan Corbet 29 Sep '04

29 Sep '04

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

2 3

Box from hell testing for FC3t2
by Alan Cox 29 Sep '04

29 Sep '04

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

5 8

Re: Automated Mirror Selection [Re: Worst experience with Up2Date ever.]
by Fulko.Hew＠sita.aero 29 Sep '04

29 Sep '04

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.) :-)

2 1

Re: Automated Mirror Selection [Re: Worst experience with Up2Date ever.]
by William Hooper 29 Sep '04

29 Sep '04

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

1 0

fedora kernel can't boot from sata disk
by Lars G 29 Sep '04

29 Sep '04

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

5 5

Added "fi" to line 78 of /sbin/start_udev
by Mike Martin 29 Sep '04

29 Sep '04

I ran "yum update" and was having udev problems at boot time. I added a "fi" to line 78 of /sbin/start_udev and I could boot. -Best Regards...

3 2

← Newer
1
2
3
4
5
6
7
8
...
46
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

test September 2004