Project

General

Profile

Bug #8263

Deal with memory requirements check in tails-upgrade-frontend-wrapper vs Jessie

Added by anonym about 5 years ago. Updated about 4 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
-
Target version:
Start date:
11/14/2014
Due date:
% Done:

100%

Feature Branch:
Type of work:
Code
Blueprint:
Starter:
Affected tool:
Upgrader

Description

In 01c88c1 it was lowered since (at least on the automated test suite's "hardware") Jessie doesn't leave enough free non-buffer/cache memory for tails-upgrade-frontend-wrapper to do the actual upgrade check.

We probably want to do something smarter, or verify that this new number is safe.


Related issues

Related to Tails - Feature #10540: Smarter check for free memory in the Upgrader's wrapper Resolved 11/12/2015
Related to Tails - Feature #8083: Fix automatic upgrades on Jessie Resolved 10/12/2014
Related to Tails - Feature #7986: Re-evaluate hardware requirements on Jessie Resolved 10/02/2014

Associated revisions

Revision 220c9ce7 (diff)
Added by intrigeri about 4 years ago

Revert "Lower required free (non-buffer/cache) memory for Tails Upgrader."

This reverts commit 01c88c1b5f13ea02437c2f547fad0dd61946abdc.

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:

  • #8083 and #7986 will tell us if the value this commit reverts to
    is OK.

Revision b8a97e4f (diff)
Added by intrigeri about 4 years ago

Upgrader wrapper: make the check for free memory smarter.

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

History

#1 Updated by anonym about 5 years ago

  • Assignee set to intrigeri

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.

#2 Updated by intrigeri about 5 years ago

  • Blocks Feature #7986: Re-evaluate hardware requirements on Jessie added

#3 Updated by intrigeri about 4 years ago

  • Description updated (diff)

#4 Updated by intrigeri about 4 years ago

I agree with anonym's reasoning above.

Note that I think the explanation in the message for 01c88c1 is bogus (MIN_MEMFREE is the safe bound and matters, while MIN_TOTAL_MEMFREE is the unsafe bound that doesn't matter much).

#5 Updated by intrigeri about 4 years ago

  • Related to Feature #10540: Smarter check for free memory in the Upgrader's wrapper added

#6 Updated by intrigeri about 4 years ago

  • Related to Feature #8083: Fix automatic upgrades on Jessie added

#7 Updated by intrigeri about 4 years ago

  • Blocks deleted (Feature #7986: Re-evaluate hardware requirements on Jessie)

#8 Updated by intrigeri about 4 years ago

  • Related to Feature #7986: Re-evaluate hardware requirements on Jessie added

#9 Updated by intrigeri about 4 years ago

  • Status changed from Confirmed to Resolved
  • % Done changed from 0 to 100

#10 Updated by intrigeri about 4 years ago

  • Assignee deleted (intrigeri)

Also available in: Atom PDF