Платы Raspberry Pi давно научились грузиться не только с карты памяти, и переход на eMMC становится разумным решением там, где устройство должно работать годами без снятия носителя. Впаянный накопитель заметно надёжнее карты: выше запас циклов записи, нет ручки для вытаскивания, нет скачков контактов в трясущемся корпусе. Но пересадка привычной процедуры прошивки на новый носитель спотыкается об один важный момент: без карты памяти записать образ напрямую невозможно, и приходится либо подключаться по USB в служебном режиме, либо переносить работающую систему с уже существующей карты. Разберём оба пути шаг за шагом, с командами, порядком действий и типовыми ошибками.
Почему eMMC и зачем переходить с карты памяти
Карта памяти в серийном устройстве это самая слабая деталь. Её дёшево менять, но она изнашивается от журналов и временных файлов, неудобна в корпусе и легко вылетает при вибрации или при ударе. eMMC впаяна на плату, рассчитана на больший ресурс и воспринимается системой как обычный блочный диск. Скорость последовательных операций заметно выше, чем у средней карты, и стабильнее хвосты задержек, что сказывается на обновлениях системы. Переход оправдан там, где плата работает автономно: счётчики, датчики, точки вещания, промышленные приставки.
Отдельный плюс это цепочка загрузки. eMMC умеет аппаратные загрузочные разделы, которые стартуют без участия операционной системы, и режим стирания в одной транзакции. С точки зрения программного проекта eMMC просто выглядит как диск с именем mmcblk1 или mmcblk0, в зависимости от того, куда смотрит контроллер первым. Именно поэтому при переносе системы важно не перепутать источник и назначение: оба устройства находятся под рукой с похожими именами и снаружи выглядят одинаково.
Два пути установки и выбор по оборудованию
Для платы без слота карты памяти существует режим загрузки по USB, когда микросхема eMMC предъявляется компьютеру как накопитель, и образ записывается напрямую, как на флешку. Это самый чистый маршрут и единственный для плат, у которых слот карты отсутствует вовсе. Для старших плат с картой и eMMC вместе логичнее переносить систему с уже обжитой карты: все настройки сети, учётные записи и приложения поедут на новый носитель без повторной настройки.
Выбор маршрута выполняется по ситуации. Для серии плат в цеху правильнее прямая запись по USB: образ производится на компьютере из файла, процесс повторяем и не зависит от качества карт памяти. Для единичной машины, где система уже доведена до рабочего состояния, перенос с карты дешевле и занимает считанные минуты.
Перед началом нужны два предмета. Первый это компьютер на Linux с утилитами записи образов. Второй это образ системы в официальном формате для конкретной серии плат, потому что образы разных серий различаются загрузчиком и набором драйверов, и пропуск этого шага оборачивается загадочным рабочим столом на взгляд вроде бы рабочей платы.
Загрузка по USB и прямая запись на eMMC плату
Прямая запись начинается с перевода модуля в служебное состояние: на несущей плате выставляется перемычка, запрещающая старт с eMMC, и плата подключается к компьютеру USB-кабелем. После включения запускается утилита загрузчика, которая заливает в плату маленький стартовый загрузчик и заставляет весь чип eMMC показаться в системе как диск:
sudo apt install git libusb-1.0-0-dev
git clone --depth=1 https://github.com/raspberrypi/usbboot
cd usbboot
make
sudo ./rpibootДалее в системе появляется новый блочный диск, и на него пишется образ обычных релизов. Самый надёжный способ это записать образ командой dd с явной индикацией прогресса:
lsblk
sudo dd if=raspios-bookworm-arm64-lite.img of=/dev/sda bs=4M status=progress
syncПервой проверкой всегда служит список дисков: источник это файл образа, назначение это новый диск, появившийся после запуска служебного загрузчика. После записи плата отключается от USB, перемычка снимается, и первый старт начинается как обычно. Загрузчик платы прочитает boot-раздел и передаст выполнение ядру, точно так же, как если бы система писалась на карту памяти.
Дисциплина процесса простая и строгая: плата в режим записи, образ на диск, проверка первого старта, перемычка снята. Пропуск последнего шага это классическая причина, по которой новая плата кажется неработающей: bootloader платы зависает в режиме хоста до тех пор, пока перемычка на месте, и система не поднимается, потому что и не должна.
Перенос работающей системы с карты на eMMC
Для старших плат с двумя носителями переезд выполняется из живой системы. Сначала загружаемся с карты, подключаем eMMC и выясняем, как система видит оба устройства: обычно карта живёт на mmcblk0, а eMMC на mmcblk1. После этого копируем содержимое с учётом разделов и правим привязки:
- разметить eMMC по той же схеме, что и карту: отдельный загрузочный раздел FAT и корневой ext4;
- скопировать содержимое разделов на новый диск командой rsync с сохранением прав и атрибутов;
- выяснить свежие идентификаторы разделов через blkid и подставить их в cmdline.txt и fstab на eMMC;
- убедиться, что загрузчик видит оба носителя и приоритет установлен на eMMC;
- выключить плату, вынуть карту и загрузиться с eMMC.
Копирование выполняется в таком виде:
sudo mount /dev/mmcblk1p2 /mnt
sudo rsync -aAXH / /mnt/
sudo mount /dev/mmcblk1p1 /mnt/boot/firmware
sudo rsync -aAXH /boot/firmware/ /mnt/boot/firmware/Обособленный момент это идентификаторы: прямое указание PARTUUID играет лучше смены носителей, потому что буквы дисков меняются при подключении. Если вместо разделов используются условные метки, никакой правки конфигурации вообще не потребуется. Но старые образы пишут значения жёстко, и проще два раза проверить командную строку ядра, чем вечер разбираться, почему новый носитель не монтируется.
Что выбрать между eMMC, NVMe и картой памяти
Для модулей с впаянным носителем выбор стоит один раз на годы, и неправильное решение ощущается каждый день эксплуатации. Карта памяти удобна как средство разработки и ремонта, но из года в год лидирует по отказам из-за механики и ресурса записи. eMMC стоит дороже, зато решает обе проблемы: впаяна и рассчитана на большее число циклов. Третий вариант это NVMe через адаптер: у части плат есть канал PCI Express, и подключение приносит скорость с полноценным контроллером, но стоит заметно дороже и зависит от качества адаптера и охлаждения.
Сравнение выходит аккуратным: карта для лабораторий и пробных образов, eMMC для серийных устройств со стандартной нагрузкой, NVMe только там, где производительность измеряется в рабочих показателях и важна, а не выглядит красивой строкой в прайсе. Отдельный пункт это обновление в поле: eMMC перезаписывается без снятия с платы при заранее предусмотренных инструментах, тогда как NVMe на бюджетных адаптерах любит сюрпризы с питанием при старте.
Когда плата уходит к заказчику, файл образа становится частью продукта: его происхождение подтверждается контрольной суммой и подписью, иначе ровно через год будет невозможно выяснить, откуда взялся текущий корень. Рабочий порядок простой: каждый образ формируется одним сборочным заданием на чистой машине, к нему прилагается файл со списком версий ядра, загрузчика и основных служб, а в каталоге публикации хранятся не только последние выпуски, но и предыдущие, чтобы откат выполнялся столь же подписанным образом.
Дальше остаётся согласовать доступы: где лежат образы, кто публикует новые, кто контролирует подпись. Для плат с раздельными загрузочным и корневым разделами естественно получаются две половинки: boot-раздел меняется редко и остаётся рабочим в откате, а корень пересоздаётся под каждый выпуск. Классные системы обновлений, основанные на двух разделах, при проблемном старте возвращаются к предыдущему разделу без перезаписи.
Подготовка образа к производству, подпись и учёт ревизий
Образ, развёрнутый на сто плат, должен вести себя как новый после записи, а не как копия тестовой системы. Прокручиваемый контент убирается намеренно: журналы обнуляются, временные каталоги очищаются, хранилище пакетов обновляется, а сам образ фиксируется в состоянии, где первый запуск машин стартует с чистой точки. Серийные образы отличаются от лабораторных тем, что в них нет следов предыдущей эксплуатации.
Отдельный момент это ключи терминальной службы и идентификаторы машин: копия, развёрнутая на ста платах, не должна предъявлять всем один и тот же набор ключей. Хороший механизм генерации новых ключей при первом запуске предусмотрен в составе системы и включается явно только для тиражирования. Аналогичная история с уникальными идентификаторами: специальных идентификаторов нужно стереть и сгенерировать заново при загрузке, иначе журналы ста плат будут писать об одном устройстве под одним именем.
Для производства образов выгодно держать отдельную базовую копию, в которую за больше года не пришло ни одного обновления, а все сборки логируются с датой и хешем изменений. Такая база экономит недели при возврате к старому образу: снять копию с карты образца на нужную дату можно только тогда, когда сам образец содержит пометку о версии в хранилище.
В любой более-менее серийной истории хранение образов выходит за пределы папки с файлами. Каждый выпуск получает имя с указанием числа и даты, а при входе в образ изменений фиксируется короткий список того, что поменялось с прошлого раза. Файлам проверки целостности хорошо заводить отдельный столбец рядом с самим образом: запись занимает секунды, а убирает вопросы о том, что именно было применено на конкретной плате.
Порядок хранения требует всего три правила. Первое: публикуемым считается только образ, прошедший запись и запуск тестового стенда. Второе: ранние версии не удаляются, пока стоят платы со старыми выпусками, потому что ровно они понадобятся при первом анализе отказа. Третье: набор шаблонов для проверки образа одинаковый для всех выпусков, и это позволяет оценивать новую сборку той же выборкой шагов, что и предыдущую. Тогда изменения между ревизиями видны в построчном отчёте, а не в разговорах о том, что, дескать, на прошлой неделе всё работало.
Свежие загрузчики плат умеют гибкий порядок старта: карта, USB, сеть и eMMC перечисляются по приоритетам, и выбор правится в конфигурации загрузчика. Для смешанных плат настройка решает, с чего грузиться по умолчанию, и версии загрузчика время от времени являются причиной неожиданного поведения, особенно когда в полевых условиях скапливаются платы разных поколений.
После переноса на eMMC порядок старта стоит обновить: система, умеющая и в карту и в eMMC, должна первым делом смотреть на eMMC, потому что карта отныне задумана только как способ аварийного восстановления. Правка выполняется через фирменную утилиту настройки или напрямую в конфигурации загрузчика, в зависимости от поколения платы. Проверка строится простым сравнением: снять питание, оставить одну eMMC, включить и убедиться, что система поднялась сама и полностью.
Настройки загрузчика и проверка после переезда
Проверка свежей установки занимает минуты при готовом списке: загрузчик видит плату на правильном носителе, горячие командные утилиты свидетельствуют о наличии системы, сеть получает адрес, ssh поднимается и диск показывает ровно то, что ожидалось. Отдельной строкой идёт порядок устройств: на смешанных платах важно убедиться, что система монтирует корень с eMMC, а не с карты, иначе поведение системы будет зависеть от того, какая карта попалась в руки в день перезагрузки.
Частые ошибки тоже знакомы. Модуль забывают перевести в режим записи, и образ на компьютере не появляется. Образ пишут не на то устройство, и вместо eMMC страдает рабочий диск. Загрузчик не обновлён под eMMC и зависает в попытке старта с удалённой карты. Все три ситуации лечатся повторным проходом по процедуре и через несколько плат перестают быть сюрпризом, а становятся строкой в чек-листе. А накопленная дисциплина возвращается итогом каждую неделю: очередная плата поднимается по привычному сценарию и без ручной работы.