Skip to content

Instantly share code, notes, and snippets.


deterenkelt/Grub2 setup

Last active Jun 13, 2020
What would you like to do?
Grub2 setup
This guide helps to install the Grub2 bootloader, so that
- it would work for both BIOS and UEFI systems;
- for both 32-bit and 64-bit platforms;
- it would be possible to create a disk image with a rescue
system, that could be dd-copied on a flash stick;
- it would write a single and small Grub2 config file, the
way that it could be done with Grub1 –
NO grub.d/
NO obscure compiling for a simple config file
Keep it simple, baka.
I. Medium preparation
II. Partitioning
III. Creating filesystems on partitions
IV. Mounting partitions
V. Installing Grub2
VI. Writing the Grub2 configuration file
VII. Unmounting partitions
VIII. Detaching the hardware drive
A. Installing grub on a disk image file
B. Grub configuration file tips and quirks
I. Medium preparation
If you’re installing onto a hardware drive, that had Windows before,
it’s better to do an erase on the disk, because Windows bootloader leaves
something, that confuses grub2 and may lead to it being unable to perform
installation on it.
# lsblk
# dd if=/dev/zero of=/dev/sdX
II. Partitioning
A bootable drive has to have three partitions in order to be
compatible with both BIOS and (U)EFI:
- “BIOS boot” partition – for Grub2 to know where to embed its
loader. This partition must have “LegacyBIOSbootable” flag,
to be sure that a BIOS, that may check not only the MBR on
the drive, but also the first partition, that MBR mentions,
would find there a bootable one;
- “EFI boot” where UEFI will look for EFI images;
- a partition for Grub2 files: its config file, filesystem modules,
modules for drawing a CLI, fonts. This partition will also
hold the files to which the bootloader will handle over the
control: that may be kernel blobs, initramfs images, rescue
CD .iso files, memtest86+…
The partitions will be created with “fdisk”. Start it:
# fdisk /dev/sdX
“fdisk” is controlled by one-letter commands. Type “m” to acquaint yourself
with the list of commands. When ready, print the disk information to verify,
that it’s the drive you need.
If the drive has unwanted partitions, delete them with “d” command.
Create a GUID partition table (or simply “GPT”. This is a modern rep-
lacement for the old MBR partition table). GPT will leave first sectors
on the disk empty, reserved for MBR. This allows the disk to boot on both
UEFI and BIOS systems. This is helpful, for the drive may be easily removed
and attached to you older computer, or if one day UEFI breaks (or you’d
wish to disable UEFI boot), you can run your motherboard in BIOS-com-
patible mode – and the drive will still boot.
Create a partition that will be “BIOS boot”. 1 MiB is enough. The com-
mand below says that “partition number one starts at 2048 sectors from
the beginning of the disk and goes for 1 MiB”. (The number 2048 is typi-
cally suggested by “fdisk” itself, and may vary. The offset of 2048 sec-
tors comprises the space, that GPT reserves for the MBR and for itself.)
n 1 2048 +1M
Grub2 will use “BIOS boot” partition to store code for booting from MBR.
(The legacy way, for better compatibility.) The MBR is small, so it may have
only a small portion of the bootloader code, around 200 bytes. This is what
in Grub terms is called “stage1”. This is not enough to run a full-fledged
program to draw a menu, offer a simple command line, chainload other systems,
so any MBR bootloader would typically store the bulk of its code somewhere
behind the MBR. And Grub2 will use this partition for this purpose. This is
called “stage1.5” in Grub terms.
Next, a similar partition, but for the EFI bootloader has to be created.
The command below tells “fdisk” to create a “partition number 2, that
starts at sector 4096 and guess for 3 MiB”.
n 2 4096 +3M
This “EFI boot” partition takes the same role as “BIOS boot”, and may be
only a little larger than the latter. Typically you won’t need more than
one EFI image on that partition, as all EFI systems are now 64-bit, and
32-bit EFIs existed only for a short time and weren’t widespread, but
just in case, or to have a backup when you switch distros, it’s better
to have a partition, that can accommodate 2–3 EFI images, and as each
image takes about 0.7–1.1 KiB, a size of 2–3 MiB is a reasonable choice.
Some guides tell to create very large EFI partitions, up to 100–300 MiB.
This is needed only for systems, that boot directly from the EFI partition:
for them the EFI partition is not just an intermediate stage of a bootloader,
for them it takes functions of a partition that holds the kernel image, the
initramfs image, their versions and backups. This of course, takes space.
But with Grub2 bootloader EFI images are lightweight and kernels and initramfs
images go to a separate partition, that will be created next in this guide.
Create the third partition, that will hold grub files (its configuration file,
filesystem modules etc.) and kernels, initramfs images, memtest86+ or rescue CD
.iso files depending on what’s needed. Choose the size according to what you need:
- Grub2 modules will use 12–15 MiB (you may delete some filesystem modules
after installation to make it approach the lower border, in case that
you’re constrained in space);
- a set of a kernel image, and config file will take 8–10 MiB
 ⋅ 4.5…5.5 MiB for the kernel;
⋅ 3 MiB for;
⋅ 0.15 KiB for the kernel config file.
Add 5–10 MiB to this, if you’re using an initramfs (the size may vary depen-
ding on the way you generate it). Multiply that size on the number of backups
(or alternative versions from distros installed in parallel to the main one).
- if you create a rescue flash stick, then you don’t need kernels or initramfs
images there, but instead you place the .iso file here (as is), so check its
size. With SystemRescueCD you may also wish to add ≈200 MiB to this partition
to keep a storage file, to which you’ll store changes made at runtime.
On a single-OS desktop system 30 MiB is enough to hold Grub files, memetest86+
and two sets of kernel blobs with accompanying files ( and config).
So you wish at least a 40 MiB partition. For a rescue stick go with a minimum
of 1 GiB.
n 3 10240 +40M
Distribute the rest of the space according to what’s needed. A desktop or a ser-
ver system would need at least two partitions for mountpoints / and /home and
maybe a swap partition. On a rescue flash stick no partitions needed, but it’s
probably a good idea to make a partition there to use it as a regular flash stick.
Maybe two partitions: one with ext2 for Linux and one with NTFS for Windows.
Now partitions are created, but they need to be marked with byte
sequences, that would tell BIOS or EFI about their purpose. The “x”
command below tells “fdisk” to go into deeper menu with an extended
set of commands.
t 1 4
Changed type of partition 'Linux filesystem' to 'BIOS boot'.
t 2 1
Changed type of partition 'Linux filesystem' to 'EFI System'.
A 1
The LegacyBIOSBootable flag on partition 1 is enabled now.
Next, you’d probably want to set UUID for partitions. They already have
a randomly generated UUID, but there are several reasons to changes them
to something more meaningful and simple. A regular UUID is a set of hexa-
decimal numbers (from 0 to 9 and A to F) set in five groups separated with
hyphens, e.g. 12345678-1234-1234-1234-123456789012.
There is but a single case, when a partition UUID comes useful, but it’s
crucially important moment in the boot process. A partition UUID is the
only way to directly point to the Linux kernel from Grub, where its “/”
mountpoint resides.
Kernel of course accepts the path as “/dev/sda4”, for example. However,
neither “/dev/sda4”, nor “/dev/sda”, nor “/dev” itself exist yet at the
time, when grub is ready to handle over the control to the kernel. Grub
doesn’t guarantee – and it cannot guarantee – that “/dev/sda4” would be
found. To circumvent this and specify the “/” mountpoint by a filesystem
label (or filesystem UUID), some people use an initramfs image. But it
isn’t necessary, as the Linux kernel can find the proper device and par-
tition by the partition UUID. (And this guide will employ that.)
This makes the single good use for a partition UUID. For the rest of the
mountpoints neither partition, nor filesystem UUIDs are of any value –
once the kernel handles the control over to an init system (usually this
is /sbin/init) and it starts to mount other filesystems, their labels are
better identifiers than UUIDs.
Passing the root partition UUID to the kernel is helpful mostly for portable
or rescue operating systems, that usually are installed on a flash stick.
(So that it would always find its root partition – independently of who is
/dev/sda today). There is a number of cases, when this approach comes handy
even or a PC/laptop:
- USB drives were left before HDD/SSD in the boot order in BIOS/UEFI.
You accidentally forget a flash stick, turn off your computer –
and when you turn it again, the device order has changed.
- You bought a new 15 TiB for your rig, you turn the computer off,
insert the drive, connect it, turn the power on – and it happened so
that the disk controller sees the new drive before the old ones.
- You attached an external drive to your laptop. Would you like to detach
it every time your laptop boots?
Tip: the first block of number in the UUID sequence is suitable
to hold the date in the YYYYMMDD format. To the second block you may add
the partition number by order, e.g. to have
# … 20170724-0001-0000-0000-000000000000
# … 20170724-0002-0000-0000-000000000000
# … 20170724-0003-0000-0000-000000000000
# … 20170724-0004-0000-0000-000000000000
Now the command to change the UUID on partition 4 with “fdisk” would be
u 4 20170724-0004-0000-0000-000000000000
Once done, verify the partition table.
No errors detected.
(For any remaining partitions the type will remain “Linux filesystem”
which is fine for /, /home and swap.)
Return to the main “fdisk” menu and view the information about
the partition with your own eyes before writing it to the disk.
i 1
Device: disk1
Start: 2048
End: 4095
Sectors: 2048
Size: 1M
Type: BIOS boot
Type-UUID: 21686148-6449-6E6F-744E-656564454649
UUID: B59E96AF-F437-41B9-8FEC-90B5E9EC7C38
i 2
Device: disk2
Start: 4096
End: 10239
Sectors: 6144
Size: 3M
Type: EFI System
Type-UUID: C12A7328-F81F-11D2-BA4B-00A0C93EC93B
i 3
Device: disk3
Start: 10240
End: 6291422
Sectors: 6281183
Size: 40M
Type: Linux filesystem
Type-UUID: 0FC63DAF-8483-4772-8E79-3D69D8477DE4
UUID: 01234567-8901-2345-6789-012345678901
Write the partition table to the disk.
III. Creating filesystems on partitions
The first partition, “BIOS boot”, must remain a raw space.
The second partition, “EFI boot”, must have a FAT16 or a FAT32 filesystem.
The command below creates one with the minimum amount of reserved sectors
(-R 2), a sector size of 512 bytes (-S 512) and labels it as “EFI_PART”.
Change the X in “/dev/sdX2” to your drive letter.
# mkfs.fat -R 2 -S 512 -n EFI_PART /dev/sdX2
*Some distros may have “mkfs.vfat” instead of “mkfs.fat”.
For the third partition, that would hold Grub files, create an ext2 parti-
tion. Replace the X in “/dev/sdX3” to your drive letter.
# mkfs.ext2 -L BOOT_PART \
-m 0 \
-b 4096 \
-U 00112233-0011-0011-0011-001122334455 \
For the root partition (Linux “/” mountpoint) on a desktop/server system
the following options are recommended. It enables journalling (-j), sets
a label (-L ROOT_PART), reserves 5% of disk space for the “root” user (-m 5),
sets the filesystem sector size (use the physical sector size of your
drive here, in this example it’s 4096), sets options for large files support,
indexing and amount of superblocks (-O <…>), -N sets the number of inodes.
Inodes may take up to gigabytes of space, and for a root file system you’d
need about 300’000, if you mount /tmp and /var/tmp as tmpfs, set to a mini-
mum of 500’000 otherwise. If you want to keep on the root filesystem LXD
images, multiply that number on the amount of operating systems that you’re
going to virtualise. If in doubt, don’t include the inode number and allow
mkfs.ext4 grab several gigs of your space.
Set the filesystem UUID equal to the partition UUID it resides upon, if you
wish to boot the kernel without an initrd and make the system boot indepen-
dently of the boot order. To retrieve the partition UUID, you may use the
following snippet:
# blkid /dev/sdX4 | sed 's/.*PARTUUID="\(.*\)".*/\1/'
The UUID can then be copypasted in the following command:
# mkfs.ext4 -j \
-m 5 \
-b 4096 \
-O dir_index,extent,^extra_isize,huge_file,^large_file,sparse_super2 \
-N 500000 \
-U 20170724-0003-0000-0000-000000000000 \
If you’re on a terminal, that doesn’t support copypaste (or you don’t know
how to do that), the UUID retrieving snipped can be turned into a function
that you can pass the path to the drive:
# partuuid() { blkid "$1" | sed 's/.*PARTUUID="\(.*\)".*/\1/'; }
then in the mkfs.ext keys:
… \
-U $(partuuid /dev/sdX4) \
It’s good to give filesystem labels easily identifying a particular
partition on a particular machine. Imagine yourself migrating the OS
from an old drive to a new one. You don’t want to have two disk with
partitions called ROOT_PART on both of them. Give them a prefix like
HOME1_ or MYPC1_, so that when you’ll be moving your files to another
drive, the number there (e.g. HOME2_, MYPC3_) would be telling you
which disk is the new one.
For the /home and storage partitions use a similar command, except:
- use “-m 0” to not reserve space for root: the /home partition
is usually the largest, so you’ll lose a big chunk of space,
if you allow mkfs to reserve space for root there. (Reserving
space for the root user makes sense only for / and /tmp, but
not for /home. mkfs reserves space on *any* partition by default,
because it assumes, that /home may be not separated from the /.)
- set the number of inodes depending on content type that you’re
going to store:
⋅ large files (like TV shows, DVD, blurays): go with 1’100’000
per 3 TB.
⋅ mixed files (video, pictures, music): 1’500’000 per 3 TB
⋅ many small files (any type), your ~/, your ~/Desktop:
750’000 inodes per 100 GB. Your $HOME is going to hold
various caches in the dot-directories, so the partition
selected to hold it will be ridden with a lot of small
trash files, that will pile up for years (everyone likes
thumbnails, but do you clean them at least once in six
IV. Mounting partitions
Create mountpoints. (Only the partitions no. 2 and no. 3 are mounted.
The first partition “BIOS boot” remains a raw partition.)
# mkdir efi_part grub_part
# mount /dev/sdX2 efi_part
# mount /dev/sdX3 grub_part
V. Installing Grub2
Make sure, that you are using Grub2 (and not Grub1 aka legacy Grub)!
The old Grub (Grub1, Grub Legacy) has a maximum version 0.99, and
Grub2 for a long time kept “the tradition” and went with a version, “Grub2” was an unofficial name. Currently Grub2 has a version
Steps V.a, V.b and V.c are to be followed one after another on every
system, independently of whether you’re installing on a disk image file
or onto a hardware drive.
Note, that unlike with Grub1, with Grub2 the command grub-install runs
for the entire drive /dev/sdX, not on particular partitions.
V.a. Install the MBR-compatible version of Grub
# grub-install --target=i386-pc --boot-directory=./grub_part/ /dev/sdX
Installing for i386-pc platform.
Installation finished. No error reported.
V.b. Install the EFI image (64-bit version) of Grub
# grub-install --target=x86_64-efi --removable --boot-directory=./grub_part/ --efi-directory=./efi_part/ /dev/sdX
Installing for x86_64-efi platform.
efibootmgr: EFI variables are not supported on this system.
efibootmgr: EFI variables are not supported on this system.
Installation finished. No error reported.
You can ignore messages about “EFI variables”, these warnings won’t
prevent the disk from booting successfully.
V.c. Installing the EFI image (32-bit version) of Grub
# grub-install --target=i386-efi --removable --boot-directory=./grub_part/ --efi-directory=./efi_part/ /dev/sdX
As it was said above, 32-bit EFIs are pretty rare, and Grub, if it
will not find a 32-bit EFI interface on the system, may fail with
an error (though it still will install the files). Unless you really
have a rare 32-bit EFI, you may ignore these errors, 64-bit EFI image
is what most people need.
V.d. Fixing the names of the EFI images
Grub creates files named grub*.efi, and those may be not recognised
by the EFI firmware… without some additional tricks, for which you’d
need a separate tool to fix brains in the EFI itself. The easiest way
to make it boot is to simply change the file names to be standard ones.
# cd ./efi_part/EFI
# mv gentoo boot
# mv boot/grubx64.efi boot/bootx64.efi
# mv boot/grubia32.efi boot/bootia32.efi
# mv boot/grub.efi boot/boot.efi
# cd ..
VI. Writing the Grub2 configuration file
The configuration file starts with a piece that is common for any type
of installation, be it desktop, server or a rescue system.
Copy to ./grub_part/grub/grub.cfg:
# Grub2 configuration file
if [ -s $prefix/grubenv ]; then
if [ "${next_entry}" ] ; then
set default="${next_entry}"
set next_entry=
save_env next_entry
set boot_once=true
set default="0"
if [ x"${feature_menuentry_id}" = xy ]; then
export menuentry_id_option
function load_video {
if [ x$feature_all_video_module = xy ]; then
insmod all_video
insmod efi_gop
insmod efi_uga
insmod ieee1275_fb
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
if loadfont $font ; then
set gfxmode=auto
insmod gfxterm
set locale_dir=$prefix/locale
set lang=en_US
insmod gettext
terminal_output gfxterm
insmod gzio
insmod part_gpt
insmod ext2
insmod search_fs_label
insmod search_fs_uuid
# The root variable here refers to the partition, on which the “grub”
# folder resides along with the kernel and initramfs images, .iso files
# (if any). It’s not the linux root, i.e. the “/” mountpoint. This “root”
# refers to a partition that’s typically mounted to /boot on a running
# system.
# The “linux root”, i.e. the drive and the partition for the “/” mount-
# point doesn’t concern Grub, as Grub kicks either a kernel/memtest86
# blob, or an initramfs image, or a bootable .iso file – and none of
# these things reside on the “/” mountpoint. They’re all here, in the
# to-be /boot.
search --no-floppy --set=root --label BOOT_PART
The remaining part would slightly differ, depending on the type
of installation.
VI.a. Example setup for a desktop/server system
set default=new_gentoo
set fallback=1
set timeout=7
# Retrieve filesystem UUID by a human-readable label, then
# pass it as partition UUID to the kernel as “root” parameter.
search --no-floppy --set=linux_root_dev --label ROOT_PART
probe --fs-uuid --set=linux_root_fs_uuid ($linux_root_dev)
menuentry 'Gentoo Linux 5.6.7-gentoo-i55' --id new_gentoo {
linux /vmlinuz-5.6.7-gentoo-i55 root=PARTUUID=$linux_root_fs_uuid rootflags=data=journal,errors=remount-ro,barrier=0 vga=0x318
menuentry 'Gentoo Linux 4.5.6-gentoo-i55' --id old_gentoo {
linux /vmlinuz-4.5.6-gentoo-i55 root=PARTUUID=$linux_root_fs_uuid rootflags=data=journal,errors=remount-ro,barrier=0 vga=0x318
This sets up two menu entries, “new_gentoo” and “old_gentoo”, the former is
set as the default and the latter is chosen as fallback (fallback values
start with 0). Timeout before the boot is set to seven seconds.
This will work only if partition UUID would match the filesystem UUID, like
it was shown in part III of this guide. In case you got a system on which
those UUIDs don’t match, you can define linux_root_fs_uuid manually, after
retrieving the value with “blkid” (see part III above).
set linux_root_fs_uuid=<UUID>
If your installation would still require an initramfs to boot, then that init-
ramfs should handle the mounting of the Linux root partition, and those images
typically do that by LABEL or UUID. (You don’t need “search” and “probe” com-
mands.) The menuentry item would look like this:
menuentry 'RedHat Linux 1.0' --id redhat {
linux /vmlinuz-2.6.32 root=LABEL=ROOT_PART rootflags=data=journal,errors=remount-ro,barrier=0 vga=0x318
initrd /initram.igz
The syntax in the Grub configuration file is full of quirks, so it’s recom-
mended to follow this guide to the letter. If you’re going to make any sub-
stantial changes, read the Addendum B – some common quirks and inconsisten-
cies are explained there.
VI.b. Example setup for a rescue flash stick
set default=rescue_64
set fallback=1
set timeout=3
menuentry 'Rescue CD 64-bit' --id rescue_64 {
loopback loop /sysresccd-5.3.2.iso
linux (loop)/isolinux/rescue64 isoloop=sysresccd-5.3.2.iso setkmap=us nonm scandelay=1
initrd (loop)/isolinux/initram.igz
menuentry 'Rescue CD 32-bit' --id rescue_32 {
loopback loop /sysresccd-5.3.2.iso
linux (loop)/isolinux/rescue32 isoloop=sysresccd-5.3.2.iso setkmap=us nonm scandelay=1
initrd (loop)/isolinux/initram.igz
Note that the paths to the kernel and the initramfs images lead inside the
loop device, that is created beforehand for the .iso file. There is nothing
but the “grub” folder and the .iso file on the partition.
VII. Unmounting partitions
# umount efi_part
# umount grub_part
VIII. Detaching the hardware drive
If you were installing Grub on a removable USB drive, you need to detach
it safely. Otherwise it won’t be guaranteed, that everything was written
to disk properly.
# udisksctl power-off -b /dev/sdX
A. Installing on a disk image file
A.1. Creating an image
This command creates a 3 GiB sparse file (the file will grow only as
it’s written into). It can be used instead of a hardware drive.
$ dd if=/dev/zero of=disk.img bs=1G seek=3 count=0
“ls” should report the file size as empty, as nothing has been
written to it yet.
$ ls -slah disk.img
0 -rw-r--r-- 1 user user 3.0G May 25 19:56 disk.img
A.2. Creating filesystems on partitions
First, the disk image has to be turned into an actual device, loop
device in /dev/. This can be done with the following command:
# losetup --partscan --find --show disk.img
The partitions will be accessible as “/dev/loop0p1”, “/dev/loop0p2”
and so on. Partitions start with 1, like with /dev/sdX* ones.
A.3. Unmounting the loop device created for the disk image file
# losetup -d /dev/loop0
A.4. Packing the disk image file
If you’d need to pack the raw disk image file (for example, to upload it
to a service, that allows uploads only of archived files), you would pro-
bably use “tar”, and in order to preserve sparseness, that is, to prevent
accidentally blowing the file size to the space it claimed, rather than
what it actually takes, a special key must be added to the “tar” command.
# tar acSf disk.img.tar disk.img
A.5. Testing the disk image file
Before writing the disk image to a flash stick it would be nice to
test it first, in order to ensure, that it boots. You can use Qemu
for this purpose:
# qemu-system-x86_64 -enable-kvm \
-cpu host \
-smp 1,cores=1,threads=1 \
-boot order=d \
-m 1024 \
-drive file=disk.img
B. Grub configuration file tips and quirks
Before all, note, that though the configuration file has some resemblance
with a shell script, the language isn’t Shell.
Tip: you can see, what value a variable was assigned, when Grub was loading,
by adding it to a menuentry title. Note the double quotes:
menuentry "Test entry. root = $root" --id test {
Quirk: search command and spaces. Despite that it looks like a normal command:
search --no-floppy --set=linux_root_dev --label ROOT_PART
it is not. “ROOT_PART” is not actually an argument to --label, it’s a free-
standing argument. Parameters to the “search” command take no arguments,
that’s why you have to use “=” with --set: so it would be read as a single
Quirk: search command and parameter names. Even though there are commands
(or, more precisely, aliases) “search.fs_label” and “search.fs_uuid”, their
dashed equivalents are --label and --fs-uuid – there is no --fs-label. Grub
will silently fail on search command, if you’d use --fs-label.
Quirk: inability to retrieve the partition UUID as easily as filesystem UUID.
Before going to the difficulties related to Grub, a couple of words must be
said about the kernel. The syntax to its “root” parameter is explained in
/usr/src/linux/Documentation/admin-guide/kernel-parameters.txt as follows:
root= [KNL] Root filesystem
See name_to_dev_t comment in init/do_mounts.c.
The file init/do_mounts.c will tell us that kernel has no means to find
a partition by filesystem label or filesystem UUID. It seems that working
on the partition level brings less complexity to the boot process. Anyway,
the partition UUID is the only thread left to one who doesn’t want to use
an initramfs and still wants a system booting stably and withstanding chan-
ges to the boot order of the drives.
Now for the Grub part. Its “probe” command has only a parameter to retrieve
the filesystem UUID, there is no parameter to retrieve the partition UUID,
In the vast abundance of utilities, that Grub offers at the boot stage, there
are “ls”, that can print PARTUUID for a specific device and there is “regexp”,
which can cut the relevant chain of symbols from the “ls” output. But there
is no way to glue these tools together, as the language of the configuration
file is not really shell. The closest you can reach to is “eval”, however
it wouldn’t allow you to glue “ls” and “regexp”, even if you’d use a variable
to store an intermediate result. (You’d have to use “eval set varname=” and
the “set” command requires that the variable name, the equals sign and the
value would all be a single string, which puts a cross over the eval’s cap-
ability to substitute command output as a parameter for another command.)
It’s also futile to attempt to avoid “set” in favour of “setparams” and do
an “eval setparams ls” within a function. The Grub developers didn’t offer us
means to easily boot our systems without an initrd. The way Grub2 is made
implies that you’re intended to use grub-mkconfig, so that it would compile
a damn text file that is grub.cfg. They think that this is more handy than
using --part-uuid to “probe”. This is absurd, but that’s how it is.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.