При сборке в контейнерном окружении скрипт /usr/sbin/x11presetdrv вызывает /usr/libexec/X11/drvpre.d/nvidia, который определяет версию ядра через uname(). Это приводит к некорректной работе, так как в изолированном окружении uname() возвращает версию ядра хоста, а не версию ядра, установленного внутри контейнера. Предлагаю добавить входной параметр для явного указания версии ядра, чтобы обойти ограничение uname() в контейнерных сборках.
(Ответ для Дмитрий на комментарий #0) > в изолированном > окружении uname() возвращает версию ядра хоста, а не версию ядра, > установленного внутри контейнера. В этом случае модуль ядра nvidia тоже хостовый, правильно?
(Ответ для Sergey V Turchin на комментарий #1) > (Ответ для Дмитрий на комментарий #0) > > в изолированном > > окружении uname() возвращает версию ядра хоста, а не версию ядра, > > установленного внутри контейнера. > В этом случае модуль ядра nvidia тоже хостовый, правильно? Неа, как один из примеров, мы собираем например на ALS целиком систему: https://altlinux.space/alt-atomic/onyx/actions/runs/631/jobs/1 У "forgejo-runner" который собирает систему может быть любое ядро, оно отличается от того ядра которое включает в себя сам контейнер и которое будет фактически поставлено при установке системы
(Ответ для Дмитрий на комментарий #2) > У "forgejo-runner" который собирает систему может быть любое ядро, оно > отличается от того ядра которое включает в себя сам контейнер и которое > будет фактически поставлено при установке системы А работает там модуль nvidia из какого ядра? Хостового или контейнеровского?
(Ответ для Sergey V Turchin на комментарий #3) > (Ответ для Дмитрий на комментарий #2) > > У "forgejo-runner" который собирает систему может быть любое ядро, оно > > отличается от того ядра которое включает в себя сам контейнер и которое > > будет фактически поставлено при установке системы > А работает там модуль nvidia из какого ядра? Хостового или контейнеровского? Из контейнеровского, ядра у нас лежат тут: /usr/lib/modules/<version>/vmlinuz initramfs тут: /usr/lib/modules/<version>/initramfs.img Например когда если мы вызываем depmod внутри контейнера мы передаём ему версию что бы он его сам искал в /usr/lib/modules/<version>/, не пытаясь определить по uname: depmod -a '6.12.66-6.12-alt1' Справка: depmod -h Usage: depmod -[aA] [options] [forced_version]
Раз от хостового ядра в контейнере ничего нет, значит uname() сообщает не ту версию ядра. Это какой гипервизор?
(Ответ для Sergey V Turchin на комментарий #5) > Раз от хостового ядра в контейнере ничего нет, значит uname() сообщает не ту > версию ядра. > > Это какой гипервизор? Да, итоговый хук "/drvpre.d/nvidia" который настраивает nvidia и делает всякие разные симлинки не отработает потому что не понимает где он собственно запущен, он не ожидает что будет работать в контейнере где ядро хоста не имеет значения. Это не гипервизор, это обычные OCI-контейнеры (podman/docker) которые использует forgejo-runner на altlinux.space. В Linux контейнеры разделяют ядро с хостом — uname() это системный вызов к хостовому ядру, поэтому он всегда возвращает версию ядра хоста, но наш OCI-контейнер уже содержит своё ядро и свои модули и узнать о них с помощью uname() невозможно при сборке образа. Поэтому вариантов кроме как дать возможность указывать параметром ядро вручную я не вижу. Мы сейчас это починили тем что сделали упрощённый аналог всей той бизнес-логики что делает/drvpre.d/nvidia на баш, но этот вариант мне не нравится, я хочу что бы отрабатывало Ваше решение нативно при установке
Подумав ещё, пришёл к выводу что адаптировать x11presetdrv/nvidia для контейнерной сборки не имеет практического смысла. Около 60% логики этого инструмента — определение GPU через PCI-скан и выбор подходящей версии драйвера под конкретное оборудование. При сборке контейнерного образа целевое GPU неизвестно, поэтому вся эта логика неприменима. Для наших целей достаточно упрощённого скрипта на bash, который берёт самый свежий установленный в образ драйвер и создаёт необходимые симлинки. Выбор драйвера под конкретное оборудование уже должно отработать на целевой машине, только вот там запрещено изменение /usr, но это уже другая проблема. Думаю можно закрывать :)
(Ответ для Дмитрий на комментарий #6) > Это не гипервизор, это обычные OCI-контейнеры (podman/docker) В таком случае не вводите в заблуждение. Используется ядро хоста. Синхронизируйте установленные пакеты ядер на хосте и внутри контейнера.
