Запис образу операційної системи під Linux

Ми можемо використати або програму з графічним інтерфейсом (наприклад, balenaEtcher), або звичайну команду dd. BalenaEtcher у мене не спрацював, тому розповім, як використати dd.

Спершу потрібно визначити, який пристрій відповідає за потрібну картку. Раджу бути обережним, оскільки якщо ви виберете не той блочний пристрій, то команди запису можуть легко зіпсувати важливу інформацію на жорсткому диску. Перегляньте всі блочні пристрої:

$ lsblk 

NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS

sda           8:0    1     0B  0 disk 

sdb           8:16   1  58.2G  0 disk 

└─sdb1        8:17   1  58.2G  0 part 

Ось вона - /dev/sdb, картка на 64 Gb.

Запис

Для запису використовуємо dd, але послідовність команд може змінюватися залежно від того, який у вас образ: стиснутий чи розпакований, а також від формату архіву. Orange часто використовує 7zip у своїх збірках, а Armbian - xz.

sudo dd if=Armbian.img of=/dev/sdb bs=4M status=progress oflag=direct

xzcat Armbian.img.xz | sudo dd of=/dev/sdb bs=4M status=progress oflag=direct

7z x -so Orangepi.7z | sudo dd of=/dev/sdb bs=4M status=progress oflag=direct

Зазвичай у Linux існує буфер запису для блочних пристроїв: спочатку дані записуються в пам’ять, а вже потім ядро виконує реальний запис на пристрій. Коли цей процес завершиться, наперед невідомо. Єдиний спосіб забезпечити запис — викликати команду sync, щоб примусово скинути кеш на пристрій. Однак така поведінка нам не підходить, тому що потрібно, щоб dd записував дані безпосередньо на пристрій. Для цього використовується опція oflag=direct.

Верифікація запису

Звісно, цей етап можна пропустити, але я б не радив цього робити. Нещодавно я витратив чимало часу, намагаючись зрозуміти, чому Orange Pi 5 не подавав жодних ознак життя. Як виявилося, я зібрав цілий "букет" помилок:

• Зношена microSD-картка, через що частина блоків була записана з помилками.

• Проблеми з роботою програмного забезпечення, таких як balenaEtcher і Ubuntu Startup Disk.

• Глюки USB 3.0: microSD-рідер, сумісний з USB 3.0, записував дані з помилками, коли його під'єднували до порту USB 3.0.

Отже, щоб уникнути подібних проблем, краще після запису перевірити, що саме записано на картці.

Розгляну 2 методи як перевірити дані.

Побайтове порівняння

Перше, що потрібно зробити, — це дізнатися, скільки місця займає образ. Якщо у нас нестиснений образ, то все просто: достатньо подивитися розмір файлу.

Для архівів у форматах 7z і xz можна скористатися наступними командами, щоб визначити розмір образу в архіві:

xz --robot --list Armbian.img.xz

7z l Orangepi.7z

Коли ми дізналися розмір, можна запустити команду cmp для порівняння образів. Ось декілька можливих варіантів перевірки:

cmp -n 1258291200 Armbian.img <(sudo dd if=/dev/sdb bs=1M) ## нестиснений образ

cmp -n 1258291200 <(xzcat Armbian.img.xz) <(sudo dd if=/dev/sdb bs=1M) 

cmp -n 1258291200 <(7z x -so Orangepi.7z) <(sudo dd if=/dev/sdb bs=1M) 

Якщо все збігається, команда cmp завершить виконання без будь-яких повідомлень. У разі помилок вона виведе відповідне повідомлення в консоль, наприклад:

cmp: EOF on /dev/fd/62 after byte 1258291200, in line 8093713

Перевірка контрольної суми

Є й інший спосіб — перевірка контрольної суми запису. Він має перевагу, оскільки не вимагає повторного читання первинного образу, що може заощадити час на великих файлах.

Якщо контрольна сума відсутня, її можна один раз обчислити та зберегти поруч із образом. Ось приклади команд для цього:

sha256sum Armbian.img > Armbian.img.sha256 ## нестиснений образ

xzcat Armbian.img.xz | sha256sum > Armbian.img.sha256

7z x -so Orangepi.7z | sha256sum > Orangepi.img.sha256

А тепер найважливіше — обчислимо контрольну суму записаних даних на SD-картці. Для цього нам потрібно знати розмір оригінального образу. Якщо зчитати навіть на один байт більше чи менше, контрольна сума не збігатиметься.

Приклад: мій образ займає 1,258,291,200 байт, що відповідає:
1,258,291,200 / 1024 / 1024 = 1200 блоків розміром 1М.

Запускаємо команду:

sudo dd if=/dev/sdb bs=1M count=1200 | sha256sum

Після виконання порівнюємо отримані результати. Якщо контрольна сума не співпадає з оригіналом, шукаємо причину: це може бути проблемна картка, рідер або навіть комп'ютер :)