Feature #12065

Increase loop.max_loop

Added by intrigeri 2016-12-23 08:23:17 . Updated 2017-01-24 20:42:57 .

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Target version:
Tails 2.10
Start date:
2016-12-23
Due date:
% Done:

100%

Feature Branch:
feature/12065-increase-max-loops
Type of work:
Code
Blueprint:

Starter:
Affected tool:
Deliverable for:

Description

I’m running an experiment with an arbitrarily large system partition on a (virtual) Tails USB stick. It has all incremental upgrates applied on top of a Tails 2.0 installation. The goal is to identify shortcomings that come with applying many incremental upgrades. It doesn’t boot anymore unless I set loop.max_loop=N, with N large enough, on the kernel command-line. It would be nice if this worked out of the box.

Subtasks

History

#1 Updated by intrigeri 2016-12-27 09:50:46

  • Status changed from Confirmed to In Progress
  • % Done changed from 0 to 10
  • Feature Branch set to feature/12065-increase-max-loops

#2 Updated by intrigeri 2016-12-29 13:41:46

  • Assignee changed from intrigeri to anonym
  • % Done changed from 10 to 50
  • QA Check set to Ready for QA

I’ve verified that the parameter is applied on startup, but didn’t test if it’s done early enough to be taken into account at live-boot time. But since the loop module has to be loaded at live-boot time anyway, I don’t see how the value of the max_loop parameter can change later. Test suite passes on Jenkins.

#3 Updated by anonym 2017-01-10 14:05:38

  • Status changed from In Progress to Fix committed
  • Assignee deleted (anonym)
  • % Done changed from 50 to 100
  • QA Check changed from Ready for QA to Pass

Looks good.

(For the record, once Tails has booted I have no issue setting up a seemingly arbitrary number of loop devices, e.g.

for i in $(seq 1 1000); do
  losetup /dev/loop${i} /dev/sr0
done


works just fine.)

#4 Updated by anonym 2017-01-24 20:42:57

  • Status changed from Fix committed to Resolved