Centos altarch что это

Обновлено: 04.07.2024

To extend the CentOS Linux usability base beyond the architectures supported already in the code base, and beyond what is being done in the Core SIG.

Current Status

This SIG is now producing CentOS Linux 7 install images and full trees for ppc64, ppc64le, i386, armhfp (arm v7 32-bit), aarch64 (arm v8 64-bit).

Abstract

This SIG would be a setup and managed up from community members who want to come and help port CentOS Linux to architectures and platforms not supported by the Core SIG itself.

Note: this is not called secondary arch group, since the word secondary indicates some level of inferiority - and I would rather we use release tagging (test, devel, alpha, beta, etc) rather than silo a group into always being only 'secondary'.

The group would have the ability to import content as needed, adapt content as needed, deliver in media that is suitable and needed for the platform they are targeting. Allowing for a lot more flexibility w.r.t features specific to their audience, and may or may not map to upstream tree's.

For vendor driven ecosystems where they own the entire platform and implementation of the platform (eg. as seen in the ARMv7 and v8 space), I encourage vendors to get involved with the effort - however do so without making it a role driven position. For the continuity of the effort, its far more productive for vendors to encourage individual level participation from their organisations into the CentOS AltArch effort.

We will retain the requirement that all 'CentOS' branded content must be hosted, built and delivered from infra operated by the CentOS Infra team, signed with a CentOS key (run by the Core SIG), must be freely redistributeable.

Create arch specific tags in the SIG as needed. eg:
- altarch-aarch64
- altarch-power8
- altarch-i686
These arch branches will/can be used to host spec file and source changes as needed specific to that arch. If a change is needed for multiple arch's, we just need to then carry it in all those branches (but we can socialise the changeset to the other arch's that might benefit from this change). The baseline assumption is that the core protected branch then only corresponds to the x86_64 distro for CentOS Linux 7, and for i686 + x86_64 on CentOS Linux 5 and 6.

In situations where there is a need for multi branches (eg. for aarch64 for vendor specific content ?) we would need to workout a naming process. the current model does not scale well for that (since git and koji targets are meant to line up, with only peer inheritance). This is a challenge we are trying to work through for the VIRT, Storage and Cloud SIGs as well - so a solution might not be too far (if there really is a need for this level of granularity in the AltArch SIG).

Koji can grow targets as needed. These targets should map to the git branch names as much as possible, and as hardware is available to contribute into a central pool. Each koji target per branch should have atleast a -devel, -testing and -released targets. Users in the AltArch group should be able to pull from their own branch, the protected git branches, and other arch branches.

For people who want to work on pre-release platforms, we can come up with a working process that helps them stage and release early onplatform availability.

A lot of people are interested in running Linux on such kind of cheap/small boards, as home server appliance, domestic controller, small VPN endpoint, etc. While there already exists a number of distributions providing support for such boards, someone already using CentOS x86_64 for their servers/workstations/laptops will probably be interested in managing even such small armv7hl boards with the same tools. That's why the CentOS AltArch SIG decided to try to port the existing code from CentOS x86_64 to the armv7hl/armhfp platform.

'It's worth knowing that the distribution for armv7hl platform is called "CentOS Userland Linux" and not "CentOS Linux". The reason is that the AltArch SIG can decide to include some other packages, replace some components or not build some packages from the upstream distribution. The most obvious case is the kernel, as kernel 3.10.0-* (used in the CentOS 7 x86_64 distribution), and 4.18.0-x (used in the CentOS 8 x86_64 distribution) don't support the armv7hl architecture.

We still have the RaspberryPi images available, while as of CentOS 7.5.1804 the generic images can be used natively on R-Pi boards with the upstream kernel. (Support is not complete but it is very usable.)

How to Unpack the Image for Your Board

Once you have downloaded the corresponding image for your board model, transfer it to your SD card:

uBoot Setup (Not Needed for the RaspberryPi Boards)

After you have unpacked the generic image to your SD card, you have to do one additional step. The actual commands depend on many things but specially on the SoC vendor and the type of board.

First you need to install uboot images:

Let's suppose you do this from your linux laptop and that your board is a Bananapro (AllWinner SoC):

Or assuming that your board is a Beagle Bone Black (TI):

For your information, here is a list of boards that have a uboot file for armhfp (from uboot-images-2018.09):

Once the image is transferred, you can put the SD card in the dedicated slot for your ARM device and boot it up.
- root password: centos
- eth0 setting: dhcp
- selinux status: enforcing
How to Resize/Expand the RootFS for the Whole SD Card

Depending on the SD card size you used, you will probably want to expand the RootFS (/) to the maximum capacity of the underlying SD card. For your convenience we've added the cloud-utils-growpart tool, packaged as an rpm file and available through the Extras repository for armv7hl.

If you just want to use/expand the whole remaining capacity, just run (either as root or as a normal user with sudo rights) the following command:

WiFi on the RaspberryPi 3B and 3B+
- First, obtain the two firmware files we can't distribute:
- Next, use nmcli to connect to the wireless network:
Installing an armv7hl (32 bit) VM on an aarch64 (64 bit) Machine

Do you have a CentOS-7 aarch64 machine and need to run a 32 bit arm Virtual Machine? . If so, here is an outstanding blog post by Fabian Arrotin (one of our core CentOS team members):

Getting help

Contributing to the Arm32 Group

How Can I Update My Kernel?

Depending on which board image you're using, it can use the generic kernel or the RaspberryPi variant. It's normally all configured automatically but even if you point to the correct repository, you'll have take care of the following (depending on the board variant):

RaspberryPi 2 and 3

yum update will bring the updated kernel and nothing else needs to be done. Just reboot and you'll be using the new kernel.

Generic Kernel

Before centos-userland-release-7-5.1804, in order to activate the new kernel and edit /boot/extlinux/extlinux.conf, you had to run /usr/bin/update-boot. This is no longer valid and it is done automatically by grubby.

How Can I Enable EPEL 7 on armhfp ?

The answer is easy in a sense that there is no official EPEL repository for armhfp. But because lot of users were asking for this, we decided to use the centos armhfp builders to (re)build Source packages from EPEL 7 (and try to track those automatically) when they're idle. Please note that it's just an automatic rebuild without any QA/test and also the resulting packages are not signed. To use that repository, proceed as follows:

SpecialInterestGroup/AltArch/armhfp (последним исправлял пользователь RichBowen 2021-06-28 18:26:48)

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

Технически это rsync , обычно по расписанию. Кто-то для этого предоставляет готовый набор скриптов, как Fedora, а кто-то просто говорит что надо синхронизироваться вот с этого сервера и рекомендуемый набор параметров. Самый затратный ресурс это место, мы недавно добрались до 4 терабайт и это дорого в нашем случае для того что не генерирует никакой прибыли. Взамен мы получили локальную доступность используемых нами дистрибутивов, это позволило упростить первоначальную настройку серверов исключив из неё обязательный доступ к Интернет. А ещё конечно мы рады что приобщились к чем-то большому, даже если наше участие в этом не сильно заметно.

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

Будем говорить о пакетном менеджере yum с установленным по умолчанию плагином fastestmirror и нас будет интересовать только процесс выбора конкретного зеркала.

Список зеркал

Известно, что список репозиториев задаётся в файлах в каталоге /etc/yum.repos.d/ если не указано иное. Вот так выглядят настройки репозитория Base в файле /etc/yum.repos.d/Centos-Base.repo :

Здесь видно две опции которые задают место откуда можно получать данные. Первая baseurl непосредственно указывает зеркало, никакого выбора тут не нужно. Вторая mirrorlist указывает ссылку по которой будет возвращён список из 10 зеркал из которых и будет делаться выбор, именно эта опция активна. Также мы видим несколько переменных внутри ссылки, все они в конечном итоге отражают конкретное место в дереве каталогов репозитория:
И всё это вместе соответствует иерархии каталогов непосредственно на сервере.
Реализация

Проверка осуществляется по списку в следующем порядке (цитирую из кода):

Пункты 1 и 2 работают или-или, чтобы проверить не только код страны, но и код штата. По сути происходит попытка выбрать ближайшие географически серверы. Для каждого шага выполняется запрос из базы данных, например:

Потом идёт проверка живости зеркал по этому списку путём сравнения хешей, как написано выше. Если набирается 10 живых, то на этом требуемая задача выполнена, работа завершена. Если не набирается то переходим к следующему шагу чтобы добрать общий список до 10 или пока не исчерпаем все варианты. Результат сохраняется в файле и отдаётся на откуп фронтенд части представленной Python скриптом ml.py, задача которого выбрать и отдать нужный файл, предварительно выяснив страну источника запроса по IP адресу. Также учитывается и тип протокола IPv4 или IPv6, для которых формируются разные списки.

Вернёмся к запросу в котором используется ORDER BY RAND() , означает ли это что список будет случайным? Да, насколько случайна само реализация в СУБД, но это касается только порядка внутри каждого шага. То есть, если для конкретной страны набирается больше 10 зеркал нужного типа репозитория и архитектуры (для России всего 17), то в итоге каждый раз мы будем получать перетасованный список из 10 разных зеркал в одной стране. Если их меньше, то вверху списка всегда будут перетасованные репозитории из одной страны, дальше перетасованные репозитории из ближайших стран и так далее по шагам. В итоге получаем не совсем случайный список состоящий из нескольких случайных частей. Это имеет значение когда рабочих зеркал внутри одной страны не так много, например IPv6 зеркал в России всего 7 и они всегда будут вверху списка:

Ещё хуже дело обстоит с архитектурой i386 это альтернативная архитектура для Centos 7 и отдельная система зеркал. В России всего один такой сервер который поддерживает альтернативные архитектуры, он всегда будет на первом месте:

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

Сканирование репозиториев происходит постоянно и не учитывая механизмы кеширования результат обновляется примерно раз в 3 часа. Цитата из mirrorlist_crawler_deployment_notes.txt:

- A full scan of all repos and all versions without any cached data is going to take close to 3 hours, but typically altarch is <10min, C6 <25min, C7 <25min with all the repos enabled

Можно ожидать что каждые 15 минут у нас будет новый список, за 30 минут какие-то изменения в нём произойдут обязательно. Но! Помним что чем меньше активных зеркал тем менее случаен порядок и на первом месте сейчас в России всегда одно и то же зеркало.

Fastestmirror

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

В dnf тоже используется fastestmirror из набора библиотек RPM, но там это решено через libcurl и в целом всё сложнее устроено.

На практике получились следующие результаты первого места на недельном опросе через каждые 10 минут. Цифры — количество раз сколько узел выигрывал при сравнении, для fastestmirror и fping :

Видно что выбор не прямо однозначный, но тут скорее всего играет роль близость точки с которой я делал опрос — до нескольких зеркал, разница меньше миллисекунды. Второй момент, IPv6 список отличается и он хуже — ближайший IPv6 узел дальше чем ближайший IPv4 и выбор меньше. С учётом приоритета IPv6 получается не очень. Результаты fping лаконичнее, меньше выигрывавших узлов, но в целом одинаковы с fastestmirror .

RIPE Atlas

Пробники (синие маркеры) и зеркала (красные маркеры) распределены слишком неравномерно и тяготеют к столицам, поэтому результаты не стоит воспринимать как что-то значимое. Сырые данные доступны начиная с измерения номер 23159879 по 23159901, при желании их можно проанализировать более строго. Обобщённый итог количество первых мест для IPv4:

Лучшие результаты в районе одной или нескольких миллисекунд, а самый худший результат по отклику в Салехарде, пробник 22767:

Послесловие

При этом доля этого трафика изнутри нашей сети ничтожна.

Вот так на нём заканчивается место:

Хорошо различимые ступеньки — моменты когда мы добавляем новый дистрибутив. Когда всё начиналось это был VirtualBox работающий под Windows на офисном компьютере на котором хранились видеоархивы нашего рекламного отдела. Потом мы перебрались на боевую систему виртуализации и стало чуть полегче:

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

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

Технически это rsync , обычно по расписанию. Кто-то для этого предоставляет готовый набор скриптов, как Fedora, а кто-то просто говорит что надо синхронизироваться вот с этого сервера и рекомендуемый набор параметров. Самый затратный ресурс это место, мы недавно добрались до 4 терабайт и это дорого в нашем случае для того что не генерирует никакой прибыли. Взамен мы получили локальную доступность используемых нами дистрибутивов, это позволило упростить первоначальную настройку серверов исключив из неё обязательный доступ к Интернет. А ещё конечно мы рады что приобщились к чем-то большому, даже если наше участие в этом не сильно заметно.

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

Будем говорить о пакетном менеджере yum с установленным по умолчанию плагином fastestmirror и нас будет интересовать только процесс выбора конкретного зеркала.

Список зеркал

Известно, что список репозиториев задаётся в файлах в каталоге /etc/yum.repos.d/ если не указано иное. Вот так выглядят настройки репозитория Base в файле /etc/yum.repos.d/Centos-Base.repo :

Здесь видно две опции которые задают место откуда можно получать данные. Первая baseurl непосредственно указывает зеркало, никакого выбора тут не нужно. Вторая mirrorlist указывает ссылку по которой будет возвращён список из 10 зеркал из которых и будет делаться выбор, именно эта опция активна. Также мы видим несколько переменных внутри ссылки, все они в конечном итоге отражают конкретное место в дереве каталогов репозитория:
И всё это вместе соответствует иерархии каталогов непосредственно на сервере.
Реализация

Проверка осуществляется по списку в следующем порядке (цитирую из кода):

Пункты 1 и 2 работают или-или, чтобы проверить не только код страны, но и код штата. По сути происходит попытка выбрать ближайшие географически серверы. Для каждого шага выполняется запрос из базы данных, например:

Потом идёт проверка живости зеркал по этому списку путём сравнения хешей, как написано выше. Если набирается 10 живых, то на этом требуемая задача выполнена, работа завершена. Если не набирается то переходим к следующему шагу чтобы добрать общий список до 10 или пока не исчерпаем все варианты. Результат сохраняется в файле и отдаётся на откуп фронтенд части представленной Python скриптом ml.py, задача которого выбрать и отдать нужный файл, предварительно выяснив страну источника запроса по IP адресу. Также учитывается и тип протокола IPv4 или IPv6, для которых формируются разные списки.

Вернёмся к запросу в котором используется ORDER BY RAND() , означает ли это что список будет случайным? Да, насколько случайна само реализация в СУБД, но это касается только порядка внутри каждого шага. То есть, если для конкретной страны набирается больше 10 зеркал нужного типа репозитория и архитектуры (для России всего 17), то в итоге каждый раз мы будем получать перетасованный список из 10 разных зеркал в одной стране. Если их меньше, то вверху списка всегда будут перетасованные репозитории из одной страны, дальше перетасованные репозитории из ближайших стран и так далее по шагам. В итоге получаем не совсем случайный список состоящий из нескольких случайных частей. Это имеет значение когда рабочих зеркал внутри одной страны не так много, например IPv6 зеркал в России всего 7 и они всегда будут вверху списка:

Ещё хуже дело обстоит с архитектурой i386 это альтернативная архитектура для Centos 7 и отдельная система зеркал. В России всего один такой сервер который поддерживает альтернативные архитектуры, он всегда будет на первом месте:

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

Сканирование репозиториев происходит постоянно и не учитывая механизмы кеширования результат обновляется примерно раз в 3 часа. Цитата из mirrorlist_crawler_deployment_notes.txt:

- A full scan of all repos and all versions without any cached data is going to take close to 3 hours, but typically altarch is <10min, C6 <25min, C7 <25min with all the repos enabled

Можно ожидать что каждые 15 минут у нас будет новый список, за 30 минут какие-то изменения в нём произойдут обязательно. Но! Помним что чем меньше активных зеркал тем менее случаен порядок и на первом месте сейчас в России всегда одно и то же зеркало.

Fastestmirror

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

В dnf тоже используется fastestmirror из набора библиотек RPM, но там это решено через libcurl и в целом всё сложнее устроено.

На практике получились следующие результаты первого места на недельном опросе через каждые 10 минут. Цифры — количество раз сколько узел выигрывал при сравнении, для fastestmirror и fping :

Видно что выбор не прямо однозначный, но тут скорее всего играет роль близость точки с которой я делал опрос — до нескольких зеркал, разница меньше миллисекунды. Второй момент, IPv6 список отличается и он хуже — ближайший IPv6 узел дальше чем ближайший IPv4 и выбор меньше. С учётом приоритета IPv6 получается не очень. Результаты fping лаконичнее, меньше выигрывавших узлов, но в целом одинаковы с fastestmirror .

RIPE Atlas

Пробники (синие маркеры) и зеркала (красные маркеры) распределены слишком неравномерно и тяготеют к столицам, поэтому результаты не стоит воспринимать как что-то значимое. Сырые данные доступны начиная с измерения номер 23159879 по 23159901, при желании их можно проанализировать более строго. Обобщённый итог количество первых мест для IPv4:

Лучшие результаты в районе одной или нескольких миллисекунд, а самый худший результат по отклику в Салехарде, пробник 22767:

Послесловие

При этом доля этого трафика изнутри нашей сети ничтожна.

Вот так на нём заканчивается место:

Хорошо различимые ступеньки — моменты когда мы добавляем новый дистрибутив. Когда всё начиналось это был VirtualBox работающий под Windows на офисном компьютере на котором хранились видеоархивы нашего рекламного отдела. Потом мы перебрались на боевую систему виртуализации и стало чуть полегче:

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

Читайте также: