Bug #17124
Install Linux 5.3 from sid
100%
Description
We install it from experimental for 4.0~rc1, but we shouldn’t ship a kernel from experimental in 4.0.
The relevant commit is 031cf21cc898693476bad209db4815805c05aded.
Subtasks
Related issues
|
Related to Tails - |
Resolved | ||
|
Related to Tails - |
Resolved | ||
| Related to Tails - Bug #17154: Improve entropy gathering | Confirmed | ||
|
Related to Tails - |
Resolved | ||
| Blocks Tails - Feature #16209: Core work: Foundations Team | Confirmed | ||
|
Blocks Tails - |
Resolved |
History
#1 Updated by segfault 2019-10-05 19:50:24
- blocks Feature #16209: Core work: Foundations Team added
#2 Updated by segfault 2019-10-05 19:50:41
- related to
Bug #17117: Upgrade to Linux 5.3 added
#3 Updated by segfault 2019-10-05 19:51:45
- Description updated
#4 Updated by intrigeri 2019-10-18 07:30:09
I’ve just asked carnil about their planned timing wrt. uploading 5.3 to sid (or a newer 5.3.x to experimental).
#5 Updated by intrigeri 2019-10-20 07:06:58
- Assignee set to intrigeri
https://salsa.debian.org/kernel-team/linux/tree/sid has 5.3.7-1 but it was not uploaded yet. I’ll keep an eye on it today but the chances we can upgrade the kernel in 4.0 final start to look pretty slim.
#6 Updated by intrigeri 2019-10-20 14:49:00
- Assignee deleted (
intrigeri) - Priority changed from Normal to Elevated
- Target version changed from Tails_4.0 to Tails_4.1
- Type of work changed from Code to Wait
OK, even if a newer Linux landed in sid right now, factoring in the time it takes to update our APT snapshots, it’s too late to give it sufficient QA ⇒ postponing. But we should really do this for 4.1 so bumping priority a bit.
#7 Updated by intrigeri 2019-10-31 09:20:12
- related to
Feature #17202: Upgrade to Buster 10.2 added
#8 Updated by intrigeri 2019-11-09 13:32:00
- related to
Bug #17161: devel branch FTBFS since virtualbox 6.0.14-dfsg-1 was uploaded to sid and linux-image-5.3.0-trunk-amd64 is not in experimental anymore added
#9 Updated by intrigeri 2019-11-09 13:36:41
- Assignee set to intrigeri
- Type of work changed from Wait to Code
#10 Updated by intrigeri 2019-11-09 13:39:42
- Feature Branch set to bugfix/17124-17161-linux-5.3-from-sid+force-all-tests
#11 Updated by intrigeri 2019-11-09 14:07:35
- Status changed from Confirmed to In Progress
Applied in changeset commit:tails|306fc1ff047412a0ec2ebdca033f491f0b8a5b05.
#12 Updated by intrigeri 2019-11-10 07:52:34
Full test suite passed on my local Jenkins with 5.3.7-1. Next steps:
bump ’debian’ APT snapshot again to get 5.3.9-1 (uploaded yesterday; fixes sound output on a variety of hardware)donebump expiration date of said snapshot- -go through https://tails.boum.org/contribute/Linux_kernel/-
#13 Updated by intrigeri 2019-11-11 07:07:20
The first full test suite run on lizard with 5.3.9-1 has only one failure, which is a known test suite bug (Bug #17102).
The only failure on my local Jenkins (some VeraCrypt scenario) looks like a Dogtail / test suite bug: the screenshot shows the expected successful outcome.
#14 Updated by intrigeri 2019-11-11 07:18:12
- related to Bug #17154: Improve entropy gathering added
#15 Updated by intrigeri 2019-11-11 07:31:42
Changes:
- Tons of bugfixes. I bet the hardware support ones, especially GPU-related, will be welcome. This kernel update fixes sound support on lots of machines.
- One jitter entropy commit was backported. That’s related to Bug #17154. As far as this kernel update is concerned, I think that’s fine: as long as we ship haveged, we already have essentially the same mechanism in place, so so even if we have doubts about the quality of the generated entropy, that change should not be a regression. I’d love @segfault to confirm though. I see no way to disable this without compiling our own kernel, which I’d rather avoid.
Security:
- Included security fixes potentially relevant to Tails since 5.3.2-1~exp1 (shipped in Tails 4.0) are mostly in the Wi-Fi stack: CVE-2019-17133, CVE-2019-16746, CVE-2019-17075, CVE-2019-15098.
- https://security-tracker.debian.org/tracker/source-package/linux shows a bunch of issues that are not fixed in this new version yet. Chances are that we’ll have to upgrade again before our 4.1 release, but IMO this should not block this first iteration, especially since it’ll fix
Bug #17161.
I see no severe regression reported so far to the Debian BTS.
The diff between the .packages files (stable vs. this branch) looks entirely sane. Apart of the kernel upgrade, only changes are:
- amd64-microcode 3.20181128.1 → 3.20191021.1
- firmware-zd1211 1:1.5-6 → 1:1.5-7
https://outflux.net/blog/ has no “security things in Linux v5.3” article yet. https://kernelnewbies.org/LinuxChanges#Linux_5.3.Security has nothing new, that would need enabling.
#16 Updated by intrigeri 2019-11-11 08:00:14
- Status changed from In Progress to Needs Validation
- Assignee deleted (
intrigeri)
Bare metal (ThinkPad X1 Carbon 6th, ThinkPad X200, HP EliteBook 840G1) tests are successful: boots from USB; Wi-Fi, sound, and HTML5 video in Tor Browser all work; unplugging the USB stick triggers emergency shutdown.
So I’m done with the checklist and I think we’re now good to go!
#17 Updated by intrigeri 2019-11-11 08:00:22
- related to deleted (
Bug #17161: devel branch FTBFS since virtualbox 6.0.14-dfsg-1 was uploaded to sid and linux-image-5.3.0-trunk-amd64 is not in experimental anymore
#18 Updated by intrigeri 2019-11-11 08:00:31
- blocks
Bug #17161: devel branch FTBFS since virtualbox 6.0.14-dfsg-1 was uploaded to sid and linux-image-5.3.0-trunk-amd64 is not in experimental anymore added
#19 Updated by intrigeri 2019-11-13 09:52:25
Note that 5.3.9-2 was uploaded to sid since, and this branch does not pick it up due to older APT snapshots. We’ll get this upgrade via Feature #17202 so I’d rather not block on this and instead get this merged (e.g. because it fixes the almost-1-month-old devel branch FTBFS).
#20 Updated by segfault 2019-11-13 18:32:38
intrigeri wrote:
> * One jitter entropy commit was backported. That’s related to Bug #17154. As far as this kernel update is concerned, I think that’s fine: as long as we ship haveged, we already have essentially the same mechanism in place, so so even if we have doubts about the quality of the generated entropy, that change should not be a regression. I’d love @segfault to confirm though. I see no way to disable this without compiling our own kernel, which I’d rather avoid.
Yes, haveged also uses jitter entropy, and the entropy from the kernel is hopefully not worse, and potentially better than the one from haveged. I don’t think we should try to disable the it.
#21 Updated by segfault 2019-11-13 18:55:00
- Status changed from Needs Validation to Resolved
- % Done changed from 0 to 100
Applied in changeset commit:tails|6a00e904aff33405b603edaadb68f46dbc163df7.
#22 Updated by intrigeri 2019-11-15 09:26:38
- related to
Bug #17236: Enable the init_on_alloc=1 and init_on_free=1 Linux options added