This blog is the result of at least two hours of pain and suffering while trying to boot off of an Ubuntu-based CD. If it saves even one person from the same laborious fate, it has served its purpose.
How many times have you attempted to boot from an Ubuntu CD, only to find yourself sitting in front of a very intimidating (initrd) prompt with no clue as to why the system failed to boot or how to fix it? Unfortunately, the causes of this dreaded phenomena are many, which often makes troubleshooting this problem very difficult. I myself have run into this issue on occasion, though up until a couple weeks ago it had never been caused by anything too difficult to fix. Most of the time it was simply a matter of using unsupported hardware. That all changed with my latest install.
Now, before I go any further with this, I should probably note that the distribution I had trouble with was NOT Ubuntu; it was an Ubuntu derivative, Eeebuntu, developed by a third party that is not in any way affiliated with Ubuntu. In fact, I later tried installing from an official Ubuntu CD and it booted just fine!
That being said, it’s quite possible that you have found yourself faced with the (initrd) prompt on at least one occasion. If so, you hopefully figured out what went wrong and were able to fix it. But, what if you’ve exhausted all of your obvious options? It’s quite possible that you’ll ask questions on the Ubuntu forums, only to find that nobody has an answer that solves your problem. That isn’t in any way meant to disparage the Ubuntu community. In fact, I think you’ll find that the forums are very helpful and that the community is very friendly and knowledgeable. Rather, it’s quite possible that, for whatever reason, you’ve run into a problem the community hasn’t yet encountered or been able to solve, which on some rare occasions may even turn out to be a bug. Whatever the reason may be, short of finding another Linux distribution, you may be thinking that all is lost. Fortunately, there’s another way!
When you see the (initrd) prompt, it’s because, for whatever reason, Ubuntu was unable to find or mount the root filesystem. The solution is to manually do the mounting for the Ubuntu CD. Assuming you can get the filesystem mounted, you should have no problem breaking out of what at first glance may have seemed to be a hopeless situation.
Now, you may be tempted to believe that the root filesystem of the Ubuntu CD is the same root filesystem you would see after booting the Ubuntu LiveCD, but that’s actually incorrect. Ubuntu uses a special compressed filesystem called SquashFS. If you mount your Ubuntu LiveCD, you should find it in /path/to/cdrom/casper/filesystem.squashfs. With this information in mind, we can proceed.
Step 1: Manually mount the CD
From the (initrd) prompt, manually enter the following command:
mount /dev/scd0 /cdrom
(scd0 should be replaced by the device name that refers to your optical drive.)
If you can’t find a device name for your optical drive, that may be why the initrd (short for initial RAM disk) failed to mount it. If you’re sure there’s no device in /dev for your optical drive, copy the contents of the Ubuntu disc to an external hard drive or USB thumb drive (either should be recognized immediately by the initrd after being plugged into a USB port.) Mount it instead of the CD to complete this step. To do so, use the command:
mount /dev/your_device /cdrom
(note that the device name usually shows up as sda1, sdb1, sdc1, etc.)
Step 2: Manually mount the root filesystem
Again, from the (initrd) prompt, enter the following command:
mount -o loop /cdrom/casper/filesystem.squashfs /mnt/root
At this point, things may or may not get tricky. Most likely, the command will be successful and you’ll be ready to continue booting the Ubuntu LiveCD. If that’s the case, skip directly to step 4.
Step 3: I can’t mount the root filesystem; HELP!
It’s possible that you’re more than just a little unlucky, and that for some very strange reason that I haven’t yet figured out, you don’t have support for loopback devices. Fear not! You will have some extra work to do, but the following steps should work just fine.
First, you’ll need access to another Linux machine. You’ll also need a spare hard drive or USB thumb drive. Please note that if using a thumb drive, you’ll need one larger than 2GB, as the SquashFS filesystem included on the CD will take up more than 2GB of space when decompressed. Finally, make sure that squashfs support is installed on your system, as it most likely isn’t by default. Depending on your Linux distribution, yo u may or may not have to patch your kernel and compile the squashfs module manually. If you’re using a distribution like Ubuntu, you shouldn’t have to.
Now, mount the block device you’re going to extract the filesystem’s contents to (we’ll refer to it henceforth as /dev/sda1.) We’ll assume for the sake of this tutorial that we’re mounting it to the directory /mnt/tmp. To do so, you would enter the following command:
mount /dev/sda1 /mnt/tmp
Next, we must mount the SquashFS filesystem. Assuming we’re using the mount point /mnt/squashfs, we would do so with the following command:
mount -o loop /path/to/cdrom/casper/filesystem.squashfs /mnt/squashfs
Finally, copy the contents of /mnt/squashfs to /mnt/tmp. Note that simply using the command cp will result in symbolic links being treated as real directories, which is not desirable. Instead, we’ll use tar and pipes. Enter the following commands, in order:
cd /mnt/tmp
tar -jcvp /mnt/squashfs/* | tar -jvxp
When the above commands are completed, enter this one last command:
mv /mnt/tmp/mnt/squashfs/* /mnt/tmp; rm -rf /mnt/tmp/mnt
Now, just unmount the volumes and you’re done!
umount /mnt/tmp
umount /mnt/squashfs
Step 4: Success!
At this point, you’ve succeeded in mounting the root filesystem that, for whatever reason, was unable to be mounted automatically by the LiveCD. Just type the command “exit” from the prompt and watch as Ubuntu continues where it left off. Note that you will no longer have a splash screen during the boot process, so expect to see the output of init for a few seconds as it starts background processes before seeing a graphical login.
Wrapping Things Up
Hopefully, this blog will prove useful to someone. Even if you haven’t run into this issue before, it’s good information to have on hand for the day when that changes. In addition, the techniques outlined in this blog aren’t just useful for getting a cranky LiveCD to behave. If you’re using a device that’s bootable via the BIOS but which isn’t supported by Ubuntu, and you’d rather not take the time to modify the LiveCD to make it work, simply follow the steps above to copy the contents of the CD to another device and manually mount the real root filesystem.
james October 16th, 2008
We at eRacks are designing a new model geared specifically toward the developer, and want to hear from you, the customer, about what you would like to see in the system (please leave detailed comments for this blog post!)
We’ve been batting around a few ideas, both software and hardware related, and would like to share them here for your consideration.
1. IDE, Revision Control System and your Operating System of Choice
Our development model would (of course!) come pre-installed with the best in open source development-related software. Do you have a favorite IDE, or do you prefer to simply invoke your text editor, compiler and makefiles directly? Would you like us to install a revision control system such as CVS, Subversion, Mercurial or Git? What’s your operating system of choice? Are you a fan of Linux, FreeBSD, OpenBSD, NetBSD, OpenSolaris, etc.?
2. What Kind of Developer are you?
While there are usually at least some applications common to most developers, a great deal of the software you’d like to be installed will probably depend significantly on the kind of development you do. Are you a kernel developer? If so, we’ll install the kernel source and headers for you. Are you an applications developer? If so, are there any open source libraries you’d like us to pre-install for you? What about you web developers out there? We could, at your option, install a local web and database server for testing purposes, as well as your scripting engine of choice (PHP, Ruby, Python, Perl, etc.) Do you not fit exactly into any of these categories? Have we missed something? Let us know!
3. Hardware
Do you prefer to develop on a laptop, or do you like to do your programming on a desktop machine? What would you think about having the option of two or more monitors to help you spread out your work, configured to your unique specifications (would you like 2 or more individual displays, or 2 or more monitors tied together into a single virtual display?)
Anything we haven’t mentioned that you’d love to see in a development-specific model? Again, just let us know! Be sure to leave us a comment sharing your thoughts.
james September 18th, 2008
Posted In: Development, New products
Have you ever needed to backup the contents of one or more filesystems to another machine, yet you only had a single hard drive in the machine being backed up and found that you lacked the temporary disk space necessary to create your backup before shuttling it across the network to its final destination?
As an example, when I backup my laptop, I have too many gigabytes of data to realistically store my data on DVD-R’s, and my only option is to create a tarball of the root filesystem and store it on another machine on my network. The problem is that if I try to create a backup of my laptop’s contents, I find that the resulting tarball backup is too large to fit on the hard drive along with all the data.
One solution that I’ve found to this problem is to avoid storing the backup on the source machine altogether. Through stdin and stdout, along with the magic of *NIX pipes, we can stream the data in realtime over to its destination, and only then write it to disk.
Before we begin, it is very important to note that in most situations, you’ll have to boot into another environment and manually mount your partition before proceeding, particularly when dealing with an operating system’s root filesystem. Otherwise, not only will tar choke on certain directories like /proc and /dev, the contents of the disk will also continue to change as the backup is being made, leading to inconsistencies between the data on your filesystem and the data in the backup.
With that in mind, assuming that you have ssh installed and configured correctly on both the source and destination computers, you can create a backup with the following commands (as root):
#cd /path/to/your/mounted/filesystem
#tar -jcvp | ssh username@destination “cat > /path/to/backup.tar.bz2”
If you prefer to use gzip as opposed to bzip2, replace the above tar command with the following:
#tar -zcvp | ssh username@destination “cat > /path/to/backup.tar.gz”
Now, let’s say that you’ve created a new partition and want to restore a previous backup. Again, assuming that ssh is configured properly on the source and the destination machines, and assuming that you’ve mounted your partition, you would recover your backup with the following commands (again, as root):
#cd /path/to/your/mounted/filesystem
#ssh username@destination “cat /path/to/backup.tar.bz2” | tar -jvxp
If the backup is a gzipped archive, then replace the above tar command with the following:
#ssh username@destination “cat /path/to/backup.tar.gz” | tar -zvxp
Note that the user specified by ‘username’ above should have read/write permissions on the directory where the backup is to be stored for this procedure to work.
The astute reader will probably notice the missing -f option, which one usually passes to tar. The reason for this is that it tells tar to write its data to, or read its data from, a file. However, by ommitting it, we tell tar to send its output to stdout, or to receive its data from stdin when reading from an archive, which allows us to make use of pipes. It’s situations like these where the power of *NIX really shines!
james May 28th, 2008
Posted In: Backups
Tags: backup, bzip, bzip2, filesystem, gzip, partition, ssh, zip