Re: SL 6.0 printer-configuration problems
On Thu, Mar 17, 2011 at 3:51 PM, Spencer Buckner wrote: > I am using System->Administration->Printing to configure an HP DeskJet 500 > printer connected to the parallel port of a stand-alone computer (not part > of a network). The HP DeskJet 500 is the only printer connected to the > computer and is specified to be the default printer. (snip) > I have seen messages from Ubuntu users with the same problems but have not > found any understandable fixes. Can anyone help? SL6 does not have parallel port support (it was dropped upstream). But ELRepo comes to the rescue :-) http://elrepo.org/tiki/kmod-lp Try installing that package and see if that solves your problem. Akemi
SL 6.0 printer-configuration problems
I am using System->Administration->Printing to configure an HP DeskJet 500 printer connected to the parallel port of a stand-alone computer (not part of a network). The HP DeskJet 500 is the only printer connected to the computer and is specified to be the default printer. I have not been able to successfully configure the printer. It worked reliably under Fedora 10 and earlier versions of Fedora before I installed SL 6.0. I have tried the following configuration Settings: Network Printer->LPD/LPR Host or Printer Description:HP DeskJet 500 Location: Device URI: lpd://localhost Make and Model: HP DeskJet 500 Foomatic/pcl3 (recommended) Network Printer->AppSocket/HP JetDirect Description:HP DeskJet 500 Location: Device URI: socket://localhost:9100 Make and Model: HP DeskJet 500 Foomatic/pcl3 (recommended) Devices: A printer connected to the parallel port. Description:HP DeskJet 500 Location: Device URI: parallel:/dev/lp1 Make and Model: HP DeskJet 500 Foomatic/pcl3 (recommended) Results: 1. The command, Network Printer->Find Network Printer, never works. (The printer _is_ turned on.) 2. The command, Print Test Page, produces error messages: com.apple.print.recoverable or: Printer 'HP-DeskJet-500' may not be connected. (The printer _is_ connected.) I have seen messages from Ubuntu users with the same problems but have not found any understandable fixes. Can anyone help? Thanks, Spencer
Re: GDM theme
On 03/17/2011 09:21 PM, Chris Tooley wrote: Ok, this is a really stupid question: How do I change the theme for GDM in SL6? Thanks, -Chris Not sure, it has been changed in Fedora 12/13 and SL6 uses the same way. If you want to change the background of the login screen, change the file "default.xml" in "/usr/share/backgrounds/"; there is a file "tuv.xml" which is .
Re: Persistent Data in SL LiveDVD on USB
Hi William, You have definitely no overlay file with the name "overlay--4C04-9372" in /LiveOS folder on your USB stick. So overlay will not work. > [root@livecd sluser]# dir /overlayfs/LiveOS/ > home.img osmin.img squashfs.img It's hard to say why this happened. However, it should be possible to create the overlay file just manually. Change to the /LiveOS on your USB stick and run dd if=/dev/zero of=overlay--4C04-9372 count=1024 bs=1M This will create a 1024 MB file (/LiveOS/overlay--4C04-9372) filled with zeros. If you now boot your USB stick the file /LiveOS/overlay--4C04-9372 should be found and take to store the persistence changes. Please note that the overlay file should not be used completely: http://www.livecd.ethz.ch/usbdisk.html#limits In worst case you can just remove it again and start with a new and "empty" one. Cheers, Urs On 03/17/2011 08:56 PM, William Shu wrote: Dear Urs, What I obtained is below. Unfortunately, a bit mobile now, I have only the USB stick to work on SL6 and so cannot un-install it as such; but I had no complaints! I recall when installing SL6 on the USB that I had warning about its label (made up of some control-character sequence, starting, I think, with ^17). Since installation was complete, and in prior attempts the label was changed, I did not think it was a problem. Now, I'm not so sure! Regards, William. [sluser@livecd ~]$ su [root@livecd sluser]# dir /LiveOS/overlay--4C04-9372 dir: cannot access /LiveOS/overlay--4C04-9372: No such file or directory [root@livecd sluser]# dir /LiveOS/overlay--4C04-9372 [root@livecd sluser]# find / -iname "*4C04-9372*" -print /dev/disk/by-uuid/4C04-9372 /dev/.udev/links/disk\x2fby-uuid\x2f4C04-9372 [root@livecd sluser]# mkdir /overlayfs [root@livecd sluser]# mount -n -t auto UUID=4C04-9372 /overlayfs [root@livecd sluser]# [ -f /overlayfs/LiveOS/overlay--4C04-9372 -a -w /overlayfs/LiveOS/overlay--4C04-9372 ]&& echo ok [root@livecd sluser]# dir /overlayfs/ boot/ EFI/ LiveOS/ syslinux/ [root@livecd sluser]# dir /overlayfs/LiveOS/ home.img osmin.img squashfs.img [root@livecd sluser]# William --- On Thu, 3/17/11, Urs Beyerle wrote: From: Urs Beyerle Subject: Re: Persistent Data in SL LiveDVD on USB To: "William Shu" Cc: scientific-linux-us...@fnal.gov Date: Thursday, March 17, 2011, 10:00 AM Hi William On 03/17/2011 06:15 AM, William Shu wrote: Thank you very much Urs. Below are the requested outputs: (A) for losetup; and (B) for dracut. It seems the overlay is not being found! On a related matter, you say livecd-tools and liveusb-creator are part of the live iso's, but I had to "yum install" them before I could use them in making the USB! Thanks for the debug info. You are right. liveusb-creator is not part of Live iso's. But livecd-tools and therefore livecd-iso-to-disk should be installed. However, doing "yum update livecd-tools" is always a good idea. Yes, the overlay is not found in your case: dracut: + mkdir /overlayfs dracut: + mount -n -t auto UUID=4C04-9372 /overlayfs dracut: + [ -f /overlayfs/LiveOS/overlay--4C04-9372 -a -w /overlayfs/LiveOS/overlay--4C04-9372 ] dracut: + umount -l /overlayfs dracut: + [ -z ] dracut: + [ -n UUID=4C04-9372 -a -n /LiveOS/overlay--4C04-9372 ] dracut: + warn Unable to find persistent overlay; using temporary Can you quickly check, if the overlay file is on your Live USB drive and if it is writable (w)? In your case the overlay file should be /LiveOS/overlay--4C04-9372 You might want to reproduce the mounting of your USB stick (as done be dracut) on a SL6 system. Plugin the stick. If it gets auto-mounted, un-mount it. As root try mkdir /overlayfs mount -n -t auto UUID=4C04-9372 /overlayfs [ -f /overlayfs/LiveOS/overlay--4C04-9372 -a -w /overlayfs/LiveOS/overlay--4C04-9372 ]&& echo ok Cheers, Urs
Re: Virtual floppy as sda on Dell M605 blades
On Mar 17, 2011, at 19:20 , Joel Maslak wrote: > I'm seeing some differences in SCSI drive numbering in SL 6 / RHEL 6, > compared to CentOS 5 / RHEL 5. This means that on *some* of my servers, > /dev/sdb is actually the first hard disk, which makes kickstarting a bit more > annoying. Does anyone know a way to reverse the order or similar easily? We're using "pci=bfsort" for SL5 and "pci=bfsort nousb" for SL6 when kickstarting. The "pci=bfsort" is kept on the installed system, "nousb" isn't. Eventually, using /dev/disk/by-* will be the right solution, but for the time being these kernel parameters give us consistent device enumeration across SL5/6. - Stephan > A parameter to grub to either remove the virtual floppy or reorder these > would be handy, if someone knows of one. Certainly I can disable the virtual > floppy in these machines, but I'd rather not do that (it's needed for BIOS > updates). > > In CentOS 5 / RHEL 5, I would see disk configurations such as: > > scsi 0:0:0:0: CD-ROM Virtual CDROM1.00 PQ: 0 ANSI: 0 > CCS > scsi 1:0:0:0: Direct-Access Virtual Floppy 1.00 PQ: 0 ANSI: 0 > CCS > scsi 2:0:0:0: Direct-Access SEAGATE ST973451SS SM04 PQ: 0 ANSI: 5 > scsi 2:0:1:0: Direct-Access SEAGATE ST973451SS SM04 PQ: 0 ANSI: 5 > scsi 2:1:0:0: Direct-Access Dell VIRTUAL DISK 1028 PQ: 0 ANSI: 5 > s > sd 0:1:0:0: Attached scsi disk sda > sd 2:0:0:0: Attached scsi removable disk sdb > > Basically, sda was the internal RAID 1 disk array and sdb is the DRAC > "virtual floppy". This worked fine, and our scripts knew to expect sda as > the first disk. Note that these are identical systems, purchased at the same > time and delivered together. > > On SL 6 / RHEL 6, it reverses the order of sda and sdb: > > scsi 0:0:0:0: CD-ROM Virtual CDROM1.00 PQ: 0 ANSI: 0 > CCS > scsi 1:0:0:0: Direct-Access Virtual Floppy 1.00 PQ: 0 ANSI: 0 > CCS > scsi 2:0:0:0: Direct-Access SEAGATE ST973451SS SM04 PQ: 0 ANSI: 5 > scsi 2:0:1:0: Direct-Access SEAGATE ST973451SS SM04 PQ: 0 ANSI: 5 > scsi 2:1:0:0: Direct-Access Dell VIRTUAL DISK 1028 PQ: 0 ANSI: 5 > sd 2:1:0:0: [sdb] Attached SCSI disk > sd 1:0:0:0: [sda] Attached SCSI removable disk > > (sdb becomes 1:0:0:0, sdb becomes 2:0:0:0) -- Stephan Wiesand DESY -DV- Platanenenallee 6 15738 Zeuthen, Germany smime.p7s Description: S/MIME cryptographic signature
public keys and SL6
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I came across an odd feature in sl6 and maybe someone understands what causes this. It seems that SL6 has an agent that does an ssh-add when you log in. Unfortunately, it appears to snarf up any key you happen to have in your .ssh area even ones with nonstandard names. It has the rather disturbing feature that if you do a ssh-add -l immediately after logging in it shows your encrypted private key as being loaded. It seems not to be really since when you try to use it it then asks for the pass phrase with a gui popup. I'm guessing that it just looks at the pub part and recognizes that you "might use it" later. In my case I keep some specialized unencrypted keys for specific functions (i.e. in the remote authorized_keys file these guys allow execution of a single rather harmless command). It seems that these get ssh-add'ed automatically at login and they are presented to the remote hosts in ways that preclude my using public key access on the second hop in a chain of ssh's (yes initially the real encrypted key gets used but on the second hop it appears the specialized ones get presented and force a failure for an actual login). I googled and found that there is an openssh agent in the startup applications that appears to have a related function but I don't seem to have that enabled so configuring is likely futile. I do have a workaround (simply move all these keys to some other area than .ssh) but I'm curious as to what is doing this and it seems like something people might want to be aware of. - -- Robert E. Blair, Room C221, Building 360 Argonne National Laboratory (High Energy Physics Division) 9700 South Cass Avenue, Argonne, IL 60439, USA Phone: (630)-252-7545 FAX: (630)-252-5047 GnuPG Public Key: http://www.hep.anl.gov/reb/key.asc -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) iEYEARECAAYFAk2CgIsACgkQOMIGC6x7/XQrfACgl/SAarLpTYwNB/OYyJiHcTU6 wsYAn20O6f3wytPmBLxTASgTxhtdP2a8 =Ir7x -END PGP SIGNATURE- <> smime.p7s Description: S/MIME Cryptographic Signature
GDM theme
Ok, this is a really stupid question: How do I change the theme for GDM in SL6? Thanks, -Chris
Re: Persistent Data in SL LiveDVD on USB
Dear Urs, What I obtained is below. Unfortunately, a bit mobile now, I have only the USB stick to work on SL6 and so cannot un-install it as such; but I had no complaints! I recall when installing SL6 on the USB that I had warning about its label (made up of some control-character sequence, starting, I think, with ^17). Since installation was complete, and in prior attempts the label was changed, I did not think it was a problem. Now, I'm not so sure! Regards, William. [sluser@livecd ~]$ su [root@livecd sluser]# dir /LiveOS/overlay--4C04-9372 dir: cannot access /LiveOS/overlay--4C04-9372: No such file or directory [root@livecd sluser]# dir /LiveOS/overlay--4C04-9372 [root@livecd sluser]# find / -iname "*4C04-9372*" -print /dev/disk/by-uuid/4C04-9372 /dev/.udev/links/disk\x2fby-uuid\x2f4C04-9372 [root@livecd sluser]# mkdir /overlayfs [root@livecd sluser]# mount -n -t auto UUID=4C04-9372 /overlayfs [root@livecd sluser]# [ -f /overlayfs/LiveOS/overlay--4C04-9372 -a -w /overlayfs/LiveOS/overlay--4C04-9372 ] && echo ok [root@livecd sluser]# dir /overlayfs/ boot/ EFI/ LiveOS/ syslinux/ [root@livecd sluser]# dir /overlayfs/LiveOS/ home.img osmin.img squashfs.img [root@livecd sluser]# William --- On Thu, 3/17/11, Urs Beyerle wrote: > From: Urs Beyerle > Subject: Re: Persistent Data in SL LiveDVD on USB > To: "William Shu" > Cc: scientific-linux-us...@fnal.gov > Date: Thursday, March 17, 2011, 10:00 AM > Hi William > > On 03/17/2011 06:15 AM, William Shu wrote: > > Thank you very much Urs. > > > > Below are the requested outputs: (A) for losetup; and > (B) for dracut. It seems the overlay is not being found! > > > > On a related matter, you say livecd-tools and > liveusb-creator are part of the live iso's, but I had to > "yum install" them before I could use them in making the > USB! > > > > Thanks for the debug info. > > You are right. liveusb-creator is not part of Live iso's. > But livecd-tools and therefore livecd-iso-to-disk should be > > installed. However, doing "yum update livecd-tools" is > always a good idea. > > Yes, the overlay is not found in your case: > > dracut: + mkdir /overlayfs > dracut: + mount -n -t auto UUID=4C04-9372 /overlayfs > dracut: + [ -f /overlayfs/LiveOS/overlay--4C04-9372 -a -w > /overlayfs/LiveOS/overlay--4C04-9372 ] > dracut: + umount -l /overlayfs > dracut: + [ -z ] > dracut: + [ -n UUID=4C04-9372 -a -n > /LiveOS/overlay--4C04-9372 ] > dracut: + warn Unable to find persistent overlay; using > temporary > > Can you quickly check, if the overlay file is on your Live > USB drive and if it is writable (w)? In your case the > overlay > file should be > > /LiveOS/overlay--4C04-9372 > > You might want to reproduce the mounting of your USB stick > (as done be dracut) on a SL6 system. Plugin the stick. If it > > gets auto-mounted, un-mount it. As root try > > mkdir /overlayfs > mount -n -t auto UUID=4C04-9372 /overlayfs > [ -f /overlayfs/LiveOS/overlay--4C04-9372 -a -w > /overlayfs/LiveOS/overlay--4C04-9372 ] && echo ok > > > Cheers, > > Urs >
Re: Virtual floppy as sda on Dell M605 blades
On 03/17/2011 12:20 PM, Joel Maslak wrote: I'm seeing some differences in SCSI drive numbering in SL 6 / RHEL 6, compared to CentOS 5 / RHEL 5. This means that on *some* of my servers, /dev/sdb is actually the first hard disk, which makes kickstarting a bit more annoying. Does anyone know a way to reverse the order or similar easily? A parameter to grub to either remove the virtual floppy or reorder these would be handy, if someone knows of one. Certainly I can disable the virtual floppy in these machines, but I'd rather not do that (it's needed for BIOS updates). Well, hopefully with 6.1 you'll be able to use /dev/disk/by-path labels, see: https://bugzilla.redhat.com/show_bug.cgi?id=621515 I've made a request there for an updates image. Might not be too hard to do. Actually, the more I look at this, part --ondisk might work and only part --onpart doesn't not. Not sure. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com
Re: Installing upstream providers documentation locally
On 03/17/2011 07:06 AM, Matt Willsher wrote: Hello, Are there RPM packages available that contain the upstream vendor's manuals for SL6 for location installation? If there aren't in SL6, are they in the upstream vendor's distribution? Thanks, Matt They are not in SL6. If they are somewhere else, I don't know. I am impressed by the number of formats TUV has their documents in nowdays. (epub, pdf, html, single-html) Troy -- __ Troy Dawson daw...@fnal.gov (630)840-6468 Fermilab ComputingDivision/SCF/FEF/SLSMS Group __
Virtual floppy as sda on Dell M605 blades
I'm seeing some differences in SCSI drive numbering in SL 6 / RHEL 6, compared to CentOS 5 / RHEL 5. This means that on *some* of my servers, /dev/sdb is actually the first hard disk, which makes kickstarting a bit more annoying. Does anyone know a way to reverse the order or similar easily? A parameter to grub to either remove the virtual floppy or reorder these would be handy, if someone knows of one. Certainly I can disable the virtual floppy in these machines, but I'd rather not do that (it's needed for BIOS updates). In CentOS 5 / RHEL 5, I would see disk configurations such as: scsi 0:0:0:0: CD-ROM Virtual CDROM1.00 PQ: 0 ANSI: 0 CCS scsi 1:0:0:0: Direct-Access Virtual Floppy 1.00 PQ: 0 ANSI: 0 CCS scsi 2:0:0:0: Direct-Access SEAGATE ST973451SS SM04 PQ: 0 ANSI: 5 scsi 2:0:1:0: Direct-Access SEAGATE ST973451SS SM04 PQ: 0 ANSI: 5 scsi 2:1:0:0: Direct-Access Dell VIRTUAL DISK 1028 PQ: 0 ANSI: 5 s sd 0:1:0:0: Attached scsi disk sda sd 2:0:0:0: Attached scsi removable disk sdb Basically, sda was the internal RAID 1 disk array and sdb is the DRAC "virtual floppy". This worked fine, and our scripts knew to expect sda as the first disk. Note that these are identical systems, purchased at the same time and delivered together. On SL 6 / RHEL 6, it reverses the order of sda and sdb: scsi 0:0:0:0: CD-ROM Virtual CDROM1.00 PQ: 0 ANSI: 0 CCS scsi 1:0:0:0: Direct-Access Virtual Floppy 1.00 PQ: 0 ANSI: 0 CCS scsi 2:0:0:0: Direct-Access SEAGATE ST973451SS SM04 PQ: 0 ANSI: 5 scsi 2:0:1:0: Direct-Access SEAGATE ST973451SS SM04 PQ: 0 ANSI: 5 scsi 2:1:0:0: Direct-Access Dell VIRTUAL DISK 1028 PQ: 0 ANSI: 5 sd 2:1:0:0: [sdb] Attached SCSI disk sd 1:0:0:0: [sda] Attached SCSI removable disk (sdb becomes 1:0:0:0, sdb becomes 2:0:0:0) -- *Joel Maslak *Director, Information Technology | Local Matters Inc. *Office:* 303.285.3533 *Email:* jmas...@localmatters.com | *Web:* http://www.localmatters.com *Blog:* http://www.localmatters.com/blog |*Twitter:* @matterslocal Join the conversation: Insights on local search, online advertising and more at http://www.localmatters.com/blog
Re: why does 32-bit SL6 have a loadable module for 64-bit btrfs?
On Thu, Mar 17, 2011 at 8:49 AM, Lamar Owen wrote: > I don't see a mention of btrfs in Red Hat's release notes. Looks like it is mentioned only in the Installation guide and Technical Notes: http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Installation_Guide/Adding_Partitions-x86.html http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Technical_Notes/storage.html > Ok, so looking in the spec file for SL6/RHEL6: > %changelog > * Mon Jun 7 2010 Josef Bacik 0.19-11 > - fix btrfs-progs so it only buils on x86_64, Resolves: rhbz#596690 > > Hmm, let's see: > https://bugzilla.redhat.com/show_bug.cgi?id=596690 > Title: missing package btrfs-progs for i686 > "BTRFS is going to be Tech Preview only for x86_64, you will not be able to > use it on any other architecture." > > Doesn't say why. Indeed. Akemi
Re: why does 32-bit SL6 have a loadable module for 64-bit btrfs?
[Going back on-list, as I originally forgot to reply-all, and this might interest others.] On Thursday, March 17, 2011 08:56:45 am you wrote: > On Thu, 17 Mar 2011, Lamar Owen wrote: > > Well, this is one that, due to the new kernel source packaging, > > you'd have to ask upstream, since SL's kernel is a direct rebuild. > i suspected as much, but am i at least sane to think that this is a > strange combination of packaging? Yes, you're quite sane, assuming that btrfs can't possibly be supported by a 32-bit kernel. After all, a 32-bit kernel can support (not well, but that's another matter) an XFS filesystem up to 16TB of occupied data; I got bit by that, with a 20TB LVM logical volume formatted XFS, with a 32-bit kernel. When the amount of data on that filesystem went above 16TB (which it did), the kernel lost its ability to mount that filesystem. MD5 sum checks on the files in that filesystem, once I restored access to it by installing a 64-bit CentOS, passed and so I knew no data was corrupted. And, in fact, googling around I find in https://bugs.launchpad.net/ubuntu/+source/dpkg/+bug/607632 that at least on Ubuntu a 32-bit kernel can do btrfs. I don't see a mention of btrfs in Red Hat's release notes. It's listed as experimental in the Fedora documentation from Fedora 11; just checking now on my Fedora 14 32-bit box, I see: [root@localhost ~]# yum list|grep btrfs btrfs-progs.i6860.19-12.fc14 fedora So F14 has 32-bit btrfs-progs. Ok, so looking in the spec file for SL6/RHEL6: %changelog * Mon Jun 7 2010 Josef Bacik 0.19-11 - fix btrfs-progs so it only buils on x86_64, Resolves: rhbz#596690 Hmm, let's see: https://bugzilla.redhat.com/show_bug.cgi?id=596690 Title: missing package btrfs-progs for i686 "BTRFS is going to be Tech Preview only for x86_64, you will not be able to use it on any other architecture." Doesn't say why.
Installing upstream providers documentation locally
Hello, Are there RPM packages available that contain the upstream vendor's manuals for SL6 for location installation? If there aren't in SL6, are they in the upstream vendor's distribution? Thanks, Matt
why does 32-bit SL6 have a loadable module for 64-bit btrfs?
still teaching my class on RH sys admin using SL6 and, spur of the moment, decided to show students how to format and mount a btrfs filesystem, only to discover that the 32-bit version of SL6 on their student systems couldn't find the btrfs-progs package, because (of course) btrfs is a 64-bit filesystem. but what surprised me was that their 32-bit installs *did* have the loadable module btrfs.ko, which i find odd. what's the point of a loadable module for btrfs when the system has no corresponding userspace utilities? rday -- Robert P. J. Day Waterloo, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday
Re: Persistent Data in SL LiveDVD on USB
Hi William On 03/17/2011 06:15 AM, William Shu wrote: Thank you very much Urs. Below are the requested outputs: (A) for losetup; and (B) for dracut. It seems the overlay is not being found! On a related matter, you say livecd-tools and liveusb-creator are part of the live iso's, but I had to "yum install" them before I could use them in making the USB! Thanks for the debug info. You are right. liveusb-creator is not part of Live iso's. But livecd-tools and therefore livecd-iso-to-disk should be installed. However, doing "yum update livecd-tools" is always a good idea. Yes, the overlay is not found in your case: dracut: + mkdir /overlayfs dracut: + mount -n -t auto UUID=4C04-9372 /overlayfs dracut: + [ -f /overlayfs/LiveOS/overlay--4C04-9372 -a -w /overlayfs/LiveOS/overlay--4C04-9372 ] dracut: + umount -l /overlayfs dracut: + [ -z ] dracut: + [ -n UUID=4C04-9372 -a -n /LiveOS/overlay--4C04-9372 ] dracut: + warn Unable to find persistent overlay; using temporary Can you quickly check, if the overlay file is on your Live USB drive and if it is writable (w)? In your case the overlay file should be /LiveOS/overlay--4C04-9372 You might want to reproduce the mounting of your USB stick (as done be dracut) on a SL6 system. Plugin the stick. If it gets auto-mounted, un-mount it. As root try mkdir /overlayfs mount -n -t auto UUID=4C04-9372 /overlayfs [ -f /overlayfs/LiveOS/overlay--4C04-9372 -a -w /overlayfs/LiveOS/overlay--4C04-9372 ] && echo ok Cheers, Urs
Re: No success installing ATI Radeon HD5970 driver
Hi Phil- Very rewarding, if not a bit confusing, starting from scratch with the "SL6 Live" installation and THEN making the leap to install the proprietary ATI (release 02/15/2011) drivers worked. In fact, the SL6 Live appeared (literally) to recognize the graphics subsystem in that the installation feedback stream was at a font size (and type?!?) which was readable (if one can speed read). My objective was not to have proprietary ATI control, but it is present and the performance is what would be expected with this display driver. It was almost perfectly smooth. After most initial prelim installation of system updates and such, graphics failed. But after the delightful success of the initial performance, a quick re-install of ATI things solved the problem(s). I should add that while I was very motivated to get maximum performance (data visualization, not games), the "basic" display driver components which were packaged with SL DVD LIVE proper recognized not only the display card but the monitor model. Thus far keeping fingers crossed. I don't know if I can offer further help others to solve this rather hideous problem(s), but I will endeavor to keep technical information forthcoming. Best regards, Wil On Wed, Mar 16, 2011 at 1:54 PM, Phil Perry wrote: > On 16/03/11 20:02, Wil Irwin wrote: > >> Hi Phil- >> >> I VERY much appreciate your suggestion and help. Sadly, these repo options >> didn't solve my problem. >> >> > Hmm :-( > > > "Everything" installed correctly (i.e., without error and a clean install >> report). However, I was unable to make any changes using the SL default >> 'display' GUI. >> >> I noted that elsewhere in the repo documentation (which I hastily ignored >> due to the excitement over your solution), the HD 5970 series was not >> included in the list of supported devices. >> >> > I'm really unsure which models are supported by which driver - I can't seem > to find this information in the ATI documentation. The list of supported > devices in the elrepo.org documentation is for the older legacy driver, > not the current release. > > All I can tell you is that when I go to the ATI driver download page, and > enter your device, it says the current (11.2) driver supports your card. I > have no idea when support was added. Most documentation only states that > current cards are supported by the current driver. > > > Am I missing something completely? I do have experience with Linux >> installations (not an expert by any means). And, specifically, have fought >> with display adaptor installations endlessly. Probably one of the most >> frustrating aspect of getting a new system up and running. >> >> Thanks again for any further guidance you can provide. >> >> > I'm not an ATI user so it's difficult for me to offer much in the way of > informed advice. Do you see any errors in your Xorg logs or anything else > useful to go on? > > Reading back through the thread, about the only thing I can think to check > is regarding your /etc/X11/xorg.conf file. By default, SL6 doesn't have an > xorg.conf file. The elrepo.org packages will create a suitable xorg.conf > file during the installation of the drivers. If you've already created one > then the elrepo.org package will try to use that but if it's broken then > it's not going to work. Thus I would suggest uninstalling the > elrepo.orgpackages, make sure you (backup if necessary, and) delete > /etc/X11/xorg.conf > if it still exists and then reinstall the packages. Just a guess really. > >
