Сразу коротко ответ: обновление, которое представляет из себя новую прошивку BIOS, установка подразумевает автоматическое обновление биоса.
Внимание: устанавливать обновление нежелательно, если компьютер функционирует корректно. Могут легко появиться проблемы.
Разбираемся
Точной информации об этом нет вообще.
По поводу биоса — да, именно, имеется ввиду обновление того самого биоса, который содержит множество настроек железа (при помощи которых иногда и разогнать комп можно):
PS: в BIOS обычно можно попасть если при включении ноута зажимать кнопку F1 / F2 / Del — какую именно, это уже зависит от модели устройства (смотрите инструкцию).
Однако в интернете нашел картинку, оказывается под данным названием может быть устройство в диспетчере:
Вот свойства устройства:
Из чего можно сделать такие выводы:
Если у вас появилось устройство System Firmware — мое мнение не удалять его и вообще ничего с ним не делать. Лучше написать по возможности в поддержку Асус. Потому что.. вы можете его удалить, а потом вообще операционная система не загрузки. Это конечно лично моя рекомендация.
Также название System Firmware упоминалось на форуме 4PDA в ветке про ноутбук ASUS TUF Gaming FX505GT, там сказано, что это — обновление биоса. То есть прошивка, которую можно скачать с офф сайта Асус, потом поставить и биос будет обновлен. Однако данный процесс необходимо выполнять только при соответствующих знаниях, ведь BIOS — дело серьезное.
Также у вас System Firmware может упоминаться в названии одного из обновлений, например в приложении Windows Update MiniTool:
Некоторые пользователи пишут — устанавливать обновление не нужно, после него может не запуститься компьютер. Неудивительно, ведь дело касается обновления биоса.
Также обновление может прилететь и через Windows Update. После установки его — тоже могут быть проблемы.
Выводы
Итак, теперь сделаем выводы:
Вот например у меня материнская плата ASUS Gryphon Z87. Обновление биоса вышло уже давно. Но я его не ставил, потому что материнка работает стабильно и без глюков. Также и вам советую — если устройство функционирует стабильно то не советую ставить новый биос)) только если в этом есть крайняя необходимость)
Надеюсь данная информация оказалась полезной. Удачи и добра, до новых встреч друзья!
——————————————————— И не надо мне писать письма или в личку по вопросам, связанным с ноутбуками, всё равно ж не отвечу;)) Всё это обсуждается на ФОРУМЕ.
——————————————————— И не надо мне писать письма или в личку по вопросам, связанным с ноутбуками, всё равно ж не отвечу;)) Всё это обсуждается на ФОРУМЕ.
——————————————————— И не надо мне писать письма или в личку по вопросам, связанным с ноутбуками, всё равно ж не отвечу;)) Всё это обсуждается на ФОРУМЕ.
——————————————————— И не надо мне писать письма или в личку по вопросам, связанным с ноутбуками, всё равно ж не отвечу;)) Всё это обсуждается на ФОРУМЕ.
У Вас устаревшая версия Windows 10 b10586, которая поддерживает DirectX 11.
В более новых версиях Windows 10 b14432 поддерживается DirectX 12.
Обновляется само через Виндовс, Интел и Нвидиа.
Смените версию на более новую b 14432 май 2016г и будет Вам доступна DirectX 12.
Правда я ставил систему с оф сайта (там установщик для флешки специально с Майкрософт качал) Почему то установил старую версию(((
Правильно настраивайте «Центр обновления»
После обновления с носителя до b14332 при длительном пользовании интернетом, скачается и обновление до версии 14432.
При включении ноутбука вылезает какое-то предупреждение
Регистрация 13.01.2012 Адрес Ачинск, Красноярский край Сообщений 280 Репутация 10
Привет всем. У жены на ноуте Dell Inspiron при включении вылезает какое-то предупредупреждение белыми буквами на чёрном экране. Текст следующий:
The AC power adapter wattage and type cannot be determined. The battery not charge. The system will adjust the performance to match the power available/
Please connect a Dell 90 W AC adapter or greater for the best system performance. Strike the F3 key (before F1 or F2 key) if you do not want to see power warning message again. Strike the F1 key to continue, F2 to run setup utillity
До этого пару раз было такое. Но ноут использовался без батареи от сети. При появлении этого предупреждения она нажимала F1. При следующем включении это так же появлялось. Я попробовал тогда вариант просто тупо выдергивал шнур из ноута, при следующем включении оно уже не вылазило. После этого вставляли батарейку, всё нормально работало, батарея заряжалась уровень заряда показывался. То есть после выдергивания шнура всё становилось норм. И вот за пол года третий раз это сообщение появилось, решил разобраться. В общем нажал я F1 комп включился (стоит батарея сейчас и ноут от сети работает, причём комп стали использовать от сети с батареей уже как несколько дней). Значит включился ноут. Батарея показывает уровень заряда 100%. Вытаскиваю шнур, показывает 99%. Решил немного подсадить её и посмотреть будет ли она заряжаться. Разрядил батарею до 97%. Воткнул шнур, показывает батарея заряжена на 100%. Выключил ноут. Включил, это предупреждение не появлялось. Батарея пишет 100% заряжена. Вытащил шнур, пишет 97%. Разрядил до 96%, воткнул шнур, пишет 100%. То есть батарея не заряжается. Что это за ерунда? И почему не зяряжается батарея а сообщение не выдаётся больше? Ведь раньше когда батарея не стояла, при появлении этой ошибки я тупо выдирал шнур и потом опять включал комп. Комп какое-то время работал от сети, когда надо было жена вставляла батарею и работала от неё. При необходимости заряжала её. Что делать?))
Устранение неполадок обновлений встроенного ПО диска
Область применения: Windows Server 2022, Windows Server 2019, Windows 10
Windows 10 версии 1703 и более поздних версий включают возможность обновления встроенного по для жестких дисков и твердотельных накопителей, которые были сертифицированы с помощью встроенного по, обновляемого AQ (дополнительный квалификатор) с помощью PowerShell.
Дополнительные сведения об этом компоненте можно найти здесь:
Обновление встроенного ПО может завершиться с ошибкой по различным причинам. Эта статья предназначена помочь при выполнении расширенных действий по устранению неполадок.
Сведения в этой статье, в зависимости от проблемы, могут быть недостаточными для полной отладки всех возможных сбоев.
Распространенные проблемы
С точки зрения архитектуры эта новая возможность опирается на API, реализованные в стеке хранилища Windows, в который PowerShell направляет вызовы. Стек хранилища зависит от драйверов и оборудования, чтобы правильно реализовывать определенные в отрасли команды. Вследствие этого создаются несколько точек, в которых возникают сбои. Далее перечислены наиболее частые проблемы.
В следующих разделах описываются сведения об устранении неполадок, связанных с использованием драйверов Microsoft или сторонних драйверов.
Определение недопустимого оборудования
Самый быстрый способ определить, поддерживает ли устройство правильный набор команд, — просто запустить PowerShell и передать объект PhysicalDisk, представляющий диск, в командлет Get-StorageFirmwareInfo. Пример:
Вот пример выходных данных:
Поле SupportsUpdate, по крайней мере для устройств SATA и NVMe, будет указывать, может ли использоваться встроенная функция PowerShell для обновления встроенного ПО.
Поле SupportsUpdate всегда будет отображать значение True для последовательно подключенных устройств SAS, так как запросы на поддержку соответствующей команды невозможны с помощью стандартных отраслевых команд.
Чтобы проверить, поддерживает ли устройство SAS набор необходимых команд, существует два варианта:
Параметры исправлений
Если тестируемое вами устройство не поддерживает соответствующий набор команд, обратитесь к поставщику, чтобы узнать о наличии обновленного встроенного ПО с набором необходимых команд, или обратитесь к Каталогу Windows Server для определения устройств, способных реализовать набор соответствующих команд.
Устранение неполадок сторонних драйверов (SAS)
Компонентами программного обеспечения, наиболее тесно взаимодействующими с оборудованием, являются драйверы мини-портов в стеке хранилища Windows. Для некоторых протоколов хранилища, например SATA и NVMe, корпорация Майкрософт предоставляет собственные драйверы для Windows. Эти драйверы предоставляют дополнительную информацию об отладке. Однако поставщики стороннего оборудования и программного обеспечения имеют полную свободу написания собственных драйверов мини-порта для своих устройств. При этом уровень их поддержки для информации об отладке может быть разным.
Чтобы определить, что произошло со встроенным ПО, скачайте и активируйте API, отправленные в стек хранилища, независимо от драйвера мини-порта. Обратитесь к следующему каналу журнала:
Просмотр событий — Журналы приложений и служб — Microsoft — Windows — StorDiag — Microsoft-Windows-Storage-ClassPnP/Operational
Этот канал записывает сведения об API Windows, отправляемых драйверам мини-порта, а также их ответы. Например, состояние ошибки, показанное непосредственно ниже, проявляется при попытке скачать образ встроенного ПО на устройство SATA, подключенное через HBA SAS, которое не реализует надлежащим образом необходимый перевод из SAS в SATA:
Ниже приведен пример выходных данных.
PowerShell вызовет ошибку и получит информацию о том, что вызванная функция (то есть Kernel API) является неправильной. Это может означать, что API не реализован драйвером мини-порта стороннего устройства SAS (значение true в этом случае) или сбой API произошел по другой причине, например из-за рассогласования сегментов скачивания.
Событие трассировки событий Windows 507 из канала показывает, что сбой запроса SCSI СРБ и предоставление дополнительных сведений, которые Сенсекэй был «5» (недопустимый запрос), а Аддитионалсенсе сведения были «36» (недопустимое поле в CDB).
Эта информация предоставляется непосредственно соответствующим мини-портом, и точность этих сведений будут зависеть от реализации и усовершенствования драйвера мини-порта.
Возможно, разные состояния ошибки будут вызывать одинаковые коды ошибок, если драйвер мини-порта не разграничит их. Например, попытка скачать недопустимый образ встроенного ПО через SAS HBA на устройство SATA (на котором ожидается ошибка) может быть переведена в аналогичные коды ошибок.
В случаях, в которых смешиваются протоколы и происходят переводы, т. е. SATA за SAS, лучше всего проверять устройство SATA с прямым подключением к контроллеру SATA, чтобы исключить его потенциальные проблемы.
Параметры исправлений
Если сторонний драйвер будет определен как таковой, что не реализует необходимые API или переводы, можно перейти на предоставленные корпорацией Майкрософт альтернативы для SATA (StorAHCI.sys) и NVMe (StorNVMe.sys) или обратиться к изготовителю OEM или HBA, который предоставил драйвер SAS, и спросить о существовании более новой версии с надлежащей поддержкой.
Дополнительное устранение неполадок в драйверах Microsoft (SATA/NVMe)
Когда встроенные драйверы Windows, например StorAHCI.sys или StorNVMe.sys, используются для хранения данных устройства управления питанием, можно получить дополнительные сведения о возможных случаях сбоев во время обновления встроенного ПО.
Помимо операционного канала Класспнп, СторахЦи и Сторнвме будут регистрировать коды возврата, относящиеся к протоколу устройства, в следующем канале ETW:
Просмотр событий — Журналы приложений и служб — Microsoft — Windows — StorDiag — Microsoft-Windows-Storage-StorPort/Diagnose
Журналы диагностики не отображаются по умолчанию и могут быть активированы или показаны выбором команды «Просмотр» в EventViewer и элемента «Показать журналы аналитики и отладки» из раскрывающего меню.
Для сбора этих расширенных записей журнала включите журнал, воспроизведите сбой обновления встроенного ПО и сохраните журнал диагностики.
Вот пример обновления встроенного ПО на неисправном устройстве SATA из-за недопустимого образа для скачивания (код события: 258):
Указанное выше событие содержит подробные сведения об устройстве в значениях параметров 2–6. Здесь мы рассматриваем различные значения регистров ATA. Спецификации ACS ATA можно использовать для декодирования указанных ниже значений для сбоя команды Download Microcode:
Это сообщает нам, что операция обновления встроенного ПО была прервана устройством.
Обновление JunOS на коммутаторах EX4500 в VirtualChassis — что может пойти не так? Часть 2
Итак, не откладывая дело в долгий ящик, публикую вторую часть приведенного ранее поста. Выражаю благодарность за публикацию — приятно, что статья вас заинтересовала и тема нашла продолжение.
Напомню, что в прошлой части я остановился на том, что после перезагрузки одно из устройств VC не заработало должным образом. Как было справедливо замечено в одном из комментариев, получается, что я после всего этого пошел домой. Нет, первая часть описывает примерно 20 минут моей почти пятичасовой эпопеи. Пристегнулись? Поехали!
После перезагрузки не совсем понятно что же произошло и произошло ли, но главное – клиентский трафик пошел. Подключаюсь через выделеный менеджмент Ethernet-интерфейс и первая неожиданность – основным RE стал member1:
login as: user user@switch password: — JUNOS 12.3R12.4 built 2016-01-20 04:27:51 UTC user@switch>
В принципе это случается и не страшно, так как устройства у меня одинаковые с pre-provisioned конфигурацией VC и любое из них может быть мастером. Операционка обновилась и это хорошо. А вот это уже не хорошо:
user@switch> show chassis routing-engine Routing Engine status: Slot 1: Current state Master DRAM 1024 Memory utilization 45 percent CPU utilization: User 14 percent Background 0 percent Kernel 11 percent Interrupt 1 percent Idle 74 percent Model EX4500-40F Serial ID Start time 2016-06-02 01:28:45 Uptime 34 minutes, 55 seconds Last reboot reason Router rebooted after a normal shutdown. Load averages: 1 minute 5 minute 15 minute 0.59 0.80 0.66 user@switch>
Устройство видит только один RE, а их должно быть два. Дальнейшее расследование только подтверждает, что негорящие светодиоды неспроста:
user@switch> show virtual-chassis Preprovisioned Virtual Chassis Virtual Chassis ID: Virtual Chassis Mode: Enabled Mstr Mixed Neighbor List Member ID Status Serial No Model prio Role Mode ID Interface 0 (FPC 0) Inactive ХХХХХ ex4500-40f 129 Linecard N 1 vcp-1 1 vcp-0 1 (FPC 1) Prsnt ХХХХХ ex4500-40f 129 Master* N 0 vcp-1 0 vcp-0 user@switch>
Первое устройство, member0, опознано как Linecard и имеет статус Inactive – это означает, что оно не принимает активного участия в виртуальном шасси. Выделенные стек-интерфейсы (vcp-1 и vcp-0) активны, значит можно попробовать локальное подключение:
Вот оно что! Операционка обновилась только на втором устройстве, а на первом — старая (обратите внимание на версию файла прошивки FPC0 и FPC1), поэтому логика VC деактивировала его. Так или иначе, устройство есть и можно попробовать обновить его заново. Одна проблема – при обновлении я следовал гайдам от Juniper и положил образ в /var/tmp, соответственно там теперь пусто и нужно заливать образ заново. Сосредотачиваю все внимание на этом свиче и несколько раз пытаюсь обновить систему/перегрузить только его (member1 продолжает работать):
user@switch> request system software add /var/tmp/jinstall-XXX.tgz validate member 0 user@switch> request system reboot member 0
Несмотря на отсутствие познаний в Unix, на которой основана JunOS, строка «KDB: enter: panic» не внушает оптимизма. Кроме прочего, система вываливается в режим системной отладки (db>), а это совсем плохо. Для справки: у Juniper есть режим знакомой всем консоли, где производится настройка работающей железки, можно зайти в командную строку Unix под root и прочее; есть режим загрузчика loader> для восстановления и заливки образа операционной системы, примерно соответствующий rommon> Cisco; и есть режим дебага db>, который появляется при проблемах с физическими компонентами кстройства. Сделать в этом режиме можно очень мало, если вы не Juniper TAC инженер. В тот момент я не особо понимаю, что это такое и, как гордый прользователь Windows, пробую нажать «дальше»:
db> help DDB Quick Help ——————- Type ‘c’ to continue, ‘reset’ or ‘panic’ to restart.
. Много вывода при перезагрузке.
***** FILE SYSTEM MARKED CLEAN ***** switch (ttyu0) login: user Logging to master . Connection to master failed, enabling local login Password: — JUNOS 11.1R3.5 built 2011-06-25 01:18:46 UTC user@switch>
О чудо – система загружается, хоть и со старой версией. На тот момент я не осознавал, что эта старая версия грузится из резервного раздела (slice alternate), так как обновляемая версия записывается в основной раздел и в моем случае не может грузиться с него. Поэтому так важно по возможности обновить загрузчик – это еще одна спасительная соломинка при возникновении проблем. В качестве ремарки: обратите так же внимание на строки «Logging to master … Connection to master failed». У всех устройств, объединенных в VC единая консоль управления, то есть при подключении, например через SSH, мы сразу попадаем в консоль устройства-мастера. Так как в моем случае VC неработоспособен, я попадаю в режим управления локальной железки.
В процессе работы, я придумываю залить образ операционки на работоспособный RE и копировать между членами VC – это и быстрее и не надо постоянно отвлекаться на WinSCP. Работает это даже моем случае, так как каналы связи между устройствами активны.
Тем не менее, попытка обновления и перезагрузки каждый раз дает один и тот же результат – я оказываюсь о режиме системного дебага с последующей возможностью загрузить старую версию. Соответственно, проблема постоянна и способом повторения шагов я ничего не добьюсь. Тут мне приходит в голову иедя – ведь у меня есть устройство с работающей системой (member1) и есть флешка, на которую можно накатить снепшот и грузиться с нее. Так и делаю:
umass1: SanDisk Corporation U3 Cruzer Micro, rev 2.00/0.10, addr 4 da1 at umass-sim1 bus 1 target 0 lun 0 da1: Removable Direct Access SCSI-2 device da1: 40.000MB/s transfers da1: 973MB (1994385 512 byte sectors: 64H 32S/T 973C) user@switch> request system snapshot local partition media external user@switch> show system snapshot media external fpc0: ————————————————————————— error: external media missing or invalid
fpc1: ————————————————————————— Information for snapshot on external (/dev/da1s1a) (backup) Creation date: Jun 2 02:28:20 2016 JUNOS version on snapshot: jbase : 11.1R3.5 jkernel-ex: 11.1R3.5 jcrypto-ex: 11.1R3.5 jdocs-ex: 11.1R3.5 jswitch-ex: 11.1R3.5 jpfe-ex45x: 11.1R3.5 jroute-ex: 11.1R3.5 jweb-ex: 11.1R3.5 Information for snapshot on external (/dev/da1s2a) (primary) Creation date: Jun 2 02:29:21 2016 JUNOS version on snapshot: jbase : ex-12.3R12.4 jkernel-ex: 12.3R12.4 jcrypto-ex: 12.3R12.4 jdocs-ex: 12.3R12.4 jswitch-ex: 12.3R12.4 jpfe-ex45x: 12.3R12.4 jroute-ex: 12.3R12.4 jweb-ex: 12.3R12.4 fips-mode-powerpc: 12.3R12.4
Обратите внимание на сообщения при подключении флешки – она определилась как системное устройство da1, это понадобится в будущем. Снепшот на внешней флешке повторяет таковой на внутреннем хранилище устройства – версия 12.3 на основном разделе (/dev/da1s2a) и 11.1 – на резервном (/dev/da1s1a). Имена слайсов так же могу пригодиться, если вы захотите загрузить систему из определенного раздела. Вставляю флешку в проблемное устройство и продолжаю:
Здесь я опять-же из предосторожности зашел в сессию управления локальным устройством, скорее всего можно было перегрузить member0 из консоли мастера. При перезагрузке вижу постоянно цикличную последовательность:
Свич никуда дальше этих повторяющихся строк не движется. Что за. Не можешь найти ядро? Через некоторое время обращаю внимание на предпоследнюю строку, жму Enter и попадаю в лоадер:
Жиденько, но все же лучше, чем цикличная перезагрузка. Сам режим лоадера как раз создан для восстановления системы, то есть я в правильном месте. Время работы перевалило за 2 часа… Пробую разные варианты расположения образа системы и обновления – без результата.
Собственно эти строки должны работать, но почему-то не работают – то ли я на тот момент уже ничего не соображал, то ли что-то еще. Я вижу ту же самую циклическую перезагрузку и ругань на отсутствие ядра. В процессе постоянной перезагрузки всплывает еще одна интересность:
Firmware Version: 01.00.00 USB: scanning bus for devices. 3 USB Device(s) found scanning bus for storage devices. 1 Storage Device(s) found ELF file is 32 bit Consoles: U-Boot console FreeBSD/PowerPC U-Boot bootstrap loader, Revision 2.4 (hmerge@svl-junos-pool130.juniper.net, Sat Mar 26 02:46:28 PDT 2011) Memory: 1024MB bootsequencing is enabled bootsuccess is not set new boot device = disk2
Для меня в тот момент это не более, чем предположение, но памятуя, что Juniper обозначает устройства с 0, мне кажется странным присутствие «disk2» — флешка у меня одна. Кроме этого, когда я вставлял флешку, она опозналась как da1. Если вы вернетесь немного назад, можно увидеть, что устройство пыталось грузиться со 2 диска сразу после перезагрузки из консоли (когда я указал внешнюю флешку как устройство для загрузки) но до текущего момента я этого не замечал. Возвращаемся в лоадер и подтверждаем опасения, диска 2 нет, а флешка является нулевым устройством:
Все? Да как бы не так! Система снова пытается грузиться с диска 2, но теперь я чувствую, что на правильном пути. Попутно перебираю близлежащие варианты c разными слайсами на флешке (nextboot diskXsY), без результата. Уже почти отчаявшись, нахожу информацию, что загрузочное устройство должно задаваться как переменная окружения из U-boot mode. Уж не знаю как описать этот четвертый режим и что там можно делать, но попасть туда можно прервав процесс загрузки нажатием Ctrl+C в самом его начале, когда система опрашивает USB устройства (USB: scanning bus for devices. ). Первая строка содержит INTERRUPT в ограничителях <>, но из-за него съезжает разметка и шрифты, поэтому ограничители убрал:
. Boot media /dev/da1 has dual root support WARNING: JUNOS versions running on dual partitions are not same ** /dev/da1s1a FILE SYSTEM CLEAN; SKIPPING CHECKS clean, 274948 free (84 frags, 34358 blocks, 0.0% fragmentation) switch (ttyu0) login: user Logging to master . Connection to master failed, enabling local login Password:
— JUNOS 12.3R12.4 built 2016-01-20 04:27:51 UTC warning: This chassis is operating in a non-master role as part of a virtual-chassis (VC) system. warning: Use of interactive commands should be limited to debugging and VC Port operations. warning: Full CLI access is provided by the Virtual Chassis Master (VC-M) chassis. warning: The VC-M can be identified through the show virtual-chassis status command executed at this console. warning: Please logout and log into the VC-M to use CLI. user@switch>
Посмотрим, что я увидел после перезагрузки:
«WARNING: JUNOS versions running on dual partitions are not same» не страшно и ожидаемо, ведь новая версия содержится только в основном слайсе устройства.
«Connection to master failed. » и «warning: This chassis is operating in a non-master role. » не страшно, так как VC нужно время, чтобы восстановить связь между членами и синхронизоровать конфигурацию.
После нескольких минут ожидания, система сама просит перезапустить консоль (WARNING: cli has been replaced by an updated version) и теперь уже грузится новая версия на правильном RE.
user@switch> show chassis routing-engine Routing Engine status: Slot 0: Current state Master DRAM 1024 Memory utilization 50 percent CPU utilization: User 43 percent Background 0 percent Kernel 24 percent Interrupt 1 percent Idle 32 percent Model EX4500-40F Serial ID Start time 2016-06-02 03:43:20 Uptime 3 minutes, 22 seconds Last reboot reason Router rebooted after a normal shutdown. Load averages: 1 minute 5 minute 15 minute 2.40 1.12 0.46 Routing Engine status: Slot 1: Current state Backup DRAM 1024 Memory utilization 44 percent CPU utilization: User 40 percent Background 0 percent Kernel 30 percent Interrupt 1 percent Idle 28 percent Model EX4500-40F Serial ID Start time 2016-06-02 01:28:45 Uptime 2 hours, 17 minutes, 57 seconds Last reboot reason Router rebooted after a normal shutdown. Load averages: 1 minute 5 minute 15 minute 0.49 0.46 0.44
user@switch> show virtual-chassis
Preprovisioned Virtual Chassis Virtual Chassis ID: Virtual Chassis Mode: Enabled Mstr Mixed Neighbor List Member ID Status Serial No Model prio Role Mode ID Interface 0 (FPC 0) Prsnt ex4500-40f ХХХХ 129 Master* N 1 vcp-1 1 vcp-0 1 (FPC 1) Prsnt ex4500-40f ХХХХ 129 Backup N 0 vcp-1 0 vcp-0
Победа! Полная и безоговорочная! Сказать, что я был доволен собой – ничего не сказать, ЧСВ просто зашкаливало. Несмотря на то, что моя работа продлилась порядка 4 часов, это было уже не так важно, так как клиенты этого не почувствовали. Я не только выдал себе виртуальную медаль, но и сохранил достаточно много денег моей компании. Впечатлений за эти 4 часа я получил столько, что потом понадобилось много дней (и пива), чтобы собрать все воедино и понять полную картину.
Теперь осталось только сделать снепшоты на внутреннее хранилище в основной раздел и, через неделю-две – в резервный. Почему через неделю – для обкатки новой версии в продакшне, так как загрузить старую версию системы из резервного раздела гораздо проще, чем ее даунгрейдить на всем устройстве.
Согласно Juniper TAC, проблемы с обновлением возникли из-за повреждения основного загрузочного раздела. Сделать с этим ничего нельзя и коммутатор надо сдавать по гарантии. Я все-таки очень надеюсь, что проблема была вызвана повреждением файловой системы (некорректная перезагрузка или подобное) и была исправлена в процессе обновления (Un-Protected 1 sectors Erasing Flash…. done), когда я задавал переменную окружения.
С какого перепуга устройство хотело грузиться с disk2, если на него никто явно не указывал и его не было в системе – непонятно, TAC так же затруднился с комментариями. В логах потом можно было даже проследить, что disk2 появляется из ниоткуда (обратите внимание, что new boot device = disk1s2 меняется на new boot device = disk2):
user@switch> request system reboot member 0 media external Reboot the system? [yes,no] (no) yes Rebooting fpc0 *** FINAL System shutdown message from root@ switch *** System going down IMMEDIATELY iuriia@CORE> JWaiting (max 300 seconds) for system process `vnlru_mem’ to stop. done Waiting (max 300 seconds) for system process `vnlru’ to stop. done Waiting (max 300 seconds) for system process `bufdaemon’ to stop. done Waiting (max 300 seconds) for system process `syncer’ to stop… Syncing disks, vnodes remaining. 2 2 2 0 1 1 1 0 0 0 0 0 done syncing disks… All buffers synced. Uptime: 23m53s recorded reboot as normal shutdown Rebooting… U-Boot 1.1.6 (Mar 26 2011 — 04:34:19) Board: EX4500-40F 10.4 EPLD: Version 6.2 (0x82) DRAM: Initializing (1024 MB) FLASH: 8 MB Firmware Version: 01.00.00 USB: scanning bus for devices… 3 USB Device(s) found scanning bus for storage devices… 1 Storage Device(s) found ELF file is 32 bit Consoles: U-Boot console FreeBSD/PowerPC U-Boot bootstrap loader, Revision 2.4 (hmerge@svl-junos-pool130.juniper.net, Sat Mar 26 02:46:28 PDT 2011) Memory: 1024MB bootsequencing is enabled bootsuccess is set new boot device = disk1s2:
can’t load ‘/kernel’ can’t load ‘/kernel.old’ Press Enter to stop auto bootsequencing and to enter loader prompt. Watchdog timed out. Resetting the board. U-Boot 1.1.6 (Mar 26 2011 — 04:34:19) Board: EX4500-40F 10.4 EPLD: Version 6.2 (0x81) DRAM: Initializing (1024 MB) FLASH: 8 MB Firmware Version: 01.00.00 USB: scanning bus for devices… 3 USB Device(s) found scanning bus for storage devices… 1 Storage Device(s) found ELF file is 32 bit Consoles: U-Boot console FreeBSD/PowerPC U-Boot bootstrap loader, Revision 2.4 (hmerge@svl-junos-pool130.juniper.net, Sat Mar 26 02:46:28 PDT 2011) Memory: 1024MB bootsequencing is enabled bootsuccess is not set new boot device = disk2
Фактически, данная проблема увеличила затраченое время часа на полтора. Да, свич так же ругается на отсутствие ядра, но почему потом система пытается использовать disk2, если система его вроде как не видела в loader> не понятно. Могу предположить, что при проблемах с загрузкой, устройство пробует циклически перебирать диски, но опять-же устройства disk2 система не видела. Как и почему потом та же самая флешка в дальнейшем с успехом загрузила устройство тоже вызывает вопросы.
Вполне возможно, что я ошибся здесь:
ведь при перезагрузке настройки loader’a теряются. Надо было попробовать «boot» вместо «reboot», но тогда я этого не сделал.
Новая версия системы ощутимо увеличила нагрузку на устройство. На старой версии, загрузка процессора в течение дня была порядка 27-30%, после обновления – 45-48%, но ведь ни достаточно простая конфигурация устройства ни характеристики трафика не поменялись. После нескольких удаленных сессий с Juniper TAC причину установить не удалось – были предположения об утечке памяти и подобных проблемах, но нет. Странно, но пришлось принять как факт.
Внимательный читатель мог обратить внимание, что имена устройств, отображаемые в лоадере (disk0) и использованого для успешной загрузки (disk1 и затем /dev/da1s1a) разные. С чем это связано не рискну утверждать. Могу предположить, что имена меняются в зависимости от степени успешной загрузки системы. Загрузил лоадер — получил одни имена устройств, обращаешься из db> — будут другие; из CLI мы вообще вызываем устройства через «media external» и «media internal». В общем, пока только предположение.
Большинство приведенных выкладок и команд я собрал воедино в гайд задолго до обновления. После этого периодически перичитывал и дополнял его, если мне на ум приходили возможные проблемы. В нем не было разве что режима db> и процедур ==>setenv. Понятное дело, всего предусмотреть не вышло и что-то не работало как должно. Но положа руку на сердце – без этого гайда и времени на его мысленную обкатку, я бы сдался. Тем более, что это была ночная работа и острота ума была снижена.
Бекапы – хоть они и не помогли мне сильно, их наличие успокаивало совесть и душу. В худшем случае, даже если все внутреннее хранилище будет повреждено, я бы скопировал текстовый конфиг в консоль. Эти два пунтка залог того, что вы сконцентрируетесь на работе, а не анализе как вернуть все в исходное состояние и что делать дальше.
Из существенных недочетов: в процессе работы у меня было запущено несколько вкладок PuTTY, пишущих лог в один файл. Разобрать потом все по отдельным устройствам и временным меткам было очень сложно, лучше было воспользоваться SecureCRT или запустить отдельное окно на разных устройствах, тем более, что у меня было достаточно средств для этого.
И в завершении – картинка с места событий. Надеюсь этот пост будет вам полезен. Удачи в грядущих обновлениях!
PS в выводах команд я использовал разметку для обычного кода «code», которая смотрится хуже, чем разметка с бэкграундом исходного кода определенного языка или BASH. Однако разметка «code» позволяет выделение жирным шрифтом, что мне было важно для выделения интересных мест в выводе команд. Если кто поделится как сделать и то и другое (бэкграунд+жирный шрифт внутри), буду признателен и обещаю использовать в дальнейшем. Апдейт: выяснилось, что в разных браузерах и версиях разметка кода отображается по-разному. Беду курить дальше, как сделать текст более наглядным и читаемым.
Сразу коротко ответ: обновление, которое представляет из себя новую прошивку BIOS, установка подразумевает автоматическое обновление биоса.
