Загрузка Banana PI M1 с жесткого диска

by Anton Chernousov aka GITA-DEV


Опубликовано: 05 Сен 2018 (последние правки 1 месяц, 1 неделя)


Загрузка Banana PI M1 с жесткого диска

Я скажем так немного слукавил и аппаратные особенности не позволят вам полноценно загрузить одноплатный ПК на базе ARM-платформы BananaPI с жесткого диска и ядро системы придется все же запускать с SD-карты, но корневой раздел системы мы можем перенести на жесткий диск и сделать это довольно просто.

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

В моем случае структура разделов выглядит следующим образом:

# fdisk -l
Disk /dev/sda: 1.8 TiB, 2000398934016 bytes, 3907029168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/mmcblk0: 7.2 GiB, 7744782336 bytes, 15126528 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x000ebf83

Device        Boot Start    End Sectors Size Id Type
/dev/mmcblk0p1 *   204800 729087 524288 256M c W95 FAT32 (LBA)
/dev/mmcblk0p2     729088 3071999 2342912 1.1G 83 Linux

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

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

# fdisk -l
Disk /dev/sda: 1.8 TiB, 2000398934016 bytes, 3907029168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xc24e99a9

Device    Boot  Start       End   Sectors Size Id Type
/dev/sda1         2048   4196351   4194304   2G 83 Linux
/dev/sda2      4196352 3907029167 3902832816 1.8T 83 Linux

Теперь создадим один корневой раздел и файл подкачки:

# mkswap /dev/sda1
# mkfs.ext4 /dev/sda2

Копируем реальную систему на sda2 раздел жесткого диска:

# mkdir /tmp/source
# mkdir /tmp/dest
# mount /dev/mmcblk0p2 /tmp/source/
# mount /dev/sda2 /tmp/dest/
# aptitude install rsync
# rsync -av --numeric-ids /tmp/source/ /tmp/dest/

Настраиваем монтирование при старте системы, для чего приводим /etc/fstab в соответствие:

proc           /proc          proc   defaults         0      0
/dev/mmcblk0p1 /boot          vfat   defaults         0      2
UUID=a9ff356f-adf1-47d1-a2cc-68106663ef39 / ext4 defaults,noatime,nodiratime,commit=600,errors=remount-ro 0 1
UUID=da886a46-3790-4cb1-8dfa-67239b5d086e none           swap   sw             0      0
tmpfs /tmp tmpfs defaults,nosuid 0 0

UUID-накопителей мы узнали командой blkid:

# blkid 
/dev/sda1: UUID="da886a46-3790-4cb1-8dfa-67239b5d086e" TYPE="swap" PARTUUID="c24e99a9-01"
/dev/sda2: UUID="a9ff356f-adf1-47d1-a2cc-68106663ef39" TYPE="ext4" PARTUUID="c24e99a9-02"
/dev/mmcblk0p1: SEC_TYPE="msdos" LABEL="BPI-BOOT" UUID="38E6-87AA" TYPE="vfat" PARTUUID="000ebf83-01"
/dev/mmcblk0p2: LABEL="BPI-ROOT" UUID="dcfd5d56-5efb-401e-a3d8-b5494ece78f5" TYPE="ext4" PARTUUID="000ebf83-02"
/dev/mmcblk0: PTUUID="000ebf83" PTTYPE="dos"

А вот теперь, самое интересное и если вы перезагрузите систему, то увидите, что корневой раздел указывает на SD-карту, а fstab в плане корня просто проигнорирован. За монтирования корня ядром на ARM-платформе отвечает другой механизм и именно его мы сейчас и изменим, но сначала монтируем boot-раздел:

# mount /dev/mmcblk0p1 /boot/

И уже теперь редактируем файл:

/boot/bananapi/bpi-m1/linux/boot.cmd

Меняем строку:

setenv bootargs "console=ttyS0,115200 console=tty1 board=${board} root=/dev/mmcblk0p2 rootwait rootfstype=ext4 cgroup_enable=memory swapaccount=1 hdmi.audio=EDID:0 disp.screen0_output_mode=1280x720p60 panic=10 consoleblank=0 enforcing=0 loglevel=${verbosity}"

На:

setenv bootargs "console=ttyS0,115200 console=tty1 board=${board} root=/dev/sda2 rootwait rootfstype=ext4 cgroup_enable=memory swapaccount=1 hdmi.audio=EDID:0 disp.screen0_output_mode=1280x720p60 panic=10 consoleblank=0 enforcing=0 loglevel=${verbosity}"

И компилируем cmd в scr:

# mkimage -C none -A arm -T script -d boot.cmd boot.scr

Потребуется пакет:

# aptitude install u-boot-tools

Перезагружаем и проверяем схему монтирования:

# mount
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,relatime)
udev on /dev type devtmpfs (rw,nosuid,relatime,size=444888k,nr_inodes=111222,mode=755)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=89388k,mode=755)
/dev/sda2 on / type ext4 (rw,noatime,nodiratime,errors=remount-ro,commit=600,data=ordered)
....

И доступное дисковое пространство:

# df -h
Filesystem     Size Used Avail Use% Mounted on
udev           435M    0 435M  0% /dev
tmpfs           88M 2.6M  85M  3% /run
/dev/sda2      1.8T 1.3G 1.7T  1% /
tmpfs          437M    0 437M  0% /dev/shm
tmpfs          5.0M    0 5.0M  0% /run/lock
tmpfs          437M    0 437M  0% /sys/fs/cgroup
tmpfs          437M    0 437M  0% /tmp

Напоследок можем добавить в fstab раздел подкачки и boot-раздел.


Обратите внимание на статьи:


Установка GITLAB на ARM-платформу (BananaPI M2)

Установка GITLAB на ARM-платформу (BananaPI M2)

В процессе эксплуатации GIT-хранилища RhodeCode я пришел к мнению, что надо с него мигрировать и благо, что я на него не сильно пока залез. Главная причина по которой я решил с него мигрировать, это его прожорливость и если на одной из клиентских платформ с выделенным сервером он вполне себе прижился, то на моем небольшом VPS он потребляет катастрофически много ресурсов и периодически по этому поводу залезает в swap, после чего скорость его работы падает на столько, что остается только материться. Сегодня будем пробовать не менее прожорливого монстрика GITLAB, но устанавливать его будем на наше файловое хранилище которое как наверное помните по моим предыдущим заметкам построено на ARM-платформе BabanaPI M2.


Nextcloud-сервер на базе одноплатного ПК BananaPi

Nextcloud-сервер на базе одноплатного ПК BananaPi

Представляю вашему вниманию продолжение статьи - Установка облачного хранилища NextCloud в окружение Nginx+PHP-FPM и сегодня я настрою облачное хранилище на домашнем микро-пк на базе ARM-системы Banana PI. Фактически это доработка статьи про настройке Banana PI для платформы x86 под архитектуру ARM.


Тестирование среднего тока работы HDD-накопителей (подключение HDD для Babana PI M1)

Тестирование среднего тока работы HDD-накопителей (подключение HDD для Babana PI M1)

Как все инженеры, я предварительно прочитал спецификацию на накопитель который хотел использовать в своем проекте и там был указан максимальный потребляемый ток по шине 12 вольт равный 0.4 ампера и я кстати был совершенно не удивлен когда у меня на лабораторном блоке питания с выставленным током защиты в 1А защита таки сработала. Ну, что сказать, это маркетинг и лучше провести реальные замеры прежде чем что-то проектировать, поэтому делюсь своими наблюдениями проведенными с рядом накопителей.


Есть вопросы?
Спрашивайте и я обязательно вам отвечу!

* Поля обязательные для заполнения .

Блог это некоммерческий проект! Если вам понравился мой блог и то что я пишу помогло вам на практике, то можете сказать спасибо материально.