GRUB2
Contents |
Introduction
GRUB2 is next generation, a complete rewrite, of GRUB LEGACY popular GNU/Linux boot loader. The new version has a new shell like syntax which permit advanced scripting capabilities unlike the LEGACY version. So, even seasoned GRUB LEGACY users should take a look at what GRUB2 can do to take advantage of the powerful shell like scripting along with new features.
Upgrading to GRUB 2 might be necessary as it allows:
- booting from UEFI platforms;
- booting from GPT partitioned drives without even needing an awkward hybrid MBR, even though one can use one for compatibility/portability reasons;
- booting from directly logical volume management such as LVM2 support;
- booting from raid DM-RAID support for RAID [0?] 1, 4, 5, 6, 9 and 10 [or 1x?];
- and booting from encrypted devices, LUKS I assume because of the inexistent documentation despite the cypher/hash modules being there: so no guidance on a howto for the moment.
Installation
GRUB2 is both hard masked and in development, so one has to both keywords and unmask the package as the following before merging the package.
root # echo '<sys-boot/grub-9999 **' >> /etc/portage/package.accept_keywords
root # echo 'sys-boot/grub:2' >> /etc/portage/package.unmaskroot # emerge --ask sys-boot/grub:2root # echo '>=sys-boot/grub-1.99 **' >> /etc/portage/package.accept_keywordsElse, one would have to undergo a manual configure, make and make install on his/her own which won't be covered by this modest contribution.
Configuration
Partitioning and preparing boot disk
Before installing GRUB2 to the boot media a little care should be taken when preparing and partitioning the boot device be it an internal disk or be it a removable device. This depend on the boot type involved: BIOS or UEFI. BIOS booting can be easily achieved with either booting from disk partitioned with the aging MBR or with GPT with a protective MBR or a hybrid MBR if dual booting is involved with GPT unaware OS like MSDOS/Windows. It's another story for UEFI as GPT is part of UEFI specification and it's mandatory to use GPT partitioned disk in this case.
If dual booting is involved with Windows which cannot boot from anything else but BIOS/MBR or else on GPT partitioned disk only on EFI platform. In the later case--dual booting Windows--is simple and the former is trickier on a GPT partitioned disk with a hybrid MBR. More on this subject will come later.
Before going further, one could back up the boot device MBR with something like:
root # dd if=/dev/sda of=/root/sda.mbr bs=512 count=1or simply its boot loader with something like (here one can go as far as 446 bytes):
root # dd if=/dev/sda of=/root/sda.mbr bs=440 count=1Booting in [U]EFI mode require [0x]EF00 (EFI System Partition) partition, whilst booting from BIOS/GPT mode require a [0x]EF02 (bios_boot) partition. GRUB (either GRUB2 or a patched GRUB LEGACY) require as well an [0x]EE00 protective partition in the protective MBR if any to recognize a GPT partitioned disk (and this protective partition should be listed first in the MBR in the case of a hybrid MBR). And finally booting in BIOS/MBR does not require any additional partition, however, a gap (free space, a couple of sectors) should be left to embed core.img before the first partition if installing on a traditional `/dev/sd<char>' manner or before the partition if installing on a `/dev/sd<char><int>' manner. Here is an example of a GPT partitioned disk with BIOS boot [0xEF02] partition and an EFI [0xEF00] partition. the following is the output of the `p' command in gdisk main menu.
root # gdisk /dev/sdc
GPT fdisk (gdisk) version 0.8.1
Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: present
Found valid GPT with protective MBR; using GPT.
Command (? for help): p
Disk /dev/sdc: 976773168 sectors, 465.8 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): AA369F4D-37A4-4C0D-A357-DC24B99A6337
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 976773134
Partitions will be aligned on 2048-sector boundaries
Total free space is 2014 sectors (1007.0 KiB)
Number Start (sector) End (sector) Size Code Name
1 2048 828377087 395.0 GiB 8E00 Linux LVM
2 828377088 891291647 30.0 GiB 0700 Microsoft basic data
3 891291648 975177727 40.0 GiB 0700 Microsoft basic data
4 975177728 976754687 770.0 MiB 8300 Linux filesystem
5 976754688 976756735 1024.0 KiB EF02 BIOS boot partition
6 976756736 976773134 8.0 MiB EF00 EFI System
Command (? for help):
parted gives a somewhat different output with a slightly different semantics for the same device, here is the output.
root # parted /dev/sdc
GNU Parted 3.0
Using /dev/sdc
(parted) print
...
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Number Start End Size File system Name Flags
1 1049kB 424GB 424GB Linux LVM lvm
2 424GB 456GB 32.2GB Microsoft basic data
3 456GB 499GB 42.9GB Microsoft basic data
4 499GB 500GB 807MB ext2 Linux filesystem
5 500GB 500GB 1049kB BIOS boot partition bios_grub
6 500GB 500GB 8396kB EFI System boot
(parted)
Creating partions in gdisk is pretty straight forward for somebody who used fdisk. Just type `n' in the main menu, then provide a beginning and end sector if need be and then type the partition type EF00 for an EFI system partition for example. That's all.
Generating grub.cfg configuration file
At this point, you should generate GRUB2 configuration file before going further. If you're updating from sys-boot/grub:0 running the following command may be necessary.
root # grub2-menulst2cfg /boot/grub/grub.conf /boot/grub2/grub.cfgOtherwise, just run the following command to make use of automated GRUB2 scripts to get a fresh configuration file. You may disable a few unwanted/unnecessary scripts from `/etc/grub.d/' by disabling the executable bit.
root # chmod -x /etc/grub.d/<int_prefix>_<name>And or else add your custom scripts and set the executable bit to include them in the configuration generation. See GRUB2#Troubleshooting and Quircks.
root # grub2-mkconfig -o /boot/grub2/grub.cfgUEFI installation
Before setting up UEFI boot, one has to partition the boot device with a GPT compatible disk tools like GPT fdisk or gdisk, parted or gparted (a gtk gui) or other tools that I did not bother to try at this point. It's advised to have something greater than 200MB and maybe smaller than 500MB for multi boot systems. GPT disk is a powerful tools than can be used to setup a few advanced settings like hybrid MBR or the number of alignment sectors. The default 2048 sectors (1MiB) is a sane default which will permit to make use of sector 34-2048 to embed GRUB2 core.img for example if one forgot to leave some space for BIOS boot partition.
Let's move to installing GRUB2 and setting up an EFI boot entry. I do not have an EFI board so EFI specifc boot steps is not tested!
First, create a filesystem and a mount point for the EFI partition with something like:
root # mkdosfs -F 32 -n efi-boot /dev/sda1
root # mkdir /boot/efi
root # echo 'LABEL=efi-boot /boot/efi vfat defaults 0 2' >> /etc/fstab
root # mount /boot/efi
root # mkdir -p /boot/efi/{EFI/BOOT,GRUB2}And then install GRUB2 (x86 users should replace x86_64 by i386)
root # grub2-efi-x86_64-install --root-directory=/boot/efi --boot-directory=/boot/efi/EFI --bootloader-id=GRUB2 --no-floppyor install everything manually if something goes wrong.
root # cp -a /lib/grub2/x86_64-efi/* /boot/efi/GRUB2/root # cp /boot/efi/GRUB2/grub.efi /boot/EFI/BOOT/BOOTX64.EFIIt might be necessary to build a customized core.img with a few builtin modules to be safe or to satisfy specific requirements.
root # grub2-mkimage -p /grub2 -o /boot/efi/GRUB2/grub.efi -O x86_64-efi ext2 fat lvm part_msdos part_gpt search_fs_uuidBefore any attempt to add a menu entry to EFI boot menu, inserting EFI module and merge the utility is necessary.
root # modprobe efivars
root # echo 'sys-boot/efibootmgr **' >> /etc/portage/package.accept_keywordsroot # emerge --ask sys-boot/efibootmgrAnd then add an boot menu entry.
root # efibootmgr --create --gpt --disk /dev/sda --part 1 --write-signature --label "GRUB2" --loader "\\EFI\\GRUB2\\grub.efi"BIOS/MBR installation
Installing in this mode is straight forward as it's just like the legacy GRUB with new GRUB2 additions. Care should be taken for the first partition alignment. GRUB2 uses the gap between the MBR and the first partition to embed its core.img. If the disk is partitioned with recent tools, fdisk for example, the first partition should aligned to 2048 sector boundary. So the installation will go just fine. Otherwise, GRUB2 will rely on the `/boot' device to load core.img. In this later case something like:
root # mount /boot
root # chattr -i /boot/grub2/core.img
root # grub2-install --boot-directory=/boot --no-floppy /dev/sda
root # chattr +i /boot/grub2/core.imgthe chattr commands are there to prevent core.img being moved by filesystem maintainance tools.
If using another specific bootloader like TrueCrypt bootloader which is problematic with GRUB2 at the moment, and then need to boot another OS, it's necessary in that case to install GRUB2 to a partition with something like:
root # grub2-install --boot-directory=/boot --no-floppy --force /dev/sda5Just ensure to have enough gape before that partition or else... you will simply destroy your partition along with LUKS or LVM2 header if any! Else, run a `mount boot' as root and use something similar to the previous example.
BIOS/GPT installation
BIOS/GPT setup is straight forward without GPT unaware multiboot OSs.
GPT partitioned disk without hybrid MBR
This setting is maybe the simplest methode in this guide along with a plain BIOS/MBR setup, well, assuming that at least an EF02 type partition was created with a GPT compatible tools. A simple command like the following is enough to get everything fine and running.
root # mount /boot
root # grub2-install --modules="part_gpt fat ext2" --no-floppy /dev/sdaAnd everything should goes as expected. I couldn't install GRUB2 without an EF02 partition although sector 34-2047 and about the same unused amount free sector at the end were left. You're warned!
GPT partitioned disk with hybrid MBR
Multi booting OSs that aren't aware of GPT partitioned disk, e.g. Windows 7 or Windows XP for those who still use that thing--that's because MSDOS/Windows cannot boot from anything else than BIOS/MBR aside from MSDOS/Windows 7 and possibly 8 from EFI platforms,--require this tricky workaround. The thing to keep in mind is that playing with a hybrid MBR can be tricky so, nothing in this sub-section should be taken as solid rock working but rather simply guidances to experiment to get something working.
First of, GRUB2 should boot and should recognize a partition table be it GPT or MBR simply by loading the associated module (part_gpt or part_msods). So it should be expected to be able to boot on BIOS/MBR or BIOS/GPT depending on GRUB2 loaded module? Nothing is far from the truth, because, the previous sections outlined the differences between installing GRUB2 on BIOS/MBR and BIOS/GPT. I don't know how grub2-install behave when trying to install in BIOS/MBR mode with an EF02 (or bios_boot in parted terms) partition because I did not simply try it.
Actually there's simple thing that would determine grub2-install to install in BIOS/MBR or BIOS/GPT: it's the presence of a EE00 (GPT protective) and being the first partition in the MBR with that. With a hybrid MBR, GRUB2 will install just fine if and only if the first partition in the MBR table is an EE00 partition. An EF02 partition should be present anywhere in the disk and not necessarily in the MBR list to leave a few room to embed core.img in the disk tough.
Creating a hybrid MBR is easy with gdisk: just hit `r' (recovery and transformation) in the main, then hit `h' (CHS recompute) in that menu, and then enter a series of partition (less or equal to 3) in the order you want it to be listed in the MBR, and then enter the hexadecimal partition type without the `0x' prefix or accept the default with hitting repeatedly with `Y', and enable only a single boot flag as the following example.
root # gdisk /dev/sdg
GPT fdisk (gdisk) version 0.8.1
Partition table scan:
MBR: MBR only
BSD: not present
APM: not present
GPT: present
Found valid MBR and GPT. Which do you want to use?
1 - MBR
2 - GPT
3 - Create blank GPT
Your answer: 2
root # gdisk /dev/sdg
...
Using GPT and creating fresh protective MBR.
Command (? for help): r
Recovery/transformation command (? for help): p
Disk /dev/sdg: 625142448 sectors, 298.1 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 744E8BF3-39A4-4908-8646-AC2E5661C8CF
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 625142414
Partitions will be aligned on 2048-sector boundaries
Total free space is 2014 sectors (1007.0 KiB)
Number Start (sector) End (sector) Size Code Name
1 2048 566233087 270.0 GiB 8300 Linux filesystem
2 566233088 625142414 28.1 GiB 0700 Microsoft basic data
Recovery/transformation command (? for help): h
WARNING! Hybrid MBRs are flaky and dangerous! If you decide not to use one,
just hit the Enter key at the below prompt and your MBR partition table will
be untouched.
Type from one to three GPT partition numbers, separated by spaces, to be
added to the hybrid MBR, in sequence: 2 1
Place EFI GPT (0xEE) partition first in MBR (good for GRUB)? (Y/N): N
Creating entry for GPT partition #2 (MBR partition #1)
Enter an MBR hex code (default 07):
Set the bootable flag? (Y/N): Y
Creating entry for GPT partition #1 (MBR partition #2)
Enter an MBR hex code (default 83):
...
Unused partition space(s) found. Use one to protect more partitions? (Y/N): N
Recovery/transformation command (? for help): o
Disk size is 625142448 sectors (298.1 GiB)
MBR disk identifier: 0x00000000
MBR partitions:
Number Boot Start Sector End Sector Status Code
1 * 566233088 625142414 primary 0x07
2 2048 566233087 primary 0x83
4 1 2047 primary 0xEE
Recovery/transformation command (? for help): w
And then check out if the operation was successful or not by listing the devices.
And finally install GRUB as usual. Everything should be fine at this point. See troubleshooting section for possible issues not listed on the previous Notes and comments.
Multiboot
There's a truly improved chainload mode compared to GRUB LEGACY: the new iso (or loop) chainload mechanism. Actually, one could still chainload iso images with GRUB LEGACY, and I did, but there were no way to pass kernel cmdline arguments. In either case, the iso image in question should have been built with that in mind like SysRescueCd or on a lesser extend Gentoo liveCD, otherwise booting will just fail badly in the physical media check/test. Gentoo liveCD is handy because it has a minimal shell which let mount the squashed image to the right place and then hit ESC to continue the boot process. That's a handy way to install an OS with everything in RAM, especially for such light liveCD, without listening to a whining drive on each command.
Chainloading ISO image
To chainload an iso with custom or defaults kernel cmdline arguments, something like the following can be easily added to grub.cfg.
menuentry "SYSRESCUECD" {
loopback loop /sysrecuecd-x86-2.3.1.iso
linux (loop)/isolinux/rescue64 nomodeset vga=791 docache setkmap=fr isoloop=/sysrecuecd-x86-2.3.1.iso
initrd (loop)/isolinux/initram.igz
}For a permanent and automatic entry to grub.cfg, a custum file could be added to `/etc/grub.d'.
#!/bin/sh
exec tail -n +3 $0
menuentry "GRUB4DOS" {
linux /grub4dos-0.4.4/grub.exe --config-file=/menu.lst
}
menuentry "SYSRESCUECD" {
loopback loop /sysrecuecd-x86-2.3.1.iso
linux (loop)/isolinux/rescue64 nomodeset vg=791 docache setkmap=fr isoloop=/sysrecuecd-x86-2.3.1.iso
initrd (loop)/isolinux/initram.igz
}
menuentry "STG3-AMD64" {
set cmdline="dokeymap looptype=squashfs loop=/image.squashfs cdroot"
loopback loop /stg3-amd64-<DATE>.iso
linux (loop)/isolinux/gentoo $cmdline root=/dev/ram0 init=/linuxrc initrd=gentoo.igz
initrd (loop)/isolinux/gentoo.igz
}Chainloading other bootloader
Chainloading other bootloader is fairly easy if there's support in GRUB2 for that specific bootloader. Otherwise, one could use a man in the middle or another bootloader in other words to do the task if necessary. In the latter case, one could use GRUB4DOS as it has functionalities similar to GRUB LEGACY. This is required when loading another bootloader like TrueCrypt become problematic in a single multiboot disk, otherwise something as simple as the following is enough to boot another disk with whatever bootloader.
menuentry "WHATEVER" {
insmod part_msdos
insmod chainload
chainloader (hd1,1)+1
}Chainloading TrueCrypt bootloader
Well, let's make a long story short: GRUB2 cannot neither chainload a disk with TrueCrypt in the MBR neither the rescue CD image. This is perfectly possible, feasible and works just fine with GRUB LEGACY. It even works with GRUB4DOS! This could be used as workaround. See bug #385619 for more info and the above GRUB4DOS menu entry as a starting point. The infamous `invalid signature' await the more adventurous ones.
Simply put, one should stick to GRUB LEGACY or to another bootloader or else... use GRUB4DOS as workaround for this. GRUB4DOS has a very similar GRUB LEGACY interface and menu.lst entry which can be used to chainload TrueCrypt bootloader or rescue CD to boot from an encrypted partition. An executable with grldr in the `/' root of the booting device is required, plus a menu.lst. See below for a menu entry example. Chainloading TrueCrypt bootloader in another disk is straightforward like any other bootloader.
title Windows7-TrueCrypt-BIOS/MBR
find --set-root /truecrypt_rescue_image.iso
map --mem /truecrypt_rescue_image.iso (hd32)
map (hd0) (hd1)
map (hd1) (hd0)
map --hook
root (hd32)
chainloader (hd32)
Another workaround cited on the bug is to boot from TrueCrypt as the main boot loader and then hit ESC[ape] to chainload the following partition if any or the following disk.
MSDOS/Windows
If MSDOS/Windows is in another disk with its bootloader in the MBR, then one can boot with a simple menu entry as the previous example in Chainloading other bootloader section.
Things could become more complicated if MSDOS/Windows is in another partition of the disk and the partition is encrypted with TrueCrypt for example, or simply if a hybrid MBR is involved.
The simpliest way to dual boot MSDOS/Windows is using BIOS/MBR combination. Simply backup the whole MBR to be safe or simply the bootloader before installing MSDOS/Windows as that thing will overwrite the bootloader for sure. And then simple menu entry could added to grub.cfg.
menuentry "Windows 7 BIOS/MBR" {
insmod part_msdos
insmod ntldr
insmod ntfs
ntldr (hd0,msdos1)/bootmgr
}Or the following for MSDOS/Windows XP
menuentry "Windows XP BIOS/MBR" {
insmod part_msdos
insmod ntldr
insmod ntfs
ntldr (hd0,msdos1)/ntldr
}An entry with GPT/hybrid MBR doesn't not to the list to the previous usual BIOS/MBR examples. Booting multiple MSDOS/Windows could be achieved with remapping and/hiding partion with partool.
menuentry "Windows 7 BIOS/MBR" {
insmod part_msdos
insmod chain
parttool hd1,msdos1 hidden+ boot-
parttool hd1,msdos2 hidden- boot+
chainloader (hd1,msdos2)+1
}menuentry "Windows 7 BIOS/MBR" {
insmod part_msdos
insmod chain
drivemap hd0 hd1
chainloader (hd1,msdos2)+1
}An UEFI dual boot could be achieved with the following, if, for example, the default bootloader was overwritten with GRUB2 or simply that bootmgr doesn't do the trick for different reasons.
menuentry "Windows 7 UEFI/GPT" {
insmod part_gpt
insmod search_fs_uuid
insmod chain
search --fs-uuid --no-floppy --set=root 28cf-35de
chainloader ($root)/EFI/MICROSOFT/BOOT/bootmgfw.efi
}Troubleshooting and Quirks
Chroot installation
If you have a separate `/boot' partition and plan to install GRUB2, be sure to mount only the target root partition before chrooting, but not the `/boot' partition as well. Mount `/boot' once inside the chroot environment. This is required because grub-mkconfig will not detect `/boot' as a separate partition and will assume `/boot' and `root' [`/'] are on the same partition if `/boot' was mounted before chrooting.
root # mount -t someFS /dev/sd<xy> /mount/point
root # cd /mount/point
root # mount --rbind {/,}dev
root # mount --rbind {/,}proc
root # chroot . /bin/bash
root # mount /dev/sd<uv> /bootroot # grub2-install --modules=ext2 --no-floppy /dev/sd<x>Fancy theming and settings
It may happen that relying on automated scripts doesn't work out of the box entirely and a few setting from `/etc/default/grub' aren't included in grub.cfg. In that case including a custom file in `/etc/grub.d/' may be necessary to make sure everything would be included. I had to add a custom file to get a few settings respected as the following file.
#!/bin/sh
exec tail -n +3 $0
insmod fat
insmod font
set gfxmode=1280x800
set gfxpayload=keep
load_video
insmod gfxterm
terminal_output gfxterm
loadfont ${prefix}/unifont.pf2
insmod jpeg
background_image ${prefix}/background-${gfxmode}.jpg
set menu_color_normal=white/black
set menu_color_highlight=black/magenta
Booting from LVM2 Logical Volume
Booting from a Logical Volume is very easy and may threw the need of an initramfs. Simply set the root device to <VG>-<LV> as what you have in `/dev/mapper/' device list in your grub.cfg or `/etc/grub.d' seting for automated configuration generation and update.
...
insmod lvm
set root=(<VG>-<LV>)
...Booting from RAID Array
The documentation on this subject, along with booting from encrypted physical volumes, is close to null. As I do not boot from a RAID array, anyone who managed to boot from a complex RAID array is welcomed to complete this section.
root # for i in 1 3 4
do UUID=$(mdadm -D /dev/md$i | grep UUID | awk '{ print $3 }')
UUID=${UUID//:}; uuid=${UUID:0:8}
for j in 9 13 15; do uuid+=-${UUID:$j:4}; done
uuid+=-${UUID:21:12}
echo -n "(md$i) /dev/disk/by-id/md-uuid-$uuid" >> /boot/grub2/device.map
unset UUID uuid; doneAnd then re-generate GRUB2 configuration file. Checkout out the generated cfg file to see if everything is fine at this point.
Booting from a RAID array is very similar to booting from a LVM Logical Volume aside from RAID specific terminology and syntax of raid partitioned volume.
...
insmod raid
# and load the related `mdraid' module `mdraid09' for raid arrays with version 0.9 metadata, and `mdraid1x' for arrays with version 1.x metadata.
insmod mdraid09
set root=(md0p1)
# or the following for an unpartitioned raid array
set root=(md0)
...I can guess tat this should work with a simple software RAID setup. However, I have no idea or what command, if any exit at the moment of writing, to use to assemble an array such as `mdadm --assemble --scan /dev/md0' that an initramfs could take care of.
Booting from LUKS Physical Volume
...
insmod gcry_twofish
insmod gcry_sha256
insmod gcry_whirlepool
# the rest may come one day...
...Booting from newtwork (PXE)
Booting from newtwork (PXE) Network boot from read-only server
GPT hybrid MBR workaround
GRUB2 require an EE00 partition type first in the MBR partition list entry, but that may pose a problem to boot other OSs in the same disk especially MSDOS/Windows, to recognize a GPT partitioned disk with or without hybrid MBR. A workaround would be simply removing any protective EE00 partition, with fdisk for example but not gdisk! (it won't work with gdisk as the fake partition is just there to protect GPT main table), and boot in BIOS/MBR mode. Just remember to not use other disk tools but gdisk (it should work with [g]parted) to resize after that, else, use gdisk to add protective EE00 partitions to protect at least GPT main and backup partition before using any non GPT aware tools if necessary.
There's another issue, MSDOS/Windows may not find any suitable partition to boot from if there's a EE00 partition protecting GPT main partition table (sector 1-2047). This is happened to me and I had to remove the protective EE00 protective partition before getting a valid MBR partition list in [MS]DOS tools (to format a partition for example, the tools recognized a GPT partitioned disk at least). And then use gdisk to recompute the CHS value for hybrid MBR (in the recovery and transformation menu, or in the expert main menu).
Commons errors
If you're getting this error:
Attempting to install GRUB to a partition disk or to a partition. This is a BAD idea.
Embedding is not possible. GRUB can only be installed in this setup by using blocklists.
However, blocklists are UNRELIABLE and their use is discouraged.
this could mean that:
- 1st: A `/boot' partition is not mounted, simply run as root `mount /boot'.
- 2nd: If you're trying to install GRUB2 in traditional BIOS/GPT setup, this could mean more likely that there isn't any EF02 or bios_boot to embed core.img. A little partition of a few hundreds kilo bytes may be enough, although it's good to align it's partition to something like 2048 sectors to avoid performance penalty, so a 1MiB partition should do.
- If you're trying to install GRUB2 in a partition e.g. `/dev/sda5' in BIOS/MBR setup (who did try it to BIOS/GPT?), simply add `--force' cmdline switch to get going. You should be fine with either enough gap before the first sector of the first partition or else use chattr command (as described in BIOS/MBR installation) to get going or else... destroy your partition boundary and possibly your LUKS or LVM2 header if any.
