Adventures in GNU/Linux remote installation – or not

I wrote this entry in stages as things unfolded.  This does not end well, I’m afraid.  But I hope it will serve to help others avoid the same plight.  First, some quick background.

In addition to fixing computers by day, I am also by default the family computer tech.  My father is not the most savvy computer user, so the seemingly constant Windows updates and crashes always threw him off.  He also sometimes clicked things he shouldn’t and ended up needing spyware removal and such as well.  Thus began a process where I began weaning him off Windows and preparing him to switch to GNU/Linux, another blog entry for another day.  I installed GNU/Linux for him and the headaches went away.  But we’ve both subsequently moved and now have many miles between us.

Recently he tried to get to his OpenOffice but he said it’s not in his system menu.  I VNC‘d to his system to see what he was talking about and sure enough, his menu is malfunctioning and fails to display any of his applications.  I tried a number of things to remedy this but there appeared to be some file corruption behind it, including some photos he fortunately has backups of.  He was really in need of an update anyway so I decided a fresh install was in order.

But what to do?  He has an older notebook with built-in floppy drive, broadband, and a CD-RW drive he couldn’t find (sigh).  He had no CD-R’s or CD-RW’s on hand anyway, so I thought a CD-less install would be the way to go.

There is an excellent article on this here.  Many thanks to David K Levine for the helpful article.

I based my install on Mr. Levine’s method but with tweaks to account for differences in configuration.  His article covers Fedora/Redhat, but I am using Linux Mint 6 Felicia and my father is on Linux Mint 3.0 Cassandra.  The VNC client on my system is vinagre and the VNC server on his system is vino-server.

You need to be able to start a VNC session from Grub since you won’t be booting from your partition with the root directory / on it.  There is a discussion on starting and stopping the VNC server, called vino-server, from the terminal here but the gist is you can use

gconftool-2 -s -t bool /desktop/gnome/remote_access/enabled true

to start it and

gconftool-2 -s -t bool /desktop/gnome/remote_access/enabled false

to stop it.

Adventures with UNetbootin

I also found out that there is a great free/libre open source software (FLOSS) tool out there for this, called Unetbootin.  This program can be run on GNU/Linux or Windows and makes the process a whole lot easier.  You can point it at an ISO of a liveCD you’ve downloaded, and it will extract fom it the files needed to boot, or it can be set to install any one of a large selection of distributions and it will download the files needed to boot.  Then it will make a “UNetbootin” entry in Grub, which you can then choose to boot to.  Depending on which option you chose it will either mount your ISO or go download one.  Then it will boot the ISO as a virtual CD and you’ll be ready to start your install.

Now, this all sounds wonderful, except for the fact that apparently there is a bug with the installer, Ubiquity, within Ubuntu/Kubuntu and therefore by extension, Linux Mint (since it’s based on Ubuntu), where no partitions are listed in the partition table and the installer cannot continue.  Here’s how it played out for me…

My father’s partition table was roughly as follows:

Filesystem  Size  Type  Mounted on
/dev/sda1     9G  ext3  /
/dev/sda2    19G  ext3  /home
/dev/sda3     2G  swap  swap

Before learning of UNetbootin I had already downloaded the ISO for Linux Mint 6 and tried this process manually.  I put the (already md5sum’ed) ISO on   /dev/sda2 (/home) , extracted and copied the needed boot files (vmlinuz and initrd.gz) to /home/boot .  This way,  /dev/sda2 would be bootable, because once mounted as / , the boot files would be in what now appeared to the system to be /boot .  Just as importantly, the target partition /dev/sda1  (/) would not be in use when trying to do the install.  However, upon booting to the virtual Linux Mint 6 liveCD, my father described video issues with dark columns obscuring much of the screen.  Thinking maybe my manual setup was no good, and forgetting how picky his video card is (it’s an old ATI Rage Mobility M3), I searched the web for answers and found UNetbootin.  Since I already had the ISO there was no point in downloading it again, so I told UNetbootin to use it.  The same video problem persisted, and this is when I realized, well, this is what he’d be seeing if he’d booted to the CD.  ‘Nuther sigh.  So I connected with VNC (tutorial here) and proceeded with the install, figuring I’d install EnvyNG or do any other video card fiddling later.  His display looked fine on my remote access screen, since I’m not using his local screen or video card.

Here is where the Ubiquity bug kicks in.  Everything came to a grinding halt when Ubiquity started the disk partitioner.  No partitions appeared there, and all the buttons were grayed out.  Since at this point you can’t designate a partition to install to, or do anything else for that matter, there is no way to proceed with the installation.  Your only option here is to quit.  This is posted as bug #288675 on, one proposed workaround being to

sudo umount -l -r -f /dev/sda1

(where sda1 was the device mounted as CD-ROM).  This didn’t do much for me except put /dev/sda1 into a state of limbo where it was reported as unmounted, and yet nothing could access it or write to it because it was reported as mounted and ‘busy.’  So, why /dev/sda1 ?  Beats me, since I set everything up on /dev/sda2 including the ISO and boot files.  Now I consider myself a reasonably savvy GNU/Linux user, and granted, I’ve been fighting the flu during all this so I’m not exactly at the top of my game, but this seems like a major flaw.

At any rate, this workaround did in fact get the partition table to display in Ubiquity, but given the limbo status of /dev/sda1 the workaround was useless after all, since at the final stage of the install it failed, unable to write to /dev/sda1 .  Fortunately, it failed out without modifying /boot/grub/menu.lst or the partition table, so I was still able to reboot and try other options.

Being the distro-hopper that I am, and given my impatience for such niggling details that can draw out a 1/2 hour process into a 5-day process, I decided to try openSUSE 11.1 instead.  I had this ISO on hand too, as a side effect of my recent escapades into trying to get my bluetooth headset working with the computer so I could use it for Skype (also another blog post for another day).  I tried this locally first, so as to not pester my father with any more fiddling than necessary.  Again, I set everything up on /dev/sda2 (or so I thought, anyway).  But this wouldn’t even find the ISO despite being in the same directory, consistently giving the error message:

Couldn't find CD image configuration file

After relocating the ISO to a number of locations on /dev/sda1 and /dev/sda2 , including /boot and /home/boot , with no success, I gave up and started searching the web again to see if anyone else encountered this problem… turns out that someone has .  As far as I can see on the openSUSE website, there is a manual method described here starting with the section titled “Installing from data saved on your local machine” which I tried unsuccessfully with several variations, and a link to an old thread on a U.S. openSUSE forum about using UNetbootin with openSUSE 10.3, to which no one has posted anything since July ’08 and there is no mention of the error I’m encountering.  There is documentation here on making a bootable USB stick, only part of which applies to what I’m doing of course but didn’t get me any further along regardless.  The closest I could find to any definitive answer on this is here, where someone pulled a quote from the aforementioned openSUSE USB stick project stating that

Other than Ubuntu- and Fedora-type systems, the initrd on SUSE-type live CDs is not directly suitable for booting from a USB stick.

All other UNetbootin and openSUSE references I have found were for openSUSE 11.1 RC1, which would seem to imply it worked in RC1 but where is the support for the distribution release?  Apparently you can’t use Unetbootin at all… you must do it manually and combine this process with the process for modifying the initrd file.  Ugh!

Frustrated, I returned to attempting the Linux Mint install, and, unable to get it to install with manual partition settings, I thought maybe it would cooperate if I let it partition the hard drive the way it wants to.  So I tried this and the setup still failed.  Only this time, it wrote to the partition table before failing.  So there I was left with all partitions wiped blank, no files installed on them, who knows what it did to the Grub menu, and all partitions ‘busy’ but unmountable so that I couldn’t at least copy vmlinuz and initrd.gz onto them to make them bootable again.  I had no way of accessing anything without rebooting, yet I knew there was nothing to boot to once I did.  Talk about being left high and dry!!!  I consider this a MAJOR failing of Ubuntu.  Shouldn’t it be checking and ensuring that it can do what it needs to do, before wiping all the partitions and leaving the user with an inoperable system??

Next I was going to try UNetbootin’s net install option, which may or may not have resolved the above issues, but thanks to Ubiquity I was dead in the water.  So I didn’t get to find out how well that works.

Fortunately, it just so happened that my son (another distro-hopper) would be visiting my father soon.  I resorted to bugging him to sacrifice some of their visiting time to use one of his liveCD’s to get him going again…  something I was desperately trying to avoid, but at this point there wasn’t much choice.  He helped Dad find the errant CD-RW drive and installed Mint 5 for him (that’s what he had on hand).  It was only dumb luck that my son was in the right place at the right time, since he lives thousands of miles from my father too.  Thank goodness, all is well now.  But all of this should have been avoidable.

Honestly!  Doesn’t anything just work??  And if I can’t install Ubuntu, Kubuntu, Mint, or openSUSE this way, that really bites into my choices of distros simple enough and polished enough so it won’t drive my father crazy trying to learn them.  It’s just this kind of irritating quirk that goes to show why GNU/Linux is still not ready for mainstream use.  Mind you, I haven’t changed my position that FLOSS is the best way to go overall for a number of good reasons.  But whether you choose GNU/Linux, Mac, or Windows, there are serious enough drawbacks to each that I don’t consider any of them to be what the end user or administrator really wants.  None of the above.  😦


3 thoughts on “Adventures in GNU/Linux remote installation – or not

  1. Pingback: Install GNU/Linux without a CD « g33kgrrl’s garage

  2. Pingback: Install GNU/Linux without a CD – part 1 « g33kgrrl’s garage

  3. Pingback: Install GNU + Linux without a CD – using your internal hard drive « g33kgrrl’s garage

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s