Комп'ютер не завантажується після встановлення Windows 10

Метки: , , , ,

Вчора, після інсталяції десятої вінди, комп'ютер, зібраний десять років тому, не зміг пройти навіть перший етап завантаження. На екрані була така картина:

ASRock 775XFire eSATA2 post code 78

Зупинка сталася на пост-коді 78, що видно як на моніторі, так і на POST-платі:

PCI card post code 78

У нас материнська плата ASRock 775XFire-eSATA2 із AMI BIOS, а https://ru.wikipedia.org/wiki/Коды_ошибок_BIOS повідомляє, що на етапі із кодом 78 створюється список пристроїв із яких можна виконати завантаження. На моніторі також помітно, що BIOS розпізнав вінчестер Seagate ST3200827AS, але далі просунутися не може — процес завантаження нескінченно довго стоїть на одному місці.

ST3200827AS

Спершу я подумав, що старенький диск, який іноді клацав головками, не пережив запису такої кількості інформації одразу і віддав богу душу.

Я взяв новенький Seagate ST500DM002, повторив інсталяцію Windows 10 на ньому і, яке ж було моє здивування, коли і з ним, із майже новим жорстким диском, система так само відмовилась запускатися.

ST500DM002

Поліз в Інтернет шукати рішення схожих ситуацій. Із самого початку натрапив на проблему, що була присутня в одній із збірок Windows 10 (build 9879). Цей білд активував на вінчестерах функцію невмикання при подачі живлення (Powerup in Standby, PUIS). Функція ця корисна, щоб не так різко навантажувати блок живлення під час вмикання комп'ютеру, і дуже часто знаходить своє використання при наявності таких споживачів електроенергії, як RAID-масиви. Отож, та збірка вінди функцію невмикання вінчестеру вмикала, але не всі материнські плати вміють посилати спеціальну команду вінчестеру, щоб його увімкнути у необхідний момент для завантаження операційної системи.

Оскільки материнка ASRock 775XFire-eSATA2 такого точно не вміє, то я вирішив що проблема була дійсно у цьому. Для її вирішення, потрібно лише вимкнути PUIS назад. Як же це зробити, якщо система із нашим диском зовсім не завантажується? Можна спочатку від'єднати жорсткий диск, завантажитися із якогось іншого носія, підключити вінчестер, і вже тоді зробити необхідні налаштування (дивіться цей процес на відео трохи нижче).

Я завантажився у Kali Linux (можна скористатися будь-яким Лінуксом із утилітою hdparm), та вивів на екран команди доступні для диску ST3200827AS, але `hdparm -I /dev/sda` не знайшла серед них PUIS:

hdparm showing ST3200827AS commands without PUIS

Деактивація відсутнього параметру звісно не спрацювала:

# hdparm -s0 /dev/sda
/dev/sda:
spin-up: setting power-up in standby to 0
HDIO_DRIVE_CMD(powerup_in_standby) failed: Input/output error (off) 

Я не одразу повірив, що PUIS на цьому жорсткому диску немає. Думав, що Seagate використовує якусь нестандартну команду для активації цієї функції. Вважав, що якщо після встановлення Windows 10 із вінчестеру неможливо завантажитися, то PUIS точно увімкнений. Тому досить довго шукав або фірмову утиліту, яка б керувала PUIS, або секретну ATA команду.

Зрозумів я, що Powerup In Standby тут ні до чого тільки тоді, коли до рук мені потрапив Western Digital 5000AAKS про який точно було відомо, що цю функцію він підтримує.

WD5000AAKS

Перемичкою активувавши у нього PUIS, спробував завантажити комп'ютер і помітив великі відмінності у поведінці жорсткого диску із увімкненим PUIS:

  1. при увімкненому PUIS шпиндель диску не розкручується (відчувається рукою та слухом)
  2. BIOS не бачить вінчестера у standby, тож завантаженню комп'ютера він не заважає
  3. утиліта hdparm бачить налаштування “Powerup in Standby”:

    hdparm showing wd5000aaks commands with PUIS

У наших Seagate же, і шпиндель розкручувався, і у BIOS їх було видно, і PUIS жодна утиліта не побачила.

Серед скарг на те, що Windows 10 “вбиває” жорсткі диски, мені траплялися і описи проблем пов'язані всього лише із неправильною MBR. Це коли BIOS успішно проходить фазу побудови списку пристроїв, але при спробі завантаження із жорсткого диску виводиться одне із стандартних повідомлень MBR, наприклад “Invalid partition table”, або “Missing operating system”. Це легко вирішується перезаписом MBR новою таблицею розділів та перевстановленням операційної системи.

У мене ж BIOS зупинявся саме на етапі визначення жорсткого диску і не доходив до завантаження із нього, тому я не одразу подумав, що проблема може бути у цьому. Але потім я припустив, що раптом саме BIOS материнки ASRock 775XFire-eSATA2 перевіряє правильність таблиці розділів на етапі з'ясування із яких пристроїв можна завантажуватися. Тож, я знову завантажився у Linux без проблемного жорсткого диска, під'єднав його, і просто обнулив йому MBR (наприклад, `dd if=/dev/zero of=/dev/sda bs=1024 count=1`):

І дійсно, це вирішило проблему --- комп'ютер почав проходити етап завантаження із кодом 78 і спокійно йти далі.

Windows 10 на цей комп'ютер я ставив заради тесту. Все ж таки Asrock 775XFire-eSATA2 не підтримує більше ніж 2 ГБ оперативної пам'яті, а це буде замало для комфортної роботи у цій ОС.

Але, все ж таки, завантажити “десятку“ на цій материнський платі можна: я пробував заздалегідь розбивати диск у Gparted, що доступний у Kali Linux, а вже потім встановлювати десяту вінду на ці розділи, і все проходило нормально.

Також, я не зміг ще раз відтворити описану вище проблему для того, щоб проаналізувати MBR із яким не хотіла працювати материнка. Пробував ставити Windows 10 на диск із обнуленою MBR, але завантаження після інсталяції проходило без проблем. Щодо тих двох вінтів Seagate, то вони були розбиті Windows 7 та Windows XP відповідно, може річ була саме у цьому.


28 Март 2016

Оставить комментарий

Комментарии

На этой странице еще нет комментариев.

Комментарии по RSS для этой страницы | RSS лента всех комментариев


Интернет реклама