I don't want to say this but I'm not sure what I need to know exactly. I kind of know how to get things going but now I'm facing problems that I can't solve & have questions that I can't answer.

My current setup; I have a machine with a grub and two ubuntus. It has an ssd & an hdd. Ubuntu's on a partition in the ssd. I think everything is GPT. Enjoy my questions below...

-----------------------------------------------------------------------------------------------------------------------------------

When I first installed ubuntu, it installs grub with it. Where does grub go? How do I search for it on my system?

Are there maybe two ways to install grub depending on whether I'm booted in efi mode or legacy mode? ...is there even such a thing as those "boot modes"? If so, how do I find out the way grub's installed? How do I boot something in the "boot mode" I desire?

Is there a specific memory structure for efi systems & another for legacy? Meaning; maybe the location of grub depends on whether I installed it in efi mode or legacy mode?

I know that grub cannot "configure itself". Ubuntu can do the detection of OSes & configures grub to boot from them. How does it do that? If I have a live usb I have to mount things and change root, why? I mean what if there are two grubs? Which one would it configure?

How does grub boot windows? What I know is that it points to the windows boot loader which then boots windows. Where's the windows boot loader then? Didn't grub "replace" it when it was installed? Where's what? What's where? Why? How? Wah? How do I "detect"? How do I see the "map" of the boot-loaders I have?

Also what is the master boot record (mbr) in all this??

When I startup the bios, I know I can choose "which hard disk" to boot from, but I see more options, what are those?

I have an ubuntu live usb that apparently I can only boot in legacy mode. But I can't see it if I "disable legacy support" from the bios. Why? How do I boot it in efi mode?

Here's the inspiration for this thread just in case you wanna know. hehe X) https://bugs.launchpad.net/ubuntu/+s...s/+bug/1662861

https://help.ubuntu.com/community/Grub2/Setup for starters.
https://help.ubuntu.com/community/BootFromCD for boot media.
https://help.ubuntu.com/community/In.../UEFI-and-BIOS for that.

I think only 64 bit Ubuntu supports [U]EFI

Don't hold me to the fire on that.

Grub can be installed a number of different ways, generally installing to disk is recommended. It's usually mounted at /boot/grub or similar. To determine if you are booted in efi, run , If the directory does not exist, the system may be booted in BIOS or CSM mode. Generally if you are using efi, your disks are probably GPT.

Generally Grub boots Windows by chainloading the Windows bootloader, but it is also possible to use the Windows bootloader to boot linux, or to use Grub to boot Windows, though these last two options generally require extra steps to setup. The Windows boot loader should be with the rest of the Windows partitions. I don't believe Windows supports boot on a separate disk from the rest of the (Windows) installation. I'm not aware of any way to see a "map" of the bootloaders installed.

The Master Boot Record (MBR) is the first 512 bytes of a storage device. It contains an operating system bootloader and the storage device's partition table. It plays an important role in the boot process under BIOS systems. This is comparable to the ESP (efi system partition) on a GPT/UEFI system.

It's hard to say what the other options that you see in your BIOS are.

Recent versions of Ubuntu (Live) should be uefi boot compatible.

There is tons of information about efi booting and bootloaders here. The Arch Linux wiki also is a great resource

lots of good questions.

Search for the various Grub files by entering either of these commands: whereis grub, locate grub
The boot files of most concern to users are in the /boot/grub directory as indicated above.

With an efi system, you will have Grub files in the EFI partition which would also contain the files for other operating systems you have, either or Linux or windows. With an MBR install, code of one install will go to the MBR which will point to the other Grub files on the Linux system partition.

That is actually done by Grub scripts. The basic one is the grub-mkconfig and the update-grub is just a 'stub' which runs grub-mkconfig. There is also an 'os-prober' script to search for boot files. You can have any number of Linux installations with Grub on their system partition but with an MBR install, only one will have code in the MBR and that is the primary from which other systems boot, either directly or by chainloading.

Grub doesn't actually boot any windows system but rather 'chainloads' which simply points to the location on a partition where the boot files are and the windows boot files take over. You can also use a chianload command to boot any Linux which has it's Grub files on another partition. Grub does not replace windows boot files. If you have a windows install using MBR, installing Grub can overwrite the windows boot code in the MBR but it has no effect on the windows boot files on the windows partition unless the user mistakenly installs it to an ntfs partition. Grub won't do that so if it happens, it always a user error.

Mixing an MBR instal with an EFI install leads to problems and you will generally need to be pretty proficient with boot files to make that work.

All you want to know and more at the site below, GRUB2 MANUAL:

https://www.gnu.org/software/grub/manual/grub.html

Dual booting windows/Ubuntu UEFI info at the Ubuntu documentation site below:

https://help.ubuntu.com/community/UEFI

Let me try to set the stage for you ...

When you first switch-on your machine, the circuitry issues a Hardware Reset signal to the CPU(s), thereby placing all of them in "a known state." Every CPU/Core other than the first promptly freezes: the first one proceeds. This CPU now executes "various bits of initial business provided by the hardware manufacturer" – diagnostics and so forth – before finally settling down to the primary task at hand: "booting the system!"

In the early days, we referred-to this initial programming as "the BIOS" (Built-In Operating System), but that term's getting a little bit tired nowadays. These days we deal with "UEFI," which is more-or-less a defense against someone stuffing a USB-stick into a computer and thus successfully booting the system from that "stick," even though we didn't want him to be able to do that. "But, I digress ..." This layer of software will eventually find and select a "boot loader," and pass control to it.

If all goes well, Grub (being a "boot loader") will get control, and its primary duty is to give you a choice of which operating system you would now like to start. Grub's a pretty smart cookie: "he knows about file systems," and therefore he's able to find the /boot directory on a drive and to read and understand the files that are to be found in it. (Grub also has a pretty-serviceable set of "console commands" for your entertainment.)

So, after dutifully reading its configuration files. Grub presents you with a menu (and, after a specified number of seconds, moves on to some default choice). It then carries out the specified sequence of low-level commands that (the config-file says ...) are needed to select and launch your selected operating system. All of these steps are spelled-out in "ordinary files."

As others have already stated, Grub does not have to bear the entire responsibility. In the case of "The Operating System That Must Not Be Named™" ... ... it simply hands-over the keys to another "boot loader." Problem solved.

In either case: "(whatever) operating system's so-called 'trampoline' code is presented with exactly the initial environment that it has been programmed to expect." And, "it takes it from here." (Cowabunga!)

- - -

The really nice thing about Grub is that they really did a good job of it: Grub is a thorough and very well thought-out solution to "the overall booting problem, in all of its respects." Grub provides a very comprehensive set of tools (to maybe-diagnose boot-time issues), and, unlike its predecessor LILO, won't leave you in the lurch if you (oopsie!) "forgot to do something" before shutting down.

Without in any way "dissing" the LILO team, Grub (IMHO) really is significantly better. It's a sophisticated tool that is "there to help you, if it can," in exactly those situations where ... (and you know exactly what I mean if you've already been there) ... "sophisticated tools" are needed!

Definitely make it your business – very soon – to "get to know Grub." (And: LILO.)

1 members found this post helpful.

Many thanks to everyone. I've read your posts over and over, now I understand much better. I played around. I mounted the efi partition and browsed the files. I looked for grub's boot files on my system. Now I really understand most of what I didn't understand.

...Now what's left is to fix that partial upgrade. Another story. Wish me luck =)

I was always under the impression that the bios was a separate chip, a kind of miniature computer-within-the-computer with attached rom (containing the power-on self test and initial boot programs) and cmos ram (containing the bios variables). Is it actually part of the cpu then?

The bios is on the rom on the motherboard afaik. But we're mainly talking about bootloaders here, which is what the bios executes when it starts. I don't think it's a part of the cup.

BIOS (Basic Input/Output System) on PC's is nothing but a computer program for the processor. For many years, the BIOS firmware was usually found on a socketed integrated circuit. But it's nothing but a program that's executed by the computer's CPU. In a nutshell,

* Turn on computer
* CPU starts running BIOS/UEFI code doing POST checks, etc.
* BIOS/UEFI transfers program execution to an installed boot loader, usually by branching to whatever code is in the first sector of the boot media.
* Bootloader code takes over to load and start the desired operating system.

After the system boots, BIOS/UEFI code provides an abstraction layer of code for the operating system to allow interaction with the specific hardware on the particular motherboard.

1 members found this post helpful.

In the earliest computers, the process of "booting the system" was a very laborious affair that involved flipping switches and loading paper tapes. (It was quite interesting, especially when the precious tape jammed and went the way of all yellow paper things.) The CPU contained special features to initiate the startup process.

Later, things evolved into something that was much simpler: ROM = Read-Only Memory. The initial power-on process ceased to be a special-case for the CPU architecture: the designer of the motherboard simply needed a simple circuit to strobe the CPU's Reset pin and to be sure that the ROM was enabled. This caused the (primary) CPU to start executing instructions, which were supplied by the ROM. (Which, in some systems, could later be "turned off" and replaced by RAM.) This initial bit of ROM software launched the boot procedure, as well as things such as on-board hardware diagnostics (for which the original IBM PC was famous).

In the original IBM PC, this was called the "BIOS."

This is the layer of software that, for instance, finds the "master boot record" on a hard drive and loads and starts the software that leads to a boot-loader (Grub) finally being executed.

In systems with the "UEFI" feature(?), this is also the layer of software that enforces these restrictions.

In most computers today, the built-in (ROM) software is actually stored on "Flash ROM," which can be reprogrammed without physically replacing chips as was once done.

"Dual Booting" can be handled in several ways. One is to change the (BIOS-level) designation of which hard drive is checked for a master-boot record. This diverts the boot process to that particular device from the very outset.

Another way – much more common – is to set it up using the Boot Loader (Grub). Once Grub has control, it can be programmed in its configuration file to select the actual operating-system that is to be launched.

(And then, there is my preferred way to run multiple operating systems: virtual machines. But that's off-topic to this thread.)