Добрый день.
Если между первым вызовом apt update && apt dist-upgrade и вторым перегрузить контроллер, то система сносит следующие пакеты: e2fsprogs-l10n libcom-err2 libext2fs2
Приходится очень сильно выворачиваться через одно место, чтобы вытащить и поставить их обратно, ибо без них даже ssh не запускается.
Второй раз подряд наткнулся, в первый чуть не спятил.
Если я сейчас выйду из шелла, потеряю контроллер, придется ехать с новым.
При попытке вернуть пакеты:
The following packages have unmet dependencies:
libext2fs2 : Breaks: e2fslibs (< 1.43.9-1~)
E: Unable to correct problems, you have held broken packages.
Все, отвалился.
90км туда, 90 обратно.
Так… С какой версии (дата выпуска образа на какую) обновляемся?
Какая изначально стояла на 6.7.2? Не догадался проверить, попытаюсь позднее поднять лог, но, опасаюсь, придется подниматься с загрузочного образа. Пинга нет.
На текущую 2108.
Добрый день!
Если есть возможность, поделитесь логами
tar cvfz logs.tgz /var/log/apt/ /var/log/dpkg*
Нету. Везу на базу. 
С другого попробую взять, где руками их обратно поставил. Боюсь ребутать.
Логи прикладываю.
На том контроллере стоял syslog-ng, экспериментировал с логами на сервере. Думал, поломалось поэтому, но - увы. Второй запорол идентично. Партия одна и та же.
apt-logs.tar.gz (50 КБ)
А нет ли в общем доступе спасательного образа корневой ФС?
Чтоб не сносить всё под пень, а загрузиться с нее и спокойно прибить косяк.
Думаю, будет небесполезно.
Upd. Попытался сказать юбуту грузить корневую со свистка. Никак не могу успеть!!! Собака срабатывает прежде.
Нехорошо.
Психанул, скачал fit для перепрошивки. Хрен.
С тремя разными накопителями трех разных фирм - EHCI timed out on TD - token=0x80008c80
Выдает фреймочку из звездочек, чтоб я нажал FW, нажимаю, висит минут пять с мигающим желтым, перезагружается (по собаке?) и так по кругу.
Косяк…
И, наконец.
env set mmcargs setenv optargs ${optargs} root=/dev/sda1 rootwait ro; run setbootargs
Похоже, в ядре нет драйвера USB storage, он подтягивается позднее модулем, так, что ли?
[ 1.880742] VFS: Cannot open root device "(null)" or unknown-block(0,0): error -6
[ 1.888342] Please append a correct "root=" boot option; here are the available partitions:
[ 1.896747] 0100 65536 ram0 [ 1.900329] (driver?)
[ 1.902701] 0101 65536 ram1 [ 1.906317] (driver?)
[ 1.908693] 0102 65536 ram2 [ 1.912270] (driver?)
[ 1.914668] 0103 65536 ram3 [ 1.918246] (driver?)
[ 1.920617] 0104 65536 ram4 [ 1.924239] (driver?)
[ 1.926619] 0105 65536 ram5 [ 1.930196] (driver?)
[ 1.932567] 0106 65536 ram6 [ 1.936178] (driver?)
[ 1.938553] 0107 65536 ram7 [ 1.942129] (driver?)
[ 1.944523] 0108 65536 ram8 [ 1.948102] (driver?)
[ 1.950474] 0109 65536 ram9 [ 1.954071] (driver?)
[ 1.956443] 010a 65536 ram10 [ 1.960106] (driver?)
[ 1.962477] 010b 65536 ram11 [ 1.966167] (driver?)
[ 1.968541] 010c 65536 ram12 [ 1.972204] (driver?)
[ 1.974598] 010d 65536 ram13 [ 1.978263] (driver?)
[ 1.980635] 010e 65536 ram14 [ 1.984321] (driver?)
[ 1.986695] 010f 65536 ram15 [ 1.990359] (driver?)
[ 1.992736] b300 7438336 mmcblk0 [ 1.996597] driver: mmcblk
[ 1.999404] b301 16384 mmcblk0p1 883edd45-01[ 2.004569]
[ 2.006076] b302 1048576 mmcblk0p2 883edd45-02[ 2.011216]
[ 2.012718] b303 1048576 mmcblk0p3 883edd45-03[ 2.017880]
[ 2.019386] b304 1 mmcblk0p4 [ 2.023569]
[ 2.025097] b305 262144 mmcblk0p5 883edd45-05[ 2.030237]
[ 2.031740] b306 5059584 mmcblk0p6 883edd45-06[ 2.036899]
[ 2.038407] b318 4096 mmcblk0rpmb [ 2.042593] (driver?)
[ 2.044985] b310 16384 mmcblk0boot1 [ 2.049258] (driver?)
[ 2.051629] b308 16384 mmcblk0boot0 [ 2.055920] (driver?)
[ 2.058292] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
Так.
Будучи профессиональным сисадминщиком, я ТРИ часа убил на восстановление загрузки. Не считая двух поездок слесаря по 90км и двух почти суток ebookов от клиента.
НЕ ДЕЛАЙТЕ, КАК Я. Делайте так:
- перед любым апгрейдом обязательно вынимайте контроллеры и везите их к компу. Бекапный прибор должен быть под рукой и должен быть сконфигурирован под узел, чтобы за 10 минут воткнуть его вместо поцыэнта.
- ВСЕГДА перед апгрейдом бекапьте корневую ФС! Вероятно, для этого и зарезервирован пустой раздел 3:
apt install rsync
mkdir /mnt/p3
mount /dev/mmcblk0p3 /mnt/p3
rsync -avxHAXW --progress / /mnt/p3/
umount /mnt/p3
- Если апгрейд заехал не туда, наверняка контроллер больше сам не загрузится, будет крутиться в бутлупе, который прервать нельзя. Посему -
- ПЕРЕД ребутом проверьте критическое:
fsck /dev/mmcblk0p3
mc
Если что-либо из этого не работает, стоит СРАЗУ скопировать улетевшие библиотеки из lib в бекапе в lib на корне.
5) Если таки перезагрузка случилась, готовьте microusb шнурок, драйвер порта и мешок чая/кофе и сухарей.
6) В консоли прервите загрузку, когда она говорит press a key to stop autoboot.
7) Если вы не успели (как я сейчас) сбекапить корень, то загрузитесь в однопользовательском режиме. Для этого скажите
env edit mmcargs
В предложенной к редактированию строке добавьте single, примерно вот так:
mmcargs=setenv optargs ${optargs} root=/dev/mmcblk${mmcdev}p${mmcpart} rootwait ro single; run setbootargs
Загрузившись, суньте флешку со скопированной с другого контроллера корневой ФС и скопируйте недостающие файлы на место. В отличие от странного uboot, ядро кушает любой исправный свисток.
- Если успели, - всё чуть проще, вам достаточно указать root=/dev/mmcblk0p3 вместо p2, и загрузка пройдет с альтернативного раздела, контроллер будет рабочим (ну, в зависимости от свежести бекапа) и вы сможете неспешно починить содержимое основной ФС.
Прошу включить это (вычесав эмоции) в доку по апгрейду ПЕРВЫМ пунктом. Спасибо.
1 лайк
Еще нюанс есть:
Для того чтобы контроллер автоматически грузился c резервного раздела надо отключить отключение в /etc/init.d/wb-init
fw_setenv upgrade_available 0
выполнить
fw_setenv upgrade_available 1
Тогда механизм Обновление прошивки, информация для разработчиков — Wiren Board
будет работать при неудачной загрузке.
Третий раздел был пуст, есличо.
Добрый день!
Советы вредные. Бекапы всей системы, грузиться с свистка, бороться с аппаратным вотчдогом - не нужно это всё делать. Даже если вы понимаете, что делаете - всё равно не нужно.
Про e2fsprogs сотоварищи при обновлении - попытаемся это исправить, спасибо за логи dmesg и apt. Мы видели такое уже один раз, но никак не можем воспроизвести, хотя у нас всё тестируется на обновление даже со старых релизов.
Про звёздочки и флешки я так ничего и не смог понять. Загрузка линукса с флешки после нажатия на кнопку начинается, но контроллер перезагружается? К чему тогда относятся сообщения про EHCI token error и про три перепробованные флешки?
Поскольку альтернативы нет, - нужно, увы.
Флешки ваш бутлодер не ест ни Трансенд, ни Самсунь, ни Нонейм. Прервать бутлуп, подсунув ФС на свистке, тоже не получается: до драйвера usb-storage дело не доходит.
Да, он выдает сообщение в звездочках, что нашел образ, но сразу после этого наглухо виснет до собаки.
Вредные или нет, делать в условиях чрезвычайно разборчивого бутлодера и ОЧЕНЬ странно собранного ядра (масса бубенчиков, а нужного нету) что-то надо.
я всё ещё ничего не понимаю. Что значит “флешки не ест”? Приложите пожалуйста полный лог из отладочной консоли, так будет гораздо проще.
Вы кстати флешку руфусом форматировали, как в документации описано?
Не судьба. Он умер окончательно в тот же вечер, см. ветку про батарейку. Если каким-то чудом поднимете som (отправляю прибор на замену), можете исследовать неспешно.
Это что-то под уындоус? Пардон, не юзаю с 2002. Обычный fat32/mbr. Пробовал и GPT, изофаллично.
Uboot сперва ругался на таймаут EHCI, потом таки находил файл апдейта (что загадочно), выдавал об этом сообщение и уже после вис наглухо. Надо подтаскивать версию посвежее, там эту проблему прибили уже.
Вообще просто создаю раздел типа “b” с помощью fdisk и mkfs.vfat его.
Rufus - конечно под linux не нужен.
А вот если “виснет” - надо сам файл проверить. Вот тут было аналогичное:
И действительно, md5 не сходился.
Теоретически так быть могло, не спорю: лет 15 тому назад хеш разочек не совпал.
Я привел всего лишь алгоритм аварийного спасения контроллера, который после кривого апгрейда заперся изнутри. Не более.