Как изменить версию ядра linux

Linux и Windows: помощь админам и пользователям

Администрируем и настраиваем Windows, Linux.

Как изменить ядро Ubuntu Linux

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

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

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

Для начала, вам нужно посмотреть какая версия ядра у вас сейчас. Используйте для этого команду uname :Теперь вам необходимо установить исходные коды Linux для вашего ядра, обратите внимание что у меня ядро 2.6.17-10. Вы можете заменить номер ядра на тот, который используется у вас. Вам также необходимо установить библиотеки и некоторые дополнительные программы, которые помогут вам при компиляции.

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

Вы можете увидеть что исходники устанавливаются в директории /usr/src в архивированном файле.

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

Теперь смените директорию. Заметьте что вам необходимо установить утилиту bunzip если её нет в вашей системе.

Сделайте копию текущей конфигурации ядра перед изменением. Обратите внимание, что символ `находиться под символом тильда

Теперь мы можем запустить утилиту, которая позволит нам изменить ядро:

Сперва, перейдем в меню Load an Alternate Configuration File , и загрузим файл .config (просто нажав enter).

Теперь находясь внутри утилиты, мы можем установить опции для настройки ядра. Навигация очень простая. Я решил выбрать Networking и нажал клавишу Enter для перехода в эту категорию:

Amateur Radio Support ? Зачем мне это? Вы можете видеть символ *, который означает что это есть в ядре.

Нажав клавишу ?, вы перейдете в справку для выбранного элемента:

Итак, я собираюсь отключить это немедленно. Зачем вообще это установлено в моем ядре? Я нажимаю Esc для выхода из окна справки, и потом нажму N для удаления этого элемента из ядра.

Когда вы закончите делать изменения, которые вам нужны, нажмите Exit и сохраните конфигурационный файл.

Теперь конфигурация готова для компиляции. Сперва сделаем очистку, просто для того чтобы убедиться, что все готово к компиляции.

Далее мы действительно компилируем ядро. Это делается чертовски долго, так что пойдите займитесь чем нибудь ещё.

Этот процесс создаст два .deb файла в директории /usr/src . Файл linux-image**** содержит актуальный образ ядра, а другой файл содержит измененный. Имена файлов могут быть отличными в вашей системе.

Пожалуйста обратите внимание что когда вы запустите следующие команды, вы установите новое ядро как ядро по умолчанию. Это может разрушить вашу систему. Если ваша машина не загружается, вы можете нажать Esc и меню загрузки GRUB и выбрать старое ядро. Вы можете заблокировать неверное ядро в /boot/grub/menu.lst и попробовать скомпилировать его заново.

Теперь перегрузите вашу машину. Если все работает, должно загрузиться новое измененное ядро. Проверьте это, испольльзуя uname .

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

Источник

⏬ Как понизить версию ядра в Linux

Linux живет и умирает ядром.

Если вы знакомы с тем, как работает GNU / Linux, Linux – это ядро.

Все остальное – это инструменты, которые взаимодействуют с ним.

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

Ядро операционной системы похоже на вашу сердечно-сосудистую систему.

Вы склонны забывать об этом, пока что-то пойдет не так.

Когда обновленное ядро не позволит вам использовать ваш компьютер, пришло время понизить версию.

Загрузитесь в старое ядро

Для загрузки в старое ядро вам необходимо перезагрузить компьютер.

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

В некоторых системах сразу будут показаны более старые ядра, в то время как в Ubuntu вам нужно будет выбрать «Advanced options for Ubuntu», чтобы найти более старые ядра.

Выбрав старое ядро, вы загрузитесь в свою систему.

Все должно работать как раньше.

Если проблема не устранена, значит она не в ядре.

Удалите проблемное ядро

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

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

Как избежать таким проблем в будущем

Один из самых простых способов избежать такого рода проблем – не принимать обновление сразу .

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

Особенно следует следить за пользователями со схожим оборудованием.

Если вам важна стабильность, вы также можете использовать дистрибутивы LTS.

Эти обновления более редкие, за исключением обновлений безопасности.

Это означает, что вы можете рассчитывать на то, что они будут более стабильными, чем ваш стандартный дистрибутив.

Заключение

Хотя понижение версии является самым простым способом решения проблем, связанных с ядром, это не единственный способ.

Иногда это просто невозможно.

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

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

Это не совсем просто, но не так сложно, как думают некоторые.

Источник

Как обновить ядро в системе без перезапуска сервисов (пошаговая инструкция)

Как вы думаете насколько реально зайти на машину по ssh, обновить систему, загрузить новое ядро и при этом оставаться в той же ssh сессии. Сейчас есть модное движения по обновлению ядра на лету (ksplice, KernelCare, ReadyKernel, etc), но у этого способа есть много ограничений. Во-первых, он не позволяет применять изменения, которые меняют структуру данных. Во-вторых, объекты в памяти могут уже содержать неверные данные, которые могут вызвать проблемы в дальнейшем. Здесь будет описан более «честный» способ обновить ядро. На самом деле, сам способ уже давно известен [1], а ценность этой статьи в том, что мы разберем все в деталях на реальном примере, поймем, насколько это просто или сложно, и чего стоит ждать от подобных экспериментов.

Travis CI — одна из популярных систем непрерывной интеграции, которая хорошо работает с Github. Сервис быстро развивается и если несколько лет назад он предоставлял только контейнеры с не очень свежими дистрибутивами, то сегодня там есть выбор между контейнерами и вмками, есть поддержка не только Linux систем и многое другое.

Мы начали использовать Travis-CI в нашем проекте CRIU (checkpoint/restrore in userspace) несколько лет назад и всегда брали от сервиса максимум. Начинали с проверки компиляции на x86_64, а сегодня Travis-CI запускает наши тесты, проверяет компиляцию на всех архитектурах, с разными компиляторами и даже тестирует совместимость с новыми ядрами, в том числе и самой нестабильной и передовой веткой Linux-Next.

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

А теперь к делу, господа…

Но сегодня я хочу рассказать совсем не о том, как мы тестируем CRIU, а об одном интересном варианте его использования. Представьте, что на входе у нас есть виртуальная машина, в которой через ssh запущен процесс. Как нам загрузить свое ядро так, чтобы процесс этого не заметил? Это ровно та ситуация, которую мы имеем в Travis-CI.

Внешнего доступа к виртуалке мы не имеем, и если процесс Travis по какой-то причине умирает (завершается), то сервис завершает задачу и удаляет ВМ. Согласитесь, задачка, прямо скажем, непростая. Мы даже сделали внизу голосование – просигнальте, пришло ли вам сразу в голову решение или нет.

Но мы поступили следующим образом: берем CRIU, дампим ssh-сессию Travis, загружаем новое ядро, восстанавливаем процессы и бежим дальше. Примерно так я думал, когда решил немного развлечься после обеда и показать, как все это взлетит.

Сразу скажу, что задача – отнюдь не абстрактная. У нее есть несколько реальных применений. Одно из них — это желание некоторых пользователей загрузить Ubuntu 16.04 (https://github.com/travis-ci/travis-ci/issues/5821). Разработчики Travis решать эту задачу пока не собираются, а мы можем попробовать сделать это без их помощи. Идея тут та же, берем начальную систему 14.04, обновляем ее и перезагружаемся в новое окружение.

Решение

Обновление системы — меньшая из бед, решается парой команд:

Но дальше становится намного веселее. Во-первых, возникает опрос: откуда начинать дампить? Во-вторых, как будем восстанавливать? Если что-то пойдет не так, как мы узнаем, что именно? От замороженного Travis помощи ждать не приходится.

Так что начнем разбираться своими силами. Смотрим на дерево процессов и понимаем, что дампить надо начинать с процесса SSHD, который обрабатывает нашу SSH-сессию.

Идем по всем родителям, начиная с себя, и берем второй процесс sshd от init-а:

Теперь мы знаем кого дампить и надо решить кто будет этим заниматься. Стоит учесть, что CRIU не позволяет «пилить сук, на котором сидит», так что придется создать сторонний процесс:

Пришло время сочинить команду для дампа. Если вы думаете, что это не сложно, то сильно ошибаетесь. В CRIU уже наросло такое количество опций, что не все разработчики могут сразу в них разобраться. Но на самом деле, все не так плохо, если разобраться. Строчка кода получилась достаточно короткая.

Если перевести ее на русский язык, это команда звучит примерно так: “CRIU, сделай нам дамп поддерева начиная с процесса $pid, все данные сложи в директорию /imgs, логи сохрани в файле dump.log, рассказывай подробно обо всем что делаешь, а также разрешаем тебе сохранить tcp-сокеты, unix-сокеты, связанные с внешним миром, файловые локи и дескрипторы на удаленные файлы”.

Кажется, тут все понятно, кроме удаленных файлов — откуда они возьмутся? Но достаточно вспомнить, что мы установили мажорный update на систему, а это значит, что обновилось почти все, в том числе библиотеки и запускаемые файлы. При этом наш процесс не перезапускался и по прежнему использует старые версии этих файлов. Именно для них мы и указываем опцию —link-remap.

Тут же возникает и еще одна проблема. Между сохранением и восстановлением процессов сетевой трафик должен быть заблокирован, иначе нет никакой гарантии, что TCP соединения переживут эту операцию. CRIU добавляет для этого пару правил iptables, и наша задача — эти правила восстановить после загрузки нового ядра, но до того как произойдет настройка сети. Здесь мне пришлось немного погуглить, но в целом также задача решилась не слишком сложно.

Восстановление

Итак, процессы сохранены, и пришло время время подготовить того, кто будет их восстанавливать. Тут нам придется написать свой небольшой сервис.

Кажется все готово и можно взлетать. Ключ на старт.

Полетели!

Так мы взлетели, но, как и SpaceX, с первого раза сесть не смогли. А не смогли мы, потому что посадочная платформа была кем-то уже занята. А если серьезно, то проблема в том, что CRIU позволяет восстанавливать процессы только с теми же идентификаторами, что у них были на момент дампа. Мы же перезагрузились в новую систему, где systemd (. ) и процессов стало немного больше. Эта проблема уже давно изучена наукой, и тут нам помогут контейнеры, точнее говоря, только их маленькая часть, называемая пространством имен процессов (pid namespace).

Попробуем взлететь, и снова наш корабль не выходит на связь. На этот раз идей о неполадках никаких нет, и надо как-то добывать логи. Тут было решено не думать долго, а взять да и залить их на одно из популярных хранилищ разных отходов.

Под прицелом камер мы теряем очередной корабль и понимаем, что шутки кончились. На этот раз нам жалуются на DBus сокет, т е это уже такая связь, состояние которой нам недоступно, ведь ей владеет только DBus-демон. С другой стороны, зачем sshd нужен этот сокет? Наверняка он хочет отслеживать состояние сети и прочую ерунду. Мы ничего такого делать не собираемся (точнее мы уже все сделали), так что давайте просто восстановим этот сокет как-нибудь и поедем дальше.

Фактически мы сделали свой собственный патч для CRIU. Это можно было решить более элегантно с помощью плагинов, но так было быстрее. Снова заливаем наши изменения и ждем очередного падения. На этот раз возникает проблема с псевдотерминалами: нужные нам номера уже кем-то используются. Мы могли бы монтировать devpts с newinstance, но эта опция с недавнего времени не работает.

— The newinstance mount option continues to be accepted but is now
Ignored. // Eric W. Biederman

Похоже пришло время залезть в образы процессов и немного подправить их напильником. Давайте поменяем в них номера псевдотерминалов и добавим префикс 1. Был терминал с номером 1, станет с номером 11. Для этого в CRIU есть возможность переформатировать образа в Json формат и обратно. Выглядит это примерно так:

Опять запускаем и ждем. Время уже давно послеобеденное, и вся эта затея явно сильно затянулась. Привычно получаем ошибку — на этот раз о том, что какие-то fifo файлы из /run/systemd/sessions не могут быть восстановлены. Разбираться, что это за файлы, нет никакого желания, поэтому перед восстановлением просто создадим их и побежим дальше.

Опять падаем, и на этот раз похоже налетаем на баг в CRIU. Видим, что sys_prctl(PR_SET_MM, PR_SET_MM_MAP, …) возвращает EACCES, лезем в ядро и находим, что виной тому восстановление ссылки на запускаемый файл. Ядро видит, что мы передаем ссылку на файл, у которого нет соответствующего бита. Вы же помните, что мы обновили систему целиком, и теперь эта ссылка из процесса указывает на удаленный файл. Оказывается, что перед тем как удалить файл, dpkg снял с него права на запуск.

Кажется, достаточно сделать еще один патч к CRIU, и золотой ключик будет у нас в кармане.

Заключение

Ура! Все работает https://travis-ci.org/avagin/criu/builds/181822758. На самом деле, это очень краткий пересказ всей истории. Мне пришлось запускать эту задачу в Travis 33 раза, прежде чем она впервые прошла успешно.

Что мы этим доказали? Во-первых, решили пару прикладных задач, а во-вторых показали, что CRIU — это очень низкоуровневый инструмент и даже простая задача может потребовать глубоких знаний системы. Зато старания компенсируются мощностью, гибкостью и широкими возможностями. Хотя никто не гарантирует, что вам не придётся повоевать с багами.

Источник