Thanks to Fedora community; Installation & Disk Partitioning ISSUE

[Marko Vojinovic]

On Thursday 03 November 2011 14:14:46 Linux Tyro wrote:
> On Thu, Nov 3, 2011 at 7:44 AM, Marko Vojinovic <vvmarko at gmail.com> wrote:
> What earlier I used to think is that, "BIOS only send the instructions to
> the boot-loader (probably or whatever it sends the signal to) to just boot,
> BIOS has not such a bigger memory to have the hard-disk, so hard-disk is
> always beyond the hands of BIOS, but rather BIOS just sends the signal that
> ***IT*** should be booted and ***THAT*** gets booted.

This is how bootloading works... First, there is bios, which is programmed to 
look for and execute the boot code in the MBR, and it does so at some point. 
The "look for and execute" means that bios needs to access the MBR of the 
disk, read it into RAM memory, analyze whether the data contained there is 
executable, and if it is to point the processor to execute it.

The "program" that gets executed like that is called the stage 1 bootloader, 
and it is very very small (like 512 bytes or so), since the MBR doesn't have 
more space available. What this program does is to tell the bios to access 
some physical part of the hard disk, load it into memory and execute it. The 
bios knows nothing about partitions and filesystems, so it cannot be just 
pointed to "beginning of the partition /dev/sda6", but rather it must be given 
"physical" address of the place where it should look for data. This is 
explained in more detail in

   http://en.wikipedia.org/wiki/Logical_block_addressing

The stage 1 bootloader has the LBA address of the beginning of the /dev/sda6 
partition, the LBA address of the end of the data to be read in, and the code 
to instruct the bios to go there, read that much data into memory, and execute 
it. If the bios is not designed to access the LBA address that far on the 
disk, it will fail and the machine won't boot. If it can, it goes there, reads 
the data into memory, and executes it.

This data is called the stage 2 bootloader. It is a larger and more 
complicated program. It understands filesystems, it has a configuration file (in 
Fedora it is the /boot/grub/grub.conf file, feel free to take a look), it can 
interact with a user and offer various choices for the OS to boot. Once the 
bios loads it into memory and executes it, the stage 2 bootloader reads up its 
configuration file, on the /dev/sda6 partition. If the file isn't there, the boot 
fails (so the Ubuntu bootloader won't work if you deleted the Ubuntu system 
partition). Once the configuration is processed, the user is presented with 
options to load various OS's. Once the user makes a choice, the bootloader 
will do whatever is specified for that OS in the config file. Typically, it will 
load the kernel file (/boot/vmlinuz-something) into memory, and execute it. It 
doesn't need the bios for this anymore, since it knows how to access the disk 
itself.

Another typical situation is to not load a kernel, but instead read some other 
stage 2 bootloader that resides on, say, /dev/sda1, and let that take over and 
repeat the whole thing for another OS. This is called chainloading, and that 
is how Windows gets booted from the Linux bootloader.

At any rate, eventually some kernel gets loaded into memory, and the 
bootloader instructs the processor to execute that. And that's where the 
*real* fun begins... ;-) But that's another story,,, :-)
 
> > Of course, once the OS gets booted,
> 
> from which location?

In Linux, the kernel is typically a file called vmlinuz-<something>, and it 
resides in the /boot directory of the filesystem tree. This directory can be 
basically anywhere --- on its own partition, on the / partition, on some other 
disk, etc...  The stage 2 bootloader just needs to know where to look for it.

In Windows, the kernel is (IIRC) the file C:\Windows\ntoskrnl.exe, or something 
like that. The stage 2 bootloader of Windows knows where and how to find it. 
The Windows' stage 2 bootloader gets loaded into memory and gets executed by 
the Linux stage 2 bootloader, if you choose to boot Windows when asked (the 
chainloading process).

In other OS's the kernel file may be called whatever and be situated whereever, 
depending on the OS. ;-)

> SUSE would automatically delete the MBR (which right now points to Ubuntu)
> and would set the other defaults.....in it?

Yes, SuSE would wipe and rework the MBR so that it contains the stage 1 
bootloader that points to SuSE's new stage 2 bootloader, instead of the old 
Ubuntu's stage 2 bootloader (which was deleted during SuSE installation). 
Otherwise the transition from stage 1 to stage 2 in the boot sequence above 
would be broken.

> > Since you are going to delete Ubuntu, its bootloader in MBR will fail to
> > work.
> > You want to let SuSE set up the MBR, and leave the / partition alone.
> > SuSE will take care of itself, and it will take care of Windows via
> > chainloading its bootloader on /dev/sda1. You *don't* want to leave
> > Ubuntu's bootloader in
> > the MBR.
> 
> This is a small typical, what I got means I should not change this because
> Ubuntu is in MBR and we are going to delete the Ubuntu, so enabling it
> would/could make it some problem...?

Yes. The above explanation should give you a clear idea what would happen if 
you leave Ubuntu stage 1 loader in MBR, and delete the stage 2 loader (along 
with the rest of the Ubuntu installation).
 
> The system by mistake also if becomes Non-bootable, as in the case just in
> above para, would it permanently become non-bootable or we could re-write
> the hard-disk from scratch....(just in doubt...for future
> experimentation....) However, in my case it is just dual booted, working.

Nothing is permanent, of course, it would just be a hassle to fix. Neither 
Windows nor Linux would boot, and you would need to boot from the installation 
DVD or something called the "Rescue CD", and use the rescue environment to 
reinstall both stages of the Linux bootloader (or reinstall Linux completely). 
You would need to know how to use the rescue environment and how to reconfigure 
the GRUB (the Linux bootloader) so that it loads everything correctly. This 
requires reading the documentation, which is on the Internet and you can have 
a hard time accessing it, since your computer doesn't boot...

It happened to me once, back in the day --- I had to go to a nearby Internet 
caffe to read the docs, pay them to print me the details, go back home only to 
find out that I was reading the docs for the wrong version of the software, so 
I had to visit the Internet caffe once more, pay again for the printing of new 
docs, and then go home and fix it. I wasted a whole afternoon, realizing in the 
end that it is a Good Idea to learn about these things *before* I make a 
mess... ;-)

HTH, :-)
Marko