95

This message occurs when leaving the Grub menu and before the Ubuntu splash screen.

How do I fix the problem to clear the message?

And what doe is it mean?

error:  Diskfilter writes are not supported

System boots and seems to work just fine.

2
  • 1
    Still not fixed in Ubuntu Desktop 15.04... Aug 26, 2015 at 5:07
  • 1
    Still not fixed in 16.04. This breakneck pace of bug fixing is hard to keep up with. Aug 8, 2016 at 20:47

3 Answers 3

154
+100

It's a BUG!

This is a bug that occurs in the most recent version of Ubuntu Server LTS (Ubuntu Server 14.04 LTS), when you create the boot partition (or the root partition, when the boot partition doesn't exists) inside a LVM or a RAID partition.

You can get more info about this bug in Ubuntu Launchpad: Bug #1274320 "Error: diskfilter writes are not supported".

Update: This bug is already fixed in Ubuntu Server 14.04 and some newer Ubuntu versions. Probably, you only need to run apt-get upgrade.

Why does this bug occur?

When the system is booting, GRUB reads (load_env) data in /boot/grub/grubenv. This file is called GRUB Environment Block.

From the GRUB Manual:

It is often useful to be able to remember a small amount of information from one boot to the next.

[...]

At boot time, the load_env command (see load_env) loads environment variables from it, and the save_env (see save_env) command saves environment variables to it.

[...]

grub-mkconfig uses this facility to implement GRUB_SAVEDEFAULT

This behavior can be founded in /etc/grub.d/00_header (update-grub uses this file to generate the /boot/grub/grub.cfg file):

if [ -s $prefix/grubenv ]; then
  set have_grubenv=true
  load_env
fi

The problem is that the save_env statement only works in simple installations (you can't run save_env inside a RAID or LVM disk). From the GRUB manual:

For safety reasons, this storage is only available when installed on a plain disk (no LVM or RAID), using a non-checksumming filesystem (no ZFS), and using BIOS or EFI functions (no ATA, USB or IEEE1275).

The GRUB recordfail feature uses the save_env statement to update the recordfail state (see Ubuntu Help - Grub 2, "Last Boot Failed or Boot into Recovery Mode" section). However, in Ubuntu 14.04 (and in recent Debian versions), the save_env statement (inside the recordfail feature) is used even if GRUB is installed in a LVM or a RAID.

Let's see the lines from 104 to 124 in /etc/grub.d/00_header:

if [ "$quick_boot" = 1 ]; then
    [...]
    case "$FS" in
      btrfs | cpiofs | newc | odc | romfs | squash4 | tarfs | zfs)
    cat <<EOF
  # GRUB lacks write support for $FS, so recordfail support is disabled.
  [...]
  if [ -n "\${have_grubenv}" ]; then if [ -z "\${boot_once}" ]; then save_env recordfail; fi; fi

GRUB correctly skips the recordfail feature when using unsupported filesystems (btrfs, zfs, etc), but it doesn't skip LVM and RAID at any moment.

How does GRUB protect itself from writing inside RAID and LVM?

To read/write correctly in a filesystems, GRUB loads an appropriate module.

GRUB uses the diskfilter module (insmod diskfilter) in RAID partitions, and the lvm module in LVM partitions.

Let's see the read/write implementation of the diskfilter module:

apt-get source grub2
vim grub2-2.02~beta2/grub-core/disk/diskfilter.c

I'm pasting the code here (lines from 808 to 823). The warning showed in this question appears at line 821:

static grub_err_t
grub_diskfilter_read (grub_disk_t disk, grub_disk_addr_t sector,
                  grub_size_t size, char *buf)
{
  return read_lv (disk->data, sector, size, buf);
}

static grub_err_t
grub_diskfilter_write (grub_disk_t disk __attribute ((unused)),
             grub_disk_addr_t sector __attribute ((unused)),
             grub_size_t size __attribute ((unused)),
             const char *buf __attribute ((unused)))
{
  return grub_error (GRUB_ERR_NOT_IMPLEMENTED_YET,
                 "diskfilter writes are not supported");
}

The grub_diskfilter_read function is implemented (and GRUB can read RAID filesystems). However, the grub_diskfilter_write function raises a GRUB_ERR_NOT_IMPLEMENTED_YET error.

Why does using quick_boot=0 solve the problem? And why is it the wrong solution?

If you look one more time in the /etc/grub.d/00_header code, you will see that the recordfail featured is only used when quick_boot=1. So, changing quick_boot from 1 to 0 disables the recordfail feature, and disables writes in the RAID/LVM partition.

However, it'll disable many other features too (run grep \$quick_boot /etc/grub.d/* and you'll see). More yet, if one day you change your /boot/grub directory to outside the RAID/LVM, the recordfail feature will still disabled.

Summarily, this solution unnecessarily disables features, and it's not generic.

What is the correct solution?

The correct solution should consider disable the save_env statements when GRUB is inside LVM or RAID partitions.

One patch was proposed in the Debian Bug Tracker system to implement this solution. It can be found in: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=754921

The idea behind this patch is:

  • Run a grub-probe --target=abstraction "${grubdir}" command to get what kind of abstraction modules GRUB uses to read/write files in the /boot/grub directory;
  • If GRUB uses the diskfilter or lvm module, skip the recordfail save_env statement and write an appropriated comment in the /boot/grub/grub.cfg file;
    • For example, # GRUB lacks write support for /dev/md0, so recordfail support is disabled.

How to apply the correct solution?

If you don't want to wait for this patch be applied by the Ubuntu/Debian guys in the official code, you can use my patched 00_header:

# Download
wget https://gist.githubusercontent.com/rarylson/da6b77ad6edde25529b2/raw/99f266a10e663e1829efc25eca6eddb9412c6fdc/00_header_patched
# Apply
mv /etc/grub.d/00_header /etc/grub.d/00_header.orig
mv 00_header_patched /etc/grub.d/00_header
# Disable the old script and enable the new one
chmod -x /etc/grub.d/00_header.orig
chmod +x /etc/grub.d/00_header
# Update Grub
update-grub
24
  • Thank you especially for the bug reference. I hope you will understand that I found nux' solution more compelling, though. ;)
    – Run CMD
    Jul 24, 2014 at 5:48
  • 6
    Hi @ClassStacker, I summarized the answer! It was very big and it was very difficult for many people to understand :p It is still big, but at least I organized it in sections. So now you can look only in the sections of interest. Jul 31, 2014 at 4:16
  • 8
    Wow. Thank you. If there was an "answer of the month" feature, I'd vote for yours. Also, you deserve a "no BS" award. This is the kind of articles which really provide value, and which make a huge difference between this site network as compared to forums.
    – Run CMD
    Aug 1, 2014 at 8:46
  • 1
    Sadly I have been affected by this bug and none of the fixes in the bug report or here by editing the 00_header file have worked. I won't disable the quick_boot to make it go away.
    – douggro
    Aug 18, 2014 at 5:13
  • 3
    7 years later, is this still a bug?
    – Typewar
    Aug 4, 2021 at 14:06
36

I think this error occur because of raid or LVM partition .

For a temporary fix for this problem :

Edit :/etc/grub.d/10_linux

Replace 'quick_boot="1"' with 'quick_boot="0"'

Then :

sudo update-grub
4
  • Thanks, it worked perfectly. Yes, I am using LVM for all volumes.
    – RCF
    May 18, 2014 at 0:42
  • Thank you for this solution. It saved me a lot of work. Do you have a bit of background info also?
    – Run CMD
    Jul 24, 2014 at 5:43
  • @ClassStacker if you are asking for more info from nux, you need to edit your comment to begin with (@nux). If you are asking me, what type of background are you seeking?
    – RCF
    Jul 24, 2014 at 16:43
  • 2
    @RCF-U14.04 1) No, I don't have to. Just click on "add comment" -> "help" to learn that "The post author will always be notified of your comment". 2) I wanted to know (from nux) why this solves the problem, especially given the extensive answer by Rarylson Freitas. But if you can answer that, feel free to do so.
    – Run CMD
    Jul 25, 2014 at 3:20
0

This error isn't (anymore) due to a bug as I got it on my Debian 12 server few days back. Though Rarylson Freitas' answer covers it, it mentions it as a Ubuntu bug, but the actual root cause lies buried.

Root cause: You setup GRUB to remember something for you but didn't provide a fixed, non-checksumming filesystem partition for storage.

Commonly, for GRUB to remember your last menu selection, you'd do

GRUB_SAVEDEFAULT=true

in your /etc/default/grub. To achieve this GRUB needs to write/save the selection information somewhere i.e. somewhere on a persistent disk. info grub environment 'environment block' states

GRUB provides an "environment block" which can be used to save a small amount of state.

...

The environment block is a preallocated 1024-byte file, which normally lives in ‘/boot/grub/grubenv’ (although you should not assume this).

...

For safety reasons, this storage is only available when installed on a plain disk (no LVM or RAID), using a non-checksumming filesystem (no ZFS), and using BIOS or EFI functions (no ATA, USB or IEEE1275).

I created a partition scheme where /boot/grub lived on a LVM logical volume and got this error.

When I moved my /boot to a fixed (ext4) partition (and fixed corresponding /etc/fstab entry) the issue got fixed.

GRUB: 2.12

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .