Customizing Ubuntu

Posted by Herschel_Cohen on Mar 31, 2006 10:37 AM EDT; By Herschel Cohen
Mail this story
Print this story

Getting Ubuntu Back The first of a series that begins with the recovery methods employed to revise grub to show and boot Ubuntu Breezy that resided on a second disc.

Getting Ubuntu Back


The problem I was facing was covered in the initial article that announced this series and this was identified as the first goal: Recovery of an Ubuntu Installation. At the end of the aforementioned item it was already known that we were going to have to learn just enough about Grub to revive the invisible, but known to be present Breezy installation. [Note, this begins with the assumption that you had Ubuntu installed, hence, grub exists. If your situation is even more complex, read to see what might help you, however, I doubt the solution for your problems will be found here.]

Grubbing around:

This tutorial, if it may be called such, does not have general applicability due to having a double disc system with two different Linux distributions installed on each. Moreover, both the problem and the solution were somewhat dependent upon this hardware configuration. Nonetheless, some tricks might still be learned such as the ability to access other local systems when the second is not actively running. There are a few other caveats, which the reader should be advised. When I did the work that I will attempt to describe below I kept nearly no notes, because I had no idea that I would later write up my experiences. Moreover, I had some previous, successful experience revising grub on a single disc system, hence, I was not completely green. Furthermore, I have no other explanation other than my propensity to rush towards a "working" solution in a retarded, somewhat bumbling fashion for the relative ease this problem was solved. Otherwise, how else, can I explain my complete ignorance of nearly every topic in the Grub manual.

Let's start with the"> Grub manual, where we will move immediately to Chapter or Section 4 "Booting". Actually, the system memory seems to indicate I probably jumped immediately to section 4.1 "How to boot operating systems" and from there to I see I looked at general Boot Methods link, though it eludes me now what if anything I discovered of value. The information I did pick up that was critical was the form of the grub commands scattered in various sections discussing booting methods for various OSs and their peculiarities. Since, we are Linux focused a mild chuckle will do.

So like a good scout be prepared to use this sort of syntax:

     grub> kernel /vmlinuz root=/dev/hda1

But that leaves the unanswered question where. It might be in the manual 1.. However, my speed reading implies missing most of the meaning in the content, hence, I resorted to other means to sort this out.

Finding some Tasty Grubs

Brace yourselves, we are moving towards some command line interface (CLI) to do a bit of searching. On our way the utility of the mount command will also become obvious as an invaluable tool at boot and run time (the latter means what you resort to when you have forgotten to do something in advance).

What's There:

An apology to the readers: though this problem was solved running Debian and accessing Ubuntu file system, the examples below are inverted. Nonetheless, I will explain later why this is not an exercise in confusing the reader.

On Debian you would run the su command separately to become su with root rights. When you are on Ubuntu, if you had not been using sudo recently the next line will have "Password:", which expects the main user's password to allow root rights.

UserName@NameServer:~$ sudo mount
/dev/hdb1 on / type ext3 (rw,errors=remount-ro)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
tmpfs on /dev/shm type tmpfs (rw)
usbfs on /proc/bus/usb type usbfs (rw)
tmpfs on /lib/modules/2.6.12-9-386/volatile type tmpfs (rw,mode=0755)
/dev/hda2 on /mnt/debian/home type ext3 (rw,errors=remount-ro)
tmpfs on /dev type tmpfs (rw,size=10M,mode=0755)

The above listed file systems mostly are started mounted upon boot and are in your /etc/fstab file that uses the mount command with a differing syntax. If you look at the next to the last line you could guess that I had altered that file to have the Debian /home directory ready available. However, for our current needs it would have been better to have mounted the root "/" file system in the first partition on my first disc 2.. In essence, we are missing the file system that would contain grub, hence, we have to mount it on the fly. So here's the syntax: mount [-t file system type] some-device some-where so we use:

UserName@NameServer:~$ sudo mount -t /dev/hda1 /mnt/debian/

Where is it Hiding?:

Let's find where grub is hiding on the Debian side, because that's will have the file we need to revise:

UserName@NameServer:~$ sudo find /mnt/debian/ -name grub -print

Now let's use unfailing logic to close in on the proper locations. We need not look at the first: we did not even pay much attention to the manual so who needs docs? Libraries - same only tools needed by the main application and sbin is really supposed to be for the system's person. Let's look at essentially is the /boot/grub directory 3.:

UserName@NameServer:~$ ls -l /mnt/debian/boot/grub
total 196
-rw-r--r-- 1 root root 30 2005-10-13 11:38
-rw-r--r-- 1 root root 7744 2005-10-13 11:38 e2fs_stage1_5
-rw-r--r-- 1 root root 7504 2005-10-13 11:38 fat_stage1_5
-rw-r--r-- 1 root root 8320 2005-10-13 11:38 jfs_stage1_5
-rw-r--r-- 1 root root 4818 2006-03-15 10:13 menu.lst
-rw-r--r-- 1 root root 4818 2006-03-15 10:13 menu.lst~
-rw-r--r-- 1 root root 6976 2005-10-13 11:38 minix_stage1_5
-rw-r--r-- 1 root root 9216 2005-10-13 11:38 reiserfs_stage1_5
-rw-r--r-- 1 root root 512 2005-10-13 11:38 stage1
-rw-r--r-- 1 root root 108104 2005-10-13 11:38 stage2
-rw-r--r-- 1 root root 9256 2005-10-13 11:38 xfs_stage1_5

Note to the reader (you mean there is more than one?):

Ubuntu does not come with either version of emacs installed, indeed it will be one of the customizations I will cover later. While I had one or both already available on Debian and I used emacs for my changes, use whatever text editor you a comfortable with, however, if you are not extremely cautious stay away from a word processing program. This file must remain a strictly text file in content.

Making the Changes:

I am fairly certain I looked at one file prior to opening the menu.lst, which is the file where the changes need to be made.

UserName@NameServer:~$ sudo emacs /boot/grub/menu.lst

which looks something like this on the Ubuntu side:

title Ubuntu, kernel 2.6.12-9-386
root (hd1,0)
kernel /boot/vmlinuz-2.6.12-9-386 root=/dev/hdb1 ro quiet splash
initrd /boot/initrd.img-2.6.12-9-386

title Ubuntu, kernel 2.6.12-9-386 (recovery mode)
root (hd1,0)
kernel /boot/vmlinuz-2.6.12-9-386 root=/dev/hdb1 ro single
initrd /boot/initrd.img-2.6.12-9-386

There is a lot more, but this happened to match the Ubuntu update, however, there is much more that will do you little harm reading. The one on the Debian side contained only booting instructions for itself. I simply copied the above, with the addition of a test option and pasted this into a writable copy on the Debian side. Rebooted and I had Ubuntu back running, which became my current desktop. So why are the above samples mainly showing from the Ubuntu side? About a couple of weeks ago Ubuntu had an upgrade that I noticed included a new kernel. However, the first bootup afterwards showed no sign of its presence, hence, the mounting of the Debian file system was necessary as shown. Moreover, the examination of the grub menu.lst showed that it had been changed to include the more recent kernel. Therefore, I performed the same operation a second time and I now boot from the newer Ubuntu kernel.


We are done, the first problem is solved now the real customization of the Ubuntu desktop may begin. The next problem for me was bringing my email application and all the email I stored to the Ubuntu side. If this does not interest you, skip it, but later additions should be read just for the laugh content. My professor used to maintain the experts in the field made all the mistakes, hence, they knew it deeply. You might use my predilection for bungling at least on the first try to make you errors vicariously. The sad news is you will not really be expert, but you will be forewarned of many of the locations where failures lurk.

If some consider some of the CLI overly detailed, the same techniques are used repeatedly to solve differing problems.


To some extent I can be accused of presenting too much and too little CLI syntax and results both having some validity. Moreover, it is my intention to remove some of the mystery from this approach. Many people, such as myself tend to understand incrementally. That is, while I can perform tasks I might not fully comprehend the full power of the tool that I am employing. Nonetheless, while lacking full or even partial insight I can still solve the problem at hand. Hence, I would like to introduce a few tools and methods you, the reader, might use to experiment. Let's begin with your command history:

UserName@NameServer:~$ history > /hist-

where the arrow head to the right means write into file located along this path in file (example) hist-2006-03-30-13:54:17, which created a file beginning with command 2 running up to the latest history command that generated this file by executing the command above. So the history command can be your friend to learn what you tried previously.

497 sudo mount
498 history
499 mount --help
500 emacs /boot/grub/menu.lst
501 history > ~/Documents/LXer/Articles/Techniques/Customization/Ubuntu/Grub/hist-2006-03-30-13:54:56

If you happened to run the command as I did as number 498 the output would quickly spew out multiple screens of content. Moreover, if you used your scroll wheel to go back you could be surprised to hit a hard end due to exceeding the memory set in your terminal window. The setting of bash history to 500 can be altered to a larger or lesser limit.

For those interested in doing some organized experimentation create a file, which has the command you intend to run (save the file contents at each step) paste a copy of the command into the command prompt in a terminal. Afterwards copy the results into the file (might wish to time stamp) and save the file. Repeat the next command and repeat the process. If you encounter problems you have more than a history of the commands run. Moreover, being able to show the command sequence and results will enable someone to more ready assess your problem and suggest a solution. [Do not paste the entire file, unless asked, focus upon where the problem hit and try to give the command history and output in that area, again when asked to do so.] If problems are encountered, I would suggest a post at perhaps [registration required], where when you post be descriptive of your problem. The Ubuntu site should be another location you could pose questions. If you opt for a Ubuntu chat site, again more than "Help!" should be posted, however, many chats have a facility to show only those that ask the large set of detail text you have in hand. Be warned, if you spew this out directly into the chat stream you could be banned. Another hint, ask your question and if it is met by silence it means that no one reading the post had enough confidence to believe they could offer constructive help.

I will end with a word about my point made earlier that positive results can be obtained without being a guru: while I have used the command diff -c file1 file2 many times it was only today that I read what it truly was executing. Moreover, I understood it was the command I needed to examine changes in files to decide which would be the better (or what parts of each) should be checked into the version control system. Furthermore, the point was made how the generated results both helped and hindered comprehension: the lengthened format located the proper location in the code, but being longer made it more difficult to read.

A final word of warning, if you see some smart ass give you the "RTFM" do not be overly impressed by the posturing, because the advice is inherently flawed. There is no single manual, the "T" is for THE. They might mean in their confused minds HowTos, FAQ, man, info where if you had not been a Unix student can be difficult to comprehend. Unix is an invention of humans, perhaps large, unwieldy and certainly with a myriad of contradictory manifestations it is much simpler than Nature. Many of these individuals know much less than they even dare dream. Ubuntu is friendly place, learn at your own speed. See you soon?



1. Yes, it's there - read section 5. But that's the sissy's way, we're hard types that use logic, then panic as we experiment with different CLI commands until we trip across the right set of changes. Now I ask you, who is more likely to find their way back when we have both forgotten the contents of that manual entry?

2. Had I mounted the root system, it was my experience that the /home directory with all the user files were accessible even though they resided on another partition.

3. Lucky guess.

» Read more about: Story Type: LXer Features, Tutorial; Groups: Community, Debian, Ubuntu

« Return to the newswire homepage

This topic does not have any threads posted yet!

You cannot post until you login.