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.

  • 1
    Still not fixed in Ubuntu Desktop 15.04... – ThePiercingPrince Aug 26 '15 at 5:07
  • 1
    Still not fixed in 16.04. This breakneck pace of bug fixing is hard to keep up with. – Paul Tomblin Aug 8 '16 at 20:47
up vote 143 down vote accepted
+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
  • Thank you especially for the bug reference. I hope you will understand that I found nux' solution more compelling, though. ;) – Run CMD Jul 24 '14 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. – Rarylson Freitas Jul 31 '14 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 '14 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 '14 at 5:13
  • @douggro I'm not sure why the edited 00_header file (as recommended here) wouldn't work. I know that just because it works for me (and for Rarylson Freitas) doesn't mean it necessarily would work for everyone. But did you make sure to give the right permissions to the old and new 00_header and to run update-grub? (If you just edited 00_header in place, no chmod is required, but update-grub remains necessary.) – Eliah Kagan Oct 1 '14 at 15:48

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
  • Thanks, it worked perfectly. Yes, I am using LVM for all volumes. – RCF May 18 '14 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 '14 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 '14 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 '14 at 3:20

protected by Eliah Kagan Aug 24 '14 at 14:14

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.