grub issueshttps://gitlab.manjaro.org/packages/core/grub/-/issues2023-12-22T13:47:35Zhttps://gitlab.manjaro.org/packages/core/grub/-/issues/22grub-update does not need to be required by Grub2023-12-22T13:47:35ZZeskogrub-update does not need to be required by Grub`$ pacman -Qi grub-update`
```
Name : grub-update
Version : 2.12-1
Description : GNU Grub (2) Update Menu Script
Architecture : x86_64
```
```
Depends On : grub
Required By : grub
```
The package `gru...`$ pacman -Qi grub-update`
```
Name : grub-update
Version : 2.12-1
Description : GNU Grub (2) Update Menu Script
Architecture : x86_64
```
```
Depends On : grub
Required By : grub
```
The package `grub-update` **does NOT need to be required by** `grub`.
I would like to remove `grub-update` and create my own alias for grub update.https://gitlab.manjaro.org/packages/core/grub/-/issues/12Custom kernel version is not detected2023-04-09T14:02:36ZSoftExpertCustom kernel version is not detectedHello,
I started recently maintaining the Xanmod kernel in AUR (built from the binary sources). My system is Manjaro.
The original package maintainer needs the binaries in **/boot** to have a fixed name (their boot manager is not Grub, ...Hello,
I started recently maintaining the Xanmod kernel in AUR (built from the binary sources). My system is Manjaro.
The original package maintainer needs the binaries in **/boot** to have a fixed name (their boot manager is not Grub, but syslinux) and each filename modification means that the syslinux configuration needs to be manually modified.
This means that we have currently the following binaries in **/boot** for our kernel:
```
initramfs-linux-xanmod-linux-bin-x64v2-fallback.img
initramfs-linux-xanmod-linux-bin-x64v2.img
initramfs-linux-xanmod-linux-bin-x64v2.kver
vmlinuz-linux-xanmod-linux-bin-x64v2
```
The content of **initramfs-linux-xanmod-linux-bin-x64v2.kver** is 6.2.9-x64v2-xanmod1 which corresponds to
- kernel major version
- kernel minor version
- kernel release version
- the architecture name
- flavor label and package release version
The trouble is that the current grub scripts are not picking the kernel name; from what I understand first the **.img** file, then then **vmlinuz** file names are parsed, and then the content of **.kver** file is retrieved in order to store the value in the macros used by grub scripts when generating the submenu.
So far this logic does not work with our kernel; we end up with **menuentry 'Manjaro Linux (Kernel: x64v2)'** and **menuentry 'Manjaro Linux (Kernel: x64v2 - fallback initramfs)'** in **grub.cfg** , which is, obviously, not enough to correctly identify the version of the kernel.
At the latest update of grub a few minutes ago (2.0.6.r456.g65bc45963-3) I saw the following output:
```
Creating temporary files...
Reloading device manager configuration...
Arming ConditionNeedsUpdate...
Updating linux initcpios...
==> Building image from preset: /etc/mkinitcpio.d/linux61.preset: 'default'
-> -k /boot/vmlinuz-6.1-x86_64 -c /etc/mkinitcpio.conf -g /boot/initramfs-6.1-x86_64.img
==> Starting build: '6.1.22-1-MANJARO'
-> Running build hook: [base]
-> Running build hook: [udev]
-> Running build hook: [autodetect]
-> Running build hook: [modconf]
-> Running build hook: [kms]
-> Running build hook: [keyboard]
-> Running build hook: [keymap]
-> Running build hook: [consolefont]
-> Running build hook: [block]
-> Running build hook: [filesystems]
-> Running build hook: [usr]
-> Running build hook: [fsck]
==> Generating module dependencies
==> Creating gzip-compressed initcpio image: '/boot/initramfs-6.1-x86_64.img'
==> Image generation successful
==> Building image from preset: /etc/mkinitcpio.d/linux61.preset: 'fallback'
-> -k /boot/vmlinuz-6.1-x86_64 -c /etc/mkinitcpio.conf -g /boot/initramfs-6.1-x86_64-fallback.img -S autodetect
==> Starting build: '6.1.22-1-MANJARO'
-> Running build hook: [base]
-> Running build hook: [udev]
-> Running build hook: [modconf]
-> Running build hook: [kms]
==> WARNING: Possibly missing firmware for module: 'ast'
-> Running build hook: [keyboard]
-> Running build hook: [keymap]
-> Running build hook: [consolefont]
-> Running build hook: [block]
-> Running build hook: [filesystems]
-> Running build hook: [usr]
-> Running build hook: [fsck]
==> Generating module dependencies
==> Creating gzip-compressed initcpio image: '/boot/initramfs-6.1-x86_64-fallback.img'
==> Image generation successful
==> Building image from preset: /etc/mkinitcpio.d/linux62.preset: 'default'
-> -k /boot/vmlinuz-6.2-x86_64 -c /etc/mkinitcpio.conf -g /boot/initramfs-6.2-x86_64.img
==> Starting build: '6.2.9-1-MANJARO'
-> Running build hook: [base]
-> Running build hook: [udev]
-> Running build hook: [autodetect]
-> Running build hook: [modconf]
-> Running build hook: [kms]
-> Running build hook: [keyboard]
-> Running build hook: [keymap]
-> Running build hook: [consolefont]
-> Running build hook: [block]
-> Running build hook: [filesystems]
-> Running build hook: [usr]
-> Running build hook: [fsck]
==> Generating module dependencies
==> Creating gzip-compressed initcpio image: '/boot/initramfs-6.2-x86_64.img'
==> Image generation successful
==> Building image from preset: /etc/mkinitcpio.d/linux62.preset: 'fallback'
-> -k /boot/vmlinuz-6.2-x86_64 -c /etc/mkinitcpio.conf -g /boot/initramfs-6.2-x86_64-fallback.img -S autodetect
==> Starting build: '6.2.9-1-MANJARO'
-> Running build hook: [base]
-> Running build hook: [udev]
-> Running build hook: [modconf]
-> Running build hook: [kms]
==> WARNING: Possibly missing firmware for module: 'ast'
-> Running build hook: [keyboard]
-> Running build hook: [keymap]
-> Running build hook: [consolefont]
-> Running build hook: [block]
-> Running build hook: [filesystems]
-> Running build hook: [usr]
-> Running build hook: [fsck]
==> Generating module dependencies
==> Creating gzip-compressed initcpio image: '/boot/initramfs-6.2-x86_64-fallback.img'
==> Image generation successful
==> Building image from preset: /etc/mkinitcpio.d/linux-xanmod-linux-bin-x64v2.preset: 'default'
-> -k /boot/vmlinuz-linux-xanmod-linux-bin-x64v2 -c /etc/mkinitcpio.conf -g /boot/initramfs-linux-xanmod-linux-bin-x64v2.img
==> Starting build: '6.2.9-x64v2-xanmod1'
-> Running build hook: [base]
-> Running build hook: [udev]
-> Running build hook: [autodetect]
-> Running build hook: [modconf]
-> Running build hook: [kms]
-> Running build hook: [keyboard]
-> Running build hook: [keymap]
-> Running build hook: [consolefont]
-> Running build hook: [block]
-> Running build hook: [filesystems]
-> Running build hook: [usr]
-> Running build hook: [fsck]
==> Generating module dependencies
==> Creating gzip-compressed initcpio image: '/boot/initramfs-linux-xanmod-linux-bin-x64v2.img'
==> Image generation successful
==> Building image from preset: /etc/mkinitcpio.d/linux-xanmod-linux-bin-x64v2.preset: 'fallback'
-> -k /boot/vmlinuz-linux-xanmod-linux-bin-x64v2 -c /etc/mkinitcpio.conf -g /boot/initramfs-linux-xanmod-linux-bin-x64v2-fallback.img -S autodetect
==> Starting build: '6.2.9-x64v2-xanmod1'
-> Running build hook: [base]
-> Running build hook: [udev]
-> Running build hook: [modconf]
-> Running build hook: [kms]
==> WARNING: Possibly missing firmware for module: 'ast'
-> Running build hook: [keyboard]
-> Running build hook: [keymap]
-> Running build hook: [consolefont]
-> Running build hook: [block]
-> Running build hook: [filesystems]
-> Running build hook: [usr]
-> Running build hook: [fsck]
==> Generating module dependencies
==> Creating gzip-compressed initcpio image: '/boot/initramfs-linux-xanmod-linux-bin-x64v2-fallback.img'
==> Image generation successful
==> Building image from preset: /etc/mkinitcpio.d/linux-xanmod-lts-linux-bin-x64v2.preset: 'default'
/usr/lib/initcpio/functions: line 270: printf: `P': invalid format character
-> -k /boot/vmlinuz-==> ERROR: specified kernel image does not exist: '/boot/vmlinuz-%PKGBASE%'
==> Building image from preset: /etc/mkinitcpio.d/linux-xanmod-lts-linux-bin-x64v2.preset: 'fallback'
/usr/lib/initcpio/functions: line 270: printf: `P': invalid format character
-> -k /boot/vmlinuz-==> ERROR: specified kernel image does not exist: '/boot/vmlinuz-%PKGBASE%'
Error: command failed to execute correctly
Refreshing PackageKit...
Reloading system bus configuration...
```
Is there something I could do when building the kernel so that the names of the binaries remain as listed and yet the correct kernel name can be detected and written in the **grub.cfg** file ?
Thank you in advance for your help !
P.S. I attached also the [PKGBUILD](/uploads/7833b8e7714eed35dc0cadee2d5ad334/PKGBUILD) file.https://gitlab.manjaro.org/packages/core/grub/-/issues/11Add core boot compilation support for grub2.2024-02-26T00:11:42ZdaiajiAdd core boot compilation support for grub2.https://packages.debian.org/sid/grub-coreboot-bin
Debian has a related package.
https://www.gnu.org/software/grub/manual/grub/grub.html
grub2 itself also provides support for coreboot (`i386-coreboot`).
https://blogs.coreboot.org/blo...https://packages.debian.org/sid/grub-coreboot-bin
Debian has a related package.
https://www.gnu.org/software/grub/manual/grub/grub.html
grub2 itself also provides support for coreboot (`i386-coreboot`).
https://blogs.coreboot.org/blog/category/grub2/
This is helpful for achieving complete full disk encryption.Mark WagiePhilip MüllerMark Wagiehttps://gitlab.manjaro.org/packages/core/grub/-/issues/10fgrep-is-obsolescent-using-grep-F.patch2022-10-10T15:09:17Zphoepsilonixfgrep-is-obsolescent-using-grep-F.patchhttps://github.com/phoepsilonix/manjaro-grub/commit/8dfe34275423fd1609968a8cfdf12afa7cb3224chttps://github.com/phoepsilonix/manjaro-grub/commit/8dfe34275423fd1609968a8cfdf12afa7cb3224chttps://gitlab.manjaro.org/packages/core/grub/-/issues/9GRUB menu not appearing with 2.06.r297.g0c6c1aff2-12022-08-26T12:10:05ZMark WagieGRUB menu not appearing with 2.06.r297.g0c6c1aff2-1With the update to [2.06.r297.g0c6c1aff2-1](
a66f7ba2) currently in Arch Testing, for some reason the GRUB menu does not appear during boot. I have `GRUB_TIMEOUT_STYLE=menu`and `GRUB_TIMEOUT=5`. Reverting to 2.06.r261.g2f4430cc0-1 displa...With the update to [2.06.r297.g0c6c1aff2-1](
a66f7ba2) currently in Arch Testing, for some reason the GRUB menu does not appear during boot. I have `GRUB_TIMEOUT_STYLE=menu`and `GRUB_TIMEOUT=5`. Reverting to 2.06.r261.g2f4430cc0-1 displays the menu again.https://gitlab.manjaro.org/packages/core/grub/-/issues/8Ubuntu patches failing to apply2022-08-18T02:09:05ZMark WagieUbuntu patches failing to applyAfter merging [Arch's recent changes](https://github.com/archlinux/svntogit-packages/commit/ca6954b79e3a4058c749a3d5fbcad07d1967d93d)...
c143d84b
```
==> Starting prepare()...
Apply backports...
Patch to enable GRUB_COLOR_* variables i...After merging [Arch's recent changes](https://github.com/archlinux/svntogit-packages/commit/ca6954b79e3a4058c749a3d5fbcad07d1967d93d)...
c143d84b
```
==> Starting prepare()...
Apply backports...
Patch to enable GRUB_COLOR_* variables in grub-mkconfig...
patching file util/grub-mkconfig.in
Hunk #1 succeeded at 247 (offset 1 line).
patching file util/grub.d/00_header.in
Use efivarfs modules
patching file grub-core/osdep/linux/platform.c
Hunk #1 succeeded at 108 with fuzz 2 (offset 1 line).
patching file grub-core/osdep/unix/platform.c
Patch to export /home/yochanan/bin:/home/yochanan/.local/bin:/usr/local/bin:/usr/bin:/usr/local/sbin:/opt/cuda/bin:/opt/cuda/nsight_compute:/opt/cuda/nsight_systems/bin:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl:/usr/share/zsh/plugins/ugit
patching file util/grub.d/30_os-prober.in
Patch to include Manjaro Linux Modifications
patching file util/grub-mkconfig.in
Hunk #1 succeeded at 254 (offset 6 lines).
patching file util/grub-mkconfig_lib.in
patching file util/grub.d/10_linux.in
Hunk #2 succeeded at 96 (offset 4 lines).
Hunk #3 succeeded at 112 (offset 4 lines).
Hunk #4 succeeded at 144 (offset 4 lines).
Hunk #5 succeeded at 187 (offset -14 lines).
Hunk #6 succeeded at 228 (offset 4 lines).
Hunk #7 succeeded at 256 (offset 4 lines).
Hunk #8 succeeded at 266 (offset 6 lines).
Hunk #9 succeeded at 335 with fuzz 1 (offset 6 lines).
Add Ubuntu patches
0001
patching file config.h.in
Hunk #1 succeeded at 16 (offset 4 lines).
patching file configure.ac
Hunk #1 succeeded at 1907 with fuzz 2 (offset -16 lines).
Hunk #2 succeeded at 2180 (offset -16 lines).
patching file grub-core/boot/i386/pc/boot.S
patching file grub-core/boot/i386/pc/diskboot.S
patching file grub-core/kern/main.c
Hunk #1 FAILED at 265.
Hunk #2 succeeded at 315 (offset 3 lines).
1 out of 2 hunks FAILED -- saving rejects to file grub-core/kern/main.c.rej
patching file grub-core/kern/rescue_reader.c
patching file grub-core/normal/main.c
patching file grub-core/normal/menu.c
Hunk #1 FAILED at 807.
Hunk #2 FAILED at 860.
Hunk #3 succeeded at 877 (offset 8 lines).
2 out of 3 hunks FAILED -- saving rejects to file grub-core/normal/menu.c.rej
patching file util/grub.d/10_linux.in
Hunk #1 FAILED at 21.
Hunk #2 FAILED at 158.
Hunk #3 succeeded at 158 with fuzz 1 (offset -15 lines).
2 out of 3 hunks FAILED -- saving rejects to file util/grub.d/10_linux.in.rej
==> ERROR: A failure occurred in prepare().
Aborting...
```Philip MüllerPhilip Müllerhttps://gitlab.manjaro.org/packages/core/grub/-/issues/7update-grub cryptdevice kernel option missing2021-06-17T20:11:39Zsai o naraupdate-grub cryptdevice kernel option missingSpecs:
- Manjaro 21.0.1
- Linux 5.10.26-1-MANJARO x86_64
- GRUB 2.04-22
When i do `update-grub` it generates a buggy `grub.cfg`
The erroneous line is the one calling the `linux` command
It doesn't add then kernel option `cryptdevice`
...Specs:
- Manjaro 21.0.1
- Linux 5.10.26-1-MANJARO x86_64
- GRUB 2.04-22
When i do `update-grub` it generates a buggy `grub.cfg`
The erroneous line is the one calling the `linux` command
It doesn't add then kernel option `cryptdevice`
The full generetad line is:
`linux /boot/vmlinuz-5.10-x86_64 root=UUID=e454a3cb-a8d2-46a5-a840-3ab0e3e34945
rw quiet udev.log_priority=3`
But it should be:
`linux /boot/vmlinuz-5.10-x86_64 root=UUID=e454a3cb-a8d2-46a5-a840-3ab0e3e34945
rw quiet udev.log_priority=3
cryptdevice=UUID=b0bfc399-c626-471e-b7b9-1c9519360e76:luks-b0bfc399-c626-471e-b7b9-1c9519360e76
root=/dev/mapper/luks-b0bfc399-c626-471e-b7b9-1c9519360e76`
I've searched and searched and finally found Arch wiki's fix to this in https://wiki.archlinux.org/index.php/Dm-crypt/Encrypting_an_entire_system#Configuring_GRUB_2
I could find a solution because i'm an advanced user, but for most of the people this would be impossible to achieve, so i think it should be done automatically
Thx!https://gitlab.manjaro.org/packages/core/grub/-/issues/6GRUB_DISABLE_OS_PROBER=false is missing in /etc/default/grub.pacnew from 05.0...2021-03-09T16:57:40Zjohn LandmesserGRUB_DISABLE_OS_PROBER=false is missing in /etc/default/grub.pacnew from 05.03.21 10:36That ruined my multiboot!!!!!!!!!!!!!!!!1
Info: Manjaro Stable XFCE
CPU: Quad Core Intel Core i7-1065G7 (-MT MCP-) speed/min/max: 1201/400/3900 MHz Kernel: 5.10.19-1-MANJARO x86_64 Up: 22m
Mem: 2271.8/15568.9 MiB (14.6%) Storage: 1.86...That ruined my multiboot!!!!!!!!!!!!!!!!1
Info: Manjaro Stable XFCE
CPU: Quad Core Intel Core i7-1065G7 (-MT MCP-) speed/min/max: 1201/400/3900 MHz Kernel: 5.10.19-1-MANJARO x86_64 Up: 22m
Mem: 2271.8/15568.9 MiB (14.6%) Storage: 1.86 TiB (20.6% used) Procs: 276 Shell: Bash inxi: 3.3.01https://gitlab.manjaro.org/packages/core/grub/-/issues/5Compatibility with Debian's update-grub2021-01-27T18:44:21ZTimothy Gutimothygu99@gmail.comCompatibility with Debian's update-grubHello, it appears that Debian's [update-grub](https://sources.debian.org/src/grub2/2.04-12/debian/update-grub/) script is more featureful than the one included in this repo:
```sh
#!/bin/sh
set -e
exec grub-mkconfig -o /boot/grub/grub.c...Hello, it appears that Debian's [update-grub](https://sources.debian.org/src/grub2/2.04-12/debian/update-grub/) script is more featureful than the one included in this repo:
```sh
#!/bin/sh
set -e
exec grub-mkconfig -o /boot/grub/grub.cfg "$@"
```
versus
```shell
#! /bin/sh
grub-mkconfig -o /boot/grub/grub.cfg
```
In particular, it allows passing arguments to `grub-mkconfig` while the one in this repo does not. (It also uses `exec` which is technically better as it does not spawn a separate process.)
I recommend we adopt the Debian version verbatim.https://gitlab.manjaro.org/packages/core/grub/-/issues/4Don't prevent boot time file system check of root2021-01-30T10:16:19ZAnanthDon't prevent boot time file system check of rootManjaro's grub configuration loads `/` as `rw`. This prevents `/` to be checked by fsck at boot time. `systemd-fsck-root.service` may check root at boot time if required, but only if it's mounted with `ro`. But, because of [this patch](h...Manjaro's grub configuration loads `/` as `rw`. This prevents `/` to be checked by fsck at boot time. `systemd-fsck-root.service` may check root at boot time if required, but only if it's mounted with `ro`. But, because of [this patch](https://gitlab.manjaro.org/packages/core/grub/-/blob/master/grub-manjaro-modifications.patch#L73), the check is always skipped.
Checking root fs in any other way is not trivial. Take a look at this [manjaro forum thread](https://forum.manjaro.org/t/how-to-enforce-boot-time-file-system-check/28363) for discussions on this topic.
Even when this flag is to `ro` in grub, `/` is mounted as with read-write access eventually at later stages of the boot. It's not clear why this flag should be intentionally set to `rw` here.https://gitlab.manjaro.org/packages/core/grub/-/issues/3Please consider easing configuration override from os_prober2020-11-20T08:42:02ZGastón HaroPlease consider easing configuration override from os_proberThe [adjust_timeout](https://gitlab.manjaro.org/packages/core/grub/blob/master/0003-grub-quick-boot.patch#L111]) function overrides both `timeout_style` and `timeout` when another OS is found. This makes it "impossible" to have a silent ...The [adjust_timeout](https://gitlab.manjaro.org/packages/core/grub/blob/master/0003-grub-quick-boot.patch#L111]) function overrides both `timeout_style` and `timeout` when another OS is found. This makes it "impossible" to have a silent boot. I know you are trying to make this "friendly" for regular users, but would you consider at least NOT overriding `timeout_style` and setting `timeout` to 1. So at least we can set `timeout_style=hidden` from config and have that respected. This confuses many power users as the behavior is against GRUB's official documentation.
Thank you.https://gitlab.manjaro.org/packages/core/grub/-/issues/2EFI GRUB should include the FAT module2019-05-07T18:38:23ZPete BatardEFI GRUB should include the FAT moduleNote, this is a duplicate from https://bugs.manjaro.org/#ticket/zoom/17934, which I tried to repeatedly bring to Manjaro's developer attention, but which now seems to have disappeared along with the old bug tracker.
I will also disclose...Note, this is a duplicate from https://bugs.manjaro.org/#ticket/zoom/17934, which I tried to repeatedly bring to Manjaro's developer attention, but which now seems to have disappeared along with the old bug tracker.
I will also disclose that I am the main developer of [Rufus](https://github.com/pbatard/rufus), which is a Windows application that allows people to create bootable USB Flash Drive to install distributions like Manjaro, and that what I am going to describe below is a major pain point for new Manjaro users. For instance, I could easily point to dozens of separate reddit posts from people who ran into this very issue when trying to install Manjaro, which of course is less than ideal.
Issue:
------
When trying to boot an UEFI based machine, by extracting the ISO content onto a FAT32 drive, and because the EFI GRUB bootloader used by Manjaro appears to have removed the FAT module, users are currently being greeted by a `grub rescue>` prompt:
```
Welcome to GRUB!
error: unknown filesystem
Entering rescue mode
grub rescue>
```
You should be able to test this by simply formatting a flash drive to FAT32, and copying the ISO content wholesale, and then trying to boot it on a UEFI system.
This is a very different (and surprising) behaviour from most other distributions (Debian, Ubuntu, Arch to name a few), that do support boot from FAT filesystem and something we believe that Manjaro could easily address by reinstating the fat module when invoking `grub-mkimage`.
Additional details:
-------------------
Of course, we understand that the preferred means of creating bootable media for Manjaro is through a DD copy of the ISO, since the image is an ISOHybrid, but I hope you can understand that this is not always convenient as:
- DD mode forces the partition to the size set by the maintainers
- DD mode will render all content 'invisible' from Windows (apart from the ESP), which is both confusing for a lot of Windows users, who might think that their drive has shrunk or that data was not copied, or who can't use the remainder of their drive for additional data they might wish to copy
- UEFI is supposed to solve most of the booting woes by allowing copying of bootloaders + data onto a single FAT32 partition, and, as I mentioned, most other distros seem to have no issue with this at all.
For these reasons, whereas Rufus can create a bootable media in both ISO copy (i.e. extracting ISO content to a single FAT32 partition) and DD copy, our default suggestion is to use ISO copy, which, of course, results in exactly the issue we described for anybody who attempts to create a Manjaro bootable drive with our software and picks that default. Of course, we do display a very prominent notice when we ask users to choose between ISO and DD mode, advising them to try recreating their drive in DD mode if they encounter an issue in ISO mode, but a lot of users seem to ignore that notice and end up posting on sites like reddit or superuser asking for advice as to why they cannot boot their Manjaro USB media.
So we would **strongly** suggest that you add `fat` module support to the grub efi bootloader used by Manjaro. And we would also advise that you add `ntfs` module support while you are at it, as it would help users who want to create a persistence file > 4GB (and utilities like Rufus have means to make UEFI and NTFS boot).
If you need additional details, let me know.https://gitlab.manjaro.org/packages/core/grub/-/issues/1Delay in grub installation2019-02-16T10:23:54ZMatti HyttinenDelay in grub installationSince we have adopted grub as overlay package, grub-install and especially update-grub have gained a massive delay when used in chroot. In my tests it has been about 5-6 minutes, but other manjaro-architect users report Grub-install hang...Since we have adopted grub as overlay package, grub-install and especially update-grub have gained a massive delay when used in chroot. In my tests it has been about 5-6 minutes, but other manjaro-architect users report Grub-install hanging for up to 20 minutes. Since grub is our default bootloader, this seems rather unfortunate issue.