Project

General

Profile

Feature #15339

Consider switching back to Debian sid's aufs-dkms

Added by intrigeri about 1 year ago. Updated 8 months ago.

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

100%

QA Check:
Feature Branch:
Type of work:
Research
Blueprint:
Starter:
Affected tool:

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.


Related issues

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

History

#1 Updated by intrigeri about 1 year ago

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 about 1 year ago

#3 Updated by intrigeri about 1 year ago

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

#4 Updated by intrigeri about 1 year ago

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

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

#5 Updated by intrigeri about 1 year ago

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

#6 Updated by intrigeri about 1 year ago

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

#7 Updated by intrigeri about 1 year ago

  • 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 about 1 year ago

  • Type of work changed from Code to Research

#9 Updated by intrigeri about 1 year ago

#10 Updated by intrigeri about 1 year ago

#11 Updated by intrigeri 12 months ago

  • 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 12 months ago

  • 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 10 months ago

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

#14 Updated by intrigeri 8 months ago

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

#15 Updated by intrigeri 8 months ago

  • 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 #8415 soon.

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

#16 Updated by intrigeri 8 months ago

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

Also available in: Atom PDF