Announcement

**jlittle** · Sep 06, 2020, 03:30 PM

It's a messy regression, see f.ex. this bug on launchpad. One of those where developers dispute the bug for years.

The only writing grub ever does is to the grubenv block. Grub doesn't support doing this in several cases, btrfs and LVM being a couple. So why do the grub scripts generate "save_env" commands when it knows it won't work? Beats me. So with LVM grub can't save anything, and GRUB_DEFAULT=saved is not going to work. Maybe changing GRUB_DEFAULT to 0 will fix it, but on my btrfs that made no difference.

Now, if running grub-editenv list shows "initrdfail", "next_entry", or "prev_saved_entry" from my reading of the grub.cfg generated on my Kubuntu with btrfs, that would trigger an attempt to write the grubenv block. If you see these, then deleting the file /boot/grub/grubenv might avoid the error.

**zahtar** · Sep 09, 2020, 03:07 AM

Hello jlittle, thank you for your reply!

I ran grub-editenv list in konsonle, but got no output. The file /boot/grub/grubenv has actually nothing, as to my understanding # disables everything that follows it

Code:

# GRUB Environment Block
#######################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################

Therefore I tried renaming it to grubenv_old and rebooting instead of deleting.

Right after grub, I got similar errors to the abovementioned, which read something like

Code:

error: file /boot/grub/grubenv not found

press any key to continue...

and the 0x7 notice for win10. When I booted kubuntu, I now see a new (autogenerated) grubenv file identical to the initial (like the one with the ### I mean). Rebooted and I get again the same error as in post #1. Is there any grub file I can edit, or is it as you say the inability of grub to write files that causes this?

**jlittle** · Sep 09, 2020, 05:40 AM

No, my idea was no good. The cause will be in the depths of the scripts that generate grub.cfg. Sometimes, there's variable that can be set in /etc/default/grub, often undocumented, to influence the scripts' behaviours.

This sort of thing happens with grub a lot. A radical solution, that I have used for many years, is to follow the advice in the Grub manual:

those who feel that it would be easier to write grub.cfg directly are encouraged to do so ... and to disable any system provided by their distribution to automatically run grub-mkconfig

It takes about 10 lines of grub script to boot a Ubuntu-derived system, and they can remain untouched for years; "stable". All those scripts that run other scripts that generate yet more scripts cause breakage easily.

**zahtar** · Sep 09, 2020, 02:49 PM

hello, thanks again for your support!

Messing with the grub file sounds intriguing, but my knowledge of programming is next to nothing. I have written LaTeX documents, so I understand that something begins and ends, there are various commands, # makes the line inactive and some other very basic stuff. So if it is easy to read, maybe I could attempt it. If it is a matter of setting paths like sda1, sdb1 etc I believe I can manage, but if programming knowledge is necessary, I won't be able to go all the way.

I took a superficial look on these links:

https://www.gnu.org/software/grub/ma...iguration.html
https://www.gnu.org/software/grub/ma...like-scripting

and in a quick attempt to find a minimal working example I found the following, which I cannot consider minimal:
https://gist.github.com/Pysis868/27203177bdef15fbb70c

It is now late and I am too exhausted to read them in depth and begin attempts, but if there is something more simple you could suggest, please do

**jlittle** · Sep 09, 2020, 03:42 PM

When I've got time, maybe after work, (12 hours hence) I'll test out a minimal grub.cfg. Mine presently has grown a bit with lots of cruft.

**zahtar** · Sep 10, 2020, 02:07 PM

Thanks for your support John, I appreciate it! No rush, these days are busy and I don't know when I'll be able to put time in this project.

I found the following thread that concerns installing grub in a seperate partition and manually writing a grub.cfg file. I'll take a look if I can find the partition table type and thee UUID of the ssd I am booting. It seems doable, although it doesn't mention a windows entry. I'll try it and see how it goes. Worst case scenario is a format and clean install + software which I guess will take me around 40min.

https://www.kubuntuforums.net/showth...GRUB-partition

**g.lex** · Sep 10, 2020, 10:03 PM

I'm rusty on this, now it help me clear my mind

Thanks for this wonderful help.

**jlittle** · Sep 11, 2020, 05:02 PM

Found some time to make sure my minimal grub.cfg, called grub_min.cfg, worked.

Code:

insmod part_gpt
insmod btrfs
insmod all_video
insmod part_msdos
insmod ext2

set timeout=5

menuentry 'Kubuntu' --class ubuntu --class gnu-linux --class gnu --class os {
 search --no-floppy --set=root --label "main"
 linux /@/boot/vmlinuz root=LABEL=main ro rootflags=subvol=@
 initrd /@/boot/initrd.img
}
menuentry 'extras' {
 search --no-floppy --set=root --label "main"
 configfile /@/boot/grub/grub.cfg
}

Note:

It uses labels instead of UUIDs. The partition here is lablelled "main". I find using labels far simpler, maintainable, and reliable than UUIDs, but you have to get the label right, and ensure it's unique in the system. To use a UUID, --label would change to --fs-uuid, "main" would change to the UUID, and "LABEL" would change to "UUID".
That boots to a btrfs in a subvolume called "@" (the default on a ubuntu btrfs install). If a btrfs subvolume is not used, say because the fs is ext4, one would take out all the "/@" and remove the rootflags phrase.
It uses the symlinks that APT maintains to point to the latest kernel. This means it does not have to be updated when there's a new kernel.
The "extras" just runs the bloated grub.cfg that grub builds, just in case one wants to boot an older kernel or use recovery mode.

Another install, chuck in a few more lines. For a non-ubuntu install, there are likely differences, f.ex. gentoo has "kernel" and "initramfs" instead of vmlinuz and initrd.img. I can't remember what a windows entry looks like, but one can copy paste from /boot/grub/grub.cfg.

Not really minimal but as well I have

Code:

loadfont "DejaVuSansMono24"
set gfxmode=1920x1080
insmod gfxterm
terminal_output gfxterm
if background_image -m stretch $prefix/green_arch.jpg; then
 set menu_color_normal=yellow/black
 set menu_color_highlight=black/light-gray
else
 set menu_color_normal=white/black
 set menu_color_highlight=black/light-gray
 background_color 75,75,75
fi

where the image and the font file font/DejaVuSansMono24.pf2 have to be present.

**zahtar** · Sep 13, 2020, 04:27 PM

Hello jlittle! Thank you very much for the time you have put into this!

I have noticed that the error has stopped showing up the last few days. I did the following two things:

a) I stopped shutting down from windows, only rebooting to kubuntu to shut down from there.
The reason that I started doing this, is because I want to have write access to ntfs partitions. I noticed that from time to time I was not able to write to the storage disk, or the windows disk, so after some googling I read somewhere that windows “write protects” ntfs partitions when shutting down but not when rebooting. So I started the habit of shutting down only from kubuntu.

b) I did a kernel update.
The update that Discover brought up, so I guess this might have fixed whatever made grub show the “diskfilter writes…” error occur.

Since the reason I started this thread does not occur any more, I will mark this topic as solved (I wanted to mark closed as we did not come to a final verdict but I didn't find such option). At some point I might experiment with the grub.cfg as you suggest, provided that I am certain I will not mess up the current state.

I’ll keep in mind your mwe and get back to it when I have more time, in combination with the link of post #7. But for now, I’ll stay in the “if it works don’t fix it” approach. That’s why I’ve been choosing LTS releases for the past few years

Thanks again for your time and interest!

PS: Any advice/idea is still welcome, I just wanted to mark the thread so it doesn’t draw unnecessary attention from people who could help someone else in the forums.

------------------

g.lex glad this proved helpful!

Announcement

Non fatal error after selecting grub entry

[SOLVED] Non fatal error after selecting grub entry

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment