11

Currently I have Arch and Windows with grub installed and configured. I'm going to make another Arch installation on a separate partition.

Do I need to install and configure grub again on the newly installed distribution or I can use the old one?

I suppose that if I continue using the old (current from this point of view) grub I'd have to configure it again so that it sees the new Arch installation.

What will happen if I format the current partition (with the old Arch installation)?
Will grub continue working or not (i.e. I'd need to boot some live-cd to fix it)?

To sum up: is grub installed on some general place independently from any OS, or is it tied to some (my current Arch installation).
Tutorials give this command: grub-mkconfig -o /boot/grub/grub.cfg which makes me think that grub is tied to the specific linux installation; but they also show a grub-install command without specifying any directory.

And if grub was tied to the current installation, how would my computer know which partition to check for grub? Otherwise, if it was "general", why would I have to "install" it as a package on the specific arch installation?

Improve this question
1
  • 2
    You need to be aware that on modern systems there is usually NO MBR. EFI systems boot things differently and no MBR in use. In fact, there is no BIOS partition table. This is specially true with larger hard drives, newer laptops and macs.
    – coteyr
    Commented Aug 23, 2016 at 22:21

3 Answers 3

Reset to default
15

Naming convention:

  • GRUB (some of it) stays in the MBR.

  • GRUB (rest of it) are several files that are loaded, from /boot/grub (for example: that nice image that appears as a background in GRUB is not stored on the MBR)

Notes:

  • The answer is considering an MBR setup, GRUB can be used in other setups.

  • In an EFI setup things get hairy, GRUB can be used, but so can be the kernel itself as its own EFI stub.

GRUB (some of it) is installed in the MBR. The MBR are the first 512 bytes on a disk. The MBR is also used by the partition table of the disk, therefore GRUB itself has somewhat less space than the 512 bytes.

The GRUB (some of it) inside the MBR loads a more complete GRUB (rest of it) from another part of the disk, which is defined during GRUB installation to the MBR (grub-install). Since the MBR GRUB needs to find its counterpart on disk, which normally resides on /boot, the partition where the main GRUB resides cannot be too far from the partition table (often 512MB but may vary).

It is very useful to have /boot as its own partition, since then GRUB for the entire disk can be managed from there.

What does it mean:

  • The GRUB on MBR can only load one GRUB (the rest of it) from disk.

  • That specific GRUB (the rest of it) on disk must be configured to find all OSes on the machine.

The command grub-mkconfig -o /boot/grub/grub.cfg runs os-prober (if it can find it) which scans all partitions and produces a grub.cfg pointing to all the OSes.

Therefore if you have several partitions with /boot (or the MS windows equivalents, I do not know them but os-prober knows) the os-prober will find them and create grub.cfg accordingly. Running grub-install install a GRUB (some of it) on the MBR that points to the GRUB of the current running OS with the current grub.cfg.

What does this mean:

  • You only need a single GRUB for the entire system.

  • You can have different GRUBs on different disks (since they have distinct MBRs) but that only makes sense if you plan to remove the disk.

  • You can manage the boot of all OSes from a single GRUB installation.

  • On a single disk you shall always run grub-install from a single OS only! That's important, otherwise you will keep overwriting your config.

Improve this answer
5
  • @Al.G. - Nope, it is a hard disk in all cases in the answer. GRUB has its own way of addressing partitions and hard disks. If you look in /boot/grub/grub/cfg you will see lines like: set root='hd0,gpt2' (that's hard disk 0 with a GPT partition where the partition 2 has the GRUB files). In other words GRUB (some of it) knows how to walk the partition table, it will select a hard disk, walk the partition, enter the filesystem and get the files.
    – grochmal
    Commented Aug 23, 2016 at 22:06
  • Yes, my grub.cfg contains multiple root= lines, but interestingly all of them follow this pattern: hd0,**msdos**{1,4,5}.
    – Al.G.
    Commented Aug 23, 2016 at 22:15
  • 1
    Grub does not always sit in the MBR, on EFI systems it sits elsewhere.
    – coteyr
    Commented Aug 23, 2016 at 22:17
  • 1
    @Al.G. - Yup, those are msdos partitions (not GPT), please ignore my esoteric setup os MBR+GPT (which is pretty bad, but hey)
    – grochmal
    Commented Aug 23, 2016 at 22:19
  • 1
    @coteyr - Correct. I just guessed from OPs question that no EFI was involved at all. I'll think of a way of updating the answer for other readers.
    – grochmal
    Commented Aug 23, 2016 at 22:20
10

Just to clarify: You're using grub2, correct?

In case Grub2 is installed in its own boot partition, you don't need to change anything. When it is not (which would be really strange), then you could technically retain the grub.cfg, and if your distribution has it, also /etc/grub.d.

/boot should be it's own partition, though. If you run mount and see something like this:

/dev/sda1 on /boot type ext4 (rw,relatime,seclabel,stripe=4,data=ordered)

You have Grub2 installed in its own partition, as it should be. Normally, when installing a new distro, the wizzard will usually guide you through the installation process, and even figure out what partitions contain what OS-es, if applicable. The process on Arch is a bit more tedious but very well documented.

In case horribleness ensues

Download GParted, put it on a USB stick, boot from it, and mount the /boot partition.

Then simply run as root (or with sudo):

grub-mkconfig -o /boot/grub/grub.cfg

Grub2 should be able to autodetect your partitions and act accordingly.

(At this point I'm not sure if partitions need to be all mounted for Grub2 to detect the OS-es on them, though)

If you tried to install Windows in the mean time, it might be Windows overwrote the boot loader. To fix that, simply run as root (or with sudo):

grub-install /dev/sdX

where /dev/sdX is the drive where your boot partition resides.

A little bit of explanation:

Grub2 is a Stage-2 boot loader. Meaning it's not exactly an operating system, but it's much more complex, than a simple chainloader, which would fit into the first 446bytes on your primary partition (the rest of the first sector is partition table, flags, etc.).

The MBR contains just the code to execute Grub2 code which resides on your /boot partition. Grub2 then either chainloads into another partition (for booting windows for instance, as it installs its own boot loader), but it can also run code (things like memtest), or access and run a kernel and module image (vmlinuz).

What's important to note, is that in both instances Grub2 is unloaded from memory once a kernel starts running, or another partition has been chainloaded.

Improve this answer
1
  • Thanks for your answer, the idea about separate partition for /boot was unknown for me, so I'll deffinitely give it a try. I'm accepting grochmal's as it's more descriptive, sorry for only being able to upvote!
    – Al.G.
    Commented Aug 23, 2016 at 22:10
3

Grub is not tied to a particular OS. It can reside on its private partition, though usually it's installed along the main file system. But for it to be able to boot your system(s), it needs to know about them. So you need to update Grub after any important changes in the systems present on your machine like a new OS installed or a kernel upgrade. If you delete the only Grub there is, you will not boot your system(s). There can be many Grubs on one machine, but only one is main, or active. Apart from Grub, there are other boot loaders that can be used (instead of Grub). Windows has its own boot loader, which can be set as the main one for the whole machine.

Improve this answer
3
  • If you delete the only Grub there is and usually it's installed along the main file system - so if I format my current arch installation (where grub is currently installed), grub will also disappear, right?
    – Al.G.
    Commented Aug 23, 2016 at 21:38
  • Yes. I updated my answer with some more details.
    – user147505
    Commented Aug 23, 2016 at 21:40
  • This answer is not totally true. The accepted answer explains why.
    – Quidam
    Commented Apr 23, 2020 at 2:21

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .