How to use Grub2 to boot Linux manually
Edite 28/11/2011 - Grub2 has been under some intense development resulting some commands structures altered slightly. In an error is encountered using the commands listed here please check with the latest documentation by typing "man" in front of the command that you want to use. Also the best information is the GNU/Grub2 Manual V 1.99.
I notice Grub2 has been shipped by the latest Ubuntu so I have a played with it and reported the following.
For those who are already aware Grub has an unique feature that you can communicate with it before an operating system is booted. The instruction to talk to Grub is given in any text Grub menu screen by pressing the "c" key and return. Then you will be greeted by a command prompt known as Grub prompt. In this mode Grub has an command interpretor very much like Dos or any mini operating system. Both Grub1 and Grub2 have such capability. The biggest secret in Linux I have found is that there in no installed operating system in a PC Grub cannot boot in a Grub prompt. A little bit of knowledge of it will enable you to kiss all your booting problems good bye.
There are significant differences between Grub1 (version 0.9x) and Grub2 (version 1.x) so the best way is to treat them as two different boot loaders. A bit of mixing is possible as described below.
For direct booting Grub2 can boot an installed Linux packaged with Grub1 but not necessarily the other way round. This is because a distro shipped with Grub2 may have Ext4 filing system installed by default. Grub1 cannot read a Ext4 filing system.
For indirect booting both Grub1 and Grub2 can boot each other by chainloading as the filing system is not involved. Indeed this is why Grub1 not able to read a NTFS partition but still manages to boot the boot loader inside of any MS Windows, regardless it is an old WIn2k or the Win7 that is in a trial stage.
How to get hold of Grub2
May be there is a better way but I used a Grub2 floppy or a Grub2 CD. Each can only be made from a Live CD that has been shipped with Grub2, like Ubuntu 9.10. All you need to do is to boot up such a Linux Live CD, get into a root terminal, put a floppy into the drive and issue the following commands (originated from FranklinPiat/grub-mkrescue.manpage - GRUB Wiki)
Basically the grub-mkrescue copies Grub2 image into the specified file and you use the dd command to write the same onto a floppy. For a bootable Grub2 CD the instructions are
grub-mkrescue --image-type=floppy /tmp/grub-rescue.flp
dd if=/tmp/grub-rescue.flp of=/dev/fd0 bs=1024
You can drop both floppy (any spare used one and no need to format) and a blank CD to do them simultaneously. Bootable Grub floppy and Grub CD are the most lethal weapons in the booting business.
grub-mkrescue --image-type=cdrom /tmp/grub-rescue.iso
Thereafter either medium boots you to a command prompt in Grub2.
As similar to Grub1 there should be no installed PC system that cannot be booted by a Grub prompt from Grub2. I tried different Linux and MS Windows and can confirm this. This is done by indirect booting using chainloading.
Indirect booting by chainloading
For Grub1 if you want to fire up an OS, which can be any Dos, MS Windows, BSD, Solaris or Linux, installed in the 2nd partition of the 1st disk the Grub Legacy commands will be
For Grub2 the commands are slightly different and the changes are highlighted in red
For some reasons the partition number no longer starts from zero in Grub2. I believe the zero start for disk number in both Grub1 and Grub2 is for compatibility with the MS systems which use the similar numbering arrangement.
Direct booting by naming the kernel and initrd files
Grub1 and Grub2 can boot only OSes they support and since MS Windows are not supported no direct booting is possible.
There are similar small changes in commands between Grub1 and Grub2 here.
Say if I have a Linux in same partition as the above.
In a standard Linux the kernel name always starts with vmlinuz and the initrd file starts with initrd. These files by default are stored in the /boot subdirectory. Both Grub1 and Grub2 can do completion with the tab key so if I type
and follow by the tab key Grub will try to find all the files in /boot subdirectory to match the first "vmli" caharcters. Therefore there is no need to know the kernal and initrd filenames in advance if one knows to use the tab key to complete the command.
Say if my Linux has vmlinuz-2.6.18-6-686 and initrd.img-2.6.18-6-686 in /boot subdirectory one can boot up the Linux with Grub1 commands of
For Grub2 the corresponding commands will be
kernel /boot/vmlinuz-2.6.18-6-686 root=/dev/sda11 ro
Grub2 seems to be able to do away with the "read only" (ro) parameter which is required for Grub1.
linux /boot/vmlinuz-2.6.18-6-686 root=/dev/sda11
The above is just an early report of Grub2 which is beginning to show its face in September 2009. It is still an early stage to see how it performs in practice. The current documentation is still in an appalling state. However for a few hours playing with it Grub2 appears to be reasonably complete. It is about 3 to 4 years overdue.
I found out Grub2's can be restored in its root partition by Grub2 commands identical to Grub1. You need to first fire up the Linux with Grub2 using the direct method, say this is in partition sda16, and issue this command in a root console
Thereafter the Linux in sda16, in Ext4 and has Grub2 can be booted by any version of Grub indirectly. I tried the oldest Grub floppy (Version 0.91) in my collection, using the normal Grub1 commands
Last edited by saikee; 11-28-2011 at 06:35 PM.
Grub2 seems to be able to do away with the "read only" (ro) parameter which is required for Grub1.
Mount the root device read-only on boot.
The default for the kernel is to mount the root device as read-only at boot time. This option ensures that this is the mode the kernel uses. It overrides the rw command-line option, if it had been specified earlier on the boot command line
---from the boot options chapter of the kernel manual
It would seem to be the kernel default behaviour that has changed.
Saikee, I take this opportunity to thank you for all the help I've had from your posts, particularly on booting. I've found multi-booting to be a great way to learn about linux. It also gives a redundancy which makes it hard even for a clown like me to completely break all his systems (at once, that is).
You are welcome.
I think booting is a classic case of what Linux is all about. It only cares about the simplest, quickest and the most efficient way to get us from A to B.
Proprietary systems have a hidden agenda of making things more complicated to protect their own interest/investment which is not always to the end user's benefit. The worst is we don't get told about the inner working and have to remain ignorant of something potentially very simple.
A Linux user who takes time to understand Grub will find it a lot easier to work with MS or others boot loaders.
One thing that 's not clear to me about Grub2 is whether it can be installed on an ext4 filesystem. Fedora 11 comes with ext4 as the default, and asks for a separate ext3 /boot partition. In fact the live CD installer won't let you either install F11 to an ext3 partition, or put the /boot directory on the ext4 / partition. And Fedora 11 comes with Grub 0.97.
The only reference I could find on the Grub2 site says very vaguely that Grub2 "supports" the ext4 FS. This may mean no more than that it will boot it from an ext3 partition like Grub 0.97.
If that is the case, we're condemned to either have a separate /boot partition for each ext4 distro, which will get messier and messier as the number of ext4 distros increases, or to use a common /boot partition for all of them. If we do the latter, there will be problems with automatic updating.
Do you know if Grub2 is or will be able to be installed on an ext4 partition?
I confirm that Grub2 has no problem to be installed inside Ext4 partition. That is where it resides in my Ubuntu 9.10 which like all my distros was installed in a single partition.
Let me jump in and ask a question that might or might not be related to this topic. I apologizes if not. I've read this post and I don't think it is related to my problem. Maybe???
I'm using Debian Squeeze and have update when called for. I have received a notice that my Squeeze system has 'chain loaded' Grub 2.
If everything works well I'm to "upgrade-from- grub-legacy' as root. I've don't this on a laptop and my desktop. I end up with 'Error 15' and my OS is useless. I've reinstall Squeeze on both machines and just left them alone on boot up. No upgrade to Grub 2.
My question: will there be a time when all this will be fixed? That is to say, during an upgrade this problem will be address? Or will I have to jump through several hoops to get it fixed?
At the moment, I just let the OS - Debian Squeeze - boot up on it's own. And I don't have a problem if I do it this way. I have refrained from going to Root and inputting the command suggested to upgrade to Grub 2.
I guess I'm getting too lazy or to used to the easy way of addressing issues that Debian is so famous for and need some input on this problem.
I believe you need to accept an upgrade in order to get Grub2 installed into Debian, unless something new has come out.
The Grub2 can be looked upon as another version of Grub except it is not compatible with Grub legacy but a small number of commands are still usable in both versions.
I think the momentum behind using Grub2 is probably due to the Ext4 filing system which can be read by Grub2 but not legacy Grub unless it has been doctored. The only legacy Grub that can handled Ext4 is the one in Ubuntu 9.04. There may be more but I use this one mainly.
Grub2 isn't difficult to use even though I haven't used it in full anger yet. I say this because I can use it to boot any system without a boot loader installed and that is not much different from legacy Grub.
If you have Grub2 installed then press the "c" key will get a Grub2 prompt. Lets say there is an unbootable Linux in sda3 or known to Grub2 as (hd0,3) (Legacy Grub calls it (hd0,2), so watch out).
The system can be boot by telling Grub2 the name of the root partition and then type the following lines
Since the kernel and the ramdisk file are always start with vmlinuz?????? and initrd???????? and stored in /boot directory therefore by using the tap key one can get Grub2 to find files for us.
linux /boot/vml(press the tap key here) ro root=/dev/sda3
initrd /boot/ini(press the tap key here)
The above way is what I do to boot up Linux installed without any boot loader or a defective boot loader.
Legacy Grub can be used in the same way except the command syntax is different in the 1st and 2nd lines.
So in answering your question there is no need to do a fix. There may be a long confusion in the period where distros are forced into Ext4 filing system but I can see some distros may doctor legacy Grub instead of siding with Grub2t, at least for the initial period.
I highly recommend Linux users to have a go at Grub prompt because it is virtually a mini operating system with which we can instruct Grub2 or legacy Grub to do things step by step. Once a Linux user knows how to fire up an operating system (Linux or MS Windows) manually in Grub prompt the chances are he/she can kiss all his/her booting problems good bye.
Last edited by saikee; 10-11-2009 at 04:57 PM.
saikee, thanks for the quick reply. I guess I'll have to break down and look deeper into Grub.
Grub2 grumble grumble
I'm finding this Grub2 business heavy going.
I've succeeded in getting Ubuntu9.10 installed without any problems, but I have had no luck in getting a Grub2 bootable CD. I have tried using exactly the commands given by Saikee in the first post here (though since I have only one cd-rom drive I had to save the file and reboot to write it); I have tried the same, but with nice -n-18 and speed=2; I have tried using the GUI "write to disk"; I have tried running grub-mkrescue from the installed Ubuntu 9.10; I have tried using a Parsix live CD; I have tried writing to disc an iso image I found in Ubuntu 9.10.
All to no avail. In the case of the Parsix effort the file produced is unreadable. In the other cases the PC just doesn't see the CD and boots from the hard drive, although live CD's and my Grub1 CD boot without any problem.
I have downloaded Grub2 from sourceforge and tried compiling it on two occasions in different OSes only to run into a string of errors, but that's probably my own stupignorance.
In spite of my strict instructions to the installer to install Grub2 in Parsix, Parsix can only be booted by using the Ubuntu 9.10 grub.cfg, or directly booting, using the Ubuntu lived CD, although all the Grub files appear to be in Pardix and I have run grub-install.
I have had a perfectly good Xubuntu Karmic from the alpha release, which never gave a moment's trouble until the update which put in Grub2 - it then refused to boot. I fixed that, in a moment of wrath, by removing every Grub file (including the bits of Grub1 that remained) and copying all the Grub1 files from my Ubuntu Hardy. It's now as happy as a pig in poo, but going 'back' to grub1 gives me the deflated feeling of someone who is not keeping up with the pace of things. Am I the only ijjit who can't cope with this? Or is Grub2 still buggy? Or is it the Ubuntu live CD?
It seems we have Grub2 because Grub1 can't handle the ext4 file system.
My short experience of the ext4 filesystem in Ubuntu Karmic makes me think it will be an improvement - it seems to boot much more quickly, apps seem to load more quickly, and if it is true that it speeds up file system checking by fsck, that alone would be worth the change as we get ever bigger hard disks. However, if you're multibooting, and you keep all your files in a large data partition (128G in my case, I'll bet others have much bigger ones), then you can't use ext4 for the data partition, which is where it would be most useful, until the last of your distros has gone over to ext4.
Moreover, I regret the loss of the ability in grub 1 to dive into a menu.lst and chop it about directly. Stuffing about with mkconfig is indirect - like using a GUI to do something that one command in a terminal will handle. You open three windows, click on six buttons, and have no idea of what you'll end up with. And I suspect that some of the scathing remarks by the grub2 developers about bad code in Grub 1 are unjustified: after all, it works pretty well. Shame it couldn't just be upgraded to deal with ext4.
I'd like to have another go with another live CD. Is there another good distro using Grub2 in its live CD? I tried Pardus, but it uses Grub1, although it lets you format the root partition as ext4. Copying the Ubuntu Grub2 files over and chrooting and grub-mkconfigging didn't make it boot either.
Saikee, are you using Grub2 in your MBR yet? Have you used it in the 145-distro box ?
In response to Loopback48 and other Debian users.
Before running the upgrade command to finalize the install of grub2 it's a good idea to check and make sure you have the os-prober package installed.
I followed the instructions and upgraded to Grub2 and the only OS that was in the new boot menu was the version that initiated the install of Grub2.
I installed os-prober and then ran upgrade-grub2 and all of my OS's including XP were restored to the boot menu.
Hopes this help someone else.
Sorry to hear you are having a problem with Grub2.
I just followed the information given in the Internet sites and got my floppy and CD made each in one attempt. I used an installed Ubuntu 9.10.
Grub1 is totally capable of booting Grub2 by chainloading and that would be recommended. When you install any distro just as a rule put Grub1 or Grub 2 inside its root partition. It saves a lot bother because if the MBR has Grub2 then
Grub2 can boot any Linux directly or indirectly in any Linux filing system.
If the MBR has Grub1 then it can boot every Linux indirectly and only directly with partition not in Ext4.
I have put Grub2 in MBR from time to time but don't really bother which Grub is there.
This thread was written to assure Linux users that Grub2 can be used very similar as Grub1. Try with Grub2 alone in floppy or a CD. Since my 145 systems box has every OS arranged chainloadable so either Grub1 or Grub2 can all of them up.
Even though I've been working with Linux for a few years I can't wrap my brain around this one. I wish one of you brainics would take me and others by the hand and leads us out of the darkness and into the light.
I have one OS installed in my PC. It's Debian Squeeze. What do I do next? Be gentle with me.
If your system only has one OS installed and it's Debian Squeeze it should be fairly straight forward. My main desktop has a single install of Squeeze and it upgraded without issues.
What should happen is that when Squeeze(testing) initiated the upgrade to Grub2 the maintainers used a two step process. They left Grub1 in the MBR and chain loaded to Grub2. This allowed the user to ensure that their OS would boot using Grub2. They left the final step up to the user. You don't have to do anything else and can leave it this way forever. If you want to go all in with Grub2 then, as root, run the "upgrade-from-grub-legacy" script.
I've successfully upgraded 3 machines. Two desktops and one laptop.
If you have multiple OS's loaded, as does my laptop and one desktop, then I recommend that you install the "os-prober" package before finalizing your upgrade. This package isn't listed as a dependency or recommended package. Why? I don't know, but it's important if you have multiple OS's installed.
If you have already upgraded, you can install os-prober after the fact and then run "update-grub2" as root. Your boot menu will be rebuilt with any OS's os-prober finds.
Thanks for the reply.
It's certainly not your fault!
Sorry to hear you are having a problem with Grub2.
I always put Grub in the root partition. I have Grub1 in the MBR pointing to Ubuntu Hardy in sda1, and menu.lst , sda.lst, sdb1.lst, sdb2.lst following the hidden partition scheme you suggested elsewhere. Now and again, when an OS won't boot, I replace with
Grub1 is totally capable of booting Grub2 by chainloading and that would be recommended. When you install any distro just as a rule put Grub1 or Grub 2 inside its root partition.
and all is merry as a marriage bell. Until Grub2, that is.
With the exception of Ubuntu 9.10, trying to chainload gives an error, usually 25: Disk read error. The manual doesn't throw a lot of light on this.
I've just been trying again to get Grub2 working in Parsix. All the files are there, not just in /boot but also in /usr/bin and /usr/sbin, but it just won't boot.
gives a syntax error although that is the syntax given in the man page.
starts running, but after a huge amount of info messages it scolds me:
grub-setup -v /dev/sda6
Earlier, I had another go at compiling it - I got a make error:
Attempting to install GRUB to a partition instead of the MBR. This is a BAD idea.
Embedding is not possible, GRUB can only be installed in this setup by using blocklists. However blocklists are UNRELIABLE and its use is discouraged.
error: If you really want blocklists, use --force
I suppose this means there's a C library missing.
make *** No rule to make target 'usr/lib/gcc/x86_64-linux-gnu/4.4.1/include/stddef.h' needed by grub-mkimage-util-i386-pc-grub-mkimage.o. Stop.
I might try downloading another Karmic live CD. Perhaps there's something funny with the one I've been using, though I checked the md5sum. Not now, though, I'm off to bed.