Results 1 to 5 of 5

Thread: update-bootloader failed due to full NVRAM

  1. #1

    Default update-bootloader failed due to full NVRAM

    Recently while doing a regular dup I noticed this error pop up at the end of the upgrade:
    Code:
    Could not prepare Boot variable: No space left on device
    Through various searches I managed to figure out that the issue was caused by lack of space in the NVRAM due to the presence of `dump-*` files in /sys/firmware/efi/efivars. After removing them I was successful in manually running the command again but I don't know how critical those files are. I tried viewing them but I found nothing but gibberish, and there's barely any resources that I could find that say anything about the purpose of NVRAM. Can I get some pointers as to why these `dump`s appeared and how I can prevent this error from happening on future boots?

  2. #2
    Join Date
    Aug 2010
    Location
    Chicago suburbs
    Posts
    16,047
    Blog Entries
    3

    Default Re: update-bootloader failed due to full NVRAM

    I cannot help with the dump files. I'm not sure what those are about.

    However: Use Yast bootloader.

    There should be a box: "Update NVRAM Entry"

    Uncheck that box.

    That way, future updates to bootloader won't attempt to write to NVRAM, and that should avoid the error you saw. They will still update what is stored in your EFI partition.
    openSUSE Leap 15.4; KDE Plasma 5.24.4;
    testing Tumbleweed.

  3. #3
    Join Date
    Sep 2012
    Posts
    8,028

    Default Re: update-bootloader failed due to full NVRAM

    Quote Originally Posted by kiroma View Post
    Can I get some pointers as to why these `dump`s appeared
    These are compressed content of kernel message buffer at the time of kernel crash. They are preserved to facilitate troubleshooting so you can get errors, stack trace etc from the time crash happened.

    Now I was rather surprised that it is enabled by default (it is not in Leap) but so it is. Normally those dumps should be copied to hard disk and deleted from NVRAM on boot, this is done by systemd-pstore.service, but this service is not installed by default (it is part of systemd-experimental package). For this reason I think auto-enabling of EFI pstore backend is not intentional.
    how I can prevent this error from happening on future boots?
    To prevent appearance of dump "files" you need to fix the reason(s) for kernel crash(es) that created them. For this you need to examine those dumps. You can of course "fix" those dumps by either blacklisting efi-pstore module or using pstore_disable=1 parameter for efi_pstore module but that is just shooting the messenger.

  4. #4

    Default Re: update-bootloader failed due to full NVRAM

    So how can I examine those dumps? Should I install the systemd-experimental package?
    From what I can tell these should be related to some deadlocks I've been experiencing periodically with the EXT4 driver, although I'm not quite sure what may be happening there.

  5. #5

    Default Re: update-bootloader failed due to full NVRAM

    So I tried installing the package and starting the service, I got the dumps and now looking through them there seems to be multiple different crash reasons.
    Anyway, thanks a lot for the pointers, I'll start a new thread if I need more help dissecting those dumps.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •