Question:
After installing Windows, his own became the primary bootloader.
There is Linux Mint, so you need to have grub.
However, instead of the standard option, in which grub becomes the primary bootloader, I want to install grub on a separate partition and write a command in the bootloader to transfer control to grub. Naturally, the screw loader should remain primary.
How to install grub to get this configuration?
Answer:
warning : the following is very simplified and applies only to the "traditional" (or "old") disk partitioning scheme called dos partition table ( mbr-based partitioning ) . although this is probably partly true for guid partition table ( gpt ) as well . but definitely not the unified extensible firmware interface ( uefi ) .
in simple terms, bios loads the first 512 bytes into memory from the block device specified in its settings, and transfers control to this “piece of code” (in terms of grub, this is called the “first stage loader” – stage 1 loader ).
in addition to the executable code, there is also some other information necessary for this code itself. it is clear that it is rather difficult to fit something reasonable into such a meager amount of code, and, in fact, this code just loads another, much larger portion of the code ( stage 2 ), and transfers control to it.
where exactly to take this second portion, the “first stage loader” learns from the very information that is written next to it in those same 512 bytes. among other things, they contain at least: the address of the block device (after all, stage 2 can be located on another used one) and the address of the sector (s) that must be loaded into memory.
why sector address and not file name? because in 512 bytes it is impossible to “pack” code that could work with the file system .
By the way, by the way: in case of overwriting a file from stage2 , its physical location will most likely change, and, accordingly, the contents of those same 512 bytes of the “first stage loader” will need to be adjusted.
and now the code that was loaded from stage 2 “understands” both file systems and configuration files, can read and display a dialog to the user based on these configuration files, and load the selected program that performs the functions of the kernel (the one that is loaded "trained": ntoskrnl.exe , linux etc. etc.).
The stage2 bootloader from ms is clearly not "trained" to load the linux program, and the stage2 grub bootloader (as well as lilo and others) is not "trained" to load ntoskrnl.exe .
but they can all load other stage1 loaders (and even stage2 loaders) and pass control to them .
and then we can only talk about the degree of automation of setting up this process.
-
in the case of the bootloader from ms , of course, no configuration automation is provided: facilitating the process of using a “foreign” operating system is a “hit below the belt”, i.e., to the wallet. as they say, "it's just business, nothing personal."
to configure, you need to get hold of the “first stage bootloader”, write these 512 bytes to a file (for example,
c:\bootsect.aln) and add a line to the operating systems section of thec:\boot.inibootloader configuration file with something like this:c:\bootsect.aln="alien operating system"do not forget to manually update the contents of this 512-byte file every time after updating the stage2 loader, to the addresses of the sectors with which it (the file) should refer!
there are, of course, all sorts of “boot managers” (of the type mentioned in the easybcd comments), but I don’t know if any of them implement automatic accounting for updates in the stage2 file of the same grub . but I suspect that it is unlikely (given, firstly, that there can be much more than one section with grubs, and secondly, that the “update initiative” comes from grub , which, quite naturally, is unlikely to suspect about the existence of any "boot managers").
- in the case of the grub bootloader, the approach is diametrically opposite: everything (that is possible) has been done to simplify the setup of the boot process for other operating systems. under “normal conditions” everything generally happens “automagically”: during the installation of the grub program (and when updating files containing stage2 ), the update-grub program (part of the grub package) is called, which (usually quite successfully) “finds” other bootloaders on block devices and their partitions, and adds items with them to the boot menu.
which path suits you best – choose for yourself.
ps Perhaps it is worth noting that the code for the "second stage loader" of the grub program has long grown to such an extent that the developers had to create (though not only for this reason) an intermediate loader (which was called stage 1.5 ). this does not change the essence, but it is even written about stages 1, 1.5 and 2 in Wikipedia , and the mention will be appropriate.
addition
about where to put 512 bytes of stage1 so as not to overwrite mbr : put it not in the mbr of the disk, but in the vbr of the partition . there is enough space. bootloader installers know this, and know how to handle it.