Вибір ядра для завантаження у консолі U-Boot через віддалене підключення
Що завалилося?
u-boot-kernel-select.png
Є один маленький CubieBoard2 поруч із маленьким роутером.
Фізичного доступу до них немає.
У роутер, під керуванням LEDE, підключено USB-UART, піни якого підключені до CubieBoard2.
І роутер, і CubieBoard2 доступні через ssh.
Саме наявність UART у збірці і дозволило підняти завалений CubieBoard2 віддалено.
Як завалилося?
Одного разу прилітає штатне оновлення ядра дебіана
linux-image-4.9.0-8-armmp-lpae.
Після оновлення система перестає виходити зв’язок.
Як це зазвичай роблять?
Тут все просто, витягуєш microsd картку, ну а далі можна не описувати.
UART, настав твій час!
Заходимо на роутер, підключаємось до USB-UART screen /dev/ttyUSB0 115200
Частина лога звичайного завантаження ядра.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 | ... 2 USB Device(s) found Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Found U-Boot script /boot/boot.scr 2471 bytes read in 169 ms (13.7 KiB/s) ## Executing script at 43100000 Mainline u-boot / new-style environment detected. 4391424 bytes read in 570 ms (7.3 MiB/s) 26547 bytes read in 347 ms (74.2 KiB/s) 18629865 bytes read in 1423 ms (12.5 MiB/s) Booting Debian 4.19.0-0.bpo.10-armmp-lpae from mmc 0:1... ## Flattened Device Tree blob at 43000000 Booting using the fdt blob at 0x43000000 Loading Ramdisk to 48e3b000, end 49fff4e9 ... OK Loading Device Tree to 48e31000, end 48e3a7b2 ... OK Starting kernel ... root: recovering journal root: clean, 102306/610800 files, 873002/2441216 blocks ... |
Дивимося процес завантаження з /boot/boot.scr, знаходимо наступне:
1 2 3 4 5 6 7 8 9 10 11 | for pathprefix in ${image_locations} do if test -e ${device} ${partition} ${pathprefix}vmlinuz-${fk_kvers} then load ${device} ${partition} ${kernel_addr_r} ${pathprefix}vmlinuz-${fk_kvers} \ && load ${device} ${partition} ${fdt_addr_r} ${pathprefix}${fdtpath} \ && load ${device} ${partition} ${ramdisk_addr_r} ${pathprefix}initrd.img-${fk_kvers} \ && echo "Booting Debian ${fk_kvers} from ${device} ${partition}..." \ && bootz ${kernel_addr_r} ${ramdisk_addr_r}:${filesize} ${fdt_addr_r} fi done |
безпосередньо зі змінними:
1 2 3 4 5 | load mmc 0:1 0x42000000 /boot/vmlinuz-4.9.0-8-armmp-lpae load mmc 0:1 0x43000000 /boot/dtb-4.9.0-8-armmp-lpae load mmc 0:1 0x44300000 /boot/initrd.img-4.9.0-8-armmp-lpae echo "Booting Debian 4.9.0-8-armmp-lpae from mmc 0:1..." bootz 0x42000000 0x44300000:${filesize} 0x43000000 |
У разі завантаження зламаного ядра ви залишаєтесь в initrd навіки.
Перезавантажуємо, чекаємо на рядок Hit any key to stop autoboot, натискаємо будь-яку клавішу і залишаємось у консолі U-Boot.
Підказка: в U-Boot є команда help.
Вводимо команди вручну, змінивши імена файлів на попереднє робоче ядро:
1 2 3 4 5 | load mmc 0:1 0x42000000 /boot/vmlinuz-4.9.0-7-armmp-lpae load mmc 0:1 0x43000000 /boot/dtb-4.9.0-7-armmp-lpae load mmc 0:1 0x44300000 /boot/initrd.img-4.9.0-7-armmp-lpae echo "Booting Debian 4.9.0-7-armmp-lpae from mmc 0:1..." bootz 0x42000000 0x44300000:${filesize} 0x43000000 |
Starting kernel ...
Оригінальний пост на SecOps.it Blog • Вибір ядра для завантаження у консолі U-Boot через віддалене підключення