Всем привет.
Так получилось, что возникла необходимость в возвращении корневой ФС к первоначальному виду (в котором она поставлялась на плате).
Для этого перезгружаю плату, прерываю дальнейшую загрузку в U-boot (нажимаю любую клавишу) и выполняю команду run safe_boot.
Система загружается, после чего ввожу install_rootfs.
Сначала идет форматирование. Ну а далее...
Привожу кусок инфы из терминала:

Copy rootfs.tgz from 192.168.0.2 ...

rootfs.tgz 0% | | 0 --:--:-- ETA
rootfs.tgz 13% |**** | 2166k 00:00:06 ETA
rootfs.tgz 17% |***** | 2929k 00:00:09 ETA
rootfs.tgz 17% |***** | 2929k 00:00:13 ETA
rootfs.tgz 17% |***** | 2929k 00:00:18 ETA
rootfs.tgz 17% |***** | 2929k 00:00:23 ETA
rootfs.tgz 17% |***** | 2929k 00:00:27 ETA
rootfs.tgz 17% |***** | 2929k - stalled -
rootfs.tgz 17% |***** | 2929k - stalled -
rootfs.tgz 17% |***** | 2929k - stalled -
rootfs.tgz 17% |***** | 2929k - stalled -
rootfs.tgz 17% |***** | 2929k - stalled -
rootfs.tgz 17% |***** | 2929k - stalled -
rootfs.tgz 17% |***** | 2929k - stalled -
rootfs.tgz 17% |***** | 2929k - stalled -
rootfs.tgz 17% |***** | 2929k - stalled -

Вот на этом все и застопоривается... В терминал бесконечно сыплются сообщения, оканчивающиеся на - stalled -
Дальше не идет. Пробовал несколько раз, результат один и тот же.
Может, кто-нибудь подскажет, что мне делать в подобной ситуации? =)
Заранее спасибо

Ах да, совсем забыл упомянуть... Все операции произвожу с использованием виртуальной машины, которая шла на диске к плате. В каталоге /tftpboot ничего не менял. Ядро, ФС и-u-boot не пересобирал

плата сейчас не под рукой, проверьте "на всякий случай", что
- архив считывается без ошибок (всякое бывает)
- сравнить эти файлы (rootfs.tgz) /tftpboot и на прилагаемом диске в каталоге \SK-AT91SAM9G45\Images

гляньте, что делает скрипт install_rootfs, если есть возможность - пройдите "по шагам"

Спасибо за подсказку, хоть она и не понадобилась. Проблема разрешилась =)

Как оказывается, передача файлов по tftp (я имею в виду вирт. машину (ВМ) с Дебианом и плату) почему-то работает довольно странно и не всегда....

Например, у меня невозможно передать файлы с платы на ВМ. Однако они без особых проблем передаются хосту с Windows, где запущен tftpd32 (иногда возникают ошибки, но повторные передачи проходят нормально). Поэтому для передачи файлов с платы на ВМ приходится слать их сначала в Windows, а уж потом через tftpd32 - на ВМ.

Обмен файлами между ВМ и Windows проходит нормально.

Самое интересное, что файлы с ВМ на плату скачиваются =) Файл rootfs.tgz - первый файл, который не удалось загрузить...

Переустановка ВМ / перераспаковка ее жесткого диска с прилагаемого DVD - не помогают.

Весь в раздумьях, в общем =) Может, кто-нибудь сталкивался с подобной проблемой? Жизнь она осложняет несильно, но все-таки неприятно использовать Windows+tftpd32 в качестве "буфера" между ВМ и платой. Да и любопытно, в чем дело =)

хм.. интересный у вас эффект, даже не могу предположить природу возникновения..
проблема явно в вашем железе или софте, ибо Павел все отлаживает в схожей конфигурации. я постоянно гоняю файлы, проблем никаких, за исключением редких выпадений по таймауту из-за древнего хаба на 10мбит.. да и на форуме такой эффект ни кем не описан.. т.ч. вы первопроходец :)
поделите поиск на аппаратную и софтовую части, и методом отсечения и исключения найдете виновника..
- может кошак/рутер стоит шибко умный
- может питание кита хилое и проседает на сетевом обмене
- может антивирус злой выкусывает из пролетающего бинарника подозрительные сигнатуры
- может.. хз.. вариантов дофига
если найдете, отпишите тут, плз, чтоб знать..
или вместе подумаем (по возможности)..

еще бы я сюда добавил проверить сетевые настройки...

Цитата

Может, кто-нибудь сталкивался с подобной проблемой? Жизнь она осложняет несильно, но все-таки неприятно использовать Windows+tftpd32 в качестве "буфера" между ВМ и платой.

Ставьте нативный Linux и никаких проблем не будет.

Вот какие сообщения приходят в терминал при попытке передать файл с платы на ВМ. На плате нахожусь в папке /home, где лежит "экспериментальный" ts_test.

# tftp -p -l ts_test 192.168.0.2

ts_test 0% | | 0 --:--:-- ETAtftp: server error: (4) unsupported request from 192.168.0.136

ts_test 0% | | 0 --:--:-- ETA

С платы на Windows + tftpd32 передается нормально. С Windows на ВМ и обратно - тоже.

Пробовал при выключенном антивирусе - то же самое.
Плата напрямую соединяется с ПК (т.е. никаких роутеров, свичей и т.д. нет)

Сегодня/завтра проверю на другом компе с нативным линуксом, отпишусь, что и как.

Подобные фокусы, припоминаю, когда поставил себе фаирвол оутпост (видимо криво настроил, терпения не хватило), его включение-выключение слабо меняло картину (я от этого интсталляцию корневой переделал на USB), потом терпение лопнуло - снес этот оутпост, все пришло в норму.

хм.. странноватая картина
стандартное ядро, бизибокс:

Код

# tftp -r zlinux -g 192.168.0.2
zlinux 100% |*******************************| 2611k --:--:-- ETA
# cp zlinux test.bin
# tftp -l test.bin -p 192.168.0.2
test.bin 0% | | 0 --:--:-- ETAtftp: server error: (4) unsupported request from
192.168.0.136
test.bin 0% | | 0 --:--:-- ETA

в логе 192.168.0.2

Код

Jan 17 10:32:58 debian dnsmasq[3716]: TFTP sent /tftpboot/zlinux to 192.168.0.136
Jan 17 10:34:19 debian dnsmasq[3716]: TFTP unsupported request from 192.168.0.136

т.е. с хоста на плату слить файл можно, а вот с платы на хост фигу.. все то же самое с tftp утилитой под Дебьяном для АРМа.
Полагаю что-то не так с dnsmasq на хосте, то ли баг пакета, то ли недонастроен, то ли засекурен..
Пока проблема не решена можно гонять файлы по FTP, или пользоваться утилитами ftpget ftpput