Fedora 25 (обновления ядра из стороннего репозитория)

что бы ядро из copr.fedorainfracloud.org всегда было в приоритете?

cost

    integer

    The relative cost of accessing this repository, defaulting to 1000. This value is compared when the priorities of two repositories are the same. The repository with the lowest cost is picked. It is useful to make the library prefer on-disk repositories to remote ones.

Нет под рукой Федоры чтобы посмотреть куда именно записывается, но это из man dnf.conf. Посмотри в /etc/dnf/dnf.conf и рядом файл настройки своего репозитория.

Добавь теги [fedora] и [dnf] — это вопрос про них, а не про ядра — тег [kernel] не релевантен тут совсем, вопрос про приоритет репозиториев в конкретном дистрибутиве.

Добавь

exclude=kernel*

Подробнее ищется запросом yum exclude package from repo

А вот тут https://bugzilla.redhat.com/show_bug.cgi?id=1402652 (самое последнее сообщение) советуют в /etc/yum.repos.d/fedora-updates.repo добавить exclude=kernel* perf python-perf в конец каждого из трёх разделов обоих файлов. Это я так понимаю, в конце каждого абзаца, в двух файлах со словом updates и без него? Но зачем perf python-perf?

Кажется сам разобрался, вот тут https://copr-be.cloud.fedoraproject.org/results/gronki/kernel-dell/fedora-25-... видно какие пакеты в репозитории...

exclude=kernel* perf python-perf действительно работает, но если запросить проверку обновлений через Gnome Software, то он найдёт в основном репозитории «запрещённые» пакеты, и предложит их установить(обновить). Как с этим быть? Как найти управу на Gnome-Software?

https://hostingkartinok.com/show-image.php?id=59348529c4431820cea2df863b9386d5]

https://hostingkartinok.com/show-image.php?id=59348529c4431820cea2df863b9386d5

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

У меня в man написано чуть иначе.

The priority value of this repository, default is 99. If there is more than one candidate package for a particular operation, the one from a repo with the lowest priority value is picked, possibly despite being less convenient otherwise (e.g. by being a lower version). То есть по умолчанию 99 а не 1000. Меньше цифра, выше приоритет. Я попробовал этот вариант. параметры прописывается как то так

priority=50 в файле репозитория, а файлы репозитория расположены в /etc/yum.repos.d

И это тоже работает, так же как и exclude. Однако, все эти параметры полностью игнорирует Gnome Software. Похоже, что Gnome Software придумали просто для красоты... :)

Ты exclude в /etc/yum.repos.d/блабла прописал? Раньше, действительно, там поломано все было, то софтварь всегда все обновить, то вообще зависал на поиске, но потом исправили. Странно что не работает.

ЕМНИП, то что после exclude идет - должно быть «separated by comma», то есть запятой и (вроде) без пробела, может поэтому софтварь не видит. Не помню уже где смотрел, попробуй поискать «packagekit exclude repo».

Пошел сегодня на багзиллу, в поисках объяснений, почему PackageKit и Gnome Software (в закрытом состоянии) отжирают порядка 200мб оперативки, может течет где. Нашел репорт по твоей теме:

https://bugzilla.redhat.com/show_bug.cgi?id=1440967

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

https://bugzilla.redhat.com/show_bug.cgi?id=1306992 https://bugzilla.redhat.com/show_bug.cgi?id=1354074

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

exclude=kernel*, perf, python-perf

Сразу не стал отписываться, так как ждал удобного момента протестировать это ещё не сколько раз. Дело в том, что буквально через несколько часов или минут, после того, того как я поставил запятые, пришло обновление с copr репозитория, с новым ядром. А по скольку по цифрам оно выглядит новей чем в базовом репозитории, то соответственно имеет больший приоритет по умолчанию. Я то вроде проверил, что запятые действительно решают проблему, но так как я этим долго занимался, я опасался, что возможно я воспринимаю желаемое за действительное, и хотел дождаться когда в основном репозитории ядро будет по цифрам такое же как в copr или новей.

И кстати гугление «packagekit exclude repo» мне особо тоже ничего не дало, кроме чувства безнадёжности, так как багов оформленных на эту тему очень много.

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

В основном репозитории Fedora, обновилось ядро, и оно снова совпадает с версией в Copr. Как только я заметил, что ядро обновилось, а я это отслеживал через установленную в виртуальную машину Fedora. Я проверил обновления через Gnome Software на основной машине, и снова ни каких проблем всё хорошо, обновления не требуются. Я потом проверил ещё раз. Обновления Gnome Software всё так же не находил. Но через сутки, после этого, Gnome Software предложил мне обновить ядро до версии из основного репозитория. Как это объяснить с логической точки зрения, я не знаю. версия ядра всё та же, только к обновлению дополнительно были предложены пакеты kexec-tools и kexec-tools-anaconda-addon. Однако dnf считает, что ни каких обновления для машины не требуются.

Итак, gnome-software игнорирует знак *. Для того, что бы gnome-software, понимал какие пакеты я исключаю, мне пришлось указать полный список пакетов, а точней, я прописал следующее:

exclude=kernel, kernel-core, kernel-cross-headers, kernel-debug, kernel-debug-core, kernel-debug-debuginfo, kernel-debug-devel, kernel-debug-modules, kernel-debug-modules-extra, kernel-debuginfo, kernel-debuginfo-common, kernel-devel, kernel-headers, kernel-modules, kernel-modules-extra, kernel-tools, kernel-tools-debuginfo, kernel-tools-libs, kernel-tools-libs-devel, perf, perf-debuginfo, python-perf, python-perf-debuginfo, kexec-tools, kexec-tools-anaconda-addon

Я просто перечислил через запятую все пакеты который есть в copr, указан имена пакетов до номера версии. Но в copr отсутсвуют пакеты kexec-tools, kexec-tools-anaconda-addon, и раньше похоже их не было в основной репозитори fedora, и dnf не предлагал мне их установить, когда у меня в исключениях было прописано вот так: exclude=kernel*, perf, python-perf

На всякий случай, я решил добавить и эти пакеты в exclude, но я не уверен, что я поступаю правильно, может быть их надо обновить/установить? Да и потом, это не дело, каждый раз при обновлении выяснять, что не плохо бы ещё что нибудь дописать в include...

Кстати, перечисляя пакеты через запятую в include, в конце самый последний пакет, должен заканчиваться, или запятой, или без какого либо знака препинания. Поставите точку, gnome-software не будет исключать последний пакет из списка.

В общем в конце или ничего, или запятая.

Нашёл описание kexec-tools, возможно стоит рискнуть и попробовать позволить установить эти пакеты... http://www.opennet.ru/tips/info/2237.shtml

В include удалил из списка последние два пакета, а именно kexec-tools, kexec-tools-anaconda-addon Однако dnf всё равно не предлагает мне обновить/установить эти пакеты. А вот gnome-software предлагает их установить/обновить, через систему обновлений. Почему так происходит?

сделай перед dnf update:

dnf clean all

Вообще бред какой-то получается. Можешь попробовать написать в багзиллу Fedora по поводу игнорирования * и этого странного поведения.

Но, честно говоря, разработчикам Fedora класть на этот packagekit, что видно по игнорируемым репортам, видимо они этим самым gnome software не пользуются. Например эпичный баг, когда обновления через gnome software ломали всю структуру зависимостей чинили несколько релизов.

По поводу этих kexec - с твоей же ссылки «возможность быстрой перезагрузки через обновление ядра в памяти» - как я понимаю, это штука для обновления ядра без перезагрузки. Но gnome software всегда обновляется с перезагрузкой, т.е. надобность этого пакета под сомнением. С другой стороны, не представляю чем его наличие может помешать, я бы на твоем месте не вписывал его в exclude, мало ли, когда-нибудь запилят для gnome-software возможность установки обновлений без перезагрузки.

kexec-tools-anaconda-addon - вот этого я немного не понимаю, анаконда - это установщик fedora, зачем он сам себя устанавливает в систему, для меня загадка. dnf remove anaconda предложил мне удалить в числе прочих зависимостей drpm, что несколько озадачило, но в итоге, даже с его удалением, dnf update нормально работает с deltarpm и никаких других проблем не замечено.

kexec-tools - это всё таки не обновление ядра без перезагрузки, подобного рода фичи по умолчанию в дистрибутивы не включаются, предоставляются отдельно и как правило за деньги, например у canonical. Это скорей более быстрая перезагрузка без участия BIOS для повторой инициализации оборудования, во всяком случае я это именно так понял, более подробно обсуждение в комментариях к статье, а статья обратите внимание 2009 года. Ещё до твоего ответа пакеты kexec-tools, kexec-tools-anaconda-addon я не только исключил из include, но даже позволил gnome-software их обновить, да да именно обновить, эти пакеты и так в системе у меня установлены были, но более старых версий, то есть это обновление было. А что касается dnf clean all, спасибо за информацию, но так как я уже эти пакеты установил через gnome-software, то я решил проверить ситуацию на виртуалке.

На виртуалке уже стояло последнее ядро от основного репозитория федоры, такой же версии как и в copr, но обновления kexec-tools ещё не были установлены, видимо эти пакеты совсем недавно обновились.

Я добавил copr репозиторий с ядром, установил соответствующий include, и дал sudo dnf update. И вот система мне предложила Установка: kernel-core x86_64 4.10.12-200.dell.fc25 gronki-kernel-dell 20 M kernel-modules x86_64 4.10.12-200.dell.fc25 gronki-kernel-dell 23 M kernel-modules-extra x86_64 4.10.12-200.dell.fc25 gronki-kernel-dell 2.2 M Обновление: kexec-tools x86_64 2.0.13-7.fc25.3 updates 429 k kexec-tools-anaconda-addon x86_64 2.0.13-7.fc25.3 updates 91 k Удаление: kernel x86_64 4.8.6-300.fc25 @anaconda 0 kernel-core x86_64 4.8.6-300.fc25 @anaconda 52 M kernel-modules x86_64 4.8.6-300.fc25 @anaconda 22 M kernel-modules-extra x86_64 4.8.6-300.fc25 @anaconda 2.0 M

Результат операции ================================================================================ Установка 3 Пакеты Обновление 2 Пакеты Удаление 4 Пакеты

Объем загрузки: 46 M Продолжить? [д/Н]:

работает и славно)) насчет kexec понял. насчет dnf clean all это не я писал, вроде более правильный вариант будет dnf --refresh upgrade, он не все тогда перегружать будет.

Ха, если бы оно работало. А вот не работает. Всё что я говорил выше, можно выкинуть на помойку.

Пришло новое обновление ядра с репозитория gronki. Центр приложений мне показывает обновления, а dnf НЕТ! То есть теперь Центр приложений правильно показывает ситуацию (смотря что считать правильным конечно) а dnf напротив пудрит мне мозги. Моё состояние уже становится эмоциальным. Я скоро начну называть нехорошими словами людей, связанным с разработкой Fedora, пакетным менеджером dnf и rpm!

DNF работает в целом нормально, он ставит обновления, но теперь вообще игнорирует обновления ядра... получается с любого источника...

Я вообще ничего не могу понять, в виртуальной машине, всё нормально. Почему на хосте проблемы...

команда dnf clean all прочистила мозги dnf. И вроде заработало. Я склоняюсь к тому, что нельзя использовать то gnome-software то dnf, надо выбрать что то одно, и желательно, что бы это был dnf. Иначе если использовать разные пакетные менеджеры, у одного из них рано или поздно начнёт сносить башню.

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

весело живем))

команда dnf clean all прочистила мозги dnf. И вроде заработало.

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

Я склоняюсь к тому, что нельзя использовать то gnome-software то dnf, надо выбрать что то одно, и желательно, что бы это был dnf. Иначе если использовать разные пакетные менеджеры, у одного из них рано или поздно начнёт сносить башню.

Как раз сейчас все более-менее. Пакеты ставлю dnf'ом, обновляюсь через software, проблем не возникает. Правда, никаких тонких настроек репозиториев в данный момент не использую. Год назад, как уже писал, все было намного хуже - тогда вообще нельзя было обновляться gnome-software, а при каких-то exclude в repo-файлах он впадал в ступор.

А какая модель ноутбука? И что конкретно не поддерживается? Сам просто обзавелся DELL'ом, собираюсь F25 накатывать.

После запуска ОС, по умолчанию будут следующие проблемы 1. Отсутствует информация об аккумуляторе. То есть не определяется аккомулятор, но он определиться в системе, если подключить его к сети электропитания или отключить от сети. 2. Не работает (железная) клавиша включения/выключения беспроводных интерфейсов. Кстати, в этом случае на неё можно назначить любое другое действие. 3. Не работает Wi-Fi, то есть он по умолчанию установлен в режим самолёта, и нет возможности из него выйти.

Все эти проблемы не являются проблемами дистрибутива, с такими проблемами столкнёшься при использовании любого современного линукс дистрибутива, но в Fedora решение скажем так не из лёгких.

Для решения первых двух проблем достаточно прописан в параметры загрузки ядра acpi_osi=Linux. Проблема именно в Fedora связана с тем, что ядро собрано без поддержки данного параметра, так что добавляй его или не добавляй это ничего не изменит, надо пересобирать ядро с этим параметром. Что касается третьего пункта, то достаточно создать текстовой файл с любыми именем, в нём написать blacklist dell-rbtn и положить этот файл в /etc/modprobe.d/

В моём случае модель ноутбука DELL inspiron 7537, но я думаю, подобные проблемы буду и у других моделей DELL.

В конечно итоге все проблемы, включая самые мелкие решаются указанными выше действиями. И в целом я доволен дистрибутивом Fedora 25, во всяком случае, пока доволен...

Проверил вчера на своем DELL Latitude 5480, загрузившись с livecd F25. Все норм. Аккумулятор определяется, правда, время показывает меньше, чем в W10. Клавиши отрабатывают, wifi-сети видны. Даже в контекстном меню есть пункт «Launch using Dedicated Graphics Card», который корректно отрабатывает.

Проверил вчера на своем DELL Latitude 5480, загрузившись с livecd F25. Все норм.

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

Даже в контекстном меню есть пункт «Launch using Dedicated Graphics Card», который корректно отрабатывает.

Ничего удивительного. Fedora по умолчанию поддерживает optimus, заявляют даже, что дискретка автоматически может включаться при необходимости, но как именно работает автоматика мне не известно, так как в любом случае это поддержка осуществляется только с использованием свободных драйверов, а со свободными драйверами толку от оптимуса наверное не много. При использовании пропретарных драйверов тебе придётся использовать bumblebee. Ты ведь не ставил проприетарные драйверы на nvidia?

Но тем не менее, очень приятно, что Fedora так серьёзно относится к ситуации с optimus, и смогла реализовать хотя бы это на открытых драйверах. Это так же демонстрирует, что optimus в Linux может работать так как его реализовали в Windows, просто Nvidia ведёт себя - «Ни себе ни людям». Рализация optimus в Fedora на открытых драйверах отлично дополняет известное высказывание Линуса в отношении это великой корпорации.

P\S Время от времени dnf clean all приходится использовать. Почему то dnf забывает проверить новые пакеты в copr репозитории, хотя Центр приложений GNOME молниеносно замечает и сигнализирует с предложением обновиться. Похоже какой то хитрый баг, который проявляется при использовании include.

До проприетарных дров пока руки не дошли. Планирую позже попробовать. Обнаружил сейчас особенность, что, возможно, после перевода sata-контроллера в режим ahci (до этого был intel raid) не отрабатывает IRST, хотя соответствующий раздел создан. На предыдущем ноуте (ThinkPad T440s) были соответствующие настройки в BIOS'e, а у DELL такого нет. По поводу dnf. Попробуй использовать команду: «dnf upgrade --refresh», можно прямо alias на нее сделать.