Friday, 6 December 2013

LXFDVD120 - On the hunt for LXF magazine's DVD

Will the Internet see me through in my mini-quest to find a file?  I'm looking for an ISO image for a certain issue of Linux Format Magazine (LXF).  The original site doesn't have it, and the rest of the Internet appears to be devoid of any sign that this file still exists.

I first got to looking for this file when I started collecting all the DVD's from the LXF site.  They have torrents of most of their recent DVD's, but the one for issue #120 is missing a link for downloading that particular DVD

In January 2013, I fired off an email to their support address, and I sent another one almost a year later.  In the meantime, I have taken a peek into the Internet to see if something showed up.

The main reason I wanted to have this DVD is because I love the 9.04 release of Ubuntu - the Jaunty Jackalope, and I want to see what LXF has done to customize it in this DVD.  It isn't even a good reason really, but I still went after it.

There are some copies available on archive.org.  They have a collection of the LXF DVDs, some much older then my collection of LXF DVDs needs to satisfy my need for relative completeness.  However it is user-maintaned and nobody has uploaded a copy of DVD 120.

Maybe somebody still has the hardcopy DVD - for heaven's sake, it's only 4 years old, this isn't an archeological project here!  There are some "back issues" on sale on ebay, and even amazon offer's a year's subscription to the current version.  Linuxformat.ru has a lot of older issues translated into Russian, available for subscribers, but no DVD's come with those. 

There was  an interesting site that had a listing of all publications by Future Publishing, ltd, which showed the exact DVD I am in search of:
http://www.nsrl.nist.gov/RDS/rds_2.42/ProdList.txt
Future Publishing	LXFDVD120	July 2009

I almost want to contact the company to find out if they have the hardcopy DVD somewhere, but it looks like it is more of a record then an inventory.

Well until it shows up on a torrent site, or somebody uploads theirs to archive.org, I'll just have to leave the Internet to work away steadily, perhaps turning up exactly what I needed in time.  I'll likely forget about the custom jaunty on LXFDVD120 for the time being, but eventually I will revisit this hunt, and I will be eager to try it once I get it.

Friday, 4 October 2013

Ubuntu KVM: virt-manager fails to connect to remote system by default, the fixes:

Two problems:

1. The Ubuntu KVM community wiki doesn't say fuck-all about connecting remotely.  It assumes the user is running it all on their local system.
 
2. The error message gives advice that could mislead the user to install crap on the client side that they do not need, but in either case, has nothing to do with the problem.  The "Details" text is so generic and unhelpful (you will get the same error message when the network is unavailable) that it leaves the user searching endlessly for the right bug to mach the problem.

The (useless and misleading) Error Message Advice

Unable to open a connection to the libvirt management daemon.

Verify that:
 - The 'libvirt-bin' package is installed
 - The 'libvirtd' daemon has been started
 - That you have access to '/var/run/libvirt/libvirt-sock'

The (Unhelpful) Details Text

Unable to open connection to hypervisor URI ...

<class 'libvirt.libvirtError'> virConnectOpenReadOnly() failed
Connection reset by peer
Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/connection.py", line 332, in
_open_thread
    self.vmm = libvirt.openReadOnly(self.uri)
  File "/usr/lib/python2.5/site-packages/libvirt.py", line 144, in
openReadOnly
    if ret is None:raise libvirtError('virConnectOpenReadOnly() failed')
libvirtError: virConnectOpenReadOnly() failed Connection reset by peer

 The Fixes:

(This was done using Ubuntu Hardy (8.04) in virtualbox, but I have seen the same problem with Ubuntu version 12.04, so this seems to apply across many versions of Ubuntu)

So, you installed the KVM packages, or you selected the "Virtualization" option while installing a Ubuntu server, and by default it won't work.  You've played around with the virt-manager interface on your desktop system and that already works, but now you want to manage the server from your desktop.  Here's what is missing and/or hard to find:

1. You must add your user to the libvirtd group in the file /etc/group, on the server.  "user" is the name of your user on your Desktop system, so the names need to match or you'll have to figure out something extra to make it work.

2. To connect succussfully using the ssh method, you must have created a pair of ssh key files (id_rsa, id_rsa.pub) on your Desktop system (using the command ssh-keygen, and NO PASSPHRASE)

Then you would need to copy the .pub file from the Desktop system at /home/<username>/.ssh/id_rsa.pub under a new name as /home/<username>/.ssh/authorized_keys on the server.

virt-manager will not ask you for your password in the normal ssh connection method, it will just fail with the stupid message you see at the top of this page.

Furthermore, if you followed the advice of using "sudo virt-manager" on the client or server as it's first run, it will not be able to start because your home folder will have the config directory ".virt-manager/" owned by root.  In which case, use: 

$ sudo chown -R <user>:<user> /home/<user>/.virt-manager/

From there, you will be able to run the virt-manager without having to be root.



Finally, I just wanted to comment that I originally installed virt-manager on the server, pulling tons of packages into it and essentially installing a whole desktop just to use it.  This way I could get around the problem by connecting with "ssh -X" and remotely using virt-manager.  It was a fucking waste of time.

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?






Thursday, 3 January 2013

Install package trash-cli in Ubuntu hardy

I like being able to do on the command line what I have only done with the Desktop Environment.  One of the things which I thought was un-doable was to use the Desktop Trash can from the command line.  There are two reasons why I wanted to do this: first, so I can undo mistakes.  Second, so I can empty my trash without having to be in a Desktop session.

The package trash-cli is available as far back as Intrepid (Ubuntu 8.10) but was not released for Hardy.  I checked the dependencies listed on the page at
https://launchpad.net/ubuntu/intrepid/i386/trash-cli/0.10.r55-0ubuntu1:

Depends on:

    python (>= 2.3)
    python-support (>= 0.7.1)

Then I compared with my install of hardy on a test machine.  After all updates were applied, the version of python was 2.5 and the package python-support was 0.7.5.

adam@hardy:~$ apt-cache policy python
python:
  Installed: 2.5.2-0ubuntu1
  Candidate: 2.5.2-0ubuntu1
  Version table:
 *** 2.5.2-0ubuntu1 0
        500 http://us.archive.ubuntu.com hardy/main Packages
        100 /var/lib/dpkg/status
adam@hardy:~$ apt-cache policy python-support
python-support:
  Installed: 0.7.5ubuntu1
  Candidate: 0.7.5ubuntu1
  Version table:
 *** 0.7.5ubuntu1 0
        500 http://us.archive.ubuntu.com hardy/main Packages
        100 /var/lib/dpkg/status

So I downloaded the package from the Intrepid page above, and it installed perfectly ok.  I used the command line to install it, but I suppose it would work with the Graphical installer, possibly with a warning message about it not being in the hardy repository.

adam@hardy:~$ sudo dpkg -i  trash-cli_0.10.r55-0ubuntu1_all.deb
...

Looking further, the same version is used across Intrepid, Jaunty, Karmic and Lucid, so it isn't tied to a specific set of dependencies, unlike some other packages.  I'd like to have found it in the hardy-backports repository, but at this point hardy is reaching the end of its support cycle, and only a few people like me are still messing around with it, I think.