Announcement

Collapse
No announcement yet.

Non fatal error after selecting grub entry

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    [SOLVED] Non fatal error after selecting grub entry

    ##################################### closed as an "automatic" solution came somehow up, see post #10 #####################################

    Hello everyone!

    I recently installed Kubuntu 20.04.1 and I am getting an error right after grub menu

    When choosing to boot kubuntu, I get:
    Code:
    error: diskfilter writes are not supported
    
    press any key to continue...
    and when I choose win10 I get:
    Code:
    error: diskfilter writes are not supported
    setting partition type to 0x7
    
    press any key to continue...
    In both cases the pc works, but I do want to get rid of this error/bug.

    I installed kubuntu fresh, meaning I chose the option “use the entire disk and set up LVM”. It was the first time I chose to set up LVM, all other installs I had done in the past were without it. I just thought I could do it and explore later what it is.

    I have three disks, namely 2ssd (kubuntu-windows) and one hdd (storage). During installation the disk with windows was disconnected. I booted from a usb stick and installed kubuntu with the option I mentioned above. Once install was complete, I installed the kubuntu updates and some software from Discover, all worked fine. Then I shut down, connected the win ssd, booted and did a sudo update-grub, so I could have the option to boot either OS. From that point on I am not 100% sure that the error started showing up just yet. I also did a minor edit in /etc/default/grub, in order to remember the last boot option, so it currently is:

    Code:
    #GRUB_DEFAULT=0
    GRUB_DEFAULT=saved
    GRUB_SAVEDEFAULT=true
    GRUB_TIMEOUT_STYLE=hidden
    GRUB_TIMEOUT=6
    GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
    GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
    GRUB_CMDLINE_LINUX=""
    Next, sudo update-grub, restart and I am now getting the error I described above. (By the way, the savedefault command does not work, the default option is still ubuntu, but this is not the problem here, getting rid of the “diskfilter writes” error is)

    So, after some googling (or perhaps duckduckgoing) I found that I should edit a line in /etc/grub.d/10_linux:

    quick_boot="0"

    which didn’t do anything either...

    Any ideas?

    Thanks in advance!

    EDIT: I restored et/default/grub and etc/grub.d/10_linux to their original versions, the error persists.
    Last edited by zahtar; Sep 13, 2020, 04:33 PM. Reason: extra info

    #2
    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.
    Regards, John Little

    Comment


      #3
      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?
      Last edited by zahtar; Sep 09, 2020, 03:10 AM. Reason: corrected typos

      Comment


        #4
        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.
        Regards, John Little

        Comment


          #5
          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

          Comment


            #6
            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.
            Regards, John Little

            Comment


              #7
              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

              Comment


                #8
                I'm rusty on this, now it help me clear my mind Thanks for this wonderful help.
                doss soundbox touch

                Comment


                  #9
                  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.
                  Regards, John Little

                  Comment


                    #10
                    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!
                    Last edited by zahtar; Sep 13, 2020, 05:35 PM.

                    Comment

                    Working...
                    X