Выбор загружаемого ядра в консоли 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 через удалённое подключение