<div class="gmail_quote">On Thu, Nov 3, 2011 at 11:55 AM, Marko Vojinovic <span dir="ltr"><<a href="mailto:vvmarko@gmail.com">vvmarko@gmail.com</a>></span> wrote:<br><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
This is how bootloading works... First, there is bios, which is programmed to<br>
look for and execute the boot code in the MBR, and it does so at some point.<br>
The "look for and execute" means that bios needs to access the MBR of the<br>
disk, read it into RAM memory, analyze whether the data contained there is<br>
executable, and if it is to point the processor to execute it.<br>
<br>
The "program" that gets executed like that is called the stage 1 bootloader,<br>
and it is very very small (like 512 bytes or so), since the MBR doesn't have<br>
more space available. What this program does is to tell the bios to access<br>
some physical part of the hard disk, load it into memory and execute it. The<br>
bios knows nothing about partitions and filesystems, so it cannot be just<br>
pointed to "beginning of the partition /dev/sda6", but rather it must be given<br>
"physical" address of the place where it should look for data. This is<br>
explained in more detail in<br>
<br>
<a href="http://en.wikipedia.org/wiki/Logical_block_addressing" target="_blank">http://en.wikipedia.org/wiki/Logical_block_addressing</a><br>
<br>
The stage 1 bootloader has the LBA address of the beginning of the /dev/sda6<br>
partition, the LBA address of the end of the data to be read in, and the code<br>
to instruct the bios to go there, read that much data into memory, and execute<br>
it. If the bios is not designed to access the LBA address that far on the<br>
disk, it will fail and the machine won't boot. If it can, it goes there, reads<br>
the data into memory, and executes it.<br>
<br>
This data is called the stage 2 bootloader. It is a larger and more<br>
complicated program. It understands filesystems, it has a configuration file (in<br>
Fedora it is the /boot/grub/grub.conf file, feel free to take a look), it can<br>
interact with a user and offer various choices for the OS to boot. Once the<br>
bios loads it into memory and executes it, the stage 2 bootloader reads up its<br>
configuration file, on the /dev/sda6 partition. If the file isn't there, the boot<br>
fails (so the Ubuntu bootloader won't work if you deleted the Ubuntu system<br>
partition). Once the configuration is processed, the user is presented with<br>
options to load various OS's. Once the user makes a choice, the bootloader<br>
will do whatever is specified for that OS in the config file. Typically, it will<br>
load the kernel file (/boot/vmlinuz-something) into memory, and execute it. It<br>
doesn't need the bios for this anymore, since it knows how to access the disk<br>
itself.<br>
<br>
Another typical situation is to not load a kernel, but instead read some other<br>
stage 2 bootloader that resides on, say, /dev/sda1, and let that take over and<br>
repeat the whole thing for another OS. This is called chainloading, and that<br>
is how Windows gets booted from the Linux bootloader.<br>
<br>
At any rate, eventually some kernel gets loaded into memory, and the<br>
bootloader instructs the processor to execute that. And that's where the<br>
*real* fun begins... ;-) But that's another story,,, :-)<br>
<div class="im"><br>
> > Of course, once the OS gets booted,<br>
><br>
> from which location?<br>
<br>
</div>In Linux, the kernel is typically a file called vmlinuz-<something>, and it<br>
resides in the /boot directory of the filesystem tree. This directory can be<br>
basically anywhere --- on its own partition, on the / partition, on some other<br>
disk, etc... The stage 2 bootloader just needs to know where to look for it.<br>
<br>
In Windows, the kernel is (IIRC) the file C:\Windows\ntoskrnl.exe, or something<br>
like that. The stage 2 bootloader of Windows knows where and how to find it.<br>
The Windows' stage 2 bootloader gets loaded into memory and gets executed by<br>
the Linux stage 2 bootloader, if you choose to boot Windows when asked (the<br>
chainloading process).<br>
<br>
In other OS's the kernel file may be called whatever and be situated whereever,<br>
depending on the OS. ;-)<br>
<div class="im"><br>
> SUSE would automatically delete the MBR (which right now points to Ubuntu)<br>
> and would set the other defaults.....in it?<br>
<br>
</div>Yes, SuSE would wipe and rework the MBR so that it contains the stage 1<br>
bootloader that points to SuSE's new stage 2 bootloader, instead of the old<br>
Ubuntu's stage 2 bootloader (which was deleted during SuSE installation).<br>
Otherwise the transition from stage 1 to stage 2 in the boot sequence above<br>
would be broken.<br>
<div class="im"></div></blockquote><div> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="im">Yes. The above explanation should give you a clear idea what would happen if<br>
</div>
you leave Ubuntu stage 1 loader in MBR, and delete the stage 2 loader (along<br>
with the rest of the Ubuntu installation).<br><div class="im">
<br>
</div>Nothing is permanent, of course, it would just be a hassle to fix. Neither<br>
Windows nor Linux would boot, and you would need to boot from the installation<br>
DVD or something called the "Rescue CD", and use the rescue environment to<br>
reinstall both stages of the Linux bootloader (or reinstall Linux completely).<br>
You would need to know how to use the rescue environment and how to reconfigure<br>
the GRUB (the Linux bootloader) so that it loads everything correctly. This<br>
requires reading the documentation, which is on the Internet and you can have<br>
a hard time accessing it, since your computer doesn't boot...<br>
<br>
It happened to me once, back in the day --- I had to go to a nearby Internet<br>
caffe to read the docs, pay them to print me the details, go back home only to<br>
find out that I was reading the docs for the wrong version of the software, so<br>
I had to visit the Internet caffe once more, pay again for the printing of new<br>
docs, and then go home and fix it. I wasted a whole afternoon, realizing in the<br>
end that it is a Good Idea to learn about these things *before* I make a<br>
mess... ;-)<br></blockquote></div><br>Ah, thanks, it is pretty nice explanation and I would definitely read the docs - not only for rescue but also other details you pointed, the matter is only of time... I would do that.<br clear="all">
<br>-- <br>THX<br>