[SOLVED] GRUB btrfs error: sparse file not allowed

Hey folks,

I also get the warning when starting my Manjaro:
error: sparse file not allowed. - press any key to continue booting

I used the search-function and tried
sudo grub-editenv create

and edited /etc/default/grub like this:

**cat** /etc/default/grub
#GRUB_DEFAULT="saved"
GRUB_TIMEOUT="5"
GRUB_DISTRIBUTOR="Manjaro"
GRUB_CMDLINE_LINUX_DEFAULT="quiet resume=UUID=e860eca5-9535-45e7-b109-27d415b36e2a"
GRUB_CMDLINE_LINUX=""

# If you want to enable the save default function, uncomment the following
# line, and set GRUB_DEFAULT to saved.
#GRUB_SAVEDEFAULT="true"

# Preload both GPT and MBR modules so that they are not missed
GRUB_PRELOAD_MODULES="part_gpt part_msdos"

# Uncomment to enable Hidden Menu, and optionally hide the timeout count
#GRUB_HIDDEN_TIMEOUT="5"
#GRUB_HIDDEN_TIMEOUT_QUIET="true"

# Uncomment to use basic console
GRUB_TERMINAL_INPUT="console"

# Uncomment to disable graphical terminal
#GRUB_TERMINAL_OUTPUT="console"

# The resolution used on graphical terminal
# note that you can use only modes which your graphic card supports via VBE
# you can see them in real GRUB with the command `vbeinfo'
GRUB_GFXMODE="auto"

# Uncomment to allow the kernel use the same resolution used by grub
GRUB_GFXPAYLOAD_LINUX="keep"

# Uncomment if you want GRUB to pass to the Linux kernel the old parameter
# format "root=/dev/xxx" instead of "root=/dev/disk/by-uuid/xxx"
#GRUB_DISABLE_LINUX_UUID="true"

# Uncomment to disable generation of recovery mode menu entries
GRUB_DISABLE_RECOVERY="true"

# Uncomment and set to the desired menu colors.  Used by normal and wallpaper
# modes only.  Entries specified as foreground/background.
GRUB_COLOR_NORMAL="light-gray/black"
GRUB_COLOR_HIGHLIGHT="green/black"

# Uncomment one of them for the gfx desired, a image background or a gfxtheme
GRUB_BACKGROUND="/usr/share/grub/background.png"
#GRUB_THEME="/path/to/gfxtheme"

# Uncomment to get a beep at GRUB start
#GRUB_INIT_TUNE="480 440 1"

I don't use UEFI.

Manjaro is booting (so same situation like the others having this issue). However, the warning massage still appears. What else could I try?

Seantum

sudo nano /etc/default/grub

Then set

GRUB_SAVEDEFAULT=false

Is this the only solution? @philm

3 Likes

Thank you, that did the job for me.
But weird that it doesn't work if you comment out GRUB_SAVEDEFAULT ...

Commenting out instead of changing value makes grub use the default, which seems to be "true". :wink:

Other solutions are:
Use another bootloader (e.g. rEFInd works fine for me) OR
Change Grub default location for its variables from /boot/grub... to /boot/efi/EFI/Manjaro, for example (changes to Grub are necessary).

We need to comment out ‘GRUB_DEFAULT=saved’ as well.
These are 2 separate options because we can still have GRUB_DEFAULT=saved and not having GRUB_SAVEDEFAULT to do different things (setting grubenv).

Preferably GRUB_DEFAULT=0

I personally just ignore it. I can however confirm that the above solution works

Please try and explain what you mean?

If you set GRUB_SAVEDEFAULT=false nothing else needs to be changed.

Gladly.
GRUB_DEFAULT= can be used to set default entry as the following examples show
GRUB_DEFAULT=0 {when we wish the first entry to be default - common usage}
GRUB_DEFAULT=3 {when we wish the 4th entry to be default as when we do not want to default to the latest kernel but the older kernel or to other OS's}
[But watch out for submenus which count as an entry]
We can also use the whole title to avoid miscount as like in
GRUB_DEFAULT='Manjaro Linux (Kernel: manjaro)'
GRUB_DEFAULT= does not require the use of grubenv
and the default is '0'.

GRUB_SAVEDEFAULT= on the other hand makes use of grubenv and GRUB_SAVEDEFAULT=saved makes a ....'setting' or 'entry' in /boot/grub/grubenv.
When we boot up, the grub.cfg has a 'stanza' to check if there is any entry in /boot/grub/grubenv and use that to make make the last 'saved' or 'last boot entry' as the default.
So to enable 'last boot entry' as default, we will need both
GRUB_SAVEDEFAULT=true
GRUB_DEFAULT= saved

That's the reason these are 2 separate options in /etc/default/grub.
Hope this explains.

Now, btrfs (and f2fs) by reason of their file structure, cannot use grubenv and when the grub.cfg tries to access it, there will be a non-fatal error. So since GRUB_DEFAULT= does not need to access grubenv (without GRUB_SAVEDEFAULT=true), there will be no error.
{note we now do not need to have separate boot partitions for these file systems}

Hope these explanations help.
Cheers.

2 Likes

Not sure if this is right but made a separate boot partition mounted as /boot and formatted as fat32
this is in addition to the mounted /boot/efi also formatted as fat32 the result is no grub boot error.

Your /boot must not be in fat32.
It must be in ext4 or ext2, preferably ext2.
And yes, /boot/efi must be in fat32.

You may not be facing problems now, but you will almost be certain to have problems in the future.

Correct, having a separate /boot partition not in btrfs will not give this nonfatal error. But as said, error will be avoided if small changes are made in /etc/default/grub if /boot is in /root in bttfs.

PS: some $esp are /boot like for systemd-boot and must be in fat32. But grub $esp is /boot/efi.
All $esp must be fat32
All non-$esp must not be fat32.

1 Like

Made /boot ext4 seems to still work ok.
Many thanks for all your help :+1:

2 Likes

I have the same problem.

I willingly use a btrfs system disk because I want to use it's snapshot abilities together with timeshift.

But editing /etc/default/grub so that it has
GRUB_SAVEDEFAULT=false
and
GRUB_DEFAULT=0

and afterwards running
sudo grub-editenv create
didn't solve it for me.

UPDATE:
ahh, I was missing the
sudo update-grub
now it works!

I did have a problem setting boot partition to ext4 this resulted on a new install of nothing being copied to the boot partition, this did work with it as fat32. So have temporarily abandoned this approach by using GRUB_SAVEDEFAULT=false once again.

Thank you :v:

It Did not do the Trick

but as Long as i can Log in
im good :smile:

1 Like

Did you run

sudo update-grub 

afterwards?

1 Like

No :slight_smile:

That's why it doesn't work run the command and reboot

1 Like

I realize this question has been answered already but I'm curious about something and don't want to start a new thread to ask.

Is this because with btrfs / isn't the top-most directory and it's actually @/due to subvolumes? I might be completely wrong, I'm just trying to learn about the more 'advanced' aspects of Linux now that I'm transitioning to Manjaro from MX-Linux.

Thanks!

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.

Forum kindly sponsored by