test February 2006

test@lists.fedoraproject.org

309 participants
543 discussions

cannot login back to gnome
by Antonio Olivares 24 Feb '06

24 Feb '06

Dear all, Yesterday, I was showing off Fedora Core 5 Test 2 + some updates to a colleague. I logged off gnome and logged in to KDE and then logged out and tried back to get to gnome. The system did not respond. I can only log on to gnome as root. I want to have both gnome and kde. Please advice. Best Regards, Antonio __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 1

Any instructions on how to do a netboot kickstart install on ppc with FC5T3?
by Orion Poplawski 24 Feb '06

24 Feb '06

I'm pretty new to the ppc architecture and really have no clue how to start a kickstart install on a ppc Mac via network (PXE? netboot?) start. I do PXE installs on x86 all the time... - Orion

2 2

Why is xscreensaver removed in favor of gnome-screensaver
by David Hagood 24 Feb '06

24 Feb '06

Why is xscreensaver removed in favor of gnome-screensaver? gnome-screensaver does not do DPMS, so my monitor stays on all the time boiling the cathodes away. gnome-screensaver doesn't have the eyecandy that xscreensaver has. In short, it seems a far less capable replacement. So why was xscreensaver removed?

17 41

SELinux breaks privoxy' with regards to resolving?
by David Nielsen 24 Feb '06

24 Feb '06

Hi List Is anyone else seeing this rather nasty policy violation that causes privoxy to be unable to resolve when SELinux is enabled? Sounds identical to this bug filed against FC4: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=166277 - David -- Obligatory shameless blog plug - the GNOME commentary located at: www.lovesunix.net/blog

1 0

3dfx dri problems
by George Schneeloch 24 Feb '06

24 Feb '06

I'm using Fedora Core 5 Test 2 on my desktop with a Voodoo 3 3000 agp card. /var/log/Xorg.0.log said that my 3dfx card won't work with DRI unless it was set to a 16-bit depth. I changed my DefaultDepth in /etc/X11/xorg.conf to 16 and I got this message from /var/log/Xorg.0.log: (EE) TDFX(0): dlopen /usr/lib/dri/tdfx_dri.so failed (/usr/lib/dri/tdfx_dri.so: cannot open shared object file: No such file or directory) (EE) TDFX(0): unable to find driver: tdfx_dri.so Doing "yum provides tdfx_dri.so" yields nothing for the default development repo's. It does not exist at /usr/lib/dri/tdfx_dri.so, although a bunch of other driver .so files show up there. (yum provides radeon_dri.so yields mesa-libGL as its package.) Any ideas? Thanks for reading all of this -George Schneeloch

2 1

Attention: Proprietary video driver users (ATI, Nvidia, etc.)
by Mike A. Harris 24 Feb '06

24 Feb '06

There have been a number of bugs reported in Red Hat bugzilla against X which have recently been tracked down to 3rd party video drivers being the culprit behind the problem the user was experienced. In many of the cases however, it wasn't obvious that the 3rd party drivers were at fault because the user was actually using the Red Hat supplied drivers, and not using the 3rd party driver that they had previously installed. Since I've wasted at least 6-8 hours in the last month diagnosing issues of this nature which have later turned out to be caused by proprietary drivers having been "installed" on the system, wether they were actually being *used* or not, I thought I should write a short useful informational email on the topic to the lists to try and inform people of some pitfalls you may encounter if you even _install_ 3rd party video drivers. Both ATI and Nvidia, and perhaps even other 3rd party drivers out there come in some form of tarball or equivalent form from the particular vendor. Most users seem to favour the hardware vendor supplied drivers directly, rather than using more sanely packaged 3rd party packages that contain the same drivers. This is very unfortunate, because installing these 3rd party tarball driver installations is very harmful to your clean OS installation. Both ATI and Nvidia's proprietary video driver installation utilities replace the Red Hat supplied libGL library with their own libGL. Nvidia's driver installs a replacement libglx.a X server module, removing the Red Hat supplied X.Org module in the process. ATI's driver may or may not replace libglx.a with it's own, I haven't checked (but if someone could confirm that, I'd appreciate knowing for certain). Once you have either of these drivers installed on your system, you can no longer use DRI with any video card. So if you install the ATI fglrx driver, while you should still be able in theory at least to use the Red Hat supplied radeon driver, you may no longer be able to use DRI with the radeon driver, because ATI's driver has blown away critical files that come with the OS that are needed for proper operation. If you install Nvidia's driver, and later decide to install an ATI card, and still have Nvidia's driver installed, bang - you will not be able to get Red Hat supplied DRI 3D acceleration to work. You must remove Nvidia's driver completely from your hard disk, and completely reinstall all of the xorg-x11 and mesa packages, and ensure they are all intact by using: rpm -Va Another problem being reported by a few people, is they are unable to get DRI to work because mesa libGL is looking for the DRI drivers in the wrong directory. The claim is that mesa is looking for the DRI drivers in /usr/X11R6/lib/modules. On a fresh OS install however, my findings are that mesa's libGL very much is not looking in /usr/X11R6 for it's modules. It is looking in the proper location of /usr/lib/dri for the modules. Why then is it looking in the wrong place on some systems? Answer: Because of fglrx having been installed. If you have had a previous OS release installed, and have installed ATI's fglrx driver from tarball, it has removed the OS supplied libGL et al and made backup copies of them aparently. Now you do an OS upgrade which works properly and installs everything in the right place. Then you uninstall ATI's fglrx with whatever script or whatever they supply, and now you try to run X, and get no DRI! Well, since you don't have fglrx installed at all, it must be our OS at fault right! Wrong. the uninstall script has put the OLD libGL it backed up (from FC4 or whatever) back in the system, overwriting the new FC5 supplied libGL in the process, and since ATI's fglrx driver is DRI based as well, it looks for the DRI modules in the wrong place now. Conclusions: If you are going to use any 3rd party proprietary drivers, please do yourself and everyone else a huge favour, and at least get your drivers from reputable 3rd party rpm package repositories such as livna.org which packages both the nvidia and ati proprietary drivers in rpm packages which install the drivers sanely without overwriting Red Hat/Fedora supplied files. These 3rd party packages install the files in alternative locations, and configure the X server et al. appropriately so that everything works. Since they do not blow away OS supplied files, you can use the OS supplied drivers still by reconfiguring xorg.conf. Also, if you decide to uninstall the 3rd party drivers via rpm, they just go away and cause no further harm to the system. So PLEASE USE THIRD PARTY RPM PACKAGES if you _must_ use 3rd party drivers. It helps create world peace. If you choose to install ATI or Nvidia tarball/whatever drivers directly from ATI/Nvidia (or any other vendor for that matter), your system is 100% completely and totally unsupported. Even if you are using _our_ drivers, your 3rd party driver installation may have blown away our libGL, our libglx.a or any other files that have been supplied by our OS. As such, your system is not supported. For those who encounter a bug of any kind whatsoever while using 3rd party video drivers, completely remove the 3rd party drivers from your system, and then perform a full "yum update" to ensure you have the latest Fedora Core supplied X packages installed. After doing this, do an "rpm -Va" of your whole system, in particular the xorg-x11-*, mesa-* and lib* packages. If there are any discrepancies found in any of the Fedora supplied packages, in particular in libGL, or the X server packages, remove them and reinstall them and reverify that the files installed on your system are the ones shipped by Fedora. If you are able to reproduce the problem you are having after having performed these steps, and having ensured that you are neither using 3rd party drivers, nor even have them installed, then feel free to file a bug report in bugzilla. By doing this small amount of pre-diagnosis of your own system if you are using 3rd party drivers, you will save yourself a lot of headaches, and will save other people, including developers such as myself from wasting endless hours trying to diagnose problems which turn out to be bogus. Hours which could have been spent fixing legitimate bugs that are present in bugzilla. As an additional note - if anyone is using proprietary drivers and has any problems which they believe might actually be a bug in Xorg and not in their proprietary driver - file such bugs directly in X.Org bugzilla. X.Org has an nVidia (closed) component specifically for the proprietary driver, and Nvidia engineers get those bugs and will investigate them over time. Anyhow, I hope this helps people understand at least some of the problems that can occur when you opt to using 3rd party drivers, present some alternatives, and to help people diagnose their own problems which might be caused by having installed 3rd party drivers. Thanks for reading. TTYL P.S. Feel free to forward this email on to any other lists or people whom you think might benefit from it. Also, if anyone thinks this information would be useful to have on the Fedora Wiki or somewhere else, feel free to copy my email into a wiki page, or paraphrase, etc. -- Mike A. Harris, Systems Engineer, X11 Development team, Red Hat Canada, Ltd.

8 8

FC5T3 I can't find libX11.a and libXau.a in libX11-devel.i386
by Lorenzo Fiorini 24 Feb '06

24 Feb '06

I'm trying to build my apps under FC5T3 ( my main env is FC4 ) but I can't find those static libraries. I have installed these: libX11-devel.i386 1.0.0-2.2 installed libX11.i386 1.0.0-2.2 installed Any suggestion? regards, Lorenzo Fiorini

4 4

FC5T3 crashed during install of the bootloader
by fedora 24 Feb '06

24 Feb '06

FC5T3 crashed during install of the bootloader ---------------------------------------------- Traceback (most recent call last): File "/usr/lib/anaconda/gui.py", line 1253, in handleRenderCallback self.currentWindow.renderCallback() File "/usr/lib/anaconda/iw/progress_gui.py", line 245, in renderCallback self.intf.icw.nextClicked() File "/usr/lib/anaconda/gui.py", line 951, in nextClicked self.dispatch.gotoNext() File "/usr/lib/anaconda/dispatch.py", line 146, in gotoNext self.moveStep() File "/usr/lib/anaconda/dispatch.py", line 217, in moveStep rc = apply(func, self.bindArgs(args)) File "/usr/lib/anaconda/bootloader.py", line 178, in writeBootloader justConfigFile, intf) File "/usr/lib/booty/bootloaderInfo.py", line 1190, in write justConfig | (not self.useGrubVal)) File "/usr/lib/booty/bootloaderInfo.py", line 746, in writeGrub f.write('# root %s\n' % self.grubbyPartitionName(bootDevs[0])) File "/usr/lib/booty/bootloaderInfo.py", line 989, in grubbyPartitionName return "(%s,%d)" % (self.grubbyDiskName(name), partNum) File "/usr/lib/booty/bootloaderInfo.py", line 984, in grubbyDiskName return "hd%d" % self.drivelist.index(name) ValueError: list.index(x): x not in list Local variables in innermost frame: self: <bootloaderInfo.x86BootloaderInfo instance at 0xb72fc46c> name: sda -- Best regards,

1 0

Re: hibernate/suspend?
by Mike Leahy 24 Feb '06

24 Feb '06

Orion, Thanks for the tip...that definitely got rid of the end_request errors. As for hibernate itself not working, I've been able to determine that if I have my PCMCIA wireless card connected when I run pm-hibernate, it hangs. This is a linksys WPC54GS, with a broadcom 4306 chipset. Although the FC5 kernels include a bcm43xx driver for this chipset, I have yet to get that to work properly. Instead, I've been working with ndiswrapper to run the native windows driver. I find that if I'm careful, and I disconnect and unplug the card, the hibernate process runs fine. Otherwise, I'm toast. Has anyone else had a similar experience like this? Mike Thanks again for your help, Mike Orion Poplawski wrotea; > > Mike Leahy wrote: >> > > >> > > Hello list, >> > > >> > > >> > > I installed FC5T3 yestereday. I found that I was able to >> > >successfully hibernate/restart before running any updates. However, it >> > >took about 3 or 4 minutes to complete, partly because of some errors I >> > >get when the screen first goes blank...something that looks like: >> > > >> > > "end_request: I/O error, dev fd0, <something else here>". >> > > >> > > >> > > Last time I asked about this, somebody said it was an issue with >> > >the kernel. > > > >Remove fd0 from /boot/grub/device.map, should fix that I think.

2 1

FC5T3 crash bootloader install
by fedora 24 Feb '06

24 Feb '06

Traceback (most recent call last): File "/usr/lib/anaconda/gui.py", line 1253, in handleRenderCallback self.currentWindow.renderCallback() File "/usr/lib/anaconda/iw/progress_gui.py", line 245, in renderCallback self.intf.icw.nextClicked() File "/usr/lib/anaconda/gui.py", line 951, in nextClicked self.dispatch.gotoNext() File "/usr/lib/anaconda/dispatch.py", line 146, in gotoNext self.moveStep() File "/usr/lib/anaconda/dispatch.py", line 217, in moveStep rc = apply(func, self.bindArgs(args)) File "/usr/lib/anaconda/bootloader.py", line 178, in writeBootloader justConfigFile, intf) File "/usr/lib/booty/bootloaderInfo.py", line 1190, in write justConfig | (not self.useGrubVal)) File "/usr/lib/booty/bootloaderInfo.py", line 746, in writeGrub f.write('# root %s\n' % self.grubbyPartitionName(bootDevs[0])) File "/usr/lib/booty/bootloaderInfo.py", line 989, in grubbyPartitionName return "(%s,%d)" % (self.grubbyDiskName(name), partNum) File "/usr/lib/booty/bootloaderInfo.py", line 984, in grubbyDiskName return "hd%d" % self.drivelist.index(name) ValueError: list.index(x): x not in list Local variables in innermost frame: self: <bootloaderInfo.x86BootloaderInfo instance at 0xb72fc46c> name: sda HELP

1 0

← Newer
1
...
11
12
13
14
15
16
17
...
55
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

test February 2006