Friday 26 July 2013

ATI proprietary driver vs. Ubuntu Hardy (Radeon 9250 128MB)

Approaching with much pessimism, I didn't really expect this to work.  After some struggles with the NVIDIA proprietary driver,  All I wanted to do was find out what would go wrong and why.

My disappointment was mainly in the lack of a solid answer for the problem... On the net, there are a lot of people who all had the same problem with the same exact driver, yet nobody got a straightforward, solid answer.

Here are the steps to reach the same fail message:

[On Ubuntu 8.04.4 desktop]

  • Be in possession of an old ATI card that is in the same time period as the Radeon 9200;
  • Use the ATI site support.amd.com to locate the driver for your card.
  • If the driver is 8.28.8 for Linux x86, download it.  If its a different driver... you probably have a newer series of video cards and this may not apply to you.
  • use $ chmod +x ati-driver-installer-8.28.8.run , to make the file executable.

$ sudo ./ati-driver-installer-8.28.8.run 
Creating directory fglrx-install
Verifying archive integrity... All good.
Uncompressing ATI Proprietary Linux Driver-8.28.8.....................................................................................................................................................................................................................................................................................................................................................................................................................................................................................
-e ==================================================
-e  ATI Technologies Linux Driver Installer/Packager
-e ==================================================
Detected configuration:
Architecture: i686 (32-bit)
X Server: unable to detect
Removing temporary directory: fglrx-install
So that ended that.  Searching around, near and far, I was not able to find an answer that was concrete.  I'll make an educated guess, and provide the information I could gather myself:

Going back to the starting point:  On the AMD site, there is a download which includes  "Automated installer and Display Drivers for XFree86 4.3 and X.Org 6.7, 6.8, 6.9, 7.0, 7.1".

The NVIDIA 71xxxx driver would not work with Xorg versions newer then a certain version, so I looked at the version on my Hardy system to find out if this was the case:

$ Xorg -version
...
X.Org X Server 1.4.0.90
...


Ok, so huh?  This AMD driver was released in 2006 so how is their Xorg version so much higher then Ubuntu from 2008?  According to the Distrowatch page for Ubuntu, "Breezy" released in 2005 had Xorg version 6.8.2, but next year, the "Dapper" release in 2006 had Xorg version 1.0.2.  So this must mean the version numbering dropped back to 1, in 2006.  Ultimately, this version is newer then the ones mentioned by the ATI proprietary download site.

So my X Server might not be detected because it confuses the ATI installer, with its version being 1.x, when the installer is looking for 6.x or 7.x.
 
But again, my big concern is why nobody is saying this clearly. 

Interestingly, the command "apt-cache search fglrx" reveals a certain xorg-driver-fglrx package which might have the same binary.  If this has been fixed to work in the newer X.org X Server, that definitely means that somebody figured out the problem with the binary on the ATI site, and fixed it, but didn't explain what was broken.

My conclusion:  the experts were so exasperated with the problem -- for which the answer must have been so obvious to them that they forgot to tell us newbies what it was.

Sunday 7 July 2013

Fedora 18 And Unetbootin And USB Sticks

I hadn't decided whether to use Ubuntu or Fedora on my new dual-core netbook.  I am very familiar with Ubuntu, I love Xubuntu, but I also want to dive into unfamiliar waters as well.  I am looking into the Red Hat side of the Linux family tree, and the three big ones that caught my eye were CentOS, Fedora and Mageia.  I would prefer to get into Mageia just for being entirely a community project, but it uses urpmi package manager, unique to the Mandrake/Mandriva family.  I decided to use Fedora or CentOS to get familiar with the yum package management software, and come back to Mageia after I was done.

A basic factor in my decision is 'will it even work on this PC'.  If Fedora isn't compatible with the hardware, well then my choice is already made. No point in wasting time deciding until I know it will work, whichever one I pick.

So I used Unetbootin v.585(Linux) to put the Fedora 18 64bit DVD into action on an 8GB USB stick.  Having disabled the UEFI boot system on the netbook, switching back to Legacy BIOS mode, I was almost ready, but discovered that the USB stick was formatted as a floppy, not as a hard disk (the BIOS boot order gave it away, listing it under "USB FDD" instead of "USB HDD" when plugged-in).  Viewing the drive with fdisk gave garbled partition info - there was no partition table because floppy disks don't use them.  Had to use fdisk to make a new MSDOS partition so it would be treated like a hard disk.  Then I formatted with mkdosfs, re-ran Unetbootin, and finally I was ready to boot from the USB stick.

So the test had begun.  Things were going fine until these two errors:

Warning: Could not boot.
Warning: /dev/root does not exist.

So, I tried to manually link my USB stick to /dev/root with

#ln -s /dev/sdb1 /dev/root
#exit

But the error was still there!  Now it says a different warning about not being able to mount the filesystem.

More googling, and it seems I need to set the LABEL= value in the boot menu, at the moment the machine first turns on, using the Tab key to edit the parameter, from "LABEL=Fedora\x2018\x20DVD"  to "LABEL=LIVE".  Ok, did that, but still no luck.  It is having a rough time finding /dev/root.

Somebody somewhere said to look in /dev/disk/by-label once dropped to the emergency shell (# ls -s /dev/disk/by-label).  There were names of the hard drive partitions, but "LIVE" wasn't there.  Ok, well Unetbootin never labelled the filesystem in the USB stick.  So I screwed around and invented my own link, from /dev/sdb1 to /dev/disk/by-label/LIVE.  But still, after typing 'exit' - no luck.

Finally, in frustration, I mounted my USB stick and linked that to /dev/root.
Nope.  Then I found a file: LiveOS/some-squashfs-file inside the USB stick, so I mounted that as a loopback filesystem and linked it.  Again, to no avail.
I explored the USB stick further, hoping to find the thing that Fedora needed to carry on.  Deeper down I found a rootfs.img.  I linked that.  When it still complained about not being about to mount, I mounted rootfs.img and linked that to /dev/root.  I even tried running the init script inside the rootfs.img, since I was getting desparate to move on past this roadblock.  Nothing worked.

This is the kind of madness that I was willing to go through, because I'm experienced, I like using the command line and I'm confident with it. My persistence to solve these maddening problems is strong, probably because I'm a bit mad, to be fair.  Few computer users would have the patience to fiddle with this scary-looking black screen, or even to know what they needed to do.  And the one thing that's more insane then my failed efforts is the stupidly simple answer...

Fedora 18 installer will no way, no how, boot, unless the filesystem label is set on your USB stick...

So, I took my USB stick back to a working Ubuntu system, plugged it in and typed:
$ sudo dosfslabel /dev/sdb1 LIVE

Then back to the netbook, I powered-on, changed the LABEL= paramenter at the boot menu (Tab key) set it to LABEL=LIVE, started the boot process, and all of a sudden, it boots fine, all the way to the language selection screen, just like that.

Who was the genius behind that catastrophic design?  When trying out unofficial installation methods, such as with the Unetbootin tool and a USB stick, I will expect a chance of a hiccup and I can tolerate the initial boot failure that happened, but if an intermediate user actually does the system a favour at the command line by linking the exact boot device to it's little /dev/root thingy, you'd think it would forget about labels and just use that.  But no, it won't boot without a filesystem label being set.

I think the saying is "You can lead a horse to water..." (link /dev/root) "...but  you can't make him drink." (won't use the device)  Only this isn't a horse, its a cow.  A spherical cow.  And it seems ready to crash on boot for want of a silly filesystem label.

Next thing you know, some future release of the Fedora Installer will only boot on Tuesdays.

Now my rant: this is one more event that highlights an attitude problem in the Fedora community, largely from those in charge of the project.  I foolishly complained in the "Fedora Forums" that the link was not available from the main site, depriving users the chance to find a large knowledge base with helpful staff.  The only service on the FedoraProject site was "askfedora" which is a nice way to ask one-off questions but isn't really useful as a reference site.  After I made my complaint, it was pointed out to me that the Forums are not linked, because they aren't affiliated nor blessed by the Fedora project.  Well I figure that so long as the FedoraProject doesn't have its own forums for user support, they might as well refer users to that site, but apparently thats against their corporate agenda.  Sheesh.

Another thing, you can't visit the Fedora IRC for quick help unless you register your nickname with freenode, something I have no reason to do, as an infrequent user of the service.  I discovered that being unregistered actually gets you get booted from their chatroom, to another room called 'unregistered' or some such.  "Fine!", I thought, as I sat there, I can at least talk to those few other unregistered people.  Nope, I was silenced, and a moment later, auto-banned from the 'unregistered' channel.
I don't know what kind of problems they had in #fedora to cause this rather annoying restriction, but the Ubuntu IRC channel is open, and I don't see them having any major problems there.  In fact, they even tolerated me dropping into the #ubuntu IRC channel to briefly vent my frustration about the Fedora IRC restrictiveness.  So there.  The Ubuntu IRC doesn't need to lock down their channel, they survive even with people like me who dropped in to complain about off-topic subjects like the Fedora IRC...  and might even take the time to answer!

[I wrote that the Fedora IRC wasn't friendly because of blocking and auto-banning, and the answer I got from #ubuntu was that "Indiana Jones isn't very friendly either."]
It's too bad.  It started out really nice with Fedora, I got a DVD mailed to me by a volunteer on my request, so I could start trying it out.  But my relationship with Fedora is already turning sour, and I've only just begun to explore their OS.  Perhaps I'll just use CentOS to get familiar with that variety, and move onto Mageia for a more detailed look at RPM-based distros.

One final word.  Back in 2009 when I was still a newbie, I was fdisk'ing a hard drive, and I forgot to change the partition ID to 82(Linux).  I don't remember which distro it was.  But mkfs created a linux partition inside this partition anyway (which was still using an ID for FAT32).  And you know what? That sucker booted from the partition, because it contained a valid filesystem.  Thats a heck of a lot more significant then some partition ID that doesn't impact the software or filesystem.  And remember the way you don't need to name files .jpg, .gif or .txt under GNU/Linux, because it just looks inside the file to see what it is, rather then stubbornly requiring a name extension.  And this is the OS that I have come to know and love.  An OS that is geared around predictability, stability and common sense.  I am certain that many other users expect the same.  They,  like me, would not think highly of an installer that decides to crash because of a filesystem label.

Take a Ubuntu ISO Image, put it on a USB stick labelled "Sammy."  Do you think it's going to crash?