1. 25 Jun, 2019 4 commits
  2. 14 Jun, 2019 3 commits
  3. 10 Jun, 2019 5 commits
  4. 14 May, 2019 1 commit
  5. 04 May, 2019 3 commits
  6. 03 May, 2019 4 commits
  7. 02 May, 2019 1 commit
    • Colin Watson's avatar
      Remove stale .gitignore file · a1499f89
      Colin Watson authored
      This isn't in upstream tarballs, so doesn't tend to get kept up to date,
      and indeed it was slightly out of date; it also causes dgit to want to
      commit an extra patch with its contents.  Remove it instead.
      a1499f89
  8. 15 Apr, 2019 1 commit
  9. 01 Apr, 2019 1 commit
  10. 23 Mar, 2019 11 commits
    • Colin Watson's avatar
      b35a02ab
    • Colin Watson's avatar
      Fix -Wcast-align diagnostics on ARM · 34d6b424
      Colin Watson authored
      34d6b424
    • Colin Watson's avatar
      Minimise writes to EFI variable storage · 3ddfe605
      Colin Watson authored
      Some UEFI firmware is easily provoked into running out of space in its
      variable storage.  This is usually due to certain kernel drivers (e.g.
      pstore), but regardless of the cause it can cause grub-install to fail
      because it currently asks efibootmgr to delete and re-add entries, and
      the deletion often doesn't result in an immediate garbage collection.
      Writing variables frequently also increases wear on the NVRAM which may
      have limited write cycles.  For these reasons, it's desirable to find a
      way to minimise writes while still allowing grub-install to ensure that
      a suitable boot entry exists.
      
      Unfortunately, efibootmgr doesn't offer an interface that would let
      grub-install do this.  It doesn't in general make very much effort to
      minimise writes; it doesn't allow modifying an existing Boot* variable
      entry, except in certain limited ways; and current versions don't have a
      way to export the expected variable data so that grub-install can
      compare it to the current data.  While it would be possible (and perhaps
      desirable?) to add at least some of this to efibootmgr, that would still
      leave the problem that there isn't a good upstreamable way for
      grub-install to guarantee that it has a new enough version of
      efibootmgr.  In any case, it's cumbersome and slow for grub-install to
      have to fork efibootmgr to get things done.
      
      Fortunately, a few years ago Peter Jones helpfully factored out a
      substantial part of efibootmgr to the efivar and efiboot libraries, and
      so it's now possible to have grub-install use those directly.  We still
      have to use some code from efibootmgr, but much less than would
      previously have been necessary.
      
      grub-install now reuses existing boot entries where possible, and avoids
      writing to variables when the new contents are the same as the old
      contents.  In the common upgrade case where nothing needs to change, it
      no longer writes to NVRAM at all.  It's also now slightly faster, since
      using libefivar is faster than forking efibootmgr.
      
      Fixes Debian bug #891434.
      Signed-off-by: 's avatarColin Watson <cjwatson@ubuntu.com>
      
      Bug-Debian: https://bugs.debian.org/891434
      Forwarded: https://lists.gnu.org/archive/html/grub-devel/2019-03/msg00119.html
      Last-Update: 2019-03-23
      
      Patch-Name: efi-variable-storage-minimise-writes.patch
      3ddfe605
    • Colin Watson's avatar
      ff70a6f1
    • Colin Watson's avatar
      7006c0a8
    • Colin Watson's avatar
      b146664d
    • Colin Watson's avatar
      Build-depend on libefiboot-dev and libefivar-dev · c44559cb
      Colin Watson authored
      Needed for EFI variable storage changes.
      c44559cb
    • Colin Watson's avatar
      b25203e5
    • Colin Watson's avatar
      Minimise writes to EFI variable storage · c3ab38fc
      Colin Watson authored
      Closes: #891434
      c3ab38fc
    • Colin Watson's avatar
      Minimise writes to EFI variable storage · 649e5a39
      Colin Watson authored
      Some UEFI firmware is easily provoked into running out of space in its
      variable storage.  This is usually due to certain kernel drivers (e.g.
      pstore), but regardless of the cause it can cause grub-install to fail
      because it currently asks efibootmgr to delete and re-add entries, and
      the deletion often doesn't result in an immediate garbage collection.
      Writing variables frequently also increases wear on the NVRAM which may
      have limited write cycles.  For these reasons, it's desirable to find a
      way to minimise writes while still allowing grub-install to ensure that
      a suitable boot entry exists.
      
      Unfortunately, efibootmgr doesn't offer an interface that would let
      grub-install do this.  It doesn't in general make very much effort to
      minimise writes; it doesn't allow modifying an existing Boot* variable
      entry, except in certain limited ways; and current versions don't have a
      way to export the expected variable data so that grub-install can
      compare it to the current data.  While it would be possible (and perhaps
      desirable?) to add at least some of this to efibootmgr, that would still
      leave the problem that there isn't a good upstreamable way for
      grub-install to guarantee that it has a new enough version of
      efibootmgr.  In any case, it's cumbersome and slow for grub-install to
      have to fork efibootmgr to get things done.
      
      Fortunately, a few years ago Peter Jones helpfully factored out a
      substantial part of efibootmgr to the efivar and efiboot libraries, and
      so it's now possible to have grub-install use those directly.  We still
      have to use some code from efibootmgr, but much less than would
      previously have been necessary.
      
      grub-install now reuses existing boot entries where possible, and avoids
      writing to variables when the new contents are the same as the old
      contents.  In the common upgrade case where nothing needs to change, it
      no longer writes to NVRAM at all.  It's also now slightly faster, since
      using libefivar is faster than forking efibootmgr.
      
      Fixes Debian bug #891434.
      Signed-off-by: 's avatarColin Watson <cjwatson@ubuntu.com>
      
      Bug-Debian: https://bugs.debian.org/891434
      Forwarded: https://lists.gnu.org/archive/html/grub-devel/2019-03/msg00119.html
      Last-Update: 2019-03-23
      
      Patch-Name: efi-variable-storage-minimise-writes.patch
      649e5a39
    • Colin Watson's avatar
      Add %X to grub_vsnprintf_real and friends · 27f1a9c4
      Colin Watson authored
      This is needed for UEFI Boot* variables, which the standard says are
      named using upper-case hexadecimal.
      Signed-off-by: 's avatarColin Watson <cjwatson@ubuntu.com>
      
      Bug-Debian: https://bugs.debian.org/891434
      Forwarded: https://lists.gnu.org/archive/html/grub-devel/2019-03/msg00121.html
      Last-Update: 2019-03-23
      
      Patch-Name: vsnprintf-upper-case-hex.patch
      27f1a9c4
  11. 20 Mar, 2019 3 commits
  12. 14 Mar, 2019 2 commits
  13. 12 Mar, 2019 1 commit