1. 12 Nov, 2015 1 commit
    • intrigeri's avatar
      Revert "Lower required free (non-buffer/cache) memory for Tails Upgrader." · 220c9ce7
      intrigeri authored
      This reverts commit 01c88c1b.
      Refs: #8263
      Since then, we've bumped the memory requirements (both in our
      documentation and on the test suite's "hardware") to 2 GB, so the
      original reason for this change has gone away => let's go back to
      a value that was tested and confirmed to work (as in: allow upgrading
      a running Tails) on Wheezy, instead of a value that was tested on
      Jessie, but only for checking for available upgrades.
      The follow-ups will be:
       * the cool ideas posted on
         https://labs.riseup.net/code/issues/8263#note-1 will become a new,
         dedicated ticket (that has no reason to block the Tails 2.0 release);
       * #8083 and #7986 will tell us if the value this commit reverts to
         is OK.
  2. 29 Mar, 2015 1 commit
  3. 13 Nov, 2014 1 commit
    • Tails developers's avatar
      Lower required free (non-buffer/cache) memory for Tails Upgrader. · 01c88c1b
      Tails developers authored
      At least in Jessie, this value is generally around 75 MiB in the
      automated test suite, preventing the upgrade check from
      happening. It's been lowered to an arbitrarily chosen 32 MiB, but I
      wonder if we can remove that check completely. After all, the
      available memory + buffers + cache should be what actually matters.
  4. 12 Aug, 2014 1 commit
  5. 22 Jul, 2014 1 commit
  6. 20 Jun, 2014 1 commit
    • Tails developers's avatar
      Don't allow the desktop user to pass arguments to tails-upgrade-frontend (Closes: #7410) · df1f92f0
      Tails developers authored
      ... and accordingly update the design document and manual test suite steps.
      The tails-upgrade-frontend program is run as the tails-upgrade-frontend user,
      that is basically equivalent to root. Some of the available
      tails-upgrade-frontend options might be dangerous. I've looked at it quickly and
      didn't find anything scary, but still, it's simply not worth taking the risk of
      privilege escalation, persistent root kit implementation, and so on.
      Strictly speaking, this change does not really belong to
      bugfix/7345-upgrade-from-iso-from-1.0-to-1.1, and could have been implemented
      separately. However, this branch introduces running as root a syslinux binary
      taken from the installed IUK, so it raised the flag that made me want to lock
      this down a bit more.
  7. 13 May, 2014 1 commit
    • Tails developers's avatar
      Require a bit less free memory before checking for upgrades. · 60ee6e88
      Tails developers authored
      The general goal is to avoid displaying "Not enough memory available to check
      for upgrades" too often due to over-cautious memory requirements checked in
      the wrapper.
      The specific goal is to avoid having to bump the hardware requirements for
      Tails 1.1 (Wheezy) to >> 1 GiB of RAM, as this would 1. not be very nice for
      users of oldish hardware; and 2. force us to implement #5502 ("Notify user if
      hardware requirements are not met") in time for the 1.1 freeze.
      My experiments, documented on #5390, indicate that even lower limits would
      probably work. Let's not be too adventurous to start with, though: my plan is to
      lower the limit to something that is low enough for the wrapper to dare running
      the check for upgrades, but still quite cautious.
      Later on, we could try lowering the limits even more, or even drop it entirely:
      this would require a mechanism to detect when the check for upgrades fails due
      to memory exhaustion, which don't have yet.
      Note that, if an automatic upgrade is available, Tails Upgrader checks memory
      again, to ensure there's enough free memory to apply the upgrade. This commit
      assumes that Tails Upgrader's own check is cautious enough, and that we were not
      implicitly relying on the check done earlier, in the wrapper, to ensure upgrade
      safety. This assumption might be wrong. My plan is to use the incremental
      upgrade to 1.1~rc1 as a test bench to verify this, as I have no time to fully
      test this fully right now (still, I successfully applied a small — 50 MiB —
      IUK on top of a current build from this very branch, with 126 MiB of free
      memory, and 700 MiB total free memory).
      The symptom of a failed upgrade due to lack of memory (and then, of a too low
      $mem_factor value in Frontend.pm) would be to see the upgrader that simply die
      in the middle of the download, or (worse) in the middle of the upgrade. In the
      worst case, the resulting (partially upgraded) system may not boot anymore, but
      no user data will be affected, and the user can still fix their stick by doing
      a full upgrade.
  8. 23 Mar, 2014 2 commits
  9. 18 Feb, 2014 2 commits
  10. 07 Jan, 2014 1 commit
  11. 26 Dec, 2013 1 commit
  12. 28 Nov, 2013 1 commit
  13. 26 Nov, 2013 1 commit
  14. 20 Nov, 2013 1 commit
  15. 14 Nov, 2013 3 commits
  16. 24 Jul, 2012 1 commit
  17. 20 Jan, 2012 1 commit
  18. 10 Jan, 2012 1 commit
  19. 02 Oct, 2011 3 commits
  20. 25 Sep, 2010 1 commit
  21. 23 Sep, 2010 1 commit
  22. 04 Feb, 2010 1 commit