GRUB error: sparse file not allowed, die 2th

Because the thread in which this topic has already been discussed is closed, I have to ask my question here in a new thread.

The solution described by @linux-aarhus, for example, means that the latest installed kernel is always booted: GRUB_DEFAULT=0.

However, I have always installed the latest LTS kernel and always want to boot with it. In the boot menu list, this is the 3rd entry from the top. So I selected GRUB_DEFAULT=2, but this led to another error message during the subsequent boot process: GRUB error: sparse file not allowed. What do I have to enter to be able to boot from the LTS kernel?

That cited solution does normally not apply.
It was explicitly about a case where grub had no write access.

The default is:

and it will always boot the newest - or remember the last one that you chose and boot it next time


refers to the third entry

… if and when you have one “standard” and one fallback image for each kernel
(as is generated by default)
this will be the second “standard” kernel in the list

This is not the newest - but the second, the older one.

(with these above mentioned options set)

Precisely NOT, as it is known that btrfs cannot write to grub.env, precisely because ext4 is required for this. So you get around this by omitting GRUB_SAVEDEFAULT=true and using GRUB_DEFAULT=* instead. The only problem is that I have not achieved anything with the entry GRUB_DEFAULT=2, although the 3rd entry from above should correspond to a 2 (0 - 1- 2). What have I done wrong?

0: mainline kernel
1: fallback
2: LTS-kernel
3: falback

My bad, maybe - I did not go and read your other thread that you referred to.
I didn’t search for it.
savedefault may not work because of that

but: does it?

have a look and confirm which is first, second, third …:
sudo less /boot/grub/grub.cfg

I have no knowledge about or experience with BTRFS - so I better shut up now. :man_shrugging:

On sudo less /boot/grub/grub.cfg I get an output which, to be honest, I can’t really do much with. Also, I can’t get the whole content highlighted to copy it here.

My approach was only the following:

Grub boot menu:

mainline kernel

The count starts at 0, so the LTS kernel is 2, but


does not work …

scroll through it - it’s not that long
on about the third page down you’ll see lines clearly referring to your kernels, section starts with:

### BEGIN /etc/grub.d/10_linux ###

and then:
menuentry 'Manjaro Linux ...'

1 Like
### BEGIN /etc/grub.d/10_linux ###
menuentry 'Manjaro Linux' --class manjaro --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-08e473dc-a92c-4224-9efe-ae6ac6b2e20a' {

However, I have for now reset the grub config to the initial status.

See GRUB - ArchWiki and replace /boot/vmlinuz-linux with the path of the kernel you want as the default.

Edit: when you click the link I posted, it takes you to the relevant section.

1 Like

Thanks ben, but there is no vmlinuz-linux in /boot/, only the two files with the names of my installed kernels:




I have read the passage in the Arch Wiki, but now I don’t know how to change the row fole. What good is a path with the name of the kernel if it changes again later when I upgrade?

sorry if I’m being stupid :face_with_diagonal_mouth:

No, I said to replace vmlinuz-linux with the name off your installed kernel, so set the line in /etc/default/grub as:


Had you mentioned anywhere else in this post that it was linux66, I could have told you the answer more directly.

1 Like

The grub.env file cannot be written by grub in the early stage of loading.

You will have to edit the defaults when the system is up.

This can be don using grub-editenv, for information see man grub-editenv and full manual info grub-editenv

 $ grub-editenv --help
Usage: grub-editenv [OPTION...] FILENAME COMMAND

Tool to edit environment block.

  create                     Create a blank environment block file.
  list                       List the current variables.
  set [NAME=VALUE ...]       Set variables.
  unset [NAME ...]           Delete variables.

  -?, --help                 give this help list
      --usage                give a short usage message
  -v, --verbose              print verbose messages.
  -V, --version              print program version

If FILENAME is `-', the default value //boot/grub/grubenv is used.

There is no `delete' command; if you want to delete the whole environment
block, use `rm //boot/grub/grubenv'.

Report bugs to <>.

This implies that you can preset the saved entry by knowing the entry’s identification - example from my system - yours will of course differ

sudo grub-editenv - set saved_entry=gnulinux-6.6.32-1-MANJARO x64-advanced-07c78795-e8a4-4134-be2e-be5908c5b9f8

or you can specify which entry should be used after reboot

sudo grub-editenv - set next_entry=<the-next-entry>

or you can use the grub-set-default command

 $ grub-set-default --help
Usage: grub-set-default [OPTION] MENU_ENTRY
Set the default boot menu entry for GRUB.
This requires setting GRUB_DEFAULT=saved in /etc/default/grub.

  -h, --help              print this message and exit
  -V, --version           print the version information and exit
  --boot-directory=DIR    expect GRUB images under the directory DIR/grub
                          instead of the /boot/grub directory

MENU_ENTRY is a number, a menu item title or a menu item identifier.

Report bugs to <>.

Ja, aber …

Wenn ich den Eintrag GRUB_TOP_LEVEL="/boot/vmlinuz-6.6-x86-64"
so setze, bin ich auf die genaue Bezeichnung des Kernels festgelegt und muss dann nach jedem Kernelupdate diesen Eintrag wieder anpassen, sonst gibt das ein Problem beim nächsten boot? Ich dachte eher an soetwas, wie GRUB_TOP_LEVEL="/boot/vmlinuz-lts". Geht das nicht?

To decide which entry to use one can use this snippet

 $ sudo awk -F\' '/menuentry / {print $2}' /boot/grub/grub.cfg 
Manjaro Linux (Kernel: 6.6.32-1-MANJARO x64)
Manjaro Linux (Kernel: 6.6.32-1-MANJARO x64 - fallback initramfs)
UEFI Firmware Settings

Then take the appropriate line and feed it to grub-set-default

grub-set-default "Manjaro Linux (Kernel: 6.6.32-1-MANJARO x64)"

Obviously - this approach needs to revised on kernel updates - when the kernel changes.


Thx @linux-aarhus , @ben75 and @Nachlese :+1:

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