Thanks to Fedora community; Installation & Disk Partitioning ISSUE

Linux Tyro fedora.bkn at gmail.com
Fri Nov 4 07:54:15 UTC 2011


On Thu, Nov 3, 2011 at 11:55 AM, Marko Vojinovic <vvmarko at gmail.com> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.fedoraproject.org/pipermail/users/attachments/20111104/62b78756/attachment.html 


More information about the users mailing list