Linux для arm архитектуры

Установка Linux на ARM. Подробная пошаговая инструкция и советы

Установка Linux на ARM — это довольно интересная тема. Даже принимая только то, что это довольно-таки необычно. Почему необычно? П отому что в ARM-процессорах совсем другая архитектура, чем у тех, для которых рассчитано большинство дистрибутивов Линукс.

Для тех , кто не знает, ARM — архитектура маленьких микр оп роцессоров. Если простым языком, то это архитектура процессора у маленьких компьютеров или мобильных телефонов. Поэтому вопрос : вы часто видели Linux на смартфоне (процессоре ARM)?

Основная масса больших и привычных ПК имеют архитектуру х86 или AMD64. Данные процессоры рассчитаны на трудо- и ресурсоемкие задачи:

• редактирование фотографий;
• редактирование музыки или видео;
• работа с базой данных;
• программирование и т.д .

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

Какие операционные системы подходят для ARM?

В принципе на ARM — устройствах можно запустить любую операционную систему, которая была скомпилирована под данную архитектуру. Поэтому обычные Линукс версии, которые мы уже привыкли наблюдать на своих ПК , просто не подойдут , д аже если они легковесны и подходят по другим параметрам. Но в т о ж е время в сети можно найти приличное количество уже «готовых» дистрибутивов Linux для ARM — процессоров. Ярким представителем является известный всем Android, из менее известных, но популярных — Kali Linux.

Кстати, а вы знали, что популярный Android мегакорпорации Google — это всего лишь «операционка» на основе ядра Linux ? Пр ит ом, что Андроид является самой популярной операционной системой для мобильных телефонов — этот факт, как видите, малоизвестен. Но вообще нужно понимать, что Linux здесь является всего лишь «ядром». А ядро — это всего лишь основной функционал, предполагающий использование устройствами опций аппаратной системы, драйверов, управления, утилиты для командной строки и др. Семейство Linux подразумевает совокупность всех операционных систем, использующих его ядро, но это не есть самостоятельное ядро. Различие всем системам «семейства» придает графическая оболочка, но это совсем другая история. Однако возможность использовать эти ОС без графической оболочки, а только через текстовую командную строку, расширяют сферу их применения. Именно поэтому их можно «заметить» в необычных местах:

• в сетевом оборудовании;
• в производственных станках;
• в начинке самолета или автомобиля;
• даже в современных стиральных машинах.

Итак, из семейства Linux для ARM можно подобрать конфигурации у следующих дистрибутивов:

1. Debian. Это одна из самых старых версии Линукса, большое сообщество, много программ , написанных для этой системы, стабильность работы и мн.др. Его можно «найти» практически везде, также и в ARM — процессорах.
2. Ubuntu. Кто не слышал о б Убунту, тот не слышал о Линукс. С читается , что у него бо л ее продвинутое интерфейсное оформление, чем у Дебиан, да и вообще он сам более продвинутый. Встречается в ARM — процессорах, но совсем недавно анонсирована Ubuntu Phone — специальная ОС для смартфонов, которая будет призвана конкурировать с Android. Проект анонсирован, но пока должного «движения» не замечено.
3. Kali, Arch, Gentoo и др. , и каждый со своей отличительной особенностью , и каждый используется в ARM — системах.

На самом деле , этот список можно продолжать очень долго, потому что прогресс не стоит на месте, а земля наша слави тся умельцами. И многие разработчики «подтачивают» тот или иной дистрибутив Linux под ARM — процессор.

Установка Linux на ARM — устройство

Как правило, приобретая какое-либо устройство на ARM — процессоре, вы его получаете уже с предустановленной ОС. Чаще всего на таких устройствах идет Android. Допустим, вы все равно хотите установить Linux на это ARM — устройство. Тогда у вас есть 2 пути:

1. Полноценная «перепрошивка» на «чистое железо» ;
2. Установка «внутри» или «рядом» с Android (или другой системы, суть от этого не меняется).

При полной «перепрошивке» вы потеряете весь предустановленный производителем функционал. Вряд ли это будет то, чего вы добиваетесь. Поэтому тут можно воспользоваться вторым способом и установить Linux, не удаляя основную операционную систему вашего устройства. Для этого нужно будет настроить запуск chroot-окружения внутри Андроид. Но зато на выходе вы получите 2 параллельно установленные операционные системы и сможете использовать то одну, то другую. С т ак им подход ом можно поэкспериментировать на смартфонах или планшетах, где есть экран. А на простых безэкранных устройствах с таким способом могут возникнуть трудности.

Советы при установки Linux на ARM — устройство

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

Сама технология установки Linux на ARM еще в довольно «сырой» форме. Да, есть какие-то наработки и отдельные дистрибутивы. Есть умельцы, которые делают это и говорят, что это круто. Но в целом материала и стабильности в этом мало. Это не касается тех устройств, в которых Linux предустановлен производителем!

Но в т о ж е время четко вырисовывается тенденция, что за ARM — процессорами будущее. Этому свидетельствует даже тот факт, что первое место в рейтинге суперкомпьютеров ТОП — 500 в 2021 году с большим отрывом по производительности от конкурентов занимает машина на ARM — процессорах!

У ARM — процессоров масса преимуществ , поэтому, скорее всего , в обозримом будущем они будут стоять на наших персональных компьютерах. А это значит, что Linux на ARM — устройстве не будет диковинкой! А нужно ли вам это сейчас — решать вам.

Мы будем очень благодарны

если под понравившемся материалом Вы нажмёте одну из кнопок социальных сетей и поделитесь с друзьями.

Источник

4 of the Best Linux Distributions You Can Run on ARM Devices

Day by day, ARM devices get more and more popular, especially in the world of Linux. Years ago ARM just meant the Raspberry Pi. Now it means a host of devices: hobby boards like the Pi, servers, compact desktop computers and even laptops!

That is why we have decided to make a list and discuss what the best Linux operating systems for ARM devices are. Each operating system has its negatives and positives. Which one should you use? Let’s find out!

1. Arch Linux ARM

Perhaps the most dedicated ARM Linux distribution project out there, Arch Linux ARM, aims to bring Linux to all sorts of ARM-based devices. Arch for ARM supports multiple different ARM releases, from ARM v5 to v8 with dozens of device-specific images.

The real benefit of using Arch Linux for ARM circles back to the reason Arch Linux proper is such a good choice: the Arch Linux User Repository. This is because a lot of programs in the AUR are set up to compile from scratch, meaning that for a lot of situations users will not need to rely on packages being ported, as most AUR programs can be ported to ARM by themselves easily.

2. Debian on ARM

Out of all the different types of Linux out there, you’ll find few reliable. This is why Debian has a home on many Linux servers, desktops, laptops and now even your favorite ARM computer, and comes with three separate releases: ARM EABI for old 32-bit devices, ARM hard-float for newer 32-bit devices, and a 64-bit ARM port for modern devices.

For those looking for a stable and reliable basis for a Raspberry Pi 3-powered home theater or Beaglebone Black ARM desktop, the Debian project may be a good place to start!

3. Manjaro ARM

Those who are unfamiliar with Manjaro, listen up: it’s a Linux distribution that takes the technological strength of Arch Linux and combines it with steady and stable updates, effectively turning Manjaro into a Ubuntu or Debian distro based on Arch Linux.

On ARM Manjaro’s mission is the same. Bring great Arch Linux features, but add in stability. The Manjaro ARM project does a good job at this, though at this time only supports the Raspberry Pi3 and 2. More devices like the Pi Zero and Odroid C1 (and 2) are under development.

4. Chromium OS

The best Linux distribution for ARM-based Laptops and ARM-based microcomputers doesn’t come from the Linux community. Instead, it comes (in part) from Google. Chromium OS is the open-source implementation of Google’s Chrome OS for Laptops, dongles and desktops.

Chromium OS isn’t full Linux, and when users log into it they’ll find out that the experience is essentially what users can expect on a Chromebook: a web browser, support for Chrome-based apps, and other basic tools like MP3 and video playback.

In a world where most of the technology on the Web is moving away from flash, this open-source operating makes sense, even on ARM devices. Chromium OS doesn’t have any specific builds for specific devices, but images exist for use on ARM devices here.

Conclusion

ARM is a growing competitor to the standard PC architecture and is here to stay. As more and more people go mobile or decide to indulge in small, hobbyist boards, ARM will continue to flourish. As this trend continues, we can only hope that development for high-class Linux distributions will continue as well. For now, the choices on this list are a great start.

Derrik Diener is a freelance technology blogger.

Our latest tutorials delivered straight to your inbox

Источник

Это вам не x86_64. Проблемы сборки Arch Linux под ARM-архитектуру и как мы их решали

Привет, Хабр! Меня зовут Лев Евсеенко, я работаю системным администратором в Selectel, сопровождаю сервисы наших выделенных серверов. В декабре мы пополнили линейку конфигом Ampere Altra Max M128-30 (3 ГГц, 128 ядер) с ARM-процессором внутри.

Перед введением в «эксплуатацию» нужно было разобраться с сетевой загрузкой, модифицировать служебный дистрибутив, адаптировать существующие процессы автоустановки ПО под новую архитектуру. В тексте расскажу, с какими проблемами мы столкнулись и какие решения нашли.

Вы можете подробнее почитать о том, зачем мы добавили ARM-серверы в линейку, а еще посмотреть на результаты бенчмарков тестовой платформы на Ampere Altra Q80-30 в классной статье от моего коллеги.

Если коротко, они хорошо показывают себя в многопоточных задачах и при этом намного энергоэффективнее процессоров от AMD и Intel. Основные задачи, которые решали клиенты во время тестов Ampere Altra, — работа с СУБД, запуск высоконагруженных веб-сервисов, разработка мобильных приложений и embedded-разработка.

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

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

Сетевая загрузка, или часть, в которой все идет по плану

Это была самая простая часть процесса, где все работало именно так, как ожидалось.

Автоматизируем сборку и деплой PXE-клиента

Мы используем модифицированный iPXE (небольшие изменения во время сборки, чтобы DHCP-сервер мог опознать PXE-клиент), который уже поддерживает arm64. Единственной проблемой стала сборка бинарного файла для arm64 на x86_64 GitLab-worker с помощью кросс-компиляции. Для сборки используется стандартный Docker-контейнер linux/amd64 ubuntu:20.04, Dockerfile:

Сборка выполняется из мастера iPXE GitHub следующей командой:

, где universal.ipxe — встраиваемый скрипт, который обрабатывает проблемы с сетью и работает со ссылками на загрузочные скрипты, которые генерирует наш бэкенд. На выходе получаем готовый arm64-binary, который деплоится на наши TFTP-серверы.

Убеждаемся, что DHCP-сервер отдаст ссылку на нужную сборку iPXE, в зависимости от архитектуры

Мы определяем архитектуру и/или режим загрузки (Legacy/UEFI) сервера с помощью опции 60 DHCP — Vendor class identifier:

DHCP DISCOVER от ARM64-EFI сервера.

DHCP DISCOVER от x86_64-EFI сервера.

Смотрим на часть PXE Client:Arch:00011, значения соответствуют RFC4578:

0	Standard PC BIOS
6	32-bit x86 EFI
7	64-bit x86 EFI
9	64-bit x86 EFI (obsolete)
10	32-bit ARM EFI
11	64-bit ARM EFI

В зависимости от этого значения DHCP-сервер возвращает имя необходимого файла в DHCP Option 67 — Bootfile name.

После iPXE проходит по одноразовой ссылке и получает сгенерированный загрузочный скрипт. В зависимости от содержимого скрипта сервер либо загружается с диска, либо запускает переустановку ОС, либо загружается в дистрибутив для восстановления.

Arch Linux для ARM, или грустный рассказ о неверных эстимейтах

Поскольку мы сдаем выделенные серверы в аренду и стараемся делать это очень быстро, мы автоматизируем многие процессы. Например, запуск операций зачистки дисков при завершении аренды сервера, проведение промежуточных тестов при завершении аренды и приемочных тестов после сборки сервера. Для всего этого мы используем кастомную сборку Arch Linux — внутри компании мы называем этот дистрибутив rescue. Помимо прочего, он используется для диагностики серверов и аварийных работ с ними.

Нам нужно было состыковать Arch Linux с ARM-процессором. Изначально никаких подводных камней не ожидалось: есть проект Arch Linux for ARM, на GitHub есть проект archiso-aarch64 – mkarchiso, адаптированный под aarch64. Казалось бы, собираем все вместе, заменяем архитектуру в существующих пайплайнах по сборке и деплою образа — готово. Мы оценили задачу примерно в 2 недели. Именно в этот момент все пошло не так.

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

Проблема со сборкой артефактов для загрузки сервера в режиме UEFI

Разработчик archiso-aarch64 просто продублировал большинство классов, поменяв значения переменных на необходимые для архитектуры aarch64. Нам пришлось немного модифицировать сборочные скрипты archiso-aarch64. Модификация только одна: был изменен класс, который используется при сборке образа под legacy-режим загрузки. Дело в том, что тестируемые нами серверы с процессорами ARM работают только в UEFI, но при этом в оригинальных скриптах артефакты загрузки (vmlinuz и initramfs) собираются только в legacy-части скриптов.

В итоге в часть, ответственную за сборку UEFI-артефактов, был импортирован класс, ответственный за упаковку ядра и initramfs. В строку 622 мы добавили:

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

Не поддерживалась кросс-архитектурная сборка образа

При сборке образа используется chroot, который ломается во время «добавления» пакетов «внутрь» образа.

Тут мы решили попробовать проект archboot, который обещал поддержку кросс-архитектурной сборки, но процесс интеграции наших инструментов сильно затягивался. Кроме того, в образе слишком много лишнего — например, графическая оболочка, доступ через VNC, огромная куча хуков mkinitcpio, с которой было решительно некогда разбираться. Из-за этого вернулись к использованию archiso-aarch64.

Мы пробовали собирать образ в эмулированной через QEMU виртуальной машине, но процесс занимал больше часа. Проблему со сборкой решили заведением GitLab-runners на Raspberry Pi 4. Наши раннеры для сборки x86-образа запущены на хостах облачной платформы Selectel, в то время как раннеры для этого проекта запускаются на физических RPi4, которые находятся в служебной стойке в одном из наших дата-центров.

Ранее мы писали, как внедряли серверы на «малинках» в дата-центры. Подробно описали каждый этап. Все тексты — в одной подборке.

В качестве executor в GitLab-runner используется Docker. Это сильно отличается от сборки x86-образа, где используется libvirt и QEMU. Дело в том, что последняя работает пока крайне медленно в режиме эмуляции aarch64, да и использование более простого в настройке исполнителя приветствуется. Dockerfile:

Недостаток готовых бинарных пакетов в репозиториях

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

Первым делом нам пришлось сильно переработать список пакетов для установки в дистрибутив. Огромное количество ПО просто не существует в репозиториях, да и сам репозиторий Arch Linux, хоть и поддерживается некоторыми мейнтейнерами, — является скорее неофициальным.

Достаточно много пакетов — stress-ng, утилиты для прошивки материнских плат, SSD и NIC — мы собираем сами. Некоторые из них поставляются в виде бинарных файлов только под архитектуру x86_64. Из-за этого нам пришлось переписать скрипт автотестов, а также временно отказаться от некоторых используемых фич для архитектуры arm64. Например, автоматической прошивки материнских плат и периферии, а также автоматической настройки BMC.

Коротко об автотестах при передаче сервера клиенту

После сборки платформы, а также при передаче сервера новому клиенту мы проводим ряд автотестов.

После сборки сервера он должен пройти тест комплектующих. Проверяем, что CPU, RAM, GPU и блочные устройства корректно определяются, их характеристики соответствуют заявленным. Также проверяем SMART-параметры блочных устройств и убеждаемся, что их скорость чтения соответствует классу устройства. Для проверки SMART используем самописную утилиту на Python в сочетании с базой данных граничных значений. Выход за пределы значений вызывает автоматический вывод сервера из эксплуатации и его передачу на диагностику.

Дальше стресс-тест. В течение двух часов нагружаем CPU, RAM, GPU и смотрим, чтобы не было ошибок и троттлинга. Для стресс-тестов мы используем утилиту stress-ng.

Завершают цикл приемочные тесты (перед передачей сервера новому клиенту). Здесь также проверяем комплектацию сервера и SMART-параметры дисков.

Еще немного граблей, на которые мы наступили

Отсутствие логов

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

Параметры ядра вроде debug и loglevel=7 не помогали. Через какое-то время мы догадались, в чем проблема, и решили ее добавлением параметра ядра console=tty0.

Проблема с тестами автоустановки Ubuntu 22.04

Вторая проблема была связана с тестами автоустановки Ubuntu 22.04. Нужно было быстро проверить, что сетевая установка будет работать. Но, поскольку Ubuntu перешел с использования debian-installer к subiquity, legacy-installer больше недоступен.

Мы попытались обмануть систему, вытащив необходимые файлы из установочного образа, и встретились с интересной проблемой — iPXE зависало при попытке загрузить initramfs. Оказалось, что initrd сжат с использованием Zstandart, который iPXE, судя по всему, не поддерживает. Примечательно, что версия для x86_64 не использует Zstandart.

Позже мы выяснили несколько вещей:

• установщику в любом случае необходимо выкачивать весь ISO для корректной работы,
• файлы preseed больше не поддерживаются, и необходимо использовать cloud-init/autoinstall.

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

Плавающие проблемы с дисками

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

Заключение

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

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

Был ли у вас опыт работы с ARM-процессорами? Делитесь в комментариях!

Возможно, эти тексты тоже вас заинтересуют:

Источник