Bug #13480
The Vagrant VM has too little memory for disk builds
100%
Description
As discovered on Bug #12741:
- url : https://gitlab.com/arnaud-preevio/tails.git
- branch: arnaud/bump-vm-memory
Subtasks
Related issues
Blocks Tails - |
Resolved | 2017-06-19 |
History
#1 Updated by intrigeri 2017-07-17 15:18:36
- blocks
Bug #12741: /lib/modules/*/modules.* not reproducible in some environments added
#2 Updated by bertagaz 2017-07-28 11:57:04
- % Done changed from 50 to 60
- Feature Branch set to bugfix/13480-bump-build-VM-memory
Pushed to the new related branch in tails.git to see if it means we have to bump the lizard isobuilders memory.
#3 Updated by bertagaz 2017-07-28 19:51:44
- Status changed from In Progress to Fix committed
- Assignee deleted (
bertagaz) - % Done changed from 60 to 100
- QA Check changed from Ready for QA to Pass
bertagaz wrote:
> Pushed to the new related branch in tails.git to see if it means we have to bump the lizard isobuilders memory.
Indeed had to bump isobuilders ram with 256M. Works fine now, so merged into stable and devel.
#4 Updated by intrigeri 2017-07-28 20:34:38
- Status changed from Fix committed to In Progress
- Assignee set to bertagaz
- QA Check changed from Pass to Info Needed
> bertagaz wrote:
>> Pushed to the new related branch in tails.git to see if it means we have to bump the lizard isobuilders memory.
> Indeed had to bump isobuilders ram with 256M. Works fine now, so merged into stable and devel.
Wait, why would isobuilders need more RAM due to an increase of the memory for disk builds? Don’t they build in RAM?
We do VM_MEMORY_FOR_RAM_BUILDS = VM_MEMORY_FOR_DISK_BUILDS + BUILD_SPACE_REQUIREMENT
, and the previous values worked fine, which means that we can decrease BUILD_SPACE_REQUIREMENT
so that VM_MEMORY_FOR_RAM_BUILDS
remains the same as it was, no?
#5 Updated by bertagaz 2017-07-28 21:16:44
- Status changed from In Progress to Fix committed
Applied in changeset commit:de14ab1cfb10f3fcf4de92bd0621d4f8c1f40b9f.
#6 Updated by intrigeri 2017-07-29 06:48:45
- Status changed from Fix committed to In Progress
- % Done changed from 100 to 80
(As said above I think the fix is wrong, in the sense it has problematic side-effects that don’t make sense to me.)
#7 Updated by bertagaz 2017-07-31 10:28:14
- Assignee changed from bertagaz to intrigeri
intrigeri wrote:
> > bertagaz wrote:
> >> Pushed to the new related branch in tails.git to see if it means we have to bump the lizard isobuilders memory.
>
> > Indeed had to bump isobuilders ram with 256M. Works fine now, so merged into stable and devel.
>
> Wait, why would isobuilders need more RAM due to an increase of the memory for disk builds? Don’t they build in RAM?
>
> We do VM_MEMORY_FOR_RAM_BUILDS = VM_MEMORY_FOR_DISK_BUILDS + BUILD_SPACE_REQUIREMENT
, and the previous values worked fine, which means that we can decrease BUILD_SPACE_REQUIREMENT
so that VM_MEMORY_FOR_RAM_BUILDS
remains the same as it was, no?
True, I did not think to lower BUILD_SPACE_REQUIREMENT
. I’ve pushed a commit doing that on top of the branch, does it looks good to you? If so, I’ll set back the memory of our isobuilders to where it was.
#8 Updated by intrigeri 2017-08-01 15:33:22
- Assignee changed from intrigeri to bertagaz
- QA Check changed from Info Needed to Dev Needed
> I’ve pushed a commit doing that on top of the branch, does it looks good to you?
I think you got the maths wrong: (12.5 - 12.3) * 1024 = 204.8 != 256.
I think you instead want (12.5 - 12.25) * 1024 = 256.
With this fixed + the commit message clarified (“from 256M” is wrong, I think you rather mean something like “by 256M”) i.e. rewriting history, feel free to merge directly into stable and devel :)
#9 Updated by bertagaz 2017-08-02 10:26:38
- Status changed from In Progress to Fix committed
- % Done changed from 80 to 100
Applied in changeset commit:0e25fbf8b97d779d7feb7c5ff13617f82780cb85.
#10 Updated by bertagaz 2017-08-02 13:28:45
- Assignee deleted (
bertagaz) - QA Check changed from Dev Needed to Pass
Also lowered the memory of our isobuilders to their initial amount before this branch, and the builds in Jenkins still work, so case closed I guess.
#11 Updated by bertagaz 2017-08-09 12:38:27
- Status changed from Fix committed to Resolved