On Mon, 2 Jul 2001 oms101@freeuk.com wrote:

You wont stop it booting another OS form my experiance, I thought I stored itself and all its code on the master boot record

In the case of my machine killing /boot will kill the machine but If I make /dev/hda1 (or C:) bootable I could of course boot NT again (why would I want too.... oh yeah, games!!)

My reasoning is /boot is /dev/hda2 which is the bootable partition, windows will mark /dev/hda1 (or C:) as bootable when I have to re-install it (windows that is). All I have to do now is change my machine to boot from /dev/hda2 again and everything will work, this is instead of booting the system and chrooting and running lilo or some other recovery procedure.

Anyway it is all very academic since I have a bootable recovery CD-Rom courtesy of someone on this list. And if you don't have a copy or emergency recovery system I suggest grabbing a copy of Trinux of LOAF or some other mini Linux distro and keeping it handy as it will save your life someday (well maybe not your life, but at least you won't have pulled your hair out!)

Of course I have not installed Grub yet, so I will probably seriously harm my system and do something like trash the partition table (now that can be a little tricky to recover from, but it is possible I speak from experience the first thing to do is do not shut the machine down or reboot) but I will see.

Adam

On Mon, Jul 02, 2001 at 12:27:19AM +0100, Adam Bower wrote:

What I meant to actually say in simple english was that I believe the MBR only stores the current active partition and looks there for the boot record instruction bit.

Perhaps it would help to understand more of the boot process, so here it as to the best of my knowledge.

After doing the power on self test, the BIOS looks round for something to boot. It may have the order hard coded or, more likely, have it configured in the BIOS setup. It examines each device in turn and tries to read the first sector from that device and tests it to see if it is a boot record. A boot record begins with a 8086 jump instruction (and there may be other tests too).

Once a boot record is found, it is loaded into memory and executed - it is, after all, a short machine code program. In the case of the MBR of a hard disk, this program is expected to choose an OS to boot.

The standard MBR (non-LILO) simply checks through the parition table to find the partition marked as active, loads the boot record from the first sector of that partition and executes that. That could be the boot sector part of LILO, or the boot record of any other OS depending on how things have been set up.

A boot record is 512 bytes and even using hand crafted assembler this is not much space to write a clever boot loader like LILO. Instead the boot record part of LILO loads a second stage loader which in turn offers the user interface and loads the selected kernel. LILO finds the second stage loader because the /sbin/lilo program installs a pointer to its place in the file system in the boot record part of LILO. Similarly the /sbin/lilo program generates a map to enable the second stage loader to load kernels without having to understand the filesystem.

So, going back to where this seemed to start, if you install LILO on the MBR and then subsequently blow away the Linux partition, you risk LILO not being able to find the second stage loader and thus not being able to boot anything. Of course if you just delete the Linux partition without overwriting it LILO will continue to work as it still has the disk address of the second stage loader, but this will fail as soon as you install something new on what was the Linux partition (even another copy of Linux).

HTH, Steve.