A cunning trick to remove the Grub1 partition but still having Grub1 remains operational
A distro Installer transferred into a USB device bootable by a Grub floppy - a work round to overcome no CD drive as well as no Bios support booting from a USB device
Recently I used a Dos partition to multi boot a Dos, 4 Windows and 35 Linux in the same hard disk. All the MS boot loaders and Grub1 were co-existing with each other happliy in this Dos partition. To my pleasant surprise I discovered Grub1 does not need to occupy the boot sector at all which has been given to Vista/Win7's bootmgr. This makes me think that Grub in the MBR (stage1) must have "hard coded" the hard disk address of its second part (stage2). My logic is if Grub doesn't need to find its stage2 from "a filing system" then Grub should work as long as its binary file of stage2 at the recorded location on the hard disk is available, even the partition has been deleted, re-created or modified. In other word as long as the stage2 file is in the hard disk and is not liable to be overwritten or changed then it should be possible to remove the partition holding stage2 and Grub should not complain. This was confirmed when I deleted a partition that held the stage2 but still found the same workable Grub prompt.
Some theoretical considerations of the booting process
Just like any booting process in a PC, where the MSdos partition table is used, the process has two stages. The first stage is to have the boot loader occupying the MBR or the first 512 bytes of the first boot disk. Hence every operating system's MBR section must be exactly 512 bytes long. Once this boot loader is in control it can load its second part which can be a lot larger than 512 bytes. The real intelligence of a boot loader lies with the second stage because it has a lot more codes. For Grub1 it has two files, called stage1 and stage2, to do exactly that.
In normal working Grub1 will serach a configuration file menu.lst in the /boot/grub or /grub directory. If none is found Grub1 default to a Grub prompt. Many users will be at a loss to see a Grub prompt but I like it because there is no installed PC operating system that cannot be booted up manually in a Grub prompt.
In what situation Grub has to be used but there is no partition for it?
Recently advices has been sought from me to see if Grub can boot a Vsita or Win7 installer. If this possible then several MS Windows installation DVDs, of different versions, can then be transferred into a pen drive and booted by Grub. After a bit of work I have found a solution and will be writing a tutorial for it shortly.
What I have not been aware for years is that none of the MS Windows could mount (and hence see) more than one partition in a pen drive as we don't have such silly restriction in Linux. The Vista and Win7 Windows installers also dislike logical partitions and have to reside in primary partitions so technically one can only place a maximum of 4 MS Windows installers inside a pen drive because in a Msdos partition table permits only 4 primary partitions.
Grub has the capability to hide and unhide partitions so it is ideal for hiding 3 unwanted primaries and booting the delected installer of the remaining unhide primary partition. Grub can do this at boot time as well as changing the disk order.
However if I have to formatted the 4 primary partition with the NTFS filing system there is no room to install Grub which in any case is incompatible with the NTFS filing system. Hence I have a need to put my theory into practice.
The proposed scheme
(a) ormat the 4 primaries but leave a small space at the end of the pen drive, say a couple of cylinders. A cylinder in LBA has 8.225Mb bytes. Grub1's stage1 and stage2 can be fitted inside a 1.44Mb floppy.
(b) Install the files into all the 4 primaries and make each one bootable as intended.
(c) Record the partition boundary of the 4th primary partition. Delete the 4th partition
(e) Recreate a new 4th partition at the end of the previously deleted 4th partition. The space left between the 3rd and 4th partition is unallocated but protected.
(f) Install Grub in the new 4th primary partition, make it bootable from the MBR.
(g) delete the latest 4th primary partition and re-create the previous 4th primary partition at its known position.
Detials of an example
I used Mepis Live CD as it has Grub1 inside. Other distros like Ubuntu can be used by its Grub2 has to be replaced by Grub1 using command "sudo apt-get install grub".
First I claimed the root privilege (equivalent to log in as Admin in MS Windows) in Mepis. For Live CD the root password is "root" as stated in Mepis web site.
Here is how I start with a 16Gb pen drive recognised as device sdc with 4 primary partitions. Notice the device has 1966 cylinders but I have only used up 1963 of them. This was incidental as I was squeezing 4 MS Windows installation DVDs into one pen drive. The geometry of the pen drive was first checked with the terminal command "fdisk" as follow:
To partition the device sdc I used the same fdisk command
I first wrote down on a piece of paper the start and end cylinder numbers, which are 1441 and 1963, of the last parimary partition sdc4. Once inside fdisk I used "d" to delete the 4th partition, "n" for creating a new partition, "p" for specifying it as a primary, for the start cylinder I specified 1964 and then accepted the default end cylinder position of 1966. Before I exit fdisk I used "p" to display the partition table and satified with it before confirming with "w" to write it and then used "q" to exit.
Now I have successfully added a primary partition, under the same name /dev/sdc4, on the last few cylinders of the pen drive. The previous /dev/sdc4 is now a unallocated space in the pen drive perfectly safe and cannot be touched. My new partition table is now
Disk /dev/sdc: 16.2 GB, 16173236224 bytes
255 heads, 63 sectors/track, 1966 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00017ff8
Device Boot Start End Blocks Id System
/dev/sdc1 1 393 3156741 7 Hidden HPFS/NTFS
/dev/sdc2 394 786 3156772+ 7 Hidden HPFS/NTFS
/dev/sdc3 787 1440 5253255 7 Hidden HPFS/NTFS
/dev/sdc4 1964 1966 24097+ 83 Linux
The next task is to format the partition /dev/sdc4 with a filing system that Grub can work with. This can be Ext2, Ext3, Fat16 or Fat32.
I then created a mounting point sdc4 on the subdirectory /mnt, manually mounted the device /dev/sdc4 on it.
mount /dev/sdc4 /mnt/sdc4
I know any Live CD that has Grub1 will store Grub in the directory /boot/grub so I did a check with the Mepis Live CD to make sure it has the two files stage1 and stage2 by command
and received the response
The operation of installing Grub1 in a partition comprise of
(i) make a directory /boot/grub in the new partition
(ii) copy Grub1's system files "stage1" and "stage2" into this new partition
(ii) Invoke a Grub shell and instruct Grub to set itself up.
These commands create the subdirectory in the newly mounted partition, copy the files across and then list the end result:
cp /boot/grub/stage* /mnt/sdc4/boot/grub
To invoke a Grub shell in Mepis is just typing at the terminal
Inside the Grub shell a sanity check can be carried out by asking Grub to display the geometry of 1st disk (hd0), 2nd disk (hd1), 3rd disk (hd2) untill all disks have been exhausted. This advisable so that the user is keenly aware of what disks and partitions available.
The correct disk for the sdc was (hd2) in my case as I have sda as (hd0) and sdb as (hd1). My sdc disk therefore displayed the 4 partitions of Type 7,7,7 and 83 respectively so that I could be convinced of working with the right disk. Grub1 counted disk and partition from zero so the partition I have just installed Grub, with stage1 and stage2 inside, would be (hd2,3).
To instruct Grub to setup itself in the MBR of the 3rd disk using system files obtained from its 4th partition is simply
I could now exit Grub by command
and return to the Linux terminal.
I then used fdisk again to remove the new sdc4 partition that contain Grub, recreated the old one by the previously known start and end cylinders and return to my previous partition table
The hide command only alters the partition ID from 7 to 17. The unhide command does exactly the opposite. A MS system only recognise partition ID 7 for NTFS partition and ID 17 to it is foreigh and will not be mounted.
(A) As I do not have a partition for Grub so it is not possible to have a menu.lst. I therefore have to boot every system manually in the Grub prompt which is actually what I prefer.
(B) The method described above is for Grub1. I have not tried the newer Grub2.
(C) The scheme is safe and totally stable as I place the stage2 in a dead space. An operating system for PC by default does not operate the hard disk space outside the boundary defined by the partition table. In any case the stage2 can be replaced whenever if required.
(D) The alterations of the partition table does not affect the content of the partitions' interior. Hence I can delete and re-create a partition without changing a byte to my data inside my partition.
(E) The above scheme is unnecessary if one of the primary partition can be converted into an extended partition so that Grub can be installed in one of the logical partitions.
(F) I can boot up a Grub from another source like a floppy, a CD or a hard disk partition. From it I can boot the installers inside the pen drive. Thus it is not nescessary to install a boot loader in a pen drive or to have it bootable at all. This can be a great news to PC owners who do not have a CD drive and their Bios incapable of booting from a USB device. They need a floppy though.
(G) There is no Howto or tutorial telling us that we can use Grub1 this way. The above scheme is achieved by just reasoning it out.
Way to go saikee!! Excellent piece of research. Grub2 is becoming more predominant and I feel within the next year that Legacy will be slowly left behind. I can't wait until your experimentation with that.
Grub2 is a lot more powerful but I have been using both.
Grub2 has these ground breaking features
It can read ntfs partitions!
It can boot beyond the maximum cylinders supported by the Bios. Grub1 is having difficulty in booting near the end of a 1.5TB hard disk but Grub2 goes all the way to 2TB.
Grub2 has been engineered to support gpt partition table and is ready for hard disks >2TB. Grub1 must be patched up to do the similar. Same situation with Ext4 filing system.
Grub1 still ahead with these features
There is a Grub shell inside the kernel. Grub2 has none.
Grub1 can restore Grub for multi partitions in one go. Grub2 needs to mount each one to do such repair.
Grub1 is a lot simpler to use.
I don't think Grub1 will go away and will stick around for a long time because the Linux boot loaders are interchangeable. Generally uploading Grub2 will overwrite Grub1 and vice versa. Both versions of Grub have a good future because they can boot any PC operating system manually and fire up any Linux even without a boot loader installed inside. Lilo can only do the latter.
The trend I see is Grub2 will dominate as it reaches every part Grub1 can reach but more.
I would like to see some experimentation with Loadlin.......it can still be found on Slackware repositories and is included in the install disk of 13.0. I used it once years ago with a 500mb disk but as I understand it it has no limitations on drive size. It does need a DOS partition to live.
I had tried Lodlin in my early days with Linux when I joined the JL.
It is exactly what it said "LoadLinux". However it has be launched from a Dos environment which one must boot to initially.
Dos does have a limitation on partition size and may be severely restricted by the CHS addressing in the hard disk when just ablout everybody has moved to LBA mode. Even Grub4Dos finds it hard to keep up so Loadlin does gradually losing its influence I am afraid. The program was very well written and pretty neat, obviously a tremedous amount of effort has gone into it.
I came to the conclusion that if I spend time to understand a boot loader it might as well on one that has a longer self life like Grub or Lilo.
I don't see Loadlin as a boot loader because it is not launch directly from a cool boot like others do. MS systems has bootmgr, used by Vista and Win7, and is able to boot 150 Linux when I stretched it. There is more fun with it as everything can be done by a script (batch file to be exact).