1. 14 May, 2020 1 commit
  2. 23 Dec, 2019 1 commit
  3. 18 Dec, 2019 1 commit
  4. 27 Nov, 2019 1 commit
  5. 11 Jul, 2019 2 commits
  6. 05 Jan, 2019 1 commit
  7. 27 Feb, 2018 5 commits
  8. 16 Mar, 2017 1 commit
  9. 11 Feb, 2016 3 commits
  10. 03 Jan, 2016 1 commit
  11. 22 Nov, 2015 1 commit
  12. 12 Nov, 2015 2 commits
    • intrigeri's avatar
      Upgrader wrapper: make the check for free memory smarter. · b8a97e4f
      intrigeri authored
      Quoting anonym (#8263#note-1):
      In our Live system context, where a lot of stuff is in tmpfs:es, looking
      at the values of free or /proc/meminfo alone isn't accurate for
      determining how much memory "really" is free, since the tmpfs usage is
      included in the buffers. Hence, MemFree is the lower (and safe) bound of
      how much "really" free memory we have, and MemFree + Buffers + Cache is
      the upper (and unsafe) bound. The true value should be (at least closer
      to) MemFree + Buffers + Cache - (sum of usage by tmpfs:es). We should
      check once against that value instead.
      The 300 MB magic number (minimum "real memory" available) was found
      after bisecting with an ISO built from current feature/jessie:
       * with 278000 kB of "real memory" available, Tails Upgrader could
         successfully tell me that no upgrade was available (which is indeed
         the case), or that I should manually upgrade (after tweaking
         /etc/os-release; because I started from DVD);
       * with 255000 kB of "real memory" available, the check for upgrades
         failed and the desktop session froze;
      => so 300x1024 kB should give us a small safety margin.
      For the record, a VM with 1GB of RAM allocated (891 MB visible due to
      the QXL video adapter stealing some) on current feature/jessie has
      336MB (137MB free + 39MB buffers + 212MB cache - 52MB tmpfs) of "real
      memory" available once Tor is ready and Tor Browser is started, so in
      practice any system that's beefy enough to use Tails 2.0 can check
      for upgrades.
      Closes: #10540, #8263
    • 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.
  13. 29 Mar, 2015 1 commit
  14. 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.
  15. 12 Aug, 2014 1 commit
  16. 22 Jul, 2014 1 commit
  17. 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.
  18. 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.
  19. 23 Mar, 2014 2 commits
  20. 18 Feb, 2014 2 commits
  21. 07 Jan, 2014 1 commit
  22. 26 Dec, 2013 1 commit
  23. 28 Nov, 2013 1 commit
  24. 26 Nov, 2013 1 commit
  25. 20 Nov, 2013 1 commit
  26. 14 Nov, 2013 3 commits
  27. 24 Jul, 2012 1 commit
  28. 20 Jan, 2012 1 commit