Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Switch default linux package to the new LTS, 4.19 #52863

Merged
merged 3 commits into from Dec 26, 2018

Conversation

samueldr
Copy link
Member

@samueldr samueldr commented Dec 25, 2018

Version Maintainer Released Projected EOL
4.19 Greg Kroah-Hartman 2018-10-22 Dec, 2020

Motivation for this change

An unwritten rule, but as far as I know, linuxPackages always points to the most recent LTS by the time the next NixOS release is made. Let's do this, especially since 4.20 is now released.

This branch also fixes the two failing modules. As far as building is concerned, nothing is broken currently. As far as testing and using things built with 4.19, I hope that those using _latest and _testing got enough testing done that we won't see any issues for most commonly used packages.

An additional motivation is to ensure sd_image won't hold back the channel when the latest kernel version is released. This ensures that, at least, the kernel won't be downgraded from the sd image. #52886 makes it use the default kernel and adds a new sd_image_new_kernel mirroring the existing iso_minimal_new_kernel. (Here it's not aarch64 at fault, but the fact that there's a moving target into the tested path.)

Things done

  • ✔️ Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
  • Built on platform(s)
    • ✔️ NixOS
    • ⬜ macOS
    • ⬜ other Linux distributions
  • ✔️ Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
  • ⬜ Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
  • ✔️ Tested execution of all binary files (usually in ./result/bin/)
  • ⬜ Determined the impact on package closure size (by running nix path-info -S before and after)
  • ✔️ Assured whether relevant documentation is up to date
  • ✔️ Fits CONTRIBUTING.md.

cc @NeQuissimus our kernel wizard

cc @vcunat who was involved in the last linuxPackages change.

linuxPackages.ena

cc @edolstra, maintainer of it. Looks fine, but it's a major upgrade which I cannot test.

@samueldr
Copy link
Member Author

@GrahamcOfBorg build linuxPackages_4_4.ena linuxPackages_4_4.ndiswrapper linuxPackages_4_9.ena linuxPackages_4_9.ndiswrapper linuxPackages_4_14.ena linuxPackages_4_14.ndiswrapper linuxPackages_4_19.ena linuxPackages_4_19.ndiswrapper linuxPackages_4_20.ena linuxPackages_4_20.ndiswrapper

@dtzWill
Copy link
Member

dtzWill commented Dec 26, 2018

Headers should be bumped too, seems silly to use headers from version older than default kernel used.

@samueldr
Copy link
Member Author

@dtzWill I'm confused, it looks like kernel headers aren't always updated in step; is it something that we need to review so that they're updated with kernel updates? While the default kernel was at 4.14, it got updated, but not for every kernel version in-between.

cc @NeQuissimus

@orivej
Copy link
Contributor

orivej commented Dec 26, 2018

The only downside of headers being older than the kernel is that applications may be configured without support for the latest kernel APIs. Since it takes time for applications to make use of new APIs and this use is made optional to support older kernels the updates to kernel headers are never urgent.

@domenkozar
Copy link
Member

I'd recommend bumping headers in separate PR, but as it has been said, the common denominator is the app that needs the oldest headers.

@domenkozar domenkozar merged commit b861ebb into NixOS:master Dec 26, 2018
@vcunat
Copy link
Member

vcunat commented Dec 26, 2018

TL; DR: I believe the kernel headers should be kept rather fresh, i.e. 4.19 or 4.20 ATM.

IMO reasonable SW does not count on run-time kernel providing all the features that are visible in the headers during build time. (Except for kernel modules, but those surely don't use the common linuxHeaders.) It should still watch for ENOSYS and have fallback code – at least that's how I write C. Otherwise you couldn't use binary packages independently or the kernel you choose.

BTW, I've been using 4.19 for months, but I don't really utilize anything special around the kernel.

@samueldr samueldr deleted the linux/default-new-lts branch December 26, 2018 15:56
@timokau
Copy link
Member

timokau commented Dec 28, 2018

This (b861ebb) broke the nixos.tests.nat.firewall-conntrack test.

@vcunat
Copy link
Member

vcunat commented Dec 28, 2018

Not reproducible for me nor on Hydra. It seemed like timeout due to momentary system overload or something.

@timokau
Copy link
Member

timokau commented Dec 28, 2018

That is weird, I was able to reproduce it with the nixpkgs revision that failed on hydra. I even git-bisected it to this commit. Probably something fixed it since then. Did you try to reproduce it with the revision that failed on hydra?

@samueldr
Copy link
Member Author

samueldr commented Dec 28, 2018

Given that this eval includes the commit you bisected to, this seems weird. (Look at the changes link, first commit listed.)

EDIT:

Hmm, hydra re-writing history is annoying me (if I understand this right).

EDIT2: strike-through the initial sentence, see later comment.

@timokau
Copy link
Member

timokau commented Dec 28, 2018

I can still reproduce the bisection result as follows:

git bisect start cb5bc3 de0de8
git bisect run nix build -f nixos/release.nix tests.nat.firewall-conntrack.x86_64-linux

@samueldr
Copy link
Member Author

Aah, right, this indeed breaks the test, but it breaks all tests.

server# switch_root: can't execute '/nix/store/qy8hmypwnk43i7idrp50qsgjdgm25rgy-nixos-system-server-19.03.git.52cf2dd/init': Operation not permitted

Thus this commit is broken and not failing; no tests will succeed without the patch introduced in #52942.

See also: #48828 (comment)

When on de86af4 the test succeeds here (log).

@timokau
Copy link
Member

timokau commented Dec 28, 2018

Not sure I understand the timeline here -- wasn't #52942 merged before this? And if this wasn't transient, why did the hydra build recover on restart?

Anyway, I can confirm that the test passes on current master.

@samueldr
Copy link
Member Author

Because I overlooked something when I initially said "includes the commit you bisected to". I was looking at another commit which I new should work. I was wrong, it does not include 4.14 -> 4.19 in its changes. only 889ef35, which is the fix.

So, in order,

Bisecting will always fail in the range between those. b861ebb..de86af4

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants