Зафиксировать версию ядра в NixOS

Как в вики предлагают не работает?

В wiki вот что:

Pinning a kernel version

boot.kernelPackages = pkgs.linuxPackagesFor (pkgs.linux_4_19.override {
    argsOverride = rec {
      src = pkgs.fetchurl {
            url = "mirror://kernel/linux/kernel/v4.x/linux-${version}.tar.xz";
            sha256 = "0ibayrvrnw2lw7si78vdqnr20mm1d3z0g6a0ykndvgn5vdax5x9a";
      };
      version = "4.19.60";
      modDirVersion = "4.19.60";
      };
  });

Это не то, тут просто подсовывается фиксированная версия ядра. А я хочу ставить ядро из nixpkgs, но зафиксировать версию nixpkgs, только для ядра, не для всего остального.

Также, есть вот такое

https://nixos.wiki/wiki/FAQ/Pinning_Nixpkgs

Допустим оно мне и надо, но непонятно совершенно куда вот этот код пихать

import (builtins.fetchTarball {
  # Descriptive name to make the store path easier to identify
  name = "nixos-unstable-2018-09-12";
  # Commit hash for nixos-unstable as of 2018-09-12
  url = "https://github.com/nixos/nixpkgs/archive/ca2ba44cab47767c8127d1c8633e2b581644eb8f.tar.gz";
  # Hash obtained using `nix-prefetch-url --unpack <url>`
  sha256 = "1jg7g6cfpw8qvma0y19kwyp549k1qyf11a5sg6hvn6awvmkny47v";
}) {}

Ты не используешь flakes, так?

Тогда берешь это, называешь для простоты pkgs-pinned при помощи конструкции let-in. Теперь у тебя есть pkgs, который движется вперед с обновлениями каналов, и есть pkgs-pinned, который не движется. Соответственно, boot.kernelPackages = pinned-pkgs.и погнали.

Я накладываю на ядро патч

Так, на всякий случай: а одним модулем никак не обойтись, надо прям все патчить?

Ты не используешь flakes, так?

Нет. Пусть я наверное пойму сначала как без этого.

Тогда берешь это

Вот это?

import (builtins.fetchTarball {

и т. д.?

А можно полный пример, а то такое ощущение что полных примеров острый дефицит, а без них с нуля не понятно до конца. Я например не могу до конца вкурить что в let писать а что в in.

Так, на всякий случай: а одним модулем никак не обойтись, надо прям все патчить?

А можно выборочно модули? Конечно это лучше, я думал нельзя.

Хотя в данном случае наверное отдельный модуль нельзя, я накладываю le9 патч.

Но это частный случай, могут вполне быть такие где модуль надо.

Как-то так, не проверял:

let pinned-pkgs = import (builtins.fetchTarball {
  # Descriptive name to make the store path easier to identify
  name = "nixos-unstable-2018-09-12";
  # Commit hash for nixos-unstable as of 2018-09-12
  url = "https://github.com/nixos/nixpkgs/archive/ca2ba44cab47767c8127d1c8633e2b581644eb8f.tar.gz";
  # Hash obtained using `nix-prefetch-url --unpack <url>`
  sha256 = "1jg7g6cfpw8qvma0y19kwyp549k1qyf11a5sg6hvn6awvmkny47v";
}) {};
in {
  # твой остальной конфиг
  boot.kernelPackages = pinned-pkgs;
}

Сам импорт для красоты можно в отдельный файл вынести.

Но во флейках оно конечно проще делается.

А можно выборочно модули? Конечно это лучше, я думал нельзя.

“Nix moet, alles kan".

На это у меня есть пример, на твой случай, к сожалению, нет, но вон там комментом выше вроде в нужную сторону пример, только вроде бы boot.kernelPackages = pinned-pkgs.конкретное_ядро;.

Это создать закреплённый пакет.

theNamelessOne

Почему-то получаю ошибку unexpected let.

Глобальный вопрос - куда эту конструкцию пихать? В configuration.nix у меня вообще конструкции let - in не работают.

Вот из руководства по языку вставляю

let
  a = abort "will never happen";
  b = "hello";
  c = "world";
in b + c

получаю ошибку:

error: attempt to call something which is not a function but a string

А к чему тогда этот пример…

куда эту конструкцию пихать?

не можем мы тебе ответить на этот вопрос, потому что технически правильным ответом будет «куда угодно» =(

https://github.com/tazjin/nix-1p читал?

Ну наверно тогда ни туда копипастишь. Ну вот пример с типичным configuration.nix:

{ config, pkgs, ... }:

let
  pinned-nixpkgs = {
    # Descriptive name to make the store path easier to identify
    name = "nixos-unstable-2018-09-12";
    # Commit hash for nixos-unstable as of 2018-09-12
    url = "https://github.com/nixos/nixpkgs/archive/ca2ba44cab47767c8127d1c8633e2b581644eb8f.tar.gz";
    # Hash obtained using `nix-prefetch-url --unpack <url>`
    sha256 = "1jg7g6cfpw8qvma0y19kwyp549k1qyf11a5sg6hvn6awvmkny47v";
  }) {};
in rec {
  # вот он, твой конфиг
  imports =
    [
      /etc/nixos/hardware-configuration.nix
    ];
  boot.loader.systemd-boot.enable = true;
  boot.loader.efi.canTouchEfiVariables = true;
  boot.cleanTmpDir = true;
  boot.kernelPackages = pinned-pkgs.linux_69_420; # наверно так

  # ...остальной конфиг
  # ...
}

Что конкретно у тебя не получается?

Вот это, с определенными исправлениями, вроде прошло. И все сразу понятно стало, в чем была моя ошибка. Вот что полный пример животворящий делает! С документацией конечно беда… столько лет а полных примеров нет. Ничерта же не понятно. Я ж вам блина не хаскелист…

Но теперь я понял.

Собственно вот Зафиксировать версию ядра в NixOS (комментарий) ответ как сделать именно то что я хотел.

Там опечатка только.

В пояснение к «куда угодно»: если сработало так, то должно сработать и, например, так:

{ config, pkgs, ... }:

{
  # вот он, твой конфиг
  boot.kernelPackages =
    let
      pinned-nixpkgs = {
        name = "nixos-unstable-2018-09-12";
        url = "https://github.com/nixos/nixpkgs/archive/ca2ba44cab47767c8127d1c8633e2b581644eb8f.tar.gz";
        sha256 = "1jg7g6cfpw8qvma0y19kwyp549k1qyf11a5sg6hvn6awvmkny47v";
      }) {};
    in pinned-pkgs.linux_69_420;
  # ...
}

Вот так работает

boot.kernelPackages = 
    let
      pinned-nixpkgs = import (builtins.fetchTarball {
        name = "nixos-unstable-2021-11-28";
        url = "https://github.com/nixos/nixpkgs/archive/73369f8d0864854d1acfa7f1e6217f7d6b6e3fa1.tar.gz";
        sha256 = "11z477rs1s2lhpw9h45npby86nqs7rqhi45ikh742ssxfwla52j1";
      }) {};
    in pinned-nixpkgs.linuxPackages_latest;

Я понял принцип.

я накладываю le9 патч.

Взять уже готовое и собранное zen или xanmod с этим патчем не?

boot.kernelPackages = pkgs.linuxPackages_lqx;
boot.kernelPackages = pkgs.linuxPackages_zen;
boot.kernelPackages = pkgs.linuxPackages_xanmod;

Выбирай любое.

Я хочу обычное ядро только с этим патчем. Все остальное в обычном меня полностью устраивает. Важнее даже не это, а то что я должен уметь наложить патч.

А как же познание дао формулирования своих запросов Nixу?

Вот именно, о чем и речь.

6 часов на сборку ядра? У тебя проц троттлит?

Core 2 duo, 2007-2008 года, знаешь такой проц? Он работает медленнее чем современный троттлит.

На ноуте с i3 четыре часа с копейками где-то.

pinned-nixpkgs.linuxPackages_latest

pinned latest

Я понял принцип.

И не поспоришь

Да, именно так нужно. Когда я теперь захочу обновить ядро, я просто уберу pinned- и поставится последнее на тот момент ядро. Само, без выяснения и прописывания версии руками.

Неужели это слишком сложно понять для анонимуса.

Такой не юзал, но года 3 назад проапрейдился с q6600. Да даже во время 300х селеронов ядро не собиралось несколько часов. Оно правда поменьше было

Не просто поменьше, а очень поменьше. Когда я лет 10 назад на генте сидел, у меня на одноядернике собиралось ядро за час, если не быстрее.

Что мешает закомментировать, если очень надо оставить на память уже написанное, и написать нормально? Что мешает узнать чему соответствует linuxPackages_latest в запиненом - linuxPackages_14, linuxPackages_15, и написать вместо latest конкретную версию? А вдруг эта версия (чуть с другой патч-версией - третьей компонентой версии) есть в текущем channel?

Поясни пожалуйста, я вот nixos не щупал. Но ты пишешь, что тебе нужно зафиксировать пакет с ядром потому как ты на него накладываешь патч, т.е. на исходники ядра и оно у тебя собирается 6 часов.

Тогда получается пакет с ядром в nixos ставит исходники ядра, из которых ты потом собираешь ядро с наложением патча.

Тогда мне не понятно зачем фиксировать пакет, который ставит исходники ядра? У тебя в системе есть скомпилированное ядро и модули для него, ну и пусть у тебя ставятся пакеты с новыми исходными кодами ядра, ты всегда можешь загрузиться с собранного тобой ядра.

В чём необходимость блокировать обновление пакета с исходными кодами ядра?

Если я неправильно понял, то поясни пожалуйста.

Что мешает закомментировать, если очень надо оставить на память уже написанное, и написать нормально?

Я уже написал нормально.

Что мешает узнать чему соответствует linuxPackages_latest в запиненом - linuxPackages_14, linuxPackages_15, и написать вместо latest конкретную версию?

То, что мне это знать не нужно. Меня не интересует версия. Надо чтобы автоматически ставилась последняя версия когда я «расфиксирую». Я сделал ровно это. Что-то запоминать, узнавать, прописывать мне теперь не нужно.

А вдруг эта версия (чуть с другой патч-версией - третьей компонентой версии) есть в текущем channel?

Мне до звезды что там есть. Должна автоматически ставиться последняя на данный момент версия. Если я захочу вручную рулить версиями я просто загружусь в свою LFS сборку. NixOS для этого мне не потребуется.

Тогда получается пакет с ядром в nixos ставит исходники ядра, из которых ты потом собираешь ядро с наложением патча.

Нет, не так. Не я собираю, а Nix. Это же source-based дистрибутив. Отсюда и проблема. Каждый раз когда в репах ядро обновится - оно автоматически пересобираться будет, что мне не нужно.

В отличие от генты, в NixOS кешируются результаты сборки пакета, и бинарный кеш пакетов доступен не только локально, но и на сервере. Поэтому даже создается впечатление, что все ставится из бинарных пакетов, как в бинарном дистрибутиве. Но на самом деле это source-based дистрибутив, и если модифицировать пакет, например добавить патч, как я делаю, то этот пакет уже будет собираться на моей машине при обновлении, автоматически.

из которых ты потом собираешь ядро с наложением патча

Вот что очень важно - не я руками накладываю патч. Это делает тоже Nix. Я просто указал ему - накладывать вот этот патч на последнее ядро из репов. Дальше все делается атоматически.

Таких возможностей в других дистрибутивах вообще нет, поэтому со стороны выглядит немного непривычно.

Понятно, а разве нельзя как в Gentoo отключить сборку ядра, а ставить только исходные кода?

Можно наверное, но зачем мне ставить исходные коды если я не буду их собирать? И зачем мне вручную что-то собирать и патчить если у меня NixOS и все делается автоматически?

Кроме того, не надо так узко рассматривать данную тему. Дело же не в том как ставить ядро. Я могу эту частную, незначительную проблему еще несколькими способами решить.

Вопрос шире - как зафиксировать версию пакета, когда это понадобится. Любого. Тут мне объяснили как это сделать для чего угодно, не только для ядра.

а как у вас там вообще ядро настраивают, в классическом дистрибутиве make menuconfig, а тут как это все выглядит?

Спасибо за ответ.

в классическом дистрибутиве make menuconfig

Смотря как на это посмотреть в классическом дистрибутиве. Бинарный пакет из репозитория ставится как есть и его нельзя модифицировать, или выполнить make menuconfig при установке пакета.

В бинарном дистрибутиве придется пересоздавать пакет, подсовывая ему свой .config. (или ставить в обход пакетной системы)

В генте проблема решается тем, что вместо пакета с ядром есть пакет с исходниками ядра. Хоть гента и source-based, но и в ней установка пакета должна заканчиваться установкой собранных бинарников, а не просто исходников. То есть это такой LFS или слако-подход с make; make install. По факту ядро ставится в обход пакетной системы.

В Nix как лучше сделать я пока не разобрался, но вижу что например при создании пакета с новой версией ядра скачивают исходники, запускают в них make menuconfig и дальше в таком виде засовывают в пакет.

То есть вариант тот же, как и в остальных дистрибутивах - создать пакет с нужным конфигом ядра. Плюс можно в configuration.nix прописать нужные параметры ядра относительно стандартной конфигурации из репов. Плюс можно сделать и добавить патч, который заменяет файл конфига ядра в пакете из репов.

Я с этим не заморачиваюсь и собираю ядро с конфигом из репов либо с дефолтным конфигом, на всех дистрибутивах, включая самосбор. Не считаю особо полезным его вручную подгонять.

спасибо за ответ. так и думал, по старинке, то есть если я свое ядро поддерживаю, на этапе компиляции нового ядра он будет собирать с make oldconfig и покажет новые опции которые я захочу добавить? или просто соберет со старым конфигом, и тут мне придется подсововать новый?

Я с этим не заморачиваюсь и собираю ядро с конфигом из репов либо с дефолтным конфигом

а дефолтный это который с make defconfig? и почему бы разок не заморочиться?) а то 6 часов собирать ядро это ни в какие ворота, там же всю херню в модули компилят, бууээ, можно сделать скелет конфига и пользоваться всю жизнь, если время есть конечно)

мой конфиг собирается за 10 минут на i5 3320M, а уж ежели взять от какой ни буди слаки, или упаси *** дебиана, тут и двух часов не хватит наверное.

или просто соберет со старым конфигом, и тут мне придется подсововать новый?

Скорее вот так.

а дефолтный это который с make defconfig?

Не совсем я правильно выразился. С defconfig скорее всего работать не будет. Я для самосборной системы копирую с арча конфиг и не меняю. На арче соответственно его конфиг и использовал.

и почему бы разок не заморочиться?)

Если бы разок, нет гарантий что не придется при любом обновлении на новую версию туда опять лезть. А так по дефолту само собирает и все.

Плюс еще такой момент - я хочу иметь максимально переносимую между разными машинами систему, и максимально готовую ко всему. У меня же не только Core 2 Duo ))) Просто он не основной у меня и я на нем пробую NixOS поэтому.

Я уже наелся еще 10 лет назад ситуаций когда гента была тонко заточена а потом у меня срывалась работа под хохот виндузятников, когда какой-то фигни раз в год нужной в системе не оказывалось.

После этого я за легковесность не борюсь. Я не утверждаю что затачивать не надо и надо genkernel на генте ставить. Но под мою работу мне лично удобнее не затачивать системы.

а то 6 часов собирать ядро это ни в какие ворота

Ну и пусть, оно же само собирается. Можно вообще на ночь ставить. Конечно каждый день это делать я не буду, поэтому и зафиксировал версию. Раз в месяц или несколько месяцев, скажем, можно.

я хочу иметь максимально переносимую между разными машинами систему, и максимально готовую ко всему

срывалась работа под хохот виндузятников

тут все понятно, для работы дефолт, лтс) да и гента на работе как-то не смотрится)

нет гарантий что не придется при любом обновлении на новую версию туда опять лезть

а чего в него лезть то, при обновлении? если у тебя настроено то что нужно, оно при конфигурации само спросит какие новые опции включить, это конечно учитывая если ты сам собираешь, а не в условный PKGBUILD(хотя я не в курсе как там в арче) конфиг подсовываешь.

вообще я согласен, ядро слишком сложное, не стоит туда немытыми рученками лазить, а то можно опарафиниться.

успехов в труде!

успехов в труде!

Спасибо!

то этот пакет уже будет собираться на моей машине при обновлении, автоматически

https://nixos.wiki/wiki/Distributed_build

В конфигурации слабый ноут + сервер — надо, несомненно, настроить сборку на сервере. И в случае с Nix оно работает «из коробки», что невероятно удобно.

И на сервере необязательно ставить NixOS, достаточно сам Nix с работающим nix-daemon. Ставится на любой дистр.

Нет. Пусть я наверное пойму сначала как без этого.

Лучше сразу flakes осваивай, с ними всё становится сильно проще и удобнее.

Я себе сделал билдсервер, загодя собирающий мои конфигурации с опережением, очень удобно.