Re: Thanks to Fedora community; Installation & Disk Partitioning ISSUE

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Nov 3, 2011 at 11:55 AM, Marko Vojinovic <vvmarko@xxxxxxxxx> wrote:

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.
 
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).

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... ;-)

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.

--
THX
-- 
users mailing list
users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [EPEL Devel]     [Fedora Magazine]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Desktop]     [Fedora Fonts]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Fedora Sparc]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux