Jump to content

Splinter

Пользователи
  • Content Count

    320
  • Joined

  • Last visited

Community Reputation

57 Очень хороший

4 Followers

About Splinter

  • Rank
    Пользователь

Информация

  • Пол
    Мужчина
  • Город:
    Самара
  • Интересы
    Электроника, программирование.

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. @ser_po с языка снял. Я не знаю всех ответов, я поделился своим опытом и сказал что знаю. Я не видел конкретно ваш аппарат и не знаю что у вас там на нем, сужу только по той информации которую вы сами предоставляете. И основная система и образ восстановления и раздел восстановления - это все файлы к которым доступ никак не ограничен, если у вашего экземпляра вируса есть функционал модификации образа восстановления (а это не особо трудная задача) то он это делает, но видимо не достаточно хорошо. Также в нанд есть десятки мегабайт незадействованной памяти, куда можно спрятаться. При "дип сбросе" восстанавливается только rootfs, при этом kernel и boot остаются нетронутыми. Никто не мешает вирусу модифицировать их и самовосстанавливаться после такого сброса. Вобщем вариантов-лазеек масса. Я не знаю какой у вас случай. Но если вы понимаете в работе shell(bash), то вам не составит труда притащить на плату заведомо оригинальные файлы nand_write, nand_erase, single-board-test и bmminer и восстановить работу системы. Но если вы все-таки ошиблись и там тот самый вирус, который мы сегодня обсуждали с уважаемым @ser_po , то вы получите кирпичь с двумя светящимися светодиодами на морде. Надеюсь это не ваш случай и у вас все получится.
  2. Да. Плюс незадываем что должен быть в наличии файл upgrade-marker.bin и лучше удалить вывод в dev/null для наглядности процесса. Воу-воу тише парни. Еще раз советую - не знаете shell не лезьте туда. Я намеренно не даю никаких скриптов. Кто понимает в shell тот без труда найдет нужные строки. Кто не понимает - в итоге отдаст деньги первым, но уже больше. Золотые слова! У вас же есть способ сброса с кнопки и прошивки с SD. Если они не помогают, то и обсуждаемый способ тоже не поможет. Не искушайте судьбу и не экспериментируйте.
  3. libresolver.so.1 это либа которую вирус приносит с собой. На данный момент видимо файлы вируса удалены, возможно путем "глубокого сброса" через кнопки. Вирус тоже не идеальный, он глючный, но с каждой версией все сильнее борется за живучесть. Если вы уверены в отсутствии вируса, то кто вам мешает перекинуть с рабочей платы файлы single-board-test и bmminer (первый запускает второй). Почти уверен что на данный момент у вас в системе фэйковый single-board-test и присутствует bmminer, но запуска bmminer не происходит. А все потому, что фэйковый single-board-test пытается запустить зараженный bmminer_ которого уже нет. Вобщем механизм варьируется в зависимости от версии вируса, но смысл примерно такой.
  4. Встроенная nand к процессу запуска с SD отношения не имеет, ее вообще может не быть физически, но загрузка с SD должна пойти. Если SD записана верно (а по вашим словам с нее прошились остальные майнеры), то вы делаете все верно. Остается только вариант с вирусом.
  5. Друзья! Предлагаю проблему восстановления плат управления обсуждать в другой теме. Это обширная и актуальная сейчас тема в виду объемов заражения. У кого эта проблема актуально - создайте тему с лаконичным названием. Уже есть пара тем, можно писать там. В этой же теме исторически обсуждается аппаратный ремонт. @unholyprophet на данный момент решения нет (при условии что вы все делаете верно при попытке прошить с SD)
  6. Эти 2 процесса не вполне идетичны будут. При восстановлении через кнопки - нажатие кнопки отслеживает uboot и начинает грузиться с резервного раздела, грузится полноценный Линукс и там уже производится автоматическая возня по восстановлению. При прошивке через upgrade-marker, прошивкой занимается сам uboot - получает двоичный образ системы и не задумываясь пихает его в нужную область nand. Причем на последний способ вирусу повлиять сложнее всего т.к. uboot это не файл в файловой системе а низкоуровневый бинарник, доступа к которому через файловую систему нет. Здесь единственная лозейка - повредить образ восстановления - uboot не проверяет что ему суют. А вот в первом случае, когда восстановление происходит в полноценном линуксе - точек атаки предостаточно. Вобщем ближе к телу.. найдите в runme.sh строки относящиеся к upgrade-marker. P.S. Последние описываемые здесь и в соседних ветках проблемы с вирусами пока не имеют решения, к сожалению. Признак - не шьется с СД пока не имеет решения (по крайней мере публичного).
  7. Только замена. Если просто перепаяете и он заработает - то обязательно вернется, а может и до выдачи умрет. либо проблема с питанием 1,8 В, только не 1-го домена (чипы объеденены в домены по 3 штуки, домены нумеруются от первого чипа), а 21-го, либо отвал 60-го или 61-го чипа (замеры между этими чипами покажут кто виноват). Последнее более вероятно. И в доменах нет DC-DC, там LDO (да, в каждом домене).
  8. Сферический конь.... Все показания одинаковые и верные? А какие вы показания считаете верными? Да, и что вы имеете ввиду под показаниями, вольты на вольтметре или осциллограммы, а некоторые и сопротивление мерят, и на диод звонят и интерпретируют показания. Тестпоинты стоят перед чипом, т.е. это его входы/выходы, соответственно перед 62-м есть тестпоинты, а вот перед 0-м - только 2 теспоинта. Хотя обмен по шине двунаправленный, и почти все сигналы это всеже выходы предыдущего чипа. Но с точки зрения диагностики эти сигналы полезны именно как входные сигналы следующего чипа и главный там отклик на эти сигналы от следующего чипа (RI). Советую все же на форуме нумеровать их от 1 до 63 иначе вас будут не понимать. У китайцев в логе они нумеруются то с 0, то с 1. Физические сущности (чипы) принято нумеровать с 1. С нуля нумерую программисты (массив в СИ начинается с нуля), поэтому в логе такая путаница. Возможно вы не совсем понимаете. Это творчески переработанный китайцами UART с добавлением арбитража шины в виде сигнала BO (так как UART это точка-точка). CO и RI это соответственно Tx и Rx. Сигналы инверсные и RO за 63-м чипом подтянут к плюсу. Ко всем чипам одновременно по шине приходит запрос (по CO), но ответить должен только один, адрес которого указан в запросе (по RI). Тут выходит на сцену сигнал арбитража шины - BO. Если BO на входе чипа высокий, то он не будет отвечать, так как шина занята. Итак мы плавно подобрались к вашей проблеме. ASIC = 0 и неисправность 1-го чипа это настолько редкий случай, насколько и неисправность любого другого чипа. Если диагностируете по вольтметру, то в рабочем режиме, если на всех чипах есть клок, RST и CO высокий, то ваш клиен - чип на котором RI переходит из нуля в единицу (надеюсь из данного опуса понятно почему). Для подтверждения номера диагностированного чипа, как советовали уважаемые коллеги, прижимаете его за радиатор к плате, и как правило плато начинает работать. P.S. Пока писал опус, проблема решилась. Но пусть останется на память
  9. Какой-то шаманский бубен прям )) Достаточно зажать ipreport при включении в сеть и подождать секунд 20, дальше отпускаем кнопку и ждем некоторое время пока асик не загрузится уже прошитым (на совсем старых версиях автоматической перезагрузки кажется небыло, там мигают диоды и нужно вручную перезагрузить). Почему я не написал что это самый простой способ - потому что фактически это софтовый сброс - накатывается образ системы из резервного образа из раздела восстановления. Делается это обычным скриптом и вирусу как 2 пальца об асфальт модифицировать или просто удалить этот скрипт. Я не говорю что это не стоит попробовать, я лишь призываю не надеяться на этот способ особо. На данный момент самый надежный способ - прошивка с SD - после этого система стерильна. Но для этого нужен физический доступ. Джедаи же командной строки при не заблокированном SSH в большинстве случаев могут поправить все и удаленно. Если после 10 минут bmminer все еще not found, то я вижу 2 возможных причины. 1. Циклический ребут контрольки, а то что вы попадаете на это сообщение - совпадение. Обязательно попробуйте на заведомо исправном блоке питания, или отключите полностью 2 хэш-платы (оставьте только одну). 2. Это более банально - повторное заражение. Все манипуляции при лечении с КАЖДЫМ асиком нужно производить в изолированной сети - только комп и асик (ну и тупой свич с dhcp между ними). Пока не убедитесь в том что все асики в вашей сети вылечены соединять их в одну сеть НЕЛЬЗЯ, повторное заражение происходит почти мгновенно. Убедитесь, что выставляете джамперы верно.
  10. @deadfire Да это вирус, а не прошивается потому что он подменяет стоковые файлы flash_erase и nandwrite на свои. Самый простой способ - прошиться с SD карты. Более изысканный - возвращаете на место стоковые flash_erase и nandwrite , по необходимости стопорите подозрительные процессы/демоны и прошиваетесь через SSH/SCP (возможно и вэб прошивка будет доступна).
  11. Что за странный лог, вы его либо порезали, либо это какая-то левая прошивка. Прошейте на автофрековую официальную и покажите лог. Хотя я несколько раз видел такой рваный лог когда при начале хэша проседает блок и контролька ребутится. Проверьте БП (заменой).
  12. Судя по тому что вы пишите, вы не понимаете что вы собираетесь делать. Инструкций никаких нет и не будет, это не кулинарный форум и не ютуб. Как уже кто-то написал "здесь каждый сам постигает прекрасное". Мы можем только подсказать и направить. Техника не простая и бездумно тыкать в нее не стоит. И уж тем более шить то что и так работает. ASIC=0 в 99% к прошивке PIC (это единственное что прошивается на хэш-плате) отношения не имеет.
  13. Чудес не бывает. Либо вы где-то ошибаетесь, либо вам попался какой-то больно умный вирус (маловероятно т.к. он даже не додумался ssh заблокировать, но чем черт не шутит). Скрипт прошивки напрямую затирает и прописывает все области nand кроме собственно основной - rootfs - т.е. самого важного. Последней командой скрипт взводит механизм самопрошивки rootfs uboot-ом. При перезагрузке uboot видит взведенный маркер и прошивает rootfs. Теперь ищите узкие места на которые мог воздействовать вирус: данные не пишутся в nand (лишь имитируется процесс) - слишком сложно для вируса, врядли; при перезагрузке маркер оказывается пустым - уже более реалистично; машина не ребутится по настоящему - а почему бы и нет...ну и т.д. А по существу - раз у вас там есть глаза и руки, так вручите этим рукам sd карту и вперед - процесс примитивный, справится даже сторож. Вот только если это реально вирус, то каждый прошиваемый асик нужно отключать от общей сети и не подключать его до того момента как не прошьете все машинки. Одной зараженной машинки хватит чтобы за считанные секунды заразить все машинки в сети. А включение обратно в сеть такого большого пула по одной машинке - то еще удовольствие - при прошивке с карты собьются все mac-адреса и DHCP раздаст их наобум - вот и гадайте потом где какая машинка.
  14. Скидываете все содержимое в корень SD карты отформатированной в FAT. Вставляете карту в контрольку, включаете, ждете. Процесс автоматический и от вас больше ничего не требует. https://support.bitmain.com/hc/en-us/articles/115000216034-L3-L3-and-L3-Control-Board-Program-Recovery
  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...