Feature #15339

Consider switching back to Debian sid's aufs-dkms

Added by intrigeri 2018-02-21 16:04:33 . Updated 2018-10-01 13:29:40 .

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Target version:
Tails_3.9.1
Start date:
2018-02-21
Due date:
% Done:

100%

Feature Branch:
Type of work:
Research
Blueprint:

Starter:
Affected tool:
Deliverable for:

Description

It now supports Linux 4.15. I think this time I want to keep the upstream submodule + the code that builds it and introduce a config variable that toggles it on/off so we can always prepare a branch with a new kernel without waiting for aufs-dkms in Debian to catch up.

Subtasks

Related issues

Blocked by Tails - Bug #15320: Have the aufs regression since Linux 4.14 fixed upstream Resolved 2018-02-17
Blocks Tails - Feature #15334: Core work 2018Q3: Foundations Team Resolved 2018-02-20

History

#1 Updated by intrigeri 2018-02-21 16:05:01

Not a blocker for 3.6 IMO: we have something that works fine. We’ll see if I find time to do this before the freeze.

#2 Updated by intrigeri 2018-02-22 09:26:33

#3 Updated by intrigeri 2018-02-22 13:11:24

  • related to Bug #15320: Have the aufs regression since Linux 4.14 fixed upstream added

#4 Updated by intrigeri 2018-02-22 13:12:04

  • Target version changed from Tails_3.6 to Tails_3.7

Actually, if we did that we would reintroduce the aufs bug: Bug #15320#note-4.

#5 Updated by intrigeri 2018-02-22 13:12:22

  • related to deleted (Bug #15320: Have the aufs regression since Linux 4.14 fixed upstream)

#6 Updated by intrigeri 2018-02-22 13:12:34

  • blocked by Bug #15320: Have the aufs regression since Linux 4.14 fixed upstream added

#7 Updated by intrigeri 2018-03-06 15:05:08

  • Subject changed from Switch back to Debian sid's aufs-dkms to Consider switching back to Debian sid's aufs-dkms
  • Target version changed from Tails_3.7 to Tails_3.9

I’m not convinced we should go back to using aufs-dkms: too often it’s updated too late for our needs. So let’s stick to tracking the upstream Git via a submodule for now and we’ll see how it fares.

#8 Updated by intrigeri 2018-03-06 15:05:19

  • Type of work changed from Code to Research

#9 Updated by intrigeri 2018-03-27 09:16:03

  • blocked by deleted (Feature #13245: Core work 2018Q1: Foundations Team)

#10 Updated by intrigeri 2018-03-27 09:16:08

#11 Updated by intrigeri 2018-06-05 11:16:38

  • Status changed from Confirmed to In Progress
  • % Done changed from 0 to 20
  • Linux 4.13 entered sid on 2017-10-02 and the corresponding aufs-dkms on 2017-10-06: 4 days
  • Linux 4.14 entered sid on 2017-12-01 and the corresponding aufs-dkms on 2017-12-26: 25 days
  • Linux 4.15 entered sid on 2018-02-18 and the corresponding aufs-dkms on 2018-02-21: 3 days
  • Linux 4.16 entered sid on 2018-05-02 and the corresponding aufs-dkms on 2018-05-13: 11 days

Let’s see how it goes for 4.17 but for now, my hunch is that the time it takes for aufs to be upgraded in sid after a new kernel was uploaded is too unpredictable so we cannot rely upon it: in general it’s not a problem but it has happened, and will happen again, that we need to upgrade to a new kernel for security reasons and aufs is not ready in Debian by the time we build our release. So if we switched back to Debian’s aufs-dkms, we would have to switch back’n’forth between that one and the upstream submodule from time to time. One option to make this sustainable is to have our code support both with a single config switch somewhere that allows us to easily pick the one compilation way we want without creating a messy pile of revert-of-revert commits.

#12 Updated by intrigeri 2018-06-05 11:17:31

  • Target version changed from Tails_3.9 to Tails_3.10.1

(We’re in no hurry to make a decision as our current implementation works fine => I’ll come back to this in September.)

#13 Updated by intrigeri 2018-08-04 00:57:40

  • Linux 4.17 entered sid on 2018-07-03 and the corresponding aufs-dkms on 2018-07-16: 13 days

#14 Updated by intrigeri 2018-09-12 05:44:43

  • Linux 4.18 entered sid on 2018-09-06 and the corresponding aufs-dkms on 2018-09-07: 1 day

#15 Updated by intrigeri 2018-09-12 05:47:26

  • Status changed from In Progress to Resolved
  • Assignee deleted (intrigeri)
  • % Done changed from 20 to 100

intrigeri wrote:
> Let’s see how it goes for 4.17 but for now, my hunch is that the time it takes for aufs to be upgraded in sid after a new kernel was uploaded is too unpredictable so we cannot rely upon it: in general it’s not a problem but it has happened, and will happen again, that we need to upgrade to a new kernel for security reasons and aufs is not ready in Debian by the time we build our release. So if we switched back to Debian’s aufs-dkms, we would have to switch back’n’forth between that one and the upstream submodule from time to time.

This is still my general feeling.

> One option to make this sustainable is to have our code support both with a single config switch somewhere that allows us to easily pick the one compilation way we want without creating a messy pile of revert-of-revert commits.

That’s not worth the effort IMO since segfault and I plan to work on Feature #8415 soon.

=> let’s stick to tracking upstream Git with a submodule.

#16 Updated by intrigeri 2018-10-01 13:29:40

  • Target version changed from Tails_3.10.1 to Tails_3.9.1