Добрый день!
Если есть возможность, поделитесь логами
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 тому назад хеш разочек не совпал.
Я привел всего лишь алгоритм аварийного спасения контроллера, который после кривого апгрейда заперся изнутри. Не более.
Да, один из возможных способов, конечно. Но обычно проще (при наличии бэкапов) восстановить.
Ну, “если что-то пошло не так” - всегда можно загрузить fit. Ну для этого, конечно нужно иметь у контроллера флешку. Но вообще на удаленном контроллере полезно работать в screen, чтобы даже при пропадании-восстановлении связи запущенное не свалилось.
Почитайте начало ветки. Не всегда, увы.
Эта тема была автоматически закрыта через 7 дней после последнего ответа. В ней больше нельзя отвечать.