I notice that the SuSE installer allows the user to select a boot option of:
MBR and/or boot partition. Sorry if this is a silly question!
But how can it do both. Does it not boot from the MBR OR the boot partition “/boot”?
Regards, Martin
On 2012-06-27 12:56, martinprowe wrote:
>
> I notice that the SuSE installer allows the user to select a boot option
> of:
>
> MBR and/or boot partition. Sorry if this is a silly question!
>
> But how can it do both. Does it not boot from the MBR OR the boot
> partition “/boot”?
Yes, the actual booting will be from one place only, but nevertheless, you
can install both.
–
Cheers / Saludos,
Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)
Hi Carlos,
Thanks for your reply. However, but I’m still very confused!!!
Yes, I can understand that two sets of boot code can be installed (in the MBR and the /boot partition).
But who/how is one or the other selected? In fact it seems from my experements that if I select neither, the installed system still boots?
Furthermore, how can any other location other than the MBR be the OS kick-off point?
As I understand it, all BIOS’s (ignoring the limited exceptions) will transfer control to the MBR on one of the available disc drives.
The BIOS knows no other way of linking to the disc based OS.
Regards, Martin
On 2012-06-27 14:46, martinprowe wrote:
> Hi Carlos,
>
> Thanks for your reply. However, but I’m still very confused!!!
Booting is confusing. Is a hack because of an old design that did not
forecast the need for booting multiple oses.
So now they invented UEFI.
> Yes, I can understand that two sets of boot code can be installed (in
> the MBR and the /boot partition).
> But who/how is one or the other selected? In fact it seems from my
> experements that if I select neither, the installed system still boots?
The idea is that if one is destroyed the other is still available.
> > Furthermore, how can any other location other than the MBR be the OS
> kick-off point?
> As I understand it, all BIOS’s (ignoring the limited exceptions) will
> transfer control to the MBR on one of the available disc drives.
> The BIOS knows no other way of linking to the disc based OS.
Correct. However, the generic boot code in the MBR normally boots the
partition that is marked bootable, which should be the partition that holds
grub inside.
So, if you install both methods, it is the grub in the MBR which will be
working. If this boot is destroyed and replaced with generic code, it will
be the other one.
That’s one scenario, there can be others.
–
Cheers / Saludos,
Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)
Hi Carlos,
Thank you. Going off-air now to think about this…
Regards, Martin
Not the BIOS, but a boot manager, such as Grub or another one, could load any partition boot sector. Thus Grub in MBR could load Grub in your /boot partition or another Grub somewhere else if you’re multi-booting. This is called “chainloading”.
If you have only Linux (and Unix) systems, I recommend installing Grub in both locations, the MBR and the root partition, more precisely the Grub which comes with the distro in the root parition (which is most often the same as the “/boot” partition) of that distro and the Grub of your choice in the MBR. This is the safest way to boot Linux*. If you’re mutli-booting with Windows, it is debatable. Athough Grub in MBR doesn’t bother Windows directly, it could prevent some updates such as service packs from getting installed and might get overwritten by Windows itself or some Windows program sooner or later. Therefore, many Windows users prefer to use a generic MBR with Linux.
- You’ll find why if you search the forum.
[QUOTE=please_try_again;2471692* You’ll find why if you search the forum.[/QUOTE]
Hmmm… But I still can’t get an understanding of what is going on. All the advice is prescriptive. Do this, press that…
But that strategy only works if one is starting from EXACTLY the same starting point as the author.
Any suggestions on how I can see what is going on behind the GUIs?
For example, as I understand it, irrespective of whether a generic MBR code module or GRUB’s stage1 code has been loaded into the MBR, something has to take responsibility for patching that code to point to the physical sector address for the entry point to stage1_5 or stage2.
That location is only known at install time.
Additionally, at what point is the MD code available? My guess it, that won’t be in GRUBs stage1. How about stage1_5 or stage2? If so, that code must exist on both disc outside the RAID array? Is that (should that be) the responsibility of the YaST2 boot-loader (Rocket Icon) switch “Enable Redundancy for MD Array”?
I guess what I am looking for is a “boot sequence” disassembler. So that I can see what I’ve done right, or more likely, wrong!
Best regards, Martin
It lists all the grubs installed (stage1) and where they look for stage2. stage1.5 location doesn’t change and is only present when the boot loader is in the MBR, in the sectors following the MBR on the first track. Its size depends on the version (distros). You can see the number of sectors when you install grub in MBR from the command line in the Grub shell. When used with the -v (or --verbose) option, findgrub displays the offset of stage2 and tries to guess the Linux version. It doesn’t works for all distros because findgrub only reads sectors and not files (unlike updategrub, which uses os-prober and parses boot menus). But il always works for openSUSE, because its Grub signature is different from upstream Grub.
When you put the boot loader (stage1) in a partition boot sector, the location of stage2 is written in the boot loader at installation time. If for some reason, this location changes, the OS will fail to boot (until you reinstall the boot loader).
When you put the boot loader in the MBR, stage1.5 uses the disk and partition number (and not sector numbers) to load stage2 and boot the OS. This is why it is safer. sage1.5 is able to read the filesystem.
You install the bootloader in a separate paritition outside of the RAID array or in a separate RAID array but on the first disk only … as far as I can tell, because I don’t install RAIDs very often. Now I don’t even use RAID anymore for the system (the system is easy to reinstall) but only for data.
Here’s the ouput of findgrub on my last “true” RAID (meaning OS + data), a 11.4 file server:
# findgrub -v
Find Grub Version 3.8.1 - Written for openSUSE Forums
- reading MBR on disk /dev/sda ... --> Legacy GRUB found in sda MBR => sda1 0xfd using stage1.5 (openSUSE)
- searching partition /dev/sda1 * (LINUX RAID AUTO) ...
- skipping partition /dev/sda2 (swap)
- searching partition /dev/sda3 (LINUX RAID AUTO) ...
- reading MBR on disk /dev/sdb ...
- searching partition /dev/sdb1 * (LINUX RAID AUTO) ...
- skipping partition /dev/sdb2 (swap)
- searching partition /dev/sdb3 (LINUX RAID AUTO) ...
If you’re installing a RAID on a BIOS based system, you should definitely put Grub in the MBR.
Hi “please_try_again”,
Thank you very much for your insight into this issue. And the findgrub utility is exposing a lot of very helpful information. A big thank-you to the author.
Before launching into more questions, can I check that I understand what I am seeing with findgrub?
# findgrub -v
Find Grub Version 3.8.1 - Written for openSUSE Forums
- reading MBR on disk /dev/sda ... --> Legacy GRUB found in sda MBR => sda1 0xfd using stage1.5 (openSUSE)
- searching partition /dev/sda1 * (LINUX RAID AUTO) ...
- skipping partition /dev/sda2 (swap)
- reading MBR on disk /dev/sdb ... --> Legacy GRUB found in sdb MBR => sdb1 0xfd using stage1.5 (openSUSE)
- searching partition /dev/sda1 * (LINUX RAID AUTO) ...
- skipping partition /dev/sda2 (swap)
Given the above, findgrub is telling me that:
That there is grub stage1 code in the MBR of discs sda and sdb.
That this code is linking to grub stage1.5 code (I assume located on the remaining sectors of track zero)
Which, in turn is pointing to the stage2 code located on the partitions sda1 and sdb1.
That the format of partitions sda1 and sdb1 are 0xfd (LINUX RAID) and the os is openSUSE.
Moreover, that sda1 and sdb1 are marked as “active” (the asterisk)
The consequence of this is that, once the BIOS has passed control to stage1 (in the MBR), it is in turn relayed to stage1.5.
Stage1.5 is able to deduce that the format of sda1 and sdb1 are LINUX RAID (0xfd), and it should treat them as a MD (multi-disc) and proceed with loading and executing stage2 from /dev/md0 (if that is the device name).
If I am reasonably on-track with my understanding, how should I interpret this output?
#findgrub -v
Find Grub Version 3.0.1 - Written for openSUSE Forums
- reading MBR on disk /dev/sda ... --> Grub found in sda MBR => sda1 0xfd (openSUSE)
- searching partition /dev/sda1 (LINUX RAID AUTO) ...
- reading MBR on disk /dev/sdb ... --> Grub found in sdb MBR => sdb1 0xfd (openSUSE)
- searching partition /dev/sdb1 (LINUX RAID AUTO) ...
Press <enter> to Exit findgrub...
And yet the system boots. And I see the console output, “Loading GRUB 1.5” followed by “Loading GRUB” before dropping into a SUSE splash screen.
i.e. the system seems to be loading and running grub stage 1.5 & 2 although findgrub is not reporting the stage1.5 step? It is also not reporting the active partitions?
Sorry for the long-winded question, but sometimes I’ve just got’a figure out what’s going on…
Best regards, Martin
Correct.
Well, it looks for the position of stage2 in 4 bytes starting at offset 68 (decimal) and it finds “1”, which means that it is going to use stage1.5. Then it looks for the partition number of stage2 written in stage1.5 (in 1 byte at offset 1049) and adds 1 to this value. That should gives 1 in your case (stage2 is in sda1). It already knows the BIOS drive from stage1. stage1.5 then finds stage2 by reading the file system. When you use generic MBR, stage1 doesn’t have the necessary code to read the file system and jumps to the offset of stage2 directly.
yes.
According to the offset of Grub signature, which is unique for openSUSE. If it were Mandriva, ArchLinux or old Debian (with Legacy Grub), it could not tell.
Yes, but it’s irrelevant when Grub (or another boot manager) is in MBR. The boot manager determines the partition to boot, not the BIOS.
Yes.
I don’t think so. The information “LINUX RAID” comes from fingrub, which just translates the partition ID it got from fdisk. It can only be booted from one HD at a time. But some people here know much more than I do about RAID. Maybe they can give you a better explanation.
I don’t know. 
Normally findgrub -v should say either “using stage 1.5” when Legacy grub is installed in MBR, or “using core” when Grub2 is installed in MBR, or “at offset …” followed by a sector number when stage1 is in a partition boot sector (VBR) and the MBR is generic. I don’t know why it says nothing in your case, but I guess it has something to do with RAID.
Hi “please_try_again”,
Thank you very much for sharing your knowledge.
It realty is appreciated that you are prepared to take the time to read, understand my questions and comment helpfully and informatively.
Best regards, Martin
I’d like to thank you both, for one of the most interesting and teaching threads on GRUB I’ve ever seen.