Коротко — самая надёжная и самая простая схема на Radxa Pi 4A: оставить SD/микроSD как «boot device» (загрузчик + /boot), а корневую FS перенести на NVMe. Полная загрузка (SPL → U‑Boot → загрузка прямо с NVMe без SD) возможна, но требует именно того u‑boot/SPL, который умеет инициализировать NVMe на этапе SPL, и правильной записи loader‑ов в «правильные» области накопителя — это чаще всего менее тривиально и рискованно. Ниже — пошагово, как сделать правильно (вариант A — рекомендую), а также кратко про вариант B и отладку вашего текущего состояния (когда в UART виден только SPL).
Вариант A — оставить SD для загрузчика, перенести root на NVMe (рекомендуется)
1. Загрузитесь с SD (работающая система).
2. Подготовьте NVMe
- Разметьте NVMe как GPT, создайте один основной раздел для root (ext4) и, при желании, отдельный раздел для /var или т.д.
Пример:
- Проверка дисков: lsblk
- parted /dev/nvme0n1 mklabel gpt
- parted -a optimal /dev/nvme0n1 mkpart primary ext4 1MiB 100%
- Создайте файловую систему:
mkfs.ext4 -L rootfs /dev/nvme0n1p1
3. Смонтируйте и скопируйте систему (rsync — безопасно)
- Создайте точки монтирования и смонтируйте:
mkdir -p /mnt/nvme
mount /dev/nvme0n1p1 /mnt/nvme
- Скопируйте всё, кроме виртуальных файловых систем:
rsync -aAXx --exclude={"/dev/*","/proc/*","/sys/*","/tmp/*","/run/*","/mnt/*","/media/*","/lost+found"} / /mnt/nvme/
- Если у вас отдельный /boot на SD — его не обязательно копировать (если SD остаётся для загрузки). Если вы хотите, чтобы /boot тоже был на NVMe, скопируйте /boot и подправьте загрузчики (сложно — см. ниже).
4. Обновите fstab в скопированной системе
- Получите UUID нового раздела:
blkid /dev/nvme0n1p1
- В /mnt/nvme/etc/fstab замените строку для корня на:
UUID=<полученный‑UUID> / ext4 defaults,noatime 0 1
- Рекомендация: использовать UUID, а не /dev/nvme0n1p1, чтобы не зависеть от имён устройств.
5. Обновите dietpiEnv.txt / загрузочные аргументы
- Если у вас DietPi/Armbian использует dietpiEnv.txt или u‑boot env для root=/…, поменяйте там root=UUID=… или root=/dev/disk/by-uuid/… соответственно.
- Пример: в dietpiEnv.txt / uEnv.txt / extlinux.conf укажите root=UUID=<UUID> и, при необходимости, добавьте rootwait или rootdelay=5.
6. (Опционально) Пересоберите initramfs (если используется)
- Если ваше ядро использует initramfs и/или модуль NVMe загружается слишком поздно, пересоберите:
chroot /mnt/nvme /bin/bash
update-initramfs -u -k all
exit
- Часто на Armbian/DietPi это не требуется — ядро содержит nvme.
7. Тестирование
- Оставьте SD в слоте, перезагрузите. Посмотрите dmesg / journalctl — должен подключаться root с NVMe.
- Если система поднимается и root — NVMe, можно дальше пробовать вынуть SD (только если вы делаете полную NVMe‑загрузку корректно).
Вариант B — полная загрузка с NVMe (SPL → U‑Boot → NVMe)
- Требует, чтобы SPL (и u‑boot) умели инициализировать PCIe/NVMe и чтобы загрузочные бинарники (idbloader/uboot) были доступны там, откуда SPL ожидает их загрузить. На Radxa / Rockchip это не тривиально: часто SPL загружает следующий загрузчик из SPI-флеша, eMMC или SD; для NVMe нужно специальный u‑boot/spl или запись loader'ов в нужные смещения на накопителе.
- Действуйте только с официальной инструкцией Radxa/Armbian для вашей ревизии платы и версии прошивки. Неправильная запись loader'ов может сделать устройство не загружаемым без вмешательства и аппаратного восстановителя.
- Если хотите идти этим путём, ищите «Radxa Pi 4A NVMe boot» и следуйте инструкции производителя — обычно они дают скрипты/образы для обновления SPI/SPL/uboot.
Почему у вас сейчас в UART видно только «U-Boot SPL …» и дальше виснет
- Это классическая картина: SPL загрузился (из SPI/SD/eMMC), но не может найти/загрузить следующий этап (u‑boot proper) и зависает/не продолжает. Причины:
- Вы вынули SD, а SPL не умеет читать U‑Boot с NVMe (нет поддержки NVMe в SPL) → дальше ничего не загружается.
- На NVMe нет записанного u‑boot в том месте, откуда SPL ожидает его загрузить.
- или SPL ожидает другой тип таблицы/файловой системы/файла boot.scr и не находит его.
- Что сделать для диагностики:
- Вставьте SD обратно. Включите UART, посмотрите полный лог загрузки при нормальной загрузке — где SPL ломается/что он пытается загрузить дальше.
- На работающей системе выполните printenv (если доступна команда fw_printenv) или смотрите файл dietpiEnv.txt/boot.scr/extlinux.conf — какие пути и файлы использует SPL/u‑boot.
- Проверьте, видит ли U‑Boot NVMe: в работающей системе выполните dmesg | grep -i nvme и lsblk и убедитесь, что nvme0n1 отображается и ядро видит устройство.
- Если SPL не поддерживает NVMe — проще держать SD как загрузчик и root на NVMe.
Полезные команды (суммарно)
- Разметка и ФС:
parted -a optimal /dev/nvme0n1 mklabel gpt mkpart primary ext4 1MiB 100%
mkfs.ext4 -L rootfs /dev/nvme0n1p1
- Копирование:
mount /dev/nvme0n1p1 /mnt/nvme
rsync -aAXx --exclude={"/dev/*","/proc/*","/sys/*","/tmp/*","/run/*","/mnt/*","/media/*","/lost+found"} / /mnt/nvme/
- UUID:
blkid /dev/nvme0n1p1
- Обновление initramfs (если chroot нужен):
for k in /lib/modules/*/; do chroot /mnt/nvme update-initramfs -u -k $(basename $k); done
- Лог U‑Boot / диагностика:
- Смотрите UART-последовательность: если видите SPL и больше ничего — SPL не нашёл следующий загрузчик.
- Когда SD вставлен — сравните логи при загрузке с SD и без SD.
Резюме / совет
- Если цель — ускорение работы БД/GitLab — самый быстрый и безопасный путь: оставить SD как загрузчик, перенести root на NVMe через rsync, править /etc/fstab и dietpiEnv.txt на UUID и перезагрузиться с SD. Это даст полную производительность NVMe для корня и сервисов.
- Полный NVMe‑boot возможен, но требует корректного u‑boot/SPL с поддержкой NVMe и правильной записи loader'ов — следуйте официальным инструкциям Radxa/Armbian, иначе устройство может не загружаться.
- Если хотите, могу:
- дать конкретные команды под вашу текущую разметку (скачать выводы lsblk и blkid и я распишу точнее), или
- помочь диагностировать почему SPL не продолжает загрузку (покажите полный UART лог при загрузке с SD и без SD).