GRUB recordfail broken regarding LVM












1















on my UEFI booting computer I installed an fresh Ubuntu 18.04.1 LTS using LVM partition scheme some months ago.



$ lsblk -f
NAME FSTYPE LABEL UUID MOUNTPOINT
sda
├─sda1 vfat 79DE-0D6B /boot/efi
└─sda2 LVM2_member ZBlrfj-ZwAJ-2T3b-gUHr-eKVw-nhIi-9bQQTs
├─ubuntu--vg-root ext4 e85edc94-cc00-42c5-8994-cbb835e8e315 /
└─ubuntu--vg-swap_1 swap e699c892-4046-4d0b-957a-f936cc4c9973 [SWAP]


The first months every boot went as expected, what means the GRUB boot menu was only shown, if the system was not shut down correctly.
So the well known recordfail feature seemed to work fine.



But then, some weeks ago, after an system upgrade to Ubuntu 18.04.2 LTS, the GRUB boot menu started to reveal itself at every boot, with a timeout of 30 seconds. Of course, in the long run this is annoying :-(



After inspecting the grub configuration file /boot/grub/grub.cfg I found out, that the recordfail feature was declared as broken regarding the usage of LVM?! The recordfail feature was disabled and therfore, GRUB keeps showing the boot menu at every boot.



  set recordfail=1
# GRUB lacks write support for lvm, so recordfail support is disabled.


The source for this permanent disabled recordfail feature I found then in the further GRUB configration generating script /etc/grub.d/00_header in the check_writable() function.



    abstractions="$(grub-probe --target=abstraction "${grubdir}")"
for abstraction in $abstractions; do
case "$abstraction" in
diskfilter | lvm)
cat <<EOF
# GRUB lacks write support for $abstraction, so recordfail support is disabled.
EOF
return 1
;;
esac
done


As you can read, the author declared the two modules diskfilter and lvm to brake the recordfail feature, thus resulting in the annoying 30 seconds timeout at every boot.



So far this is the status quo and all things seem to work as expected...
But, why did the recordfail feature work well in the first place? Is there a unresolved bug, which is the cause for disabling it?
Am I the only person on earth running this constelation of bootloader and partition scheme?
I'm looking forward, that some one can solve this mystery.



Thanks in advance



/EDIT I don't want to just get rid of the annoying GRUB boot menu timeout. Instead, I want to understand where the underlaying problem, for this behavior, is.










share|improve this question

























  • Welcome to AskUbuntu! Can you check to see of there is a recordfail marked in your grubenv? grub-editenv - list - please note the spaces on both sides of "-" are intentional.

    – Charles Green
    Feb 24 at 21:35











  • @CharlesGreen Your command results in an empty output. This is a good sign, ain't it?

    – MrksKwsnck
    Feb 24 at 21:40













  • It was worth a shot! Are you resuming from hibernate when this happens? I really have very little knowledge on the subject...

    – Charles Green
    Feb 24 at 21:42











  • If you've had a failed boot (I have) there will be a line saying "recordfail=1", and apparently, this causes grub2 in Ubuntu to always use the recordfail timeout... https://askubuntu.com/questions/202309/cannot-get-grub-menu-to-timeout-or-go-away

    – Charles Green
    Feb 24 at 21:45






  • 3





    Possible duplicate of Cannot get grub menu to timeout (or go away)

    – Charles Green
    Feb 24 at 21:47
















1















on my UEFI booting computer I installed an fresh Ubuntu 18.04.1 LTS using LVM partition scheme some months ago.



$ lsblk -f
NAME FSTYPE LABEL UUID MOUNTPOINT
sda
├─sda1 vfat 79DE-0D6B /boot/efi
└─sda2 LVM2_member ZBlrfj-ZwAJ-2T3b-gUHr-eKVw-nhIi-9bQQTs
├─ubuntu--vg-root ext4 e85edc94-cc00-42c5-8994-cbb835e8e315 /
└─ubuntu--vg-swap_1 swap e699c892-4046-4d0b-957a-f936cc4c9973 [SWAP]


The first months every boot went as expected, what means the GRUB boot menu was only shown, if the system was not shut down correctly.
So the well known recordfail feature seemed to work fine.



But then, some weeks ago, after an system upgrade to Ubuntu 18.04.2 LTS, the GRUB boot menu started to reveal itself at every boot, with a timeout of 30 seconds. Of course, in the long run this is annoying :-(



After inspecting the grub configuration file /boot/grub/grub.cfg I found out, that the recordfail feature was declared as broken regarding the usage of LVM?! The recordfail feature was disabled and therfore, GRUB keeps showing the boot menu at every boot.



  set recordfail=1
# GRUB lacks write support for lvm, so recordfail support is disabled.


The source for this permanent disabled recordfail feature I found then in the further GRUB configration generating script /etc/grub.d/00_header in the check_writable() function.



    abstractions="$(grub-probe --target=abstraction "${grubdir}")"
for abstraction in $abstractions; do
case "$abstraction" in
diskfilter | lvm)
cat <<EOF
# GRUB lacks write support for $abstraction, so recordfail support is disabled.
EOF
return 1
;;
esac
done


As you can read, the author declared the two modules diskfilter and lvm to brake the recordfail feature, thus resulting in the annoying 30 seconds timeout at every boot.



So far this is the status quo and all things seem to work as expected...
But, why did the recordfail feature work well in the first place? Is there a unresolved bug, which is the cause for disabling it?
Am I the only person on earth running this constelation of bootloader and partition scheme?
I'm looking forward, that some one can solve this mystery.



Thanks in advance



/EDIT I don't want to just get rid of the annoying GRUB boot menu timeout. Instead, I want to understand where the underlaying problem, for this behavior, is.










share|improve this question

























  • Welcome to AskUbuntu! Can you check to see of there is a recordfail marked in your grubenv? grub-editenv - list - please note the spaces on both sides of "-" are intentional.

    – Charles Green
    Feb 24 at 21:35











  • @CharlesGreen Your command results in an empty output. This is a good sign, ain't it?

    – MrksKwsnck
    Feb 24 at 21:40













  • It was worth a shot! Are you resuming from hibernate when this happens? I really have very little knowledge on the subject...

    – Charles Green
    Feb 24 at 21:42











  • If you've had a failed boot (I have) there will be a line saying "recordfail=1", and apparently, this causes grub2 in Ubuntu to always use the recordfail timeout... https://askubuntu.com/questions/202309/cannot-get-grub-menu-to-timeout-or-go-away

    – Charles Green
    Feb 24 at 21:45






  • 3





    Possible duplicate of Cannot get grub menu to timeout (or go away)

    – Charles Green
    Feb 24 at 21:47














1












1








1


2






on my UEFI booting computer I installed an fresh Ubuntu 18.04.1 LTS using LVM partition scheme some months ago.



$ lsblk -f
NAME FSTYPE LABEL UUID MOUNTPOINT
sda
├─sda1 vfat 79DE-0D6B /boot/efi
└─sda2 LVM2_member ZBlrfj-ZwAJ-2T3b-gUHr-eKVw-nhIi-9bQQTs
├─ubuntu--vg-root ext4 e85edc94-cc00-42c5-8994-cbb835e8e315 /
└─ubuntu--vg-swap_1 swap e699c892-4046-4d0b-957a-f936cc4c9973 [SWAP]


The first months every boot went as expected, what means the GRUB boot menu was only shown, if the system was not shut down correctly.
So the well known recordfail feature seemed to work fine.



But then, some weeks ago, after an system upgrade to Ubuntu 18.04.2 LTS, the GRUB boot menu started to reveal itself at every boot, with a timeout of 30 seconds. Of course, in the long run this is annoying :-(



After inspecting the grub configuration file /boot/grub/grub.cfg I found out, that the recordfail feature was declared as broken regarding the usage of LVM?! The recordfail feature was disabled and therfore, GRUB keeps showing the boot menu at every boot.



  set recordfail=1
# GRUB lacks write support for lvm, so recordfail support is disabled.


The source for this permanent disabled recordfail feature I found then in the further GRUB configration generating script /etc/grub.d/00_header in the check_writable() function.



    abstractions="$(grub-probe --target=abstraction "${grubdir}")"
for abstraction in $abstractions; do
case "$abstraction" in
diskfilter | lvm)
cat <<EOF
# GRUB lacks write support for $abstraction, so recordfail support is disabled.
EOF
return 1
;;
esac
done


As you can read, the author declared the two modules diskfilter and lvm to brake the recordfail feature, thus resulting in the annoying 30 seconds timeout at every boot.



So far this is the status quo and all things seem to work as expected...
But, why did the recordfail feature work well in the first place? Is there a unresolved bug, which is the cause for disabling it?
Am I the only person on earth running this constelation of bootloader and partition scheme?
I'm looking forward, that some one can solve this mystery.



Thanks in advance



/EDIT I don't want to just get rid of the annoying GRUB boot menu timeout. Instead, I want to understand where the underlaying problem, for this behavior, is.










share|improve this question
















on my UEFI booting computer I installed an fresh Ubuntu 18.04.1 LTS using LVM partition scheme some months ago.



$ lsblk -f
NAME FSTYPE LABEL UUID MOUNTPOINT
sda
├─sda1 vfat 79DE-0D6B /boot/efi
└─sda2 LVM2_member ZBlrfj-ZwAJ-2T3b-gUHr-eKVw-nhIi-9bQQTs
├─ubuntu--vg-root ext4 e85edc94-cc00-42c5-8994-cbb835e8e315 /
└─ubuntu--vg-swap_1 swap e699c892-4046-4d0b-957a-f936cc4c9973 [SWAP]


The first months every boot went as expected, what means the GRUB boot menu was only shown, if the system was not shut down correctly.
So the well known recordfail feature seemed to work fine.



But then, some weeks ago, after an system upgrade to Ubuntu 18.04.2 LTS, the GRUB boot menu started to reveal itself at every boot, with a timeout of 30 seconds. Of course, in the long run this is annoying :-(



After inspecting the grub configuration file /boot/grub/grub.cfg I found out, that the recordfail feature was declared as broken regarding the usage of LVM?! The recordfail feature was disabled and therfore, GRUB keeps showing the boot menu at every boot.



  set recordfail=1
# GRUB lacks write support for lvm, so recordfail support is disabled.


The source for this permanent disabled recordfail feature I found then in the further GRUB configration generating script /etc/grub.d/00_header in the check_writable() function.



    abstractions="$(grub-probe --target=abstraction "${grubdir}")"
for abstraction in $abstractions; do
case "$abstraction" in
diskfilter | lvm)
cat <<EOF
# GRUB lacks write support for $abstraction, so recordfail support is disabled.
EOF
return 1
;;
esac
done


As you can read, the author declared the two modules diskfilter and lvm to brake the recordfail feature, thus resulting in the annoying 30 seconds timeout at every boot.



So far this is the status quo and all things seem to work as expected...
But, why did the recordfail feature work well in the first place? Is there a unresolved bug, which is the cause for disabling it?
Am I the only person on earth running this constelation of bootloader and partition scheme?
I'm looking forward, that some one can solve this mystery.



Thanks in advance



/EDIT I don't want to just get rid of the annoying GRUB boot menu timeout. Instead, I want to understand where the underlaying problem, for this behavior, is.







boot grub2 partitioning lvm






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Feb 26 at 22:47







MrksKwsnck

















asked Feb 24 at 20:46









MrksKwsnckMrksKwsnck

62




62













  • Welcome to AskUbuntu! Can you check to see of there is a recordfail marked in your grubenv? grub-editenv - list - please note the spaces on both sides of "-" are intentional.

    – Charles Green
    Feb 24 at 21:35











  • @CharlesGreen Your command results in an empty output. This is a good sign, ain't it?

    – MrksKwsnck
    Feb 24 at 21:40













  • It was worth a shot! Are you resuming from hibernate when this happens? I really have very little knowledge on the subject...

    – Charles Green
    Feb 24 at 21:42











  • If you've had a failed boot (I have) there will be a line saying "recordfail=1", and apparently, this causes grub2 in Ubuntu to always use the recordfail timeout... https://askubuntu.com/questions/202309/cannot-get-grub-menu-to-timeout-or-go-away

    – Charles Green
    Feb 24 at 21:45






  • 3





    Possible duplicate of Cannot get grub menu to timeout (or go away)

    – Charles Green
    Feb 24 at 21:47



















  • Welcome to AskUbuntu! Can you check to see of there is a recordfail marked in your grubenv? grub-editenv - list - please note the spaces on both sides of "-" are intentional.

    – Charles Green
    Feb 24 at 21:35











  • @CharlesGreen Your command results in an empty output. This is a good sign, ain't it?

    – MrksKwsnck
    Feb 24 at 21:40













  • It was worth a shot! Are you resuming from hibernate when this happens? I really have very little knowledge on the subject...

    – Charles Green
    Feb 24 at 21:42











  • If you've had a failed boot (I have) there will be a line saying "recordfail=1", and apparently, this causes grub2 in Ubuntu to always use the recordfail timeout... https://askubuntu.com/questions/202309/cannot-get-grub-menu-to-timeout-or-go-away

    – Charles Green
    Feb 24 at 21:45






  • 3





    Possible duplicate of Cannot get grub menu to timeout (or go away)

    – Charles Green
    Feb 24 at 21:47

















Welcome to AskUbuntu! Can you check to see of there is a recordfail marked in your grubenv? grub-editenv - list - please note the spaces on both sides of "-" are intentional.

– Charles Green
Feb 24 at 21:35





Welcome to AskUbuntu! Can you check to see of there is a recordfail marked in your grubenv? grub-editenv - list - please note the spaces on both sides of "-" are intentional.

– Charles Green
Feb 24 at 21:35













@CharlesGreen Your command results in an empty output. This is a good sign, ain't it?

– MrksKwsnck
Feb 24 at 21:40







@CharlesGreen Your command results in an empty output. This is a good sign, ain't it?

– MrksKwsnck
Feb 24 at 21:40















It was worth a shot! Are you resuming from hibernate when this happens? I really have very little knowledge on the subject...

– Charles Green
Feb 24 at 21:42





It was worth a shot! Are you resuming from hibernate when this happens? I really have very little knowledge on the subject...

– Charles Green
Feb 24 at 21:42













If you've had a failed boot (I have) there will be a line saying "recordfail=1", and apparently, this causes grub2 in Ubuntu to always use the recordfail timeout... https://askubuntu.com/questions/202309/cannot-get-grub-menu-to-timeout-or-go-away

– Charles Green
Feb 24 at 21:45





If you've had a failed boot (I have) there will be a line saying "recordfail=1", and apparently, this causes grub2 in Ubuntu to always use the recordfail timeout... https://askubuntu.com/questions/202309/cannot-get-grub-menu-to-timeout-or-go-away

– Charles Green
Feb 24 at 21:45




3




3





Possible duplicate of Cannot get grub menu to timeout (or go away)

– Charles Green
Feb 24 at 21:47





Possible duplicate of Cannot get grub menu to timeout (or go away)

– Charles Green
Feb 24 at 21:47










1 Answer
1






active

oldest

votes


















0














I just noticed this issue, too. It appears to be related to this change from January 9



https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1800722



It looks like a bug has been submitted to fix the issue caused by the original bug fix



https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1815002






share|improve this answer























    Your Answer








    StackExchange.ready(function() {
    var channelOptions = {
    tags: "".split(" "),
    id: "89"
    };
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function() {
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled) {
    StackExchange.using("snippets", function() {
    createEditor();
    });
    }
    else {
    createEditor();
    }
    });

    function createEditor() {
    StackExchange.prepareEditor({
    heartbeatType: 'answer',
    autoActivateHeartbeat: false,
    convertImagesToLinks: true,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: 10,
    bindNavPrevention: true,
    postfix: "",
    imageUploader: {
    brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
    contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
    allowUrls: true
    },
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    });


    }
    });














    draft saved

    draft discarded


















    StackExchange.ready(
    function () {
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f1120948%2fgrub-recordfail-broken-regarding-lvm%23new-answer', 'question_page');
    }
    );

    Post as a guest















    Required, but never shown

























    1 Answer
    1






    active

    oldest

    votes








    1 Answer
    1






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    0














    I just noticed this issue, too. It appears to be related to this change from January 9



    https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1800722



    It looks like a bug has been submitted to fix the issue caused by the original bug fix



    https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1815002






    share|improve this answer




























      0














      I just noticed this issue, too. It appears to be related to this change from January 9



      https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1800722



      It looks like a bug has been submitted to fix the issue caused by the original bug fix



      https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1815002






      share|improve this answer


























        0












        0








        0







        I just noticed this issue, too. It appears to be related to this change from January 9



        https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1800722



        It looks like a bug has been submitted to fix the issue caused by the original bug fix



        https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1815002






        share|improve this answer













        I just noticed this issue, too. It appears to be related to this change from January 9



        https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1800722



        It looks like a bug has been submitted to fix the issue caused by the original bug fix



        https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1815002







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Mar 6 at 20:06









        Andrew LowtherAndrew Lowther

        111




        111






























            draft saved

            draft discarded




















































            Thanks for contributing an answer to Ask Ubuntu!


            • Please be sure to answer the question. Provide details and share your research!

            But avoid



            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.


            To learn more, see our tips on writing great answers.




            draft saved


            draft discarded














            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f1120948%2fgrub-recordfail-broken-regarding-lvm%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown





















































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown

































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown







            Popular posts from this blog

            flock() on closed filehandle LOCK_FILE at /usr/bin/apt-mirror

            Mangá

            Eduardo VII do Reino Unido