Подменян пакет ядра в репозитории Fedora

Может лучше им на багтрекер сразу писать?

Прошли уже сутки, репозиторий не обновился, разработчики что не видят, что в репозитории один ключевой пакет подменян другим?

Обратитесь в службу поддержки Red Hat или просто переустановите ваш линукс.

Я не очень силён в английском, но как смог написал https://bugzilla.redhat.com/show_bug.cgi?id=1812703

Прошли уже сутки, репозиторий не обновился, разработчики что не видят, что в репозитории один ключевой пакет подменян другим?

Невозможно увидеть то, чего нет: ты исходишь из неверной посылки, что если rpm -qf /некий/файл возвращает имя_пакета, то имя_пакета.rpm обязательно содержит этот /некий/файл. Это далеко не всегда так. В частности, /некий/файл может создаваться скриптами во время установки пакета, как это и происходит [1] c /boot/vmlinuz-5.5.8-100.fc30.x86_64:

└► dnf -d 0 download --releasever 30 --urls kernel-core-5.5.8 | wget -i- -O- -q | rpm -qp --scripts -
postinstall scriptlet (using /bin/sh):

if [ `uname -i` == "x86_64" -o `uname -i` == "i386" ] &&
   [ -f /etc/sysconfig/kernel ]; then
  /bin/sed -r -i -e 's/^DEFAULTKERNEL=kernel-smp$/DEFAULTKERNEL=kernel/' /etc/sysconfig/kernel || exit $?
fi
preuninstall scriptlet (using /bin/sh):
/bin/kernel-install remove 5.5.8-100.fc30.x86_64 /lib/modules/5.5.8-100.fc30.x86_64/vmlinuz || exit $?
posttrans scriptlet (using /bin/sh):
/bin/kernel-install add 5.5.8-100.fc30.x86_64 /lib/modules/5.5.8-100.fc30.x86_64/vmlinuz || exit $?

Чтобы такие файлы удалялись при удалении пакета, их упоминают в секции %files соответствующего spec-файла с ключевым словом %ghost:

└► dnf -d 0 download --releasever 30 --source --urls kernel-5.5.8 | wget -i- -O- -q | rpm2cpio | cpio --extract --to-stdout kernel.spec | rpmspec -D 'dist .fc30' -P /dev/stdin| perl -anE '$flag++ if /^%files/; print if $flag && $F[1] =~ /vmlinuz/'
223204 blocks
%ghost /boot/vmlinuz-5.5.8-100.fc30.x86_64
%ghost /boot/.vmlinuz-5.5.8-100.fc30.x86_64.hmac
%ghost /boot/vmlinuz-5.5.8-100.fc30.x86_64+debug
%ghost /boot/.vmlinuz-5.5.8-100.fc30.x86_64+debug.hmac

[1] В норме должно происходить. У тебя точно не происходит? Как проверяешь?

Подменян

Учи русский. https://где-ударение.рф/%D0%B2-%D1%81%D0%BB%D0%BE%D0%B2%D0%B5-%D0%BF%D0%BE%D0%B4%D0%BC%D0%B5%D0%BD%D1%91%D0%BD/

То есть я зря на Red Hat бочку катил? Я конечно же в курсе, что файлы могут не только содержаться в архиве, но и создаваться инсталяционными сценариями, но я не думал, что подобный огород реализован в пакетах ядра (в других дистрибутивах такого кажется нет).
Получается, что команда kernel-install из инсталяционного сценария у меня не отрабатывает. Как такое могло произойти? Я сейчас попробовал вручную вызвать:

kernel-install add 5.5.8-100.fc30.x86_64 /lib/modules/5.5.8-100.fc30.x86_64/vmlinuz

В какую сторону думать? Что у меня сломалось и как чинить?

В какую сторону думать? Что у меня сломалось и как чинить?

Сука! Разобрался. В Fedora 30 мейнтейнеры прибили граб гвоздями к ядру. Это надо же было до такого додуматься. Короче, бинарный файл ядра лежит не в каталоге /boot пакета, как это сделано в других дистрибутивах и как было в предыдущих версиях федоры, а в /lib/modules/<версия>, откуда копируется инсталяционным скриптом в момент вызова команды kernel-install, kernel-install вызывает скрипты из каталога /usr/lib/kernel, из которых важным является скрипт 95-kernel-hooks.install, который собственно и осуществляет копирование. Данный скрипт входит в состав пакета grubby, который зависит от grub2.

Стройная и логичная система. Вообще, Поттеру давно уже пора новый kerneld написать, но что-то он ленится.

Коммент особенно приколен с учётом того, что реально стройный и логичный загрузчик он уже выкатил.

Я что-то не вижу здесь прибитости граба к ядру. Ты ведь понимаешь, да, что ты можешь написать любой свой хук для любого своего загрузчика и положить его в /usr/lib/kernel?

Напротив, класть ядра в /boot (и вызывать граб из пакетного менеджера) — это прибивание гвоздями ядер к традиционным загрузчикам. А ведь это далеко не всегда нужно или вообще имеет смысл. Например, если ты грузишься без загрузчика через EFISTUB, то ядро надо класть в /boot/efi и дополнительно прописывать образ efibootmgr’ом. Поэтому устанавливать ядро в /usr/lib/modules (где всё равно лежит vmlinux) и потом оттуда копировать его хуками куда надо — это более гибкий и объективно более правильный сетап.

Ну ты же панимаишь? Да? Всё для людей, чтобы было всё ясно и понятно.

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

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

Мне вообще казалось

Такая же фигня.

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

Внезапно!

Мне вообще казалось

Перекрестить — это, говорят, помогает.

администратор настраивает загрузчик вручную

Все, что можно автоматизировать, следует автоматизировать — основы системного администрирования.

А мне понравилось, как в Fedora это сделано. Точнее даже не просто понравилось, а объяснило как можно красиво сделать и в других дистрибутивах по аналогии с Fedora.

Fedora единственная, кто сама поняла что у меня ESP монтирован не в /boot и не в /boot/efi, что у меня вообще нет grub (/efi и gummiboot), и что рядом с ней на ESP лежит еще кучка ядер других дистрибутивов и надо как-то лечь рядышком.

Наверняка я бы сам не догадался так аккуратно разложить ядра. Все остальные установленные дистрибутивы вручную учил складывать себя как Fedora (в /efi/$machine_id/$kernel_version).