Could not prepare Boot variable: No space left on device grub-install: error: efibootmgr failed to register...












4














getting below error. But I think available space is enough for this (use% is 9%)
Can you please help us to resolve this ?



lab@lab:~$ sudo -E apt-get install subversion apache2-utils
Reading package lists... Done
Building dependency tree
Reading state information... Done
subversion is already the newest version (1.9.7-4ubuntu1).
apache2-utils is already the newest version (2.4.29-1ubuntu4.3).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
1 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n] Y
Setting up grub-efi-amd64-signed (1.93.4+2.02-2ubuntu8.3) ...
Installing for x86_64-efi platform.
Could not prepare Boot variable: No space left on device
grub-install: error: efibootmgr failed to register the boot entry: Input/output error.
dpkg: error processing package grub-efi-amd64-signed (--configure):
installed grub-efi-amd64-signed package post-installation script subprocess returned error exit status 1
dpkg: dependency problems prevent processing triggers for shim-signed:
shim-signed depends on grub-efi-amd64-signed; however:
Package grub-efi-amd64-signed is not configured yet.

dpkg: error processing package shim-signed (--configure):
dependency problems - leaving triggers unprocessed
Errors were encountered while processing:
grub-efi-amd64-signed
shim-signed
E: Sub-process /usr/bin/dpkg returned an error code (1)

lab@lab:~$ df -k .
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda2 479152840 37427836 417315612 9% /









share|improve this question
























  • Welcome to Ask Ubuntu. It mentions EFI so I'd check to see if you have a separate /boot partition, and it has space first. Next the most common cause; do you have inodes left? df -hi (the -h isn't needed, I just hate find larger numbers harder to read).
    – guiverc
    Sep 6 '18 at 5:29










  • lab@lab:~$ df -h Filesystem Size Used Avail Use% Mounted on udev 935M 0 935M 0% /dev tmpfs 193M 1.5M 192M 1% /run /dev/sda2 457G 36G 399G 9% / /dev/sda1 511M 4.7M 507M 1% /boot/efi
    – Shinu Thombikkodan
    Sep 6 '18 at 5:51








  • 1




    Please edit your question, and add additional info there (it allows far better formatting than comments do, plus better edit capability - even if you forget using the {} for 'code' quotes; others can do it for you)
    – guiverc
    Sep 6 '18 at 5:59








  • 1




    I don't see the inode info in your question? It's unreadable in comments sorry, and it was this info I was after moved to your question. You can reply to me or any user via comments, but additional info (such as the df -h suggested in my first comment) should go up in your question, along with subsequent info you've wrongly put in comments.. If new users come and read your question looking to help, they'll see what you add in questions, but often ignore comments :)
    – guiverc
    Sep 6 '18 at 6:16








  • 1




    @guiverc Although I also have a hard time reading the details in the comments, I doubt inodes are exhausted in the OP’s case. I can’t see any 100% used, the numbers are generally very low. There are zero inodes for /dev/sda1 aka /boot/efi which probably means it’s a FAT partition.
    – Melebius
    Sep 6 '18 at 10:08


















4














getting below error. But I think available space is enough for this (use% is 9%)
Can you please help us to resolve this ?



lab@lab:~$ sudo -E apt-get install subversion apache2-utils
Reading package lists... Done
Building dependency tree
Reading state information... Done
subversion is already the newest version (1.9.7-4ubuntu1).
apache2-utils is already the newest version (2.4.29-1ubuntu4.3).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
1 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n] Y
Setting up grub-efi-amd64-signed (1.93.4+2.02-2ubuntu8.3) ...
Installing for x86_64-efi platform.
Could not prepare Boot variable: No space left on device
grub-install: error: efibootmgr failed to register the boot entry: Input/output error.
dpkg: error processing package grub-efi-amd64-signed (--configure):
installed grub-efi-amd64-signed package post-installation script subprocess returned error exit status 1
dpkg: dependency problems prevent processing triggers for shim-signed:
shim-signed depends on grub-efi-amd64-signed; however:
Package grub-efi-amd64-signed is not configured yet.

dpkg: error processing package shim-signed (--configure):
dependency problems - leaving triggers unprocessed
Errors were encountered while processing:
grub-efi-amd64-signed
shim-signed
E: Sub-process /usr/bin/dpkg returned an error code (1)

lab@lab:~$ df -k .
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda2 479152840 37427836 417315612 9% /









share|improve this question
























  • Welcome to Ask Ubuntu. It mentions EFI so I'd check to see if you have a separate /boot partition, and it has space first. Next the most common cause; do you have inodes left? df -hi (the -h isn't needed, I just hate find larger numbers harder to read).
    – guiverc
    Sep 6 '18 at 5:29










  • lab@lab:~$ df -h Filesystem Size Used Avail Use% Mounted on udev 935M 0 935M 0% /dev tmpfs 193M 1.5M 192M 1% /run /dev/sda2 457G 36G 399G 9% / /dev/sda1 511M 4.7M 507M 1% /boot/efi
    – Shinu Thombikkodan
    Sep 6 '18 at 5:51








  • 1




    Please edit your question, and add additional info there (it allows far better formatting than comments do, plus better edit capability - even if you forget using the {} for 'code' quotes; others can do it for you)
    – guiverc
    Sep 6 '18 at 5:59








  • 1




    I don't see the inode info in your question? It's unreadable in comments sorry, and it was this info I was after moved to your question. You can reply to me or any user via comments, but additional info (such as the df -h suggested in my first comment) should go up in your question, along with subsequent info you've wrongly put in comments.. If new users come and read your question looking to help, they'll see what you add in questions, but often ignore comments :)
    – guiverc
    Sep 6 '18 at 6:16








  • 1




    @guiverc Although I also have a hard time reading the details in the comments, I doubt inodes are exhausted in the OP’s case. I can’t see any 100% used, the numbers are generally very low. There are zero inodes for /dev/sda1 aka /boot/efi which probably means it’s a FAT partition.
    – Melebius
    Sep 6 '18 at 10:08
















4












4








4


2





getting below error. But I think available space is enough for this (use% is 9%)
Can you please help us to resolve this ?



lab@lab:~$ sudo -E apt-get install subversion apache2-utils
Reading package lists... Done
Building dependency tree
Reading state information... Done
subversion is already the newest version (1.9.7-4ubuntu1).
apache2-utils is already the newest version (2.4.29-1ubuntu4.3).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
1 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n] Y
Setting up grub-efi-amd64-signed (1.93.4+2.02-2ubuntu8.3) ...
Installing for x86_64-efi platform.
Could not prepare Boot variable: No space left on device
grub-install: error: efibootmgr failed to register the boot entry: Input/output error.
dpkg: error processing package grub-efi-amd64-signed (--configure):
installed grub-efi-amd64-signed package post-installation script subprocess returned error exit status 1
dpkg: dependency problems prevent processing triggers for shim-signed:
shim-signed depends on grub-efi-amd64-signed; however:
Package grub-efi-amd64-signed is not configured yet.

dpkg: error processing package shim-signed (--configure):
dependency problems - leaving triggers unprocessed
Errors were encountered while processing:
grub-efi-amd64-signed
shim-signed
E: Sub-process /usr/bin/dpkg returned an error code (1)

lab@lab:~$ df -k .
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda2 479152840 37427836 417315612 9% /









share|improve this question















getting below error. But I think available space is enough for this (use% is 9%)
Can you please help us to resolve this ?



lab@lab:~$ sudo -E apt-get install subversion apache2-utils
Reading package lists... Done
Building dependency tree
Reading state information... Done
subversion is already the newest version (1.9.7-4ubuntu1).
apache2-utils is already the newest version (2.4.29-1ubuntu4.3).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
1 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n] Y
Setting up grub-efi-amd64-signed (1.93.4+2.02-2ubuntu8.3) ...
Installing for x86_64-efi platform.
Could not prepare Boot variable: No space left on device
grub-install: error: efibootmgr failed to register the boot entry: Input/output error.
dpkg: error processing package grub-efi-amd64-signed (--configure):
installed grub-efi-amd64-signed package post-installation script subprocess returned error exit status 1
dpkg: dependency problems prevent processing triggers for shim-signed:
shim-signed depends on grub-efi-amd64-signed; however:
Package grub-efi-amd64-signed is not configured yet.

dpkg: error processing package shim-signed (--configure):
dependency problems - leaving triggers unprocessed
Errors were encountered while processing:
grub-efi-amd64-signed
shim-signed
E: Sub-process /usr/bin/dpkg returned an error code (1)

lab@lab:~$ df -k .
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda2 479152840 37427836 417315612 9% /






apt






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Sep 6 '18 at 11:12









guiverc

4,09811522




4,09811522










asked Sep 6 '18 at 5:24









Shinu Thombikkodan

212




212












  • Welcome to Ask Ubuntu. It mentions EFI so I'd check to see if you have a separate /boot partition, and it has space first. Next the most common cause; do you have inodes left? df -hi (the -h isn't needed, I just hate find larger numbers harder to read).
    – guiverc
    Sep 6 '18 at 5:29










  • lab@lab:~$ df -h Filesystem Size Used Avail Use% Mounted on udev 935M 0 935M 0% /dev tmpfs 193M 1.5M 192M 1% /run /dev/sda2 457G 36G 399G 9% / /dev/sda1 511M 4.7M 507M 1% /boot/efi
    – Shinu Thombikkodan
    Sep 6 '18 at 5:51








  • 1




    Please edit your question, and add additional info there (it allows far better formatting than comments do, plus better edit capability - even if you forget using the {} for 'code' quotes; others can do it for you)
    – guiverc
    Sep 6 '18 at 5:59








  • 1




    I don't see the inode info in your question? It's unreadable in comments sorry, and it was this info I was after moved to your question. You can reply to me or any user via comments, but additional info (such as the df -h suggested in my first comment) should go up in your question, along with subsequent info you've wrongly put in comments.. If new users come and read your question looking to help, they'll see what you add in questions, but often ignore comments :)
    – guiverc
    Sep 6 '18 at 6:16








  • 1




    @guiverc Although I also have a hard time reading the details in the comments, I doubt inodes are exhausted in the OP’s case. I can’t see any 100% used, the numbers are generally very low. There are zero inodes for /dev/sda1 aka /boot/efi which probably means it’s a FAT partition.
    – Melebius
    Sep 6 '18 at 10:08




















  • Welcome to Ask Ubuntu. It mentions EFI so I'd check to see if you have a separate /boot partition, and it has space first. Next the most common cause; do you have inodes left? df -hi (the -h isn't needed, I just hate find larger numbers harder to read).
    – guiverc
    Sep 6 '18 at 5:29










  • lab@lab:~$ df -h Filesystem Size Used Avail Use% Mounted on udev 935M 0 935M 0% /dev tmpfs 193M 1.5M 192M 1% /run /dev/sda2 457G 36G 399G 9% / /dev/sda1 511M 4.7M 507M 1% /boot/efi
    – Shinu Thombikkodan
    Sep 6 '18 at 5:51








  • 1




    Please edit your question, and add additional info there (it allows far better formatting than comments do, plus better edit capability - even if you forget using the {} for 'code' quotes; others can do it for you)
    – guiverc
    Sep 6 '18 at 5:59








  • 1




    I don't see the inode info in your question? It's unreadable in comments sorry, and it was this info I was after moved to your question. You can reply to me or any user via comments, but additional info (such as the df -h suggested in my first comment) should go up in your question, along with subsequent info you've wrongly put in comments.. If new users come and read your question looking to help, they'll see what you add in questions, but often ignore comments :)
    – guiverc
    Sep 6 '18 at 6:16








  • 1




    @guiverc Although I also have a hard time reading the details in the comments, I doubt inodes are exhausted in the OP’s case. I can’t see any 100% used, the numbers are generally very low. There are zero inodes for /dev/sda1 aka /boot/efi which probably means it’s a FAT partition.
    – Melebius
    Sep 6 '18 at 10:08


















Welcome to Ask Ubuntu. It mentions EFI so I'd check to see if you have a separate /boot partition, and it has space first. Next the most common cause; do you have inodes left? df -hi (the -h isn't needed, I just hate find larger numbers harder to read).
– guiverc
Sep 6 '18 at 5:29




Welcome to Ask Ubuntu. It mentions EFI so I'd check to see if you have a separate /boot partition, and it has space first. Next the most common cause; do you have inodes left? df -hi (the -h isn't needed, I just hate find larger numbers harder to read).
– guiverc
Sep 6 '18 at 5:29












lab@lab:~$ df -h Filesystem Size Used Avail Use% Mounted on udev 935M 0 935M 0% /dev tmpfs 193M 1.5M 192M 1% /run /dev/sda2 457G 36G 399G 9% / /dev/sda1 511M 4.7M 507M 1% /boot/efi
– Shinu Thombikkodan
Sep 6 '18 at 5:51






lab@lab:~$ df -h Filesystem Size Used Avail Use% Mounted on udev 935M 0 935M 0% /dev tmpfs 193M 1.5M 192M 1% /run /dev/sda2 457G 36G 399G 9% / /dev/sda1 511M 4.7M 507M 1% /boot/efi
– Shinu Thombikkodan
Sep 6 '18 at 5:51






1




1




Please edit your question, and add additional info there (it allows far better formatting than comments do, plus better edit capability - even if you forget using the {} for 'code' quotes; others can do it for you)
– guiverc
Sep 6 '18 at 5:59






Please edit your question, and add additional info there (it allows far better formatting than comments do, plus better edit capability - even if you forget using the {} for 'code' quotes; others can do it for you)
– guiverc
Sep 6 '18 at 5:59






1




1




I don't see the inode info in your question? It's unreadable in comments sorry, and it was this info I was after moved to your question. You can reply to me or any user via comments, but additional info (such as the df -h suggested in my first comment) should go up in your question, along with subsequent info you've wrongly put in comments.. If new users come and read your question looking to help, they'll see what you add in questions, but often ignore comments :)
– guiverc
Sep 6 '18 at 6:16






I don't see the inode info in your question? It's unreadable in comments sorry, and it was this info I was after moved to your question. You can reply to me or any user via comments, but additional info (such as the df -h suggested in my first comment) should go up in your question, along with subsequent info you've wrongly put in comments.. If new users come and read your question looking to help, they'll see what you add in questions, but often ignore comments :)
– guiverc
Sep 6 '18 at 6:16






1




1




@guiverc Although I also have a hard time reading the details in the comments, I doubt inodes are exhausted in the OP’s case. I can’t see any 100% used, the numbers are generally very low. There are zero inodes for /dev/sda1 aka /boot/efi which probably means it’s a FAT partition.
– Melebius
Sep 6 '18 at 10:08






@guiverc Although I also have a hard time reading the details in the comments, I doubt inodes are exhausted in the OP’s case. I can’t see any 100% used, the numbers are generally very low. There are zero inodes for /dev/sda1 aka /boot/efi which probably means it’s a FAT partition.
– Melebius
Sep 6 '18 at 10:08












2 Answers
2






active

oldest

votes


















2














There have been a number of reports that if the NVRAM is more than 50% used, the efibootmgr will fail because there's a concern about being able to garbage collect EFI variables properly, or some such. Unfortunately, I couldn't find a clear way to determine the used/free space in NVRAM, so I'm going on suspicion.



There are a number of potential solutions to this:



1) Clear the dump files



grub stores efi logs in /sys/fs/efi/efivars/dump-*



Try deleting these to see if that's enough to bring the used space down. Then run apt -f install to see if the error has changed.



2) BIOS upgrade



If your hardware provider has a BIOS/EFI upgrade, then I'd recommend doing that also, then try apt -f install again.



3) LAST RESORT - DISABLE EFI CHECK



It's a little dangerous, because you could technically fill your NVRAM to a point were it's unbootable. However, I have used this process successfully on a Dell R420.



To override the check, add "efi_no_storage_paranoia" to the kernel option. To do this:




  1. Append "efi_no_storage_paranoia" to the GRUB_CMDLINE_LINUX_DEFAULT and GRUB_CMDLINE_LINUX variables in /etc/default/grub

  2. Update grub by running sudo update-grub

  3. Reboot

  4. Run apt -f install


For safety, I reverse this process afterward also. Kernel safety override parameters are not something you want to leave lying around!






share|improve this answer































    0














    I was able to fix the error by disabling the Compatibility Support Module (CSM) in my UEFI setup. After rebooting, the package update for 'grub-efi-amd64-signed' went through without issue.






    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%2f1072618%2fcould-not-prepare-boot-variable-no-space-left-on-device-grub-install-error-ef%23new-answer', 'question_page');
      }
      );

      Post as a guest















      Required, but never shown

























      2 Answers
      2






      active

      oldest

      votes








      2 Answers
      2






      active

      oldest

      votes









      active

      oldest

      votes






      active

      oldest

      votes









      2














      There have been a number of reports that if the NVRAM is more than 50% used, the efibootmgr will fail because there's a concern about being able to garbage collect EFI variables properly, or some such. Unfortunately, I couldn't find a clear way to determine the used/free space in NVRAM, so I'm going on suspicion.



      There are a number of potential solutions to this:



      1) Clear the dump files



      grub stores efi logs in /sys/fs/efi/efivars/dump-*



      Try deleting these to see if that's enough to bring the used space down. Then run apt -f install to see if the error has changed.



      2) BIOS upgrade



      If your hardware provider has a BIOS/EFI upgrade, then I'd recommend doing that also, then try apt -f install again.



      3) LAST RESORT - DISABLE EFI CHECK



      It's a little dangerous, because you could technically fill your NVRAM to a point were it's unbootable. However, I have used this process successfully on a Dell R420.



      To override the check, add "efi_no_storage_paranoia" to the kernel option. To do this:




      1. Append "efi_no_storage_paranoia" to the GRUB_CMDLINE_LINUX_DEFAULT and GRUB_CMDLINE_LINUX variables in /etc/default/grub

      2. Update grub by running sudo update-grub

      3. Reboot

      4. Run apt -f install


      For safety, I reverse this process afterward also. Kernel safety override parameters are not something you want to leave lying around!






      share|improve this answer




























        2














        There have been a number of reports that if the NVRAM is more than 50% used, the efibootmgr will fail because there's a concern about being able to garbage collect EFI variables properly, or some such. Unfortunately, I couldn't find a clear way to determine the used/free space in NVRAM, so I'm going on suspicion.



        There are a number of potential solutions to this:



        1) Clear the dump files



        grub stores efi logs in /sys/fs/efi/efivars/dump-*



        Try deleting these to see if that's enough to bring the used space down. Then run apt -f install to see if the error has changed.



        2) BIOS upgrade



        If your hardware provider has a BIOS/EFI upgrade, then I'd recommend doing that also, then try apt -f install again.



        3) LAST RESORT - DISABLE EFI CHECK



        It's a little dangerous, because you could technically fill your NVRAM to a point were it's unbootable. However, I have used this process successfully on a Dell R420.



        To override the check, add "efi_no_storage_paranoia" to the kernel option. To do this:




        1. Append "efi_no_storage_paranoia" to the GRUB_CMDLINE_LINUX_DEFAULT and GRUB_CMDLINE_LINUX variables in /etc/default/grub

        2. Update grub by running sudo update-grub

        3. Reboot

        4. Run apt -f install


        For safety, I reverse this process afterward also. Kernel safety override parameters are not something you want to leave lying around!






        share|improve this answer


























          2












          2








          2






          There have been a number of reports that if the NVRAM is more than 50% used, the efibootmgr will fail because there's a concern about being able to garbage collect EFI variables properly, or some such. Unfortunately, I couldn't find a clear way to determine the used/free space in NVRAM, so I'm going on suspicion.



          There are a number of potential solutions to this:



          1) Clear the dump files



          grub stores efi logs in /sys/fs/efi/efivars/dump-*



          Try deleting these to see if that's enough to bring the used space down. Then run apt -f install to see if the error has changed.



          2) BIOS upgrade



          If your hardware provider has a BIOS/EFI upgrade, then I'd recommend doing that also, then try apt -f install again.



          3) LAST RESORT - DISABLE EFI CHECK



          It's a little dangerous, because you could technically fill your NVRAM to a point were it's unbootable. However, I have used this process successfully on a Dell R420.



          To override the check, add "efi_no_storage_paranoia" to the kernel option. To do this:




          1. Append "efi_no_storage_paranoia" to the GRUB_CMDLINE_LINUX_DEFAULT and GRUB_CMDLINE_LINUX variables in /etc/default/grub

          2. Update grub by running sudo update-grub

          3. Reboot

          4. Run apt -f install


          For safety, I reverse this process afterward also. Kernel safety override parameters are not something you want to leave lying around!






          share|improve this answer














          There have been a number of reports that if the NVRAM is more than 50% used, the efibootmgr will fail because there's a concern about being able to garbage collect EFI variables properly, or some such. Unfortunately, I couldn't find a clear way to determine the used/free space in NVRAM, so I'm going on suspicion.



          There are a number of potential solutions to this:



          1) Clear the dump files



          grub stores efi logs in /sys/fs/efi/efivars/dump-*



          Try deleting these to see if that's enough to bring the used space down. Then run apt -f install to see if the error has changed.



          2) BIOS upgrade



          If your hardware provider has a BIOS/EFI upgrade, then I'd recommend doing that also, then try apt -f install again.



          3) LAST RESORT - DISABLE EFI CHECK



          It's a little dangerous, because you could technically fill your NVRAM to a point were it's unbootable. However, I have used this process successfully on a Dell R420.



          To override the check, add "efi_no_storage_paranoia" to the kernel option. To do this:




          1. Append "efi_no_storage_paranoia" to the GRUB_CMDLINE_LINUX_DEFAULT and GRUB_CMDLINE_LINUX variables in /etc/default/grub

          2. Update grub by running sudo update-grub

          3. Reboot

          4. Run apt -f install


          For safety, I reverse this process afterward also. Kernel safety override parameters are not something you want to leave lying around!







          share|improve this answer














          share|improve this answer



          share|improve this answer








          edited Sep 10 '18 at 23:25

























          answered Sep 8 '18 at 10:09









          tudor

          2,46341844




          2,46341844

























              0














              I was able to fix the error by disabling the Compatibility Support Module (CSM) in my UEFI setup. After rebooting, the package update for 'grub-efi-amd64-signed' went through without issue.






              share|improve this answer


























                0














                I was able to fix the error by disabling the Compatibility Support Module (CSM) in my UEFI setup. After rebooting, the package update for 'grub-efi-amd64-signed' went through without issue.






                share|improve this answer
























                  0












                  0








                  0






                  I was able to fix the error by disabling the Compatibility Support Module (CSM) in my UEFI setup. After rebooting, the package update for 'grub-efi-amd64-signed' went through without issue.






                  share|improve this answer












                  I was able to fix the error by disabling the Compatibility Support Module (CSM) in my UEFI setup. After rebooting, the package update for 'grub-efi-amd64-signed' went through without issue.







                  share|improve this answer












                  share|improve this answer



                  share|improve this answer










                  answered Dec 22 '18 at 1:16









                  user906466

                  1




                  1






























                      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.





                      Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


                      Please pay close attention to the following guidance:


                      • 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%2f1072618%2fcould-not-prepare-boot-variable-no-space-left-on-device-grub-install-error-ef%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