mageia 8 beta 1 Classic ISO Installer. partitions configured as this: /boot/EFI is on /dev/nvme0n1p1 formated fat32 / is on /dev/nvme0n1p2 formated btrfs /var is on /dev/sda3 formated ext4 /home is /dev/sda2 formated xfs swap is /dev/sda1 Installation is OK and runs to end. But at first reboot: Grub2 complains about: ------------------- error: ../../grub-core/commands/loadenv.c:216:sparse file not allowed. Press any key to continue... ------------------- After, system boots fine. Analyzing: Seems that if /boot is on rootfs (not in a separated partition), grub2 complains as he can't save which is booted. (GRUB_DEFAULT=saved and GRUB_SAVEDEFAULT=true) I think in installer, we should prevent such configuration or disable saving booting entry. See 22582. Workaround: https://forum.manjaro.org/t/solved-grub-btrfs-error-sparse-file-not-allowed/70031
Assigning to Mageia Tools maintainers. I solved my problem by reinstalling and creating a separate /boot ext4 partition. Workaround proposed above needs to edit /etc/default/grub as root and it is not trivial for "Mme Jane Doe" user... I do think installer should prevent installing with / as btrfs and without /boot separated.
(In reply to Aurelien Oudelet from comment #1) > I do think installer should prevent installing with / as btrfs and without > /boot separated. Why do you think so? /boot does not need to be a separate filesystem, grub can boot from btrfs on / just fine, and we're not really at risk because we don't use btrfs subvolumes by default. FWIW, this was already fixed previously via bug 18781, seems the patch got dropped in the meantime, here's a link for reference: http://svnweb.mageia.org/packages/cauldron/grub2/current/SOURCES/grub2-2.00-mga-dont_write_sparse_file_error_to_screen.patch?view=markup&pathrev=1040611
See Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=18781CC: (none) => doktor5000
Same here / as btrfs /boot/EFI as vfat and the solution on --------------------------------- https://forum.manjaro.org/t/grub-error-sparse-file-not-allowed/20267 To work around it edit your /etc/default/grub and change from GRUB_SAVEDEFAULT=true GRUB_DEFAULT=saved To GRUB_SAVEDEFAULT=false GRUB_DEFAULT=0 rebuild grub config sudo grub-mkconfig -o /boot/grub/grub.cfg ---------------------------------- works
CC: (none) => dieter
CC: (none) => fri
(In reply to Aurelien Oudelet from comment #0) > mageia 8 beta 1 Classic ISO Installer. > > partitions configured as this: > /boot/EFI is on /dev/nvme0n1p1 formated fat32 > / is on /dev/nvme0n1p2 formated btrfs > /var is on /dev/sda3 formated ext4 > /home is /dev/sda2 formated xfs > swap is /dev/sda1 > > Installation is OK and runs to end. But at first reboot: > Grub2 complains about: > ------------------- > error: ../../grub-core/commands/loadenv.c:216:sparse file not allowed. > Press any key to continue... > ------------------- > After, system boots fine. > > Analyzing: > Seems that if /boot is on rootfs (not in a separated partition), grub2 > complains as he can't save which is booted. (GRUB_DEFAULT=saved and > GRUB_SAVEDEFAULT=true) > > I think in installer, we should prevent such configuration or disable saving > booting entry. > > See 22582. > > Workaround: > https://forum.manjaro.org/t/solved-grub-btrfs-error-sparse-file-not-allowed/ > 70031 Having done significant work on Btrfs enablement in the past few years, I can answer a few things here. GRUB reads and writes data from filesystems by locating the offset and doing stuff in-place. Most filesystems treat write operations this way as corruption, though some filesystems like ext4 tolerate this better than xfs (which winds up trying to "repair" it) or Btrfs (which will lock the filesystem to prevent further damage). To avoid this problem with Btrfs, the GRUB filesystem driver is explicitly *read-only*. The error is printed because GRUB wants to write data and is forbidden from doing so. This will also happen when you are working with /boot on any filesystem on RAID (such as MD or LVM). (In reply to Aurelien Oudelet from comment #1) > Assigning to Mageia Tools maintainers. > > I solved my problem by reinstalling and creating a separate /boot ext4 > partition. > > Workaround proposed above needs to edit /etc/default/grub as root and it is > not trivial for "Mme Jane Doe" user... > > I do think installer should prevent installing with / as btrfs and without > /boot separated. I've been talking to GRUB upstream about this problem already for a while. There's some talk about expanding the "BIOS boot partition" to be slightly larger and to be mandatory for all installs to have GRUB boot state data which is normally saved in the grubenv file. In practice, nobody but GRUB makes the "BIOS boot partition", so GRUB is considering just renaming this to "GRUB data partition" for this stuff, which avoids all kinds of nasty issues around this.
CC: (none) => ngompa13
(In reply to Aurelien Oudelet from comment #1) > > I do think installer should prevent installing with / as btrfs and without > /boot separated. If we didn't have other issues around having separate /boot, I would say that we should just do that by default until this is fixed. But since there's a path to having this resolved in Mageia 9 and having a separate /boot is a worse user experience than just having a small error that has no impact on booting, I'd say we should leave things as-is and make adjustments once upstream has the fix for this in place.
Thank you for the thorough explanations :)
(In reply to Aurelien Oudelet from comment #4) > > This will also happen when you are working with /boot on any filesystem on > RAID (such as MD or LVM). > I don't understand why are you write such things but this is definitely not true. On my side i have 3 servers with mageia 7 and linux Raid (MD) and all of them runs fine without any errors or errors on boot. You can only use grub2 for linux raid with /boot on md stuff. My Partitions on such systems with linux raid are: Dateisystem Größe Benutzt Verf. Verw% Eingehängt auf devtmpfs 3,9G 0 3,9G 0% /dev tmpfs 3,9G 196K 3,9G 1% /dev/shm tmpfs 3,9G 908K 3,9G 1% /run /dev/md1 30G 5,3G 23G 20% / tmpfs 3,9G 0 3,9G 0% /sys/fs/cgroup /dev/md0 485M 40M 416M 9% /boot /dev/md3 420G 27G 372G 7% /var /dev/md2 1,5G 2,4M 1,4G 1% /tmp tmpfs 796M 0 796M 0% /run/user/0 And btrfs works fine with grub2 on other linux systems but not on mageia ?
(In reply to Dieter Schütze from comment #7) > (In reply to Aurelien Oudelet from comment #4) > > > > This will also happen when you are working with /boot on any filesystem on > > RAID (such as MD or LVM). > > > I don't understand why are you write such things but this is definitely not > true. > On my side i have 3 servers with mageia 7 and linux Raid (MD) and all of > them runs fine without any errors or errors on boot. You can only use grub2 > for linux raid with /boot on md stuff. My Partitions on such systems with > linux raid are: > > Dateisystem Größe Benutzt Verf. Verw% Eingehängt auf > devtmpfs 3,9G 0 3,9G 0% /dev > tmpfs 3,9G 196K 3,9G 1% /dev/shm > tmpfs 3,9G 908K 3,9G 1% /run > /dev/md1 30G 5,3G 23G 20% / > tmpfs 3,9G 0 3,9G 0% /sys/fs/cgroup > /dev/md0 485M 40M 416M 9% /boot > /dev/md3 420G 27G 372G 7% /var > /dev/md2 1,5G 2,4M 1,4G 1% /tmp > tmpfs 796M 0 796M 0% /run/user/0 > > And btrfs works fine with grub2 on other linux systems but not on mageia ? There is no support for LVM2, though, which is the most common way this is done. While it's true there's direct MD support, it's very limited. Upstream still does not recommend having /boot on such configurations (except Btrfs with RAID 1/10).
CC: (none) => bequimao.de
(In reply to Dieter Schütze from comment #7) > And btrfs works fine with grub2 on other linux systems but not on mageia ? Hi Dieter, other linux systems have the same issue, but they have patches to suppress that error message displayed by grub. Which is the same way that you're doing by disabling GRUB_SAVEDEFAULT (as this also prevents writes). We already had such a patch as linked above but seems it has been dropped somewhere before mga8, and it should be put back.
(In reply to Florian Hubold from comment #9) > We already had such a patch as linked above but seems it has been dropped > somewhere before mga8, and it should be put back. Seem like an easy fix, or why was it dropped?
Target Milestone: --- => Mageia 9
*** Bug 30164 has been marked as a duplicate of this bug. ***
CC: (none) => 79625490833
*** Bug 30178 has been marked as a duplicate of this bug. ***
CC: (none) => estellnb
Apparently, this problem is significant.
Keywords: (none) => FOR_ERRATA8
I mean it is significant in appearance, troubling users, but only cosmetic. https://wiki.mageia.org/en/Mageia_8_Errata#Boot
Keywords: FOR_ERRATA8 => IN_ERRATA8
I have now reproduced that under Debian 11: It appears if you edit /etc/default/grub to show: GRUB_DEFAULT=saved GRUB_SAVEDEFAULT=true It is because of the GRUB_SAVEDEFAULT and it appears when grub tries to write to /boot/grub/grubenv. I have already tested it, this file is not sparse in deed. The following pages suggests to check a few other things about this file, but none of that helped in deed: https://github-wiki-see.page/m/sp2004c/wiki-and-QA/wiki/grub-error%3A-sparse-file-is-not-allowed Somewhere else I had the suggestion for GRUB_PRELOAD_MODULES="part_gpt part_msdos btrfs zstd", but that did not help either (grub-install --recheck --no-rs-codes --modules="btrfs zstd part_gpt part_msdos"). I remember having used Grub with btrfs before, but that never has been a problem.
Created attachment 13208 [details] updgrubcfg - script I have resolved this issue for me by simply loading and storing the grub environment on my UEFI partition rather than trying to write to /boot. I think this would be a good solution, also for Mageia. Of course you must not hardcode the partition number of the UEFI partition in /etc/grub.d/00_header. update-grub does the right thing once this file is modified. You will only need that change for UEFI machines where the rootfs is btrfs or reiserfs. I believe I know why it does not work with btrfs: Files that are smaller than a disk block are stored with the inodes by btrfs and reiserfs. However extending the /boot/grub/grubenv file to 4096 byte did not help in deed. You could ask a btrfs expert about the issue. Nonetheless I believe an UEFI-only fix is all we need. Up to recently I have used Mageia Cauldron on an elder BIOS machine and that one did not exhibit this problem with btrfs. Here I have a resource that documents that the grubenv is most likely stored in the spare partition space with msdos/bios machines: https://www.mail-archive.com/grub-devel@gnu.org/msg32246.html
You will also need an "grub-editenv /boot/efi/grubenv create" for this, cause I suppose the grubenv file needs to exist before booting.
OOps; should likely be "#\(save_env\|load_env\)\( .[^f]\|.\?.\?$\)#" instead of "#\(save_env\|load_env\)\( [^-][^f]\|.\?.\?$\)#" for the sake of there could theoretically be another option than -f to load/save_env.
Yes, the problem is significant, because Grub needs to remember the last booted OS. Otherwise on a resume from hibernate it will try to boot into the wrong system which results in something that is like a crash or worse.