(Окончание. См. часть 1)
Часть вторая: перепрошивка и всё, что с ней связано
И ещё пара ссылок...
http://www.chatlogin.com/dbox2/chkdesign/ — большая база данных для Нейтрино
http://www.dbox2hardware.de/index.html — отдельно взятое "железо" Dboxа
http://www.dbox2.net/ — страница ещё в стадии разработки
http://www.linuxfocus.org/Deutsch/September1998/article63.html —
очень подробное описание теории и практики загрузки по сети. Конкретно с Dbox'ом никак не связано, но принципы загрузки те же.
Предисловие
Постараюсь в этой части, как и в первой, передать прежде всего личный опыт. Как практический, так и теоретический. Так как экспертом ни в теории компьютерных сетей, ни в Линуксе я не являюсь, прошу не критиковать, если где-то вы найдёте небольшие несоответствия в теоретической части. Практически всё, о чём я здесь пишу, мною опробовано, тем не менее, нет гарантий, что у вас это не будет немного по-другому (надеюсь, что в лучшую сторону).
Постарался написать попроще и попонятнее, но все равно: без навыков работы с компьютером многое — темный лес.
Еще раз акцентирую внимание на том, что теоретической подготовке в данном процессе стоит уделить особое внимание.
Режим отладки включён. Что дальше?
"Wenn man es geschafft hat, seine Dbox in Debug-Modus zu bringen, kann selbst ein Laie den Softwaretausch vornehmen", — такую фразу я вычитал в одной из инструкций. Это верно только в том случае, если этот самый "Laie" предварительно всё правильно выставил в установках локальной сети. Именно этому и посвящена бОльшая часть сегодняшнего повествования.
Итак, осталось, в принципе, всего ничего: выкачать из памяти flash старое ПО, извлечь из него микрокоды слотов чтения карточек и залить в память flash "главного виновника" — ОС Linux. Именно в этом же хронологическом порядке.
Загрузка по локальной сети — немного теории
Загрузка по локальной сети практически ничем не отличается от загрузки с жёсткого диска или из памяти flash. Единственное большое отличие — это то, что надо как-то указать Dbox'у, откуда он будет грузить ОС. Для общего случая загрузки по сети требуются три основных компонента:
- идентификатор системы
- ядро ОС
- работающая файловая система
Так как Dbox уже в режиме отладки, то системная идентичность загрузчику относительно безразлична (напомню, что именно этого мы и добивались, включая режим отладки).
Начальную и самую важную часть загрузки по сети для нашего конкретного примера можно упрощённо описать так:
- После короткого теста компонентов системы Dbox посылает по сети запрос "общего характера". Этот запрос посылается всем абонентам локальной сети. Так как наша локальная сеть состоит всего из двух абонентов, то запрос обязан "приземлиться" только на ПК. На терминале COM это видно в виде сообщения "transmitting BootP request via Broadcast".
- Сервер BootP, реализованный и запущенный программой DboxIIBoot (если установки сети на ПК правильные), отвечает на запрос и сообщает Dbox его (или её, как вам больше нравится) адрес IP, а также и свой собственный адрес IP. Помимо этого, сервер BootP сообщает Dbox'у, какой файл Dbox должен загружать в качестве системного ядра. Весь этот процесс отображается в окне терминала сообщением "Got BOOT reply from server".
- Обрадованный успеху в шаге номер 2, Dbox посылает уже конкретный запрос на загрузку файла ядра ОС. Этот запрос уже посылается серверу TFTP (trivial file transfer protocol). Под сервером в данном случае подразумеваются программы, реализующие соответствующую службу сети. Сервер TFTP отвечает на запрос и начинает посылать Dbox'у загрузочный файл, используя UDP — user datagram protocol. Если используется minflsh, то файл загрузки — это ядро Chorus OS, используемое для Betanov'ы. Если это уже Linux, то сначала загружается загрузчик Линукса PPCBoot. Если провести для упрощения аналогию с DOS/Windows, то это были бы файлы io.sys и msdos.sys.
- Собственно, на этом самое главное уже проделано. PPCBoot распаковывает ядро ОС Линукс и запускает его. С это момента весь контроль над системой передаётся системному ядру (kernel).
- После удачной загрузки система находит и распаковывает сжатый файл файловой системы, необходимой для дальнейшей загрузки. Все драйвера и все скрипты инициализации (в мире Windows мы бы их назвали config.sys и autoexec.bat) реализованы в виде файлов. [Линукс изначально был так устроен, что практически всё, включая системные ресурсы, реализовано в виде файлов, что и придаёт ОС Линукс очень большую степень прозрачности.] Так как загрузка всё ещё идёт по локальной сети, то и файловая система тоже черпается по сети из ПК. Всё дерево каталогов представлено в виде одного-единственного файла. Ядро ОС подсоединяет (по-немецки это красиво называют "wird gemountet") этот самый файл, используя так называемую NFS — network file system.
В правой половине окна установок DboxIIBoot как раз и выставляются файл загрузки ядра ОС (в верхнем правом углу) и файловая система (соответственно, в правом нижнем углу).
Mein Kampf c локальной сетью
Итак, как я уже писал в предыдущей части, первые попытки заставить Dbox грузиться по сети ни к чему ни привели. Я выставил вроде бы всё так, как было указано в инструкции: сетевую плату на 10 Мегабит в режим Half-duplex. Итак, мои действия в том порядке, в котором я их совершал:
- Запустил DboxIIBoot. Выполнил все необходимые установки для выкачивания image Betanova.
- Нажал на кнопку "Start" и включил Dbox в сеть. В окне протокола DboxIIBoot (в самом верху) увидел сообщения: "… Höchstwahrscheinlich 10/100-Problem...".
- Пошёл на страничку к Дитмару и посмотрел, что там, собственно, пишут по этому поводу. По этому поводу там писали, что если я использую комбинационную сетевую плату, то она зачастую не успевает "сориентироваться", в каком режиме она работает. К тому моменту, когда она, наконец, это делает, Dbox'у уже "надоедает ждать" ответа на запрос BootP и он начинает грузить систему из памяти flash — а там у нас что? Правильно, пока что всё ещё Betanova. Несмотря на то, что после включения режима отладки Dbox при запуске требует "ОК drücken, um das System zu aktualisieren", система Betanova всё ещё крепко сидит в памяти flash. Даже если вам упорно доказывается, что "es wurde kein System gefunden", она там есть. У меня именно так и было, но в результате я всё равно преспокойно выкачал image Betanova.
- Итак, Дитмар советовал при включении Dbox в сеть нажимать одновременно кнопки "ВКЛ" и "ВВЕРХ", втыкать вилку в розетку, ждать, пока дисплей потухнет, отпускать кнопку "ВКЛ", ждать, пока дисплей опять засветится, и отжимать "ВВЕРХ". Эта процедура побуждает Dbox выполнять полный системный тест. За это время сетевая плата успевает "сориентироваться". В окне терминала COM после теста системы появляется командная строка загрузчика. Для загрузки по сети надо набрать boot net, что я и сделал.
- В окне терминала появилось следующее:
…
Transmitting BOOTP request via broadcast...
Got BOOT reply from server 192.168.5.1, My IP 192.168.5.2
Sending TFTP-request for file C/………… (путь и имя файла)
Sending TFTP-request for file C/…………
Sending TFTP-request for file C/…………
Sending TFTP-request for file C/…………
Sending TFTP-request for file C/…………
Sending TFTP-request for file C/…………
TFTP request not answered
Boot net failed
…
Далее Dbox начинал загрузку из памяти flash, что меня ни в коем случае не устраивало.
Итак, ПК отвечал на запрос BootP, но наотрез отказывался отвечать на запрос TFTP. Решение этой проблемы отняло у меня три вечера подряд. Каждый вечер я упорно садился за компьютер и пытался выяснить причины неудач. А на следующий день я задавал этот вопрос на форуме у Берлиоза. Там мне советовали отключить антивирус, VPN и Firewall. Антивирус я вообще деинсталлировал, Firewall был выключен изначально, VPN не нашёл, как ни искал. Когда я уже совсем отчаялся в положительном результате, я попробовал удалить все лишние привязки сетевой платы. Так как я имел дело с очень "крутой" дорогой (в настоящий момент — 55 EUR в сетях Arlt) платой, она при инсталляции драйвера сделала ещё целую кучу лишних привязок к ненужным протоколам. Я просто-напросто взял и отключил все привязки сетевой платы, кроме TCP/IP (TCP/IP-Anbindung). Только после этого конструкция стала подавать признаки жизни.
И лишь тогда я понял причину всех моих прежних неудач. В первую очередь для меня был важен ответ на вопрос, а почему, собственно, ПК отвечал на запрос BootP, но не отвечал на запрос TFTP. Слегка пораскинув мозгами, я вспомнил, что до этого по незнанию выставил адрес IP вручную не только в привязке TCP/IP, но и ещё в других привязках. Причём во всех — один и тот же адрес. Таки образом, BootP сообщал Dbox'у его адрес IP, а вот когда Dbox обращался уже к конкретному host по конкретному адресу, то "натыкался" на несколько разных привязок под одним и тем же адресом. Вероятность, что Dbox'у ответит именно нужный ресурс, существует, но она невелика. Кстати, один-единственный раз у меня действительно так и получилось. В одну из моих неудачных попыток ПК неожиданно ответил на запрос. Я тут же воспользовался случаем и выкачал оригинальную прошивку Betanov'ы. Факт одноразовой удачи ещё больше поверг меня тогда в замешательство. Лишь теперь я понимаю, что это была обычная вероятность 1/x, причём икс значительно больше единицы.
Итак, краткий обзор ошибок и способы их решения:
- Если вообще нет никакой реакции (никакого ответа на запрос BootP) и в правом нижнем углу экрана (там, где часы) не появляется значок соединения по сети, значит, что-то не соответствует в установках сетевой платы. Её надо выставить на 10 Мбит Half Duplex.
- Если соединение якобы есть, но BootP-запрос остаётся без ответа, значит, что-то не так с установкой адреса IP. Проверьте в установках привязки TCP/IP, чтобы адрес был установлен вручную и начинался на 192.168….. Я себе выставил 192.168.5.1, а для Dbox'а — 192.168.5.2. Маска subnet должна быть 255.255.255.0. DNS (Domain Name Server) тоже можно включить, но ничего не выставлять.
- Если есть ответ на запрос BootP, но нет ответа на запрос TFTP — отключите все привязки, кроме привязки TCP/IP.
И вот ещё что: я использовал для всего процесса русскоязычную версию Win98. Тут меня могла бы поджидать ещё одна западня, до которой я просто не дошёл. Немецкие версии Windows для программ создают папку "Programme", в то время как русскоязычные версии папку для этих же целей называют "Program Files". Разница огромная — во втором варианте присутствует пробел в пути к файлам. Зачем я всё это рассказываю? А затем, что при инсталляции программы Dbox II Boot Manager путь инсталляции по умолчанию будет предложен именно в Program Files. Практически все инструкции настоятельно рекомендуют размещать папки с minflsh и ppcboot в корневом каталоге в директориях, в именах которых не присутствует пробелов. Правда, ни одна инструкция не пишет, почему. Ответ прост. Попробуйте запустить Linux и, открыв Shell, набрать "mkdir Programm Files" (mkdir — создать папку под Linux). Потом наберите "ll" (те, кто ещё помнит, что такое командная строка DOS, наверняка знают команду dir). Вашему взору представятся две разных папки для "Program" и для "Files". Команду "mkdir Program Files" Linux понимает НЕ как "создать папку Program Files", а как "создать папку Program и затем независимо от неё — папку Files".
Вывод из всего вышеописанного: при использовании русскоязычных Windows инсталлируйте программу DboxIIBoot (и всё остальное типа ppcboot и minflsh) в папки, путь к которым не содержит пробелов. То же касается самих прошивок.
Итак, ошибки устранены, идём дальше.
- После удачной загрузки по сети я (вернее, DboxIIBoot) выгрузил прошивку Бетанова. Я сразу сохранил файл прошивки в нескольких разных партишинах разных жёстких дисков, так как файл надо хранить как зеницу ока. [Немного о выкачивании. Сам процесс запускается в действие командой cat /dev/mtd/5 > flash.img. Команда cat в Линуксе выводит содержимое файла на стандартный вывод. В большинстве случаев стандартный вывод — это консоль. Значок ">" указывает на перенаправление вывода в файл flash.img в корневой каталог. Так как этот самый корневой каталог находится на жёстком диске ПК (см. "Теория загрузки по сети"), то и перенаправление осуществляется в тот каталог, который выставлен в установках сервера NFS.] Понадобится ли он ещё для чего-нибудь, кроме извлекания микрокодов слотов чтения карточек и чипа декодера, пока сказать сложно, но сохранить его надо обязательно. 8 Мегабайт (а в сжатом виде — и того меньше) для сегодняшних дней — мелочь.
- Далее, согласно инструкции, извлёк микрокоды слотов (4 файла).
- Сохранил их по всем углам HDD. Это не обязательно, ведь их всегда можно извлечь из файла ОС Бетанова.
- Запустил DboxIIBoot на "image flashen", выбрал файл "alexW2xBaseimageV1.6.3", нажал кнопку "Старт".
- Включил Dbox методом включения вилки в розетку.
- На экране выскочило окошко, предупреждающее о том, что я ещё могу одуматься и не делать всего этого — "dies ist die absolut letzte Warnung!..". Я не внял "взываниям сверху" и нажал "ОК".
- Dbox загрузил по сети прошивку Linux в динамическую оперативную память DRAM. Эта процедура очень быстрая и заняла пару секунд. На экране процесс визуализировался значками "#". Затем Dbox принялся стирать память flash по секторам. У меня это были просто точки на экране. У друга с Nokia 2*Intel номер сектора отображался десятичным числом. Насчитали всего 63 сектора. Затем Dbox принялся эту же память прописывать, что заняло где-то минуту пятьдесят. Во время этой процедуры на экране просто моргает курсор. Никакой визуализации прогресса нет. Создаётся впечатление, что Dbox "висит". Но если присмотреться внимательно, видно, что на нижней панели окна есть надпись, которая гласит "Schreibe flash seit 0:23 (отсчитывает время)".
- После завершения "шитья по flashу" мне было предложено перезапустить Dbox, что я и сделал.
- После загрузки ядра Linux на жидкокристаллическом дисплее надо было выставить с помощью пульта дистанционного управления адрес IP Dbox'а. Я просто нажал "ОК", оставив таким образом неизменённым 192.168.5.2.
- Следующим шагом было интимное предложение загрузить "per ftp cdk.cramfs nach /var/tmp und ucodes nach /var/ucodes". В качестве программы FTP я использовал Windows Commander, потому что он у меня уже был. Вот установки для соединения, которые у меня работают (пароль стандартный — dbox2):
- В поле "Titel" можно писать всё, что угодно, это только для Windows Commander. Соединение получилось не с первого раза — не знаю, почему. Пробуйте. С тех пор все FTP-соединения работают "с пол-оборота".
- При удачном соединении вы всегда оказываетесь в папке /var. Поэтому достаточно зайти в папку /tmp. Перетащил туда файл сdk.crams, микрокоды (на всякий случай — все четыре файла) — в /var/ucodes.
- Нажал "ОК" на дистанционке. На дисплее на секунду высветилась надпись "verifying checksum", затем "lösсhe flash", за которой последовал "schreibe flash".
- После этого мне был предложен очередной рестарт.
Первое свидание с Linux
В качестве "затравки" мне предстоял мучительный выбор между тремя имеющимися графическими оболочками — Neutrino, Enigma и Lcars. Так как я практически везде в связи с Linux непременно натыкался и на неотъемлемый термин "Neutrino", его я и решил использовать. Кроме того, про Lcars я вообще читал не очень лестные отзывы. Чтобы каждый раз не подтверждать загрузку Нейтрино, надо выставить его по умолчанию. Для этого надо нажать кнопку "dbox" на пульте, затем в меню "Einstellungen" "Diverse Einstellungen" "Neutrino automatisch starten: ein".
Думаю, нет никакой надобности писать здесь подробнейшую инструкцию о пользовании Нейтрино, тем более, что она есть в Интернете. Если вы уже дошли в своих действиях до этого места, то наверняка сумеете разобраться с управлением Нейтрино. Туда, правда, всё больше и больше добавляется новых возможностей, большинствo которых я НЕ испробовал из-за отсутствия технических предпосылок. (Например, у меня нет DSL, и, соответственно, использование Dbox в качестве прокладчика DSL-маршрута {DSL-Router} я протестировать не смог.)
Дополнительные возможности
Под дополнительными возможностями хочу кратко представить те функции, которые в систему не интегрированы по различным причинам и поэтому запускаются "извне".
- Запись цифрового потока на жёсткий диск ПК. Я для этого использую WingrabZ. Файлы, конечно, получаются здоровенные (90 минут, 3,6 ГБ), но якобы их можно сжимать в другие форматы.
- Вызов "домашней странички" Нейтрино. Для этого надо открыть стандартный браузер и в окне адреса набрать адрес IP Dbox'а.
- Просмотр потока на мониторе ПК. Нужна программа TuxVision и Trex. Вторую я откопал только в виде шаровар на 60 дней. Не понравилось то, что нельзя увеличить экран на весь монитор. Оно и понятно — ведь поток framebuffer имеет строго фиксированный размер и в режиме онлайн его можно смотреть в том же фиксированном соотношении.
- Возможность заходить в систему Dbox через соединение telnet. Я соединяюсь через программу puttytel, которая свободно распространяется в сетях WWW и довольно проста в обращении. Как и для соединения FTP, для telnet надо задать адрес IP, логин и пароль.
- Возможность проигрывать всякие анимации для жидкокристаллического дисплея. Нужна программа aniplay. Для запуска нужно закачать aniplay и сами анимации, например, в /var/tmp, затем соединиться с Dbox'ом по telnet. Чтобы программы были запускаемыми, надо их таковыми объявить. Опять же — ни одна инструкция не пишет, почему. А всё потому, что при транспортировке файлов по FTP свойства запускаемых файлов "теряются по дороге" (это как-то связано с протоколом). В Линуксе свойства файлов изменяются командой "chmod +x file_name". Запускается файл тоже не как в DOS, а вот так: "./file_name". Анимации, следовательно, надо запускать "./aniplay animation.ani". После холодной перезагрузки Dbox'а все файлы из /var/tmp/ не сохраняются, так как эта директория чисто виртуальная и создаётся в динамической памяти Dbox'а, а эта память после выключения питания своего содержимого не сохраняет.
- И последнее. Логотипы загрузки на телевизоре и жидкокристаллическом дисплее меняются простым копированием файлов logo-fb и logo-lcd в директорию /var/tuxbox/boot. Заменить же логотип режима радио совсем не так просто. Я недавно задал этот вопрос на форуме у Берлиоза и получил ответ, что для этого надо взять файловую систему cdk.cramfs и, используя программу Tuxbox Flash Tolls (не путать с Dbox Boot Manager), заменить нужный файл, запаковать всё обратно и опять загнать в Dbox. Этого я пока что не опробовал.
Полезные советы по Neutrino (из собственного опыта)
- Очень хороший способ "образумить" Dbox, если он вдруг начинает сходить с ума, я обнаружил в одном из многочисленных FAQ'ов. Первое, что приходит на ум в таком случае, — это просто заново залить Linux. Правда, при этом невозвратимо теряются списки каналов, установки графической оболочки, логотипы загрузки и т. п. Автор идеи предлагает сохранить полностью всё содержимое памяти flash на жёсткий диск ПК. Если вдруг у Dbox'а по каким-либо причинам начинается "приступ висячества", можно просто заново залить image. Заливается всё содержимое flash без загрузчика, то есть и само ядро ОС, и файловая система со всеми установками. И вы получаете систему в том состоянии, в котором вы её выкачали. У меня такое было один раз, когда у нас выбило пробки. Dbox после этого прямо с цепи сорвался — виснул после третьего переключения канала и вообще не хотел выключаться. Многократное отключение питания ни к чему не приводило. [Тот, кто работал с Linux и по каким-то причинам сталкивался с непроизвольным выключением или сбросом ПК, знает, что при запуске процесса инициализации init система делает то, что в Windows делает Scandisk при тех же условиях, — проверяет файловую систему на наличие ошибок. В Dbox'е такого я пока что не наблюдал, поэтому подозреваю, что при этом нежелательном сбросе системы процессы закрываются неправильным образом и файлы как бы тоже не закрываются должным образом. Последующая перезагрузка не помогает, поскольку файл или системный ресурс, представленный в виде файла, остаётся повреждённым.] Поэтому, если вас устраивают все установки и система работает хорошо, сделайте "резервную копию" содержимого flash, она может ещё ой как пригодиться. Я сам уже этот метод опробовал — действительно, в результате даже поиск каналов заново делать не пришлось, система была идентична своему образу двухнедельной давности.
- Самая частая причина "зависаемости" Dbox'а у меня была в пересечении внешнего и внутреннего управления системой. То есть при управлении через веб-сервер или ТuxVision и т. п.
- Так как ОС Linux намного интенсивнее использует процессор, то и нагревается он, соответственно, больше. При Betanov'e Dbox, в принципе, тоже льдом не покрывался, но заваливать его со всех сторон книгами или чем-нибудь ещё я бы не стал. У моего друга Dbox стоял в относительно узкой нише и регулярно "подвисал". Теперь у него другая подставка под телевизор, там места ощутимо больше — и проблемы как не бывало.
Если почитать постинги на форуме у Берлиоза (кстати, с Булгаковым тут нет ничего общего, просто "Берилоз" подразумевает проект BerliOS), то видно, что каждый Dbox ведёт себя немножечко по-другому. Тем не менее — надеюсь, что мои советы действительно окажутся полезными.
Послесловие
Сам я результатом операции остался очень доволен. Я заполучил не только удобную ОС, но и дополнительные знания и опыт, которые, я убеждён, — самое ценное приобретение из всего процесса.
Хотелось бы высказать нескрываемое восхищение в адрес тех, кто на голом энтузиазме воплотил в жизнь проект TuxBox и продолжает над ним работать, а также тех, кто разработал методы включения режима отладки, наверняка поплатившись на начальной стадии сосбтвенными Dbox'ами за опыт, который они сделали достоянием общественности. (Хотя навязчиво напрашивается подозрение: при всей смекалке некоторые моменты нужно было просто знать. Например, команды загрузчика и содержимое его памяти для третьего метода включения режима отладки. Отсюда вывод, что без помощи работников Betaresearch, пожелавших остаться неизвестными, тут не обошлось.)
Хочется понадеяться, что проект TuxBox будет и дальше развиваться, а перепрошивка Dbox'ов будет становиться всё проще и проще. Также очень хочется верить, что планируемый Premiere World переход на другую систему кодировки не "перекроет подачу кислорода" легальным подписчикам пакета, которые используют ОС Linux на своих приёмниках. Поживём — увидим.
P.S. Надеюсь, эта статья хоть кому-то оказалась полезной...