Рулетка оновлення BIOS: найвідважніше натискання в ІТ

Чому це здається рулеткою (і чому це не так)

Оновлення BIOS у продакшн лякає з тієї ж причини, що й заміна шасі шасі літака посеред польоту: це фундаментально, це важко спостерігати під час роботи, і якщо щось піде не так, ви не «налагоджуєте», а «відновлюєтеся».

BIOS і UEFI прошивки знаходяться нижче ОС. Вони вирішують, як навчається пам’ять, як домовляються лінії PCIe, як перелічуються завантажувальні пристрої, як керуються стани живлення, як платформа експонує таблиці ACPI і як поводяться функції безпеки на кшталт Secure Boot і TPM. Якщо будь-що з цього зміниться несподівано, ваш раніше стабільний ядро та стек сховища можуть почати влаштовувати істерики.

Але «рулетка» натякає на чистий випадок. Насправді більшість поганих наслідків походить від дуже конкретних, відтворюваних режимів відмов:

• Припущення щодо значень за замовчуванням (порядок завантаження, режим SATA, стан Secure Boot), які тихо скидаються.
• Недооцінка залежностей (прошивка BMC/IPMI, опціональні ROM NIC, прошивка RAID/HBA).
• Зміни критичних для продуктивності налаштувань без помітності (C-states, NUMA, SMT, ASPM, покоління PCIe).
• Відсутність шляху відновлення, коли хост не повертається (віддалий консольний доступ, відомий робочий образ, запасне обладнання).

Якщо ви ставитеся до оновлень BIOS як до деплоїв коду — плануйте, тестуйте на стаді, перевіряйте, відкочуйте — ви перетворюєте рулетку на рутину. Не «безпечніше». Просто контрольованіше.

Жарт №1: Прошивка BIOS — єдиний випадок, коли сервер ввічливо просить вас не робити те єдине, у чому дата-центри найкращі: відключати живлення.

Цікаві факти та історичний контекст

• BIOS походить з епохи ранніх IBM PC, де прошивка в ROM забезпечувала ініціалізацію апаратури і базовий інтерфейс для завантаження ОС.
• UEFI замінив «класичний BIOS» на сучасних платформах щоб підтримувати більші диски, швидші шляхи завантаження та більш розширюване передзавантажувальне середовище.
• Secure Boot з’явився, щоб захистити ланцюжок завантаження, але операційно це також породило нову категорію «вчора працювало — сьогодні не завантажується».
• Мікрокод CPU — це жива річ: сучасні оновлення BIOS часто пакують ревізії мікрокоду, що змінюють поведінку CPU без змін ядра.
• Ера Spectre/Meltdown зробила прошивки темою загальноопераційної уваги, а не лише приміткою «команди апаратного забезпечення».
• Тренування пам’яті керується прошивкою; оновлення можуть тонко змінювати таймінги і межі стабільності, тому «випадкові помилки ECC» іноді корелюють із ревізіями прошивки.
• Підтримка NVMe дозрівала з часом; ранні платформи відомі дивною послідовністю ініціалізації та несподіваними змінами завантаження в процесі вдосконалення PCIe ініціалізації.
• Вендори відправляють «налаштування за замовчуванням, оптимізовані для маркетингу», які оптимізовані під бенчмарки, а не під ваші SLO щодо затримки, бюджет енергоспоживання чи детермінізм шляху зберігання.

Один цитат, який варто витатуювати на внутрішній стороні кожного блокнота он-кола: «Надія — не стратегія.» — генерал Гордон Р. Салліван.

Що насправді змінює оновлення BIOS (те, що болить пізніше)

1) Механіка завантаження: записи UEFI, порядок і перелік пристроїв

Оновлення BIOS може:

• Скинути порядок завантаження до «налаштувань вендора», що зазвичай означає «який пристрій голосніше на PCIe».
• Відтворити або видалити записи завантаження UEFI (особливо якщо NVRAM скидається або перезаписується).
• Змінити порядок перелічення дисків. Ваш /dev/sda вчора може стати /dev/sdb сьогодні. Якщо ви все ще залежите від цього, ви ризикуєте.

Для Linux: ви вже маєте використовувати UUID у /etc/fstab і завантажувач, який не ламкий. Але багато реальних флотів мають «легасі винятки», які стають інцидентом завтра.

2) Поведінка CPU: мікрокод, стани живлення, можливості віртуалізації

Оновлення BIOS часто приносять:

• Новий мікрокод, що може змінювати поведінку прогнозування переходів і налаштування мітгацій.
• Інакші значення за замовчуванням для C-states і P-states (економія енергії проти затримки).
• Перемикачі віртуалізації (Intel VT-x/VT-d, AMD-V/IOMMU), які іноді скидаються.

Якщо ваше навантаження чутливе до затримок, «допомога» системи управління живленням може бути лиходієм. Якщо навантаження орієнтоване на пропускну здатність, мікрокодні міри можуть з’їсти відсотки продуктивності. Ви не сперечаєтесь про це абстрактно. Ви вимірюєте і вирішуєте.

3) Пам’ять: тренування, інтерлівінг, поведінка ECC

За пам’ять відповідає прошивка. Зміна може:

• Зрушити межі стабільності: граничні DIMM стануть помітними.
• Змінити відображення NUMA або поведінку інтерлівінгу пам’яті.
• Відкрити (або приховати) шляхи звітування виправлених помилок ECC.

4) Шлях збереження: AHCI/RAID режим, особливості NVMe, швидкість PCIe

Збереження — це місце, де «він завантажується» недостатньо. Оновлення BIOS може:

• Перемкнути режим SATA (AHCI ↔ RAID/RST), змінюючи видимість пристроїв і драйвери.
• Змінити домовленості PCIe: пристрої, що працювали на Gen4, можуть відкотитися до Gen3 (або навпаки, викликаючи нестабільність).
• Скинути опції «Above 4G decoding» або Resizable BAR, що впливають на відображення пристроїв, особливо при великій кількості NVMe.

5) Позиція безпеки: стан TPM, Secure Boot, бази ключів

Оновлення BIOS іноді скидають параметри безпеки або змінюють спосіб експозиції функцій TPM/TCG. Якщо ви використовуєте вимірюване завантаження, шифрування дисків або атестацію, трактуйте зміни прошивки як зміни політики — бо так воно і є.

Передполітна перевірка: що зафіксувати перед діями

Перед оновленням прошивки вам потрібні дві речі: знімок реальності і план відновлення, що не залежить від оптимізму.

Зафіксуйте «відбиток» прошивки

• Версія BIOS/UEFI і дата релізу.
• Версія прошивки BMC/IPMI.
• Версія мікрокоду CPU, що наразі використовується.
• Режим завантаження (UEFI проти Legacy) і стан Secure Boot.
• Версії прошивок контролерів RAID/NVMe (якщо застосовано).
• Швидкості PCIe для критичних пристроїв.

Зафіксуйте налаштування платформи, які вам важливі

Це та частина, яку люди пропускають, бо нудно і «потім подивлюсь». «Потім» — це коли ви дивитесь у віддалену консоль опівночі і намагаєтесь згадати, чи вимикали C-states на базі даних.

• Порядок завантаження і записи UEFI.
• TPM увімкнено/вимкнено та стан володіння (де релевантно).
• Налаштування віртуалізації та IOMMU.
• Профіль живлення: продуктивність проти збалансованого.
• Опції PCIe, такі як Above 4G decoding, SR-IOV.
• Режим SATA, якщо SATA взагалі присутній.

Визначте відновлення

• Перевірений доступ до віддаленої консолі (iKVM/Redfish/IPMI).
• Відомі робочі завантажувальні носії або шлях мережевого завантаження, що працює сьогодні.
• Тестований позашляховий контроль живлення.
• Шлях відкоту: метод підтримуваного вендором пониження BIOS або процедура подвійного BIOS/резервного образу.
• План «вибратися»: запасна потужність хостів, вікно обслуговування і людина на місці, якщо віддалений доступ відмовить.

Практичні завдання: команди, виводи та рішення, які ви приймаєте

Це ті команди, які я справді хочу бачити в ранбуку. Не тому, що вони модні — а тому, що змушують порівнювати «до» і «після» так, щоб впіймати тихі зміни.

Завдання 1: Отримати версію BIOS (і підтвердити, що читаєте платформу, а не здогадки ОС)

cr0x@server:~$ sudo dmidecode -s bios-version
2.4.7

Що це означає: Це версія прошивки, яку повідомляє платформа. Зафіксуйте її.

Рішення: Якщо ви не можете чітко ідентифікувати поточний BIOS, зупиніться. Ви не можете керувати змінами, які не вимірюєте.

Завдання 2: Отримати дату релізу BIOS (корисно, коли вендори повторно використовують шаблони версій)

cr0x@server:~$ sudo dmidecode -s bios-release-date
08/14/2024

Що це означає: Допомагає зіставити зміни поведінки з ритмами випуску вендора.

Рішення: Якщо встановлена прошивка застаріла відносно бази флоту — плануйте поетапні оновлення; не стрибайте на три роки одразу, якщо вендор попереджає проти цього.

Завдання 3: Підтвердити UEFI чи Legacy завантаження (це впливає на кроки відновлення)

cr0x@server:~$ test -d /sys/firmware/efi && echo UEFI || echo Legacy
UEFI

Що це означає: Режим UEFI активний, якщо існує sysfs EFI.

Рішення: Якщо ви очікували UEFI, але бачите Legacy, ймовірно вже є некоректна конфігурація; не продовжуйте, поки не дізнаєтесь чому.

Завдання 4: Перевірити стан Secure Boot (збережеться від сюрпризів «некоректний підпис» при завантаженні)

cr0x@server:~$ sudo mokutil --sb-state
SecureBoot enabled

Що це означає: Secure Boot увімкнено; завантажувачі та ядра повинні бути належним чином підписані.

Рішення: Якщо Secure Boot увімкнено в продакшні, перевірте, що шлях завантаження після оновлення все ще підписано й довірено. Якщо ви спираєтесь на власні модулі ядра, плануйте їх підпис і реєстрацію ключів.

Завдання 5: Зафіксувати поточні записи UEFI (щоб відновити їх)

cr0x@server:~$ sudo efibootmgr -v
BootCurrent: 0003
Timeout: 1 seconds
BootOrder: 0003,0001,0002
Boot0001* UEFI PXE IPv4 (MAC:3C:FD:FE:12:34:56)
Boot0002* UEFI PXE IPv6 (MAC:3C:FD:FE:12:34:56)
Boot0003* ubuntu HD(1,GPT,1c2d...,0x800,0x100000)/File(\EFI\ubuntu\shimx64.efi)

Що це означає: Маєте явні записи завантаження; BootOrder важливий; є PXE.

Рішення: Збережіть цей вивід. Якщо після оновлення машина завантажиться в PXE невірно, ви відновите BootOrder і перевірите запис диска.

Завдання 6: Ідентифікувати диски за стабільними ID (уникнути залежності від /dev/sdX)

cr0x@server:~$ lsblk -o NAME,TYPE,SIZE,FSTYPE,UUID,MOUNTPOINTS
sda     disk  1.8T
├─sda1  part  1G   vfat   3A1B-2C3D /boot/efi
└─sda2  part  1.8T ext4   2c7d...    /
nvme0n1 disk  3.5T
└─nvme0n1p1 part 3.5T xfs  9b12...   /data

Що це означає: Ви можете зіставити файлові системи з UUID; переживете перейменування.

Рішення: Якщо /etc/fstab використовує шляхи /dev/sdX, виправте це перед змінами прошивки. Прошивка не дбає про ваші ярлики.

Завдання 7: Підтвердити підказки режиму SATA (AHCI vs RAID) з повідомлень ядра

cr0x@server:~$ sudo dmesg | grep -E "ahci|megaraid|mdraid|rst|VROC" | head
[    1.912345] ahci 0000:00:17.0: AHCI 0001.0301 32 slots 6 ports 6 Gbps 0x3f impl SATA mode

Що це означає: Платформа експонує AHCI. Якщо перемкнеться на RAID, імена пристроїв і драйвери можуть змінитись.

Рішення: Якщо сьогодні ви бачите драйвери RAID і не планували цього, з’ясуйте причину. Якщо сьогодні AHCI, переконайтеся, що оновлення BIOS не скине в RAID за замовчуванням.

Завдання 8: Перевірити ревізію мікрокоду CPU, що наразі використовується

cr0x@server:~$ grep -m1 microcode /proc/cpuinfo
microcode	: 0x2f

Що це означає: Ревізія мікрокоду видима ядру. Оновлення BIOS може змінити її, навіть якщо пакет мікрокоду в ОС незмінний.

Рішення: Зафіксуйте «до». Після оновлення порівняйте. Якщо зміниться продуктивність — підозрюйте мікрокод.

Завдання 9: Перевірити активні мітгації ядра (контекст для післяоновлювальних відмін у продуктивності)

cr0x@server:~$ grep . /sys/devices/system/cpu/vulnerabilities/* | head
/sys/devices/system/cpu/vulnerabilities/spectre_v2: Mitigation: Retpolines; IBPB: conditional; STIBP: disabled; RSB filling
/sys/devices/system/cpu/vulnerabilities/mds: Mitigation: Clear CPU buffers; SMT vulnerable

Що це означає: Погляд ядра на застосовані мітгації. Прошивка/мікрокод можуть змінити доступність або ввімкнення мітгацій.

Рішення: Якщо оновлення BIOS змінює статус мітгацій, очікуйте вимірного впливу на продуктивність. Вирішіть, чи прийнятний цей баланс безпеки, і документуйте його.

Завдання 10: Перевірити швидкість/ширину PCIe для критичних пристроїв (NIC, NVMe HBA)

cr0x@server:~$ sudo lspci -s 3b:00.0 -vv | grep -E "LnkCap|LnkSta"
LnkCap: Port #8, Speed 16GT/s, Width x16, ASPM L1, Exit Latency L1 <64us
LnkSta: Speed 16GT/s, Width x16

Що це означає: Пристрій погодив PCIe Gen4 x16 (16GT/s). Після оновлення BIOS ви можете побачити пониження (8GT/s Gen3) або зменшення ширини.

Рішення: Якщо швидкість/ширина лінку зменшилась після оновлення, перевірте налаштування PCIe в BIOS, посадку riser або помилки прошивки перед тим, як звинувачувати «мережу» чи «сховище».

Завдання 11: Перевірити стан NVMe і журнали помилок (ловіть нові AER-шторми рано)

cr0x@server:~$ sudo nvme smart-log /dev/nvme0
Smart Log for NVME device:nvme0 namespace-id:ffffffff
critical_warning                    : 0
temperature                         : 41 C
available_spare                     : 100%
percentage_used                     : 2%
media_errors                        : 0
num_err_log_entries                 : 0

Що це означає: Диск зараз у нормі. Після оновлення слідкуйте за ростом записів журналу помилок або раптовими змінами температури через зміну станів живлення.

Рішення: Якщо записи помилок різко зростають після оновлення, розгляньте зміни управління живленням PCIe або нестабільність лінку, введену прошивкою.

Завдання 12: Перевірити на AER-спам PCIe (поширена «помилка продуктивності» після оновлення)

cr0x@server:~$ sudo journalctl -k -b | grep -i aer | head
Jan 22 10:14:02 server kernel: pcieport 0000:00:1c.0: AER: Corrected error received: id=00e0
Jan 22 10:14:02 server kernel: pcieport 0000:00:1c.0: PCIe Bus Error: severity=Corrected, type=Physical Layer

Що це означає: Виправлені AER помилки все одно можуть розбити продуктивність через шум переривань/журналів і перевстановлення лінку.

Рішення: Якщо після оновлення з’явився AER-спам, розглядайте це як проблему платформи: перевірте налаштування PCIe, нотатки прошивки та фізичну посадку; не просто заглушайте логи.

Завдання 13: Підтвердити час і NTP після оновлення (так, прошивка може зламати це)

cr0x@server:~$ timedatectl
               Local time: Wed 2026-01-22 10:20:11 UTC
           Universal time: Wed 2026-01-22 10:20:11 UTC
                 RTC time: Wed 2026-01-22 10:20:10
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Що це означає: RTC і системний час синхронні та адекватні.

Рішення: Якщо час неправильний після оновлення BIOS, виправте негайно. Неправильний час ламає TLS, кластерні системи, кореляцію логів і вашу здатність довести, що сталося.

Завдання 14: Перевірити стан пулу ZFS (якщо ви використовуєте ZFS, перевіряйте щоразу)

cr0x@server:~$ sudo zpool status -x
all pools are healthy

Що це означає: Немає відомих проблем з пулами наразі.

Рішення: Якщо оновлення BIOS спричиняє зміни контролера зберігання, вам потрібна базова лінія. Після оновлення перевірте знову; будь-які нові помилки контрольних сум — червоний сигнал, а не «ймовірно нормально».

Завдання 15: Перевірити multipath (SAN або подвійний шлях NVMe-oF)

cr0x@server:~$ sudo multipath -ll | head -n 12
mpatha (3600508b400105e210000900000490000) dm-2 IBM,2810XIV
size=500G features='1 queue_if_no_path' hwhandler='0' wp=rw
|-+- policy='service-time 0' prio=50 status=active
| `- 3:0:0:1 sdb 8:16 active ready running
`-+- policy='service-time 0' prio=10 status=enabled
  `- 4:0:0:1 sdc 8:32 active ready running

Що це означає: Є активний шлях і доступний другий шлях; пріоритети виглядають адекватно.

Рішення: Якщо після оновлення шлях зникає, перевіряйте нумерацію PCIe/NIC, налаштування SR-IOV або взаємодії прошивок HBA перед тим, як лізти в конфігурації SAN.

Завдання 16: Підтвердити доступність BMC (це потрібно, перш ніж щось «забрикати»)

cr0x@server:~$ ipmitool -I lanplus -H bmc01 -U admin chassis status
System Power         : on
Power Overload       : false
Power Interlock      : inactive
Main Power Fault     : false
Power Control Fault  : false
Power Restore Policy : previous

Що це означає: Позашляховий контроль працює і шасі відповідає.

Рішення: Якщо ви не можете надійно зв’язатися з BMC, не робіть віддалене оновлення BIOS. Перш за все виправте позашляховий доступ або заплануйте роботу на місці.

Швидкий план діагностики

Після оновлення BIOS найгірший час починати «широку перевірку» — коли у вас кровоточить доступність. Потрібен триаж, що звужує проблему за хвилини.

Перше: чи можете ви дістатися до машини і побачити, на якому етапі вона зупиняється?

• Позашляхова консоль: проходить POST? показує меню завантаження? зависає на тренуванні пам’яті?
• Стан живлення: чи йде в цикл перезавантажень? вимикається одразу?
• Піки/POST-коди (якщо вони є): не гламурно, але прямолінійно.

Друге: якщо воно завантажується, чи стабільний ланцюжок завантаження?

• UEFI проти Legacy змінилося?
• BootOrder скинувся на PXE?
• Secure Boot змінився і відкидає завантажувач?
• Режим диска змінився (AHCI/RAID) і приховує кореневий диск?

Третє: якщо ОС працює, що змінилося під нею?

• Домовленість PCIe: швидкість/ширина лінку, зниклі пристрої, AER-спам.
• Стани живлення CPU: нові піки затримок; змінена поведінка масштабування частоти.
• Маршрути переривань: поведінка MSI/MSI-X може зміщуватися; слідкуйте за насиченням IRQ на одному ядрі.
• Мікрокод/мітгації: регресії продуктивності; нова позиція безпеки.
• Шляхи зберігання: деградація multipath, таймаути NVMe, невідповідність прошивок контролера.

Найшвидші перевірки вузьких місць (список «не думай надто багато»)

1. Скан логів ядра: помилки, AER, IOMMU fault, скидання NVMe.
2. Наявність пристроїв: lspci, lsblk, multipath; підтвердьте, що критичні контролери є.
3. Домовленість лінку: перевірте LnkSta для NIC/HBA; пониження покоління — курильний пістолет.
4. Поведіка частоти CPU: підтвердьте governor і turbo; скидання політик живлення — поширене.
5. Затримки зберігання: швидкий погляд iostat; ще не бенчмарк, просто помічаємо пожежу.

Три корпоративні міні-історії з прошивкових окопів

Міні-історія №1: інцидент через хибне припущення

Середня компанія мала змішаний флот: деякі вузли завантажувалися з дзеркальних SATA SSD, деякі з NVMe, а кілька старих «спеціальних» машин все ще завантажувалися в Legacy-режимі, бо «так було простіше роки тому». Команда запланувала оновлення BIOS у стійці в тихий вікно.

Хибне припущення було простим: «Порядок завантаження стабільний». На половині машин після оновлення прошивка скинула BootOrder і підняла PXE вище локального диска. Хости піднялися, попросили мережу про образ завантаження і — оскільки PXE середовище все ще було налаштоване на провіжнінг — деякі почали процес інсталяції. Інші просто зависли в підказці. Усі вони опинилися недоступними.

Інженер он-кола зробив те, що робить більшість: звинуватив оновлення ОС, яке відбулося раніше того тижня. Витратили час, шукаючи зміни пакетів і регресії ядра, яких не було. Тим часом реальна проблема була видна в віддаленій консолі: привітний банер PXE, що чекає.

Виправлення було нудним: використати efibootmgr на машинах, що ще мали доступ, і налаштування BIOS на тих, що не мали, щоб відновити локальне завантаження першочергово. Довгострокове виправлення було менш захопливим, але важливішим: стандартизувати режим завантаження (UEFI), стандартизувати ідентифікатори дисків і трактувати порядок завантаження як конфігурацію, яку потрібно зафіксувати й відновлювати.

Постмортем мав одне речення, що важило: «Ми припускали, що значення за замовчуванням залишаться». Значення за замовчуванням не стійкі. Значення за замовчуванням — це уява вендора про ваші пріоритети, і вендори ніколи не бачили вашого пейджера.

Міні-історія №2: оптимізація, що відбилася бумерангом

Інша команда обслуговувала низьколатентні сервіси і раніше налаштувала BIOS для продуктивності: обмежені C-states, профіль «performance», і кілька налаштувань PCIe, щоб тримати пристрої активними й чутливими. У них була документована базова конфігурація, але вона не була застосована автоматично.

Прийшло оновлення BIOS із нотаткою про «покращену енергоефективність» і «розширену сумісність PCIe». Воно також скинуло профіль живлення на збалансований режим і знову увімкнуло глибші пакетні C-states. Системи завантажилися нормально. Все зелене. Жодних тривог.

Потім графіки зрушили. P99 затримки повільно піднялися під навантаженням, не настільки, щоб відразу спрацював пейджер, але достатньо для скарг клієнтів. Використання CPU виглядало нижчим, що ще більше плутало: машини «працювали менше», виконуючи ту ж роботу. Декілька інженерів коротко відсвяткували ефективність — ненадовго.

Бумеранг прийшов від латентності пробудження і поведінки масштабування частоти. При сплесках навантаження ядра ставали більш агресивно в сплячий стан і повільніше виходили з нього. Це прямо трансформувалося в хвостову затримку. Виправлення полягало в повторному застосуванні профілю продуктивності і верифікації, за допомогою вимірювань, що налаштування дійсно зберігаються.

Урок: «оптимізація» в нотатках релізу прошивки рідко співпадає з вашою цільовою функцією. Вендор тестує за своїми наборами і для загальних навантажень. Якщо ви тонували під затримку — переналаштовуйте після змін прошивки і доведіть це даними.

Міні-історія №3: нудна, але правильна практика, що врятувала день

Одна команда, що працювала з великим обсягом сховища, підтримувала звичку, що виглядала нав’язливою: перед застосуванням на всіх вузлах кожне оновлення BIOS спочатку застосовували на двох канарках — на одному «нормальному» вузлі і на одному «дивному» (інший NIC, інший HBA, інша конфігурація пам’яті). Вони фіксували відбитки до/після: версію BIOS, мікрокод, стан PCIe лінку і набір перевірок затримки зберігання.

Під час одного циклу оновлення «дивна» канарка повернулася з тим, що її NVMe HBA працював на зменшеній ширині PCIe. Воно все ще працювало. Просто повільніше. Логи ядра показували виправлені AER помилки, і лінк погоджувався вниз. Схоже на апаратну проблему — поки вони не зв’язали це зі зміною прошивки і не відтворили через перезавантаження.

Оскільки це була канарка, а не масове розгортання, у них був час. Вони протестували налаштування BIOS, пов’язане з управлінням живленням PCIe, і вимкнули ASPM для того слоту. Лінк стабілізувався на очікуваній ширині і швидкості. Вони додали це налаштування до післяоновлювального чек-листа і перевірили на інших вузлах.

Без аварії. Без впливу на клієнтів. Просто тихий внутрішній запис: «Прошивка X потребує принудового відключення управління живленням PCIe для HBA Y». Це такий операційний виграш, що не отримує оплесків, бо нічого не загорілося.

Жарт №2: найкраще розгортання прошивок — як гарна нарада: настільки буденна, що ніхто не пам’ятає, що вона взагалі була.

Типові помилки: симптом → корінь → виправлення

1) Симптом: хост завантажується в PXE або «Немає завантажувального пристрою»

Корінь: BootOrder скинувся; запис UEFI видалено; змінилося перелічення дисків.

Виправлення: Використайте віддалену консоль, щоб вибрати правильний запис завантаження; відновіть за допомогою efibootmgr; якщо запис відсутній — перевстановіть/створіть завантажувач (наприклад, grub-install або вендор-специфічні інструменти).

2) Симптом: ОС не знаходить кореневу файлову систему після оновлення

Корінь: Перемикнувся режим SATA (AHCI ↔ RAID) або змінився режим контролера; initramfs не містить драйвера; змінилися імена пристроїв.

Виправлення: Поверніть режим SATA/контролера в BIOS до попереднього; перебудуйте initramfs з потрібними драйверами; переконайтеся, що /etc/fstab використовує UUID.

3) Симптом: раптове збільшення латентності зберігання, але «все здорово»

Корінь: PCIe лінк погодився вниз (пониження Gen або зменшення ширини); AER-шторм виправлених помилок; зміни ASPM/керування живленням.

Виправлення: Перевірте lspci -vv для LnkSta; подивіться journalctl -k на AER; відкоригуйте налаштування PCIe/живлення в BIOS; при потребі переосадіть обладнання.

4) Симптом: збої віртуалізації або ламання passthrough

Корінь: VT-d/IOMMU вимкнено або скинуто; переключилися SR-IOV; вимкнули Above 4G decoding.

Виправлення: Увімкніть IOMMU/VT-d, SR-IOV, Above 4G decoding; перевірте групи пристроїв і прив’язку драйверів; перезавантажте і протестуйте.

5) Симптом: Secure Boot раптово блокує завантаження або модулі ядра

Корінь: Secure Boot переключився; база ключів оновлена/скинута; втрачене MOK-реєстрація.

Виправлення: Усвідомлено відновіть стан Secure Boot; перевірте реєстрацію ключів; переконайтеся, що завантажувач/ядро/модулі підписані належним чином.

6) Симптом: випадкові перезавантаження або нові виправлені помилки ECC

Корінь: Зміни тренування пам’яті, BIOS змінив таймінги; виявився граничний DIMM.

Виправлення: Порівняйте лічильники помилок DIMM, запустіть діагностику пам’яті в обслуговуванні, розгляньте зниження частоти пам’яті або заміну DIMM; якщо вендор визнає проблему, відкотіть BIOS або застосуйте виправлення пізніше.

7) Симптом: регресія продуктивності без очевидних логів

Корінь: Профіль живлення скинуто на збалансований; увімкнено глибші C-states; змінена поведінка turbo; відмінності мікрокоду/мітгацій.

Виправлення: Перевірте профіль живлення в BIOS і governor в ОС; порівняйте мікрокод і статус мітгацій; вимірюйте до/після на навантаженні, що репрезентативне для продакшну.

8) Симптом: NIC зник або імена інтерфейсів змінилися

Корінь: Зміни Option ROM/UEFI драйверів; зміни порядку PCIe-ініціалізації; скинуто SR-IOV/портові налаштування.

Виправлення: Підтвердьте наявність пристрою за допомогою lspci; перегляньте налаштування NIC у BIOS; верифікуйте правила предикативного іменування; при потребі оновіть initramfs/udev правила.

Чек-листи / покроковий план

Покроково: розгортання BIOS у продакшн з повагою до фізики

1. Читайте нотатки релізу, наче переглядаєте ризиковий PR. Шукайтеп: зміни мікрокоду, виправлення безпеки, «оновлено значення за замовчуванням», нотатки PCIe/NVMe і попередження про шлях оновлення.
2. Підтвердьте, що позашляховий доступ працює. Протестуйте віддалену консоль, контроль живлення та автентифікацію. Якщо iKVM ненадійний — плануйте роботу на місці.
3. Зафіксуйте передполітний відбиток. Збережіть виводи з команд вище у тікеті або ранбуку.
4. Експортуйте конфігурацію BIOS, якщо вендор це підтримує. Деякі платформи дозволяють профілі конфігурації BIOS. Використовуйте їх. Вони перетворюють племінні знання у файли.
5. Виберіть канарки. Один типовий вузол, один «дивний» вузол. Якщо ви канаркуєте лише прості — ви не робите канаркування.
6. Оновіть BMC/IPMI, якщо потрібно, у правильному порядку. Вендори іноді вимагають оновлення BMC перед BIOS. Ігнорування цього дасть вам дивну віддалену управління.
7. Застосуйте оновлення BIOS до канарок. Не поєднуйте з оновленнями ОС/ядра в тому самому вікні, якщо вам подобається неоднозначність звинувачень.
8. Після оновлення — верифікація (ті самі команди, що й перед полотом). Порівняйте версію BIOS, мікрокод, стан Secure Boot, записи UEFI, стан PCIe, здоров’я зберігання і логи.
9. Запустіть невеликий, цілеспрямований тест навантаження. Не бенчмарк для показухи. Щось, що нагадує продакшн: зразок затримки зберігання, перевірка пропускної здатності мережі, димовий тест додатку.
10. Тримайте паузу для спостереження. Хвостові затримки, виправлені помилки і теплові аномалії часто з’являються через годину, а не за першу хвилину.
11. Розгортайте партіями. Невеликий розмір партії з паузами. Якщо ви не можете призупинити — ви не робите rollout; ви робите подію.
12. Документуйте дельту. Будь-яке налаштування, що змінилося, будь-який необхідний оверрайд, будь-який вплив на продуктивність. Це стане «нудно, але правильно» наступного кварталу.

Чек-лист відновлення: коли хост не повертається коректно

1. Підтвердьте стан живлення через BMC; виконуйте power cycle лише за вказівками вендора (деякі платформи потребують очікувань).
2. Використайте віддалену консоль, щоб спостерігати POST-коди/повідомлення; зафіксуйте, де воно зупиняється.
3. Спробуйте меню завантаження, щоб обрати правильний пристрій; уникайте сліпого змінення множинних налаштувань BIOS.
4. Якщо записи завантаження відсутні — відтворіть або перевстановіть завантажувач.
5. Якщо диски відсутні — спочатку перевірте режим SATA/RAID і виявлення контролера зберігання.
6. Якщо ОС завантажується, але продуктивність зіпсована — перевірте PCIe лінк і AER логи перед тим, як чіпати конфігурації додатків.
7. Розглядайте відкат BIOS лише після фіксації доказів; відкат стирає сліди і може вводити власні проблеми.

Політичний чек-лист: що стандартизувати, щоб це перестало бути драмою

• Базові версії BIOS для флоту за моделлю платформи.
• Золоті профілі конфігурації BIOS: живлення, PCIe, віртуалізація, завантаження, безпека.
• Обов’язкові передполітні та післяполітні докази, прикріплені до тікетів змін.
• Вимоги до канарок і ліміти партій.
• Чіткі критерії відкату і відповідальність за процес.

Поширені питання

1) Чи варто оновлювати BIOS, якщо все працює?

Якщо «працює» включає відомі вразливості безпеки, помилки стабільності, що відповідають вашим симптомам, або вендорські рекомендації, релевантні до вашого CPU/NIC/стеку зберігання — так, але за поетапним планом. Якщо оновлення лише «додає підтримку апаратури, якої ви не маєте» — ні. Часті оновлення прошивки мають свою ціну.

2) У чому різниця між оновленням BIOS і оновленням мікрокоду з ОС?

Пакети мікрокоду в ОС можуть завантажувати мікрокод під час завантаження, але мікрокод, який надає BIOS, може відрізнятися і завантажуватися раніше в ланцюгу завантаження. Ви вимірюєте активний мікрокод через /proc/cpuinfo і порівнюєте до/після.

3) Чому мій порядок завантаження змінився після оновлення BIOS?

Бо вендори трактують порядок завантаження як перевагу, а не контракт. NVRAM може скидатись чи перезаписуватись під час оновлень. Завжди фіксуйте вивід efibootmgr -v заздалегідь.

4) Чи може оновлення BIOS знизити продуктивність зберігання без помилок?

Так. Домовленість PCIe може змінитися непомітно (Gen4 → Gen3, x8 → x4), управління живленням може змінити поведінку пробудження пристрою, і прошивка може змінити відображення IOMMU. Відсутність помилок не означає відсутність змін у продуктивності.

5) Безпечніше оновлювати BIOS з ОС чи через BMC?

«Безпечніше» залежить від зрілості інструментів платформи і вашого середовища. Оновлення через BMC можуть спрацювати, коли ОС хворіє, але вони також залежать від стабільності BMC і мережі. Інструменти в ОС можуть давати кращу видимість, але ризикують через драйвери/взаємодію з ОС. Виберіть один метод на платформу і опрацюйте його тестуванням, а не інтуїцією.

6) Чи потрібно також оновлювати прошивку BMC/IPMI?

Інколи. Вендори можуть вимагати певних версій BMC для нових BIOS-образів, несумісність може викликати дивні дані сенсорів, криві профілі вентиляторів або проблеми з віддаленою консоллю. Перевірте матрицю сумісності в нотатках релізу, які ви вже зробили вигляд, що читаєте.

7) Який найшвидший спосіб виявити «це PCIe» після оновлення BIOS?

Перевірте lspci -vv для LnkSta на ураженому пристрої і проскануйте journalctl -k на предмет повідомлень AER. Погоджений вниз лінк або AER-шторм — класична прошивкова регресія.

8) Чи можу я просто відкотити BIOS, якщо щось пішло не так?

Іноді можна, але не припускайте, що пониження підтримується або безпечне. Деякі платформи блокують відкат через ф’юзи безпеки або політику підписування капсул. Також відкат може знову скинути налаштування і ускладнити розслідування. Відкат — коли у вас є чітка регресія і відомий робочий таргет.

9) Чому змінилася поведінка Secure Boot, хоча я її не чіпав?

Оновлення BIOS можуть скинути Secure Boot до значень за замовчуванням, оновити базу ключів або змінити спосіб обробки MOK-реєстрації. Трактуйте Secure Boot як керований параметр конфігурації; перевіряйте стан після оновлення за допомогою mokutil.

10) Як утримувати налаштування BIOS послідовними по флоту?

Використовуйте інструменти вендора для експорту/імпорту профілів BIOS де можливо, і підкріпіть це перевіркою відповідності: перевіряйте ключові налаштування після оновлень. Якщо ви покладаєтесь на людей, щоб натиснути ті самі 14 перемикачів правильно — ви тренуєтеся на непослідовності.

Висновок: наступні кроки, що дійсно знижують ризик

Оновлення BIOS не є актом відваги. Вони неминучі. Відвага — це вважати їх одноразовим ритуалом, а не операційною практикою, яку можна покращувати.

Наступного разу, коли ви дивитиметесь на повідомлення «Do not power off», заслужіть спокій:

• Зафіксуйте відбиток до/після (BIOS, мікрокод, записи завантаження, стан PCIe, здоров’я сховища).
• Виконуйте канарку на одному типовому вузлі і одному дивному вузлі. Завжди.
• Перед початком перевірте позашляховий доступ, а не після жалю.
• Повторно застосуйте і перевірте налаштування BIOS, що важливі для ваших SLO, особливо параметри живлення і PCIe.
• Коли щось ламається, проводьте триаж у правильному порядку: ланцюжок завантаження → наявність пристроїв → домовленість PCIe → поведінка живлення/мікрокоду → шляхи зберігання.

Мета не в тому, щоб усунути ризик. А в тому, щоб зробити ризик зрозумілим, обмеженим і відновлюваним. Саме так продакшн-системи залишаються нудними — а це найвища похвала, яку може отримати операційна команда.