Two-boot Bootloader Download

[Fito Coulter]

Onmy laptop (HP Pavilion) I have a Linux Mint 18 installation and I recently added a Manjaro Linux installation in parallel. To do so, I let the Manjaro installer shrink my Mint partition in order to make space for the new installation.

The problem that I am experiencing now is when it comes to booting. It seems to me as if the new Manjaro installation has installed its own GRUB (which is the boot loader/manager as far as I know) because in the BIOS I used to have two OS bootloaders to chose from (Ubuntu + Manjaro).

However, as I couldn't convince my laptop to offer me the possibility to choose between the two installations, I started messing around with the options. I noticed that when choosing the Manjaro boot loader I did get that menu to choose which OS to boot. I somehow "managed" to make the Manjaro-option in the BIOS disappear; I can still boot it through the BIOS -> EFI though.

Then I discovered that I simply had to update-grub on my Linux Mint installation in order for the menu to appear as desired, but although the menu itself is showing now, I can only boot Linux Mint from it. When trying to boot Manjaro I get some kernel panic error alongside with a Can't claim resource 1 message and then it exits the boot (at least that's what I'm assuming because it won't do anything else).

Now it seemed strange to me that I even have those two separate boot loaders alongside each other. I am wondering if that could cause the problem or if someone has another idea what the problem here could be?

The thing that did the trick for me was to run sudo grub-install on my Manjaro system which restored the Manajaro boot option in the BIOS that I managed to make "disappear" before.

Once this option has been restored I was able to make it the first boot option and now everything works like charm!

Would it be possible to install several operating systems on their own partitions, each with their own boot loader installed on its respective partition which could be invoked by selecting it from a boot loader on the MBR?

This causes the bootloader from the 1st disk / 11th partition (numbering starts with 0) to be executed.For additional notes for grub and multi-OS installations have a look at for instance - but there are many grub tutorials out there...

Default Linux is able to work with up to 255 partitions on an IDE disk, but RedHat crippled fdisk with a patch to only support 8 or 16 partitions (don't remember exactly). I worked around this problem by installing RedHat Releases on low partition numbers, and moved them to higher partitons after the installation. I recommend therefore to use another distribution (I used a small Debian installation) as a base OS to administer the other installed systems (moving them around, perform backups and such).

If not mixing old Linux systems with current distributions, all installed Linux systems may use the same swap partition. Otherwise you may have to set up 2 partitions as swap partitions, since the format changed once in the past (I don't remember when exactly - just keep one spare partition as fallback if you intend to install historic Linux distributions later and experience problems with the swap partition format)

I know the first stage boot loader will make basic hardware initializations and calls the second stage boot loader like u-boot. But I still do not understand for why we need multiple stages of boot loaders.

Why can't we have only one boot loader, where we flash a single image to initialize the hardware? What would be the disadvantages going with only one stage of boot-loaders loading the kernel image directly?to make it more clear am using ARM CORTEX A8 for beagle bone black where I place MLO,U boot and kernel image in a boot Portion,as far as my knowledge first stage boot loader initializes your external RAM, where U-boot is copied,which initializes some more peripherals,why I cannot go picking up the kernel image directly instead of second stage boot loader

For example, you might want to load your operating system from a filesystem. Code to handle a filesystem might not fit in your first bootloader but code to load a second bootloader does fit. You would put all your filesystem code in the second bootloader where you have more flexibility and get your first bootloader to load it instead.

The other reason is probably upgradability of the bootloader. Bootloaders aren't perfect and there could be bugs. You could have your first bootloader configured to load a second bootloader and maybe some recovery utilities. Then you could chuck the first bootloader onto a ROM and never touch it again. If you find a bug, you can just upgrade the second stage bootloader. If you brick your system, you still have the first bootloader for recovery.

In the case of the AM3359 used in the Beaglebone Black, the first stage is actually being performed by the internal 64KiB boot ROM. Depending of the value being read from the SYSBOOT configuration bits, it will attempt to load the MLO from various possible sources and start executing it - see chapter 26 of the AM335x Technical Reference Manual.

From this point, if you don't want to use the de facto standard u-boot bootloader, nothing does prevent you to write your own equivalent of the MLO/u-boot-spl that would initialize the SDRAM and load the kernel, provided that both code and data would fit in the internal 128KiB SRAM.

This can probably be done by re-using the minimal amount of u-boot code required to do so,or if this is still too much code, by writing functionnaly equivalent code in C using the AM3359 Starterware library, or ultimately in ARM assembly code if desesperately needed.

But because this would require a lot of time, most people find more convenient to reuse the excellent u-boot bootloader, even though it has to be split into MLO/u-boot-spl and u-boot parts in order to be usable on the AM3359 and its 128KiB internal SRAM.

2)in Embedded systems another concept for multistage bootloader , in this if there is NO-FLASH memory on board then we have to boot from different devices to rootfile system ,kernel images may be on SD-card,USB-pendrive,on Network or another external device,in this condition,x-loader(first bootloader only sense where is the images and primary initialization and up to 2-bootloader(u-boot) it will fetch images from different resources)

Thats strange, I also run dual boot but my windows system assigned 500 MB as EFI system for the boot-loader. In the long run might be worth it, more flexibility to install the distro of your choice in case the boot-loader needs a partition with this space.

Thank (to pebcak as well), and I look forward to seeing what you see. Might be a change to the Windows installer since I have ran it, or maybe it was an OEM install. I have looked at a bunch and it was never 500 from a clean Windows install. P.S. I am running EFI, and not legacy in case you were wondering.

Strangely I have two efi partitions one for win 260MB on ssd1 and one for EOS of 300 MB on ssd2, the linux bootloader used 896KiB. Was not aware that I can dual boot with two separate efi partitions but EOS setup things automatically so that it works nicely together!

I chose erase and install, and made sure to select the second ssd. In your case I would first create an empty partition in windows then install on that one, it will be easier to avoid a mistake. If you need more tweaking, I would also choose other, then you can add a home partition swap etc.

You bring up an interesting thought as well. I have been hesitant to do the Linux on a separate drive method. I currently have both Windows and Linux Core files on my 256 GB SSD, and my 1TB HDD is partitioned for both a Windows side and Linux side along with a mount on boot for the Linux side. I could put Linux completely on the HDD while still leaving a bit for Windows. Not sure how well Grub will play with two Bootloaders. Of course, I would have to fix the Windows bootloader after deleting the existing Linux partitions and then start from scratch with the dual boot including a 500MB+ bootloader for the Linux drive. Any advice before I potentially ruin my Windows install would be great.

That was my original thought except for to use the Windows bootloader to house both. I did already have /, swap, and home partitions on the Elementary install. I should just be able to select the existing ones and select format for the / and home partitions while installing Endeavour.

I've tried to install various distros on my laptop quite a few times. As a result, some pretty weird stuff has happened regarding my bootloader. Or rather, my bootloaders. Note that I am not dual booting.

Whenever I turn my computer on and choose Ubuntu from the (first) GRUB menu, it says error symbol 'grub_efi_secure_boot' not found. But if I go to my computer's BIOS/UEFI settings, and exit, it shows two OS bootloaders on the same hard drive (I have one 256GB SSD): GRUB and ubuntu. When I choose GRUB, it takes me to the first, broken bootloader. But when I choose ubuntu, it boots perfectly fine into Ubuntu 20.04.

I've tried boot repair from a live USB, and it did nothing. My theory is that I have one bootloader on /dev/nvme0n1, and one in /dev/nvme0n1p1 (which is mounted to /boot/efi). However, I have no idea how to confirm this or fix anything.

If you need a custom bootloader, what you can do is write your own and link it to flash sector A. This is the flash sector where the jump-to-flash destination is. When the ROM bootloader jumps to the destination address, you put a branch there that then jumps to your "Secondary" (custom) bootloader. You can then do whatever you need to do.

The idea here is that you do not re-flash sector A in the field, ever. That way, your secondary bootloader is always intact and valid after a reboot, even if you were in the middle of field flash reprogramming.

Just to make sure we're both thinking the same here, you are going to write two different code projects. The first is your secondary bootloader. It incorporates the flash API algorithms and is capable of re-flashing your main applications. The secondary bootloader resides in flash sector A (and if it doesn't fit, you spill into sector B, etc.). The second is your main application project, and it resides in any/all of the flash sectors except those used by the secondary bootloader. The two projects are completely independent. RAM can generally be re-used (both projects can use the same RAM, since they do not both run at the same time). There is more information on this in a number of different forum threads. Here are a couple of them:

3a8082e126