Установка ОС шиндовс — дело нехитрое. Но при попытке сотворить что-то нестандартное, анончик обычно начинает сосать хуй из-за того, что кнопочки — это не всё, что присутствует в стандартном комплекте поставки. Да и кнопочки нужно жать понимаючи и последствия осознавая.
(изначально этот документ предназначался спермачам, но ебаные убунтята [которые, надеюсь, заглянут сюда за своей процией урины] вынудили внести некоторые коррективы)
() — Круглые скобки используются для вставки специфической и необязательной информации
[] — Квадратные скобки обозначают второй уровень вложенности скобок (потому что мне так удобно [нет, правда])
1981 год подходил к концу, человеки жили относительно спокойно, но внезапно на рынке появился новый пека. Это был IBM PC. Его никак нельзя назвать первым ПК, но он разительно отличался от конкурентов по следующим пунктам:
-
Открытая архитектура
Что-то сгорело — достал (а не выпаял, бгг), выкинул, сходил в махазин за заменой
Причём это касалось не только внутренних компонентов, но и периферии: IBM-овцы запилили стандартную (для линейки IBM PC) системную шину ISA
(которая сдохла через 10 лет. Ей на смену пришёл PCI и тоже сдох через 10 лет. Ну а сейчас в моде PCIe)
-
BIOS
Для того времени — вполне себе ультра-ёба-достижение, которое позволило не задумываться, откуда брать бинарники Santa Cruz Operation UNIX (линекса тогда ещё не было, только Линус) под свежекупленный пек. Создание некоторого уровня абстракции над "чистым железом" позволило не беспокоиться о том, заработает ли ОС на следующих компьютерах семейства, в которых набор этого самого железа может быть уже несколько другой
Примерно в это же время, Гойтц честно купил у Seattle Computer Products их 86-DOS, переименовал в MS-DOS и, используя наёмный труд 35 человек, начал её усиленно допиливать.
В предстоящей модели IBM PC/XT в стандартной комплектации был анонсирован жёсткий диск. Естественно, M$ не смогла обойти стороной этот факт и вежливо попросила включить их ОСь в стандартную поставку.
Так как диски были объёмом 10 и 20 МБ, возникла необходимость в файловой системе которая может работать с такими объёмами. Но в MS-DOS 1.0 была только FAT12. Пrишло вrемя для rеволюции:
Рис 1. Размер кластера для семейства FAT и максимальный объём, с которым ФС может работать
Несложно догадаться, что самой первой идеей, пришедшей в голову корпорации M$ было расширение адресации до 16 бит (а потом и до 32-х). Эти ФС были логично названы FAT16 и FAT32.
Но если уж взялись за файловую систему, надо же туда ещё чего-нибудь впилить!
Так и произошло: в 1982 году в одном подземном бункере IBM сумрачный гений Дэвид Литтон разработал механизм, позволяющий держать на диске одновременно 4 файловые системы. Буквально за полгода эта концепция была воплощена в новой версии ОС.
Впрочем, в воплощении особых технических сложностей не должно было возникнуть:
- При загрузке IBM PC, BIOS лез в конец первого сектора и начинал выполнять содержащийся там код. Поскольку ни о каких разделах речи тогда и не шло, первый сектор содержал только загрузочный код и служебную информацию об файловой системе, занимавшей весь диск.
- Тот самый сумрачный гений просто взял первый сектор жесткого диска и впилил туда программу на ассемблере, которая читала таблицу с разделами, определяла загрузочный и передавала управление первому сектору раздела (где лежит кусок кода, который раньше BIOS загружал напрямую).
Рис 2. Слева показан процесс загрузки без MBR. Есть диск, на нём, от первого до последнего сектора расположена файловая система. BIOS, передаёт управление загрузкой коду, расположенному в первом секторе жесткого диска.
Справа — процесс загрузки с MBR. Есть такой же диск. Но в первом секторе размещается информация не о файловой системе, а о так называемых "разделах". BIOS об этих кардинальных изменениях ничего не знает, да и не должен. Он всё так же вызывает (1) код из первого сектора жёсткого диска. Но вот оно отличие! В 446 байт машинных кодов умещена программа, которая научена читать таблицу разделов, искать загрузочный и передавать управление коду, расположенному в первом секторе загрузочного раздела, что она и делает (2)
В сухом остатке мы имеем штуку, которая с одной стороны может взаимодействовать с BIOS так, как это раньше делала FAT, а с другой стороны эта же штука ведёт себя как BIOS — передаёт управление коду в первом секторе ФС.
Этот самый первый сектор жесткого диска, содержащий таблицу разделов и загрузочный код, и называется MBR — главная загрузочная запись
Вышедший в 1983 IBM PC/XT искоробки оснащался свежей PC-DOS 2.0 (ну и IBM BASIC, но в нашем контексте он не интересен).
Отступление первое. Жёсткие диски. Адресация: CHS и LBA
Время шло, жёсткие диски увеличивались в объёме, и разделов стало не хватать. (напомню, MBR мог хранить ровно четыре записи о разделах).
По началу у разделов не было какого-либо разделения по типам. Раздел и раздел. Но...
Опять же не долго думая, микрософт взяла и сделола штуку под названием EBR — расширенная загрузочная запись. Звучит серьёзно, но на деле же это обычный копипаст: взяли MBR и скопировали его в начало файловой системы. Круто? Да. Но:
-
Загрузить ОС с расширенного раздела (то есть, с раздела, первым сектором которого является EBR) стандартными средствами — никак. (из-за того, что MBR [а следовательно и EBR] de jure не предназначен для загрузки ОС)
-
Следующие разделы запиливались при помощи рекурсии. Адресация представляла собой цепочку => если хоть одно звено портилось, все последующие оказывались просто недоступны.
Рис 3. Слева — классический MBR c 4 разделами; справа — в начале всё тот же MBR c 4 разделами, но в в 3-ем располагается сслыка на 5-ый, 5-ый ссылается на 7-ой, а 7-ой — на 6-ой.
В EBR так же как и в MBR есть 4 записи, но используются из них только две: первая указывает на первый сектор куска диска "приписанного" этому EBR (в этом куске создаётся ФС, и именно там лежат гифки с котиками), а вторая — на следующий EBR, и так далее по цепочке.
EBR появился в 1986. MS-DOS 3.2 была первой ОС, с которой M$ вышла на рынок к простым людям (до этого всё делалось через IBM, на пеках которого PC-DOS была предустановлена [да, тот самый OEM, которым корпорация живёт и сейчас]).
С того момента до появления и распространения EFI ничего в механизмах загрузки не менялось. И если на твоей пеке до сих пор не UEFI, то знай: ты ползаешь на 30-летних костылях.
Ограничение на один загрузочный раздел людям очень не нравилось и те, кто умел немного погромировать на ASMе, выкручивались как могли:
В самом самом начале загружается прошивка, которая может быть представлена в двух вариациях: BIOS и UEFI. Эта сущность отвечает за:
-
Тестирование компонентов при загрузке (POST). Компьютер пищит из-за аппаратных ошибок именно на этой стадии.
-
Первоначальную инициализацию устройств (ибо содержит некоторый набор "драйверов" — firmware)
При загрузке в безопасном режиме ОС шиндошс использует, в основном, драйвера из биоса
-
Передачу управления загрузчику (исполнимому коду [BIOS] или файлу [UEFI])
BIOS | UEFI | |
---|---|---|
Серийный запуск | 1981 | ~2012. Если мать выпущена позднее, с вероятностью 95% на ней УЕФИ |
Поддерживаемые типы разметки ЗУ | MBR | MBR, GPT |
Разрядность кода | 16, 32 | 32, 64 |
-
В 99% случаев UEFI — 64-хбитный
-
UEFI — сам себе загрузчик, ибо может:
-
Работать с файловой системой (VFAT, но можно поставить[1,2] драйверы для NTFS или EXT)
-
Хранить загрузочные записи в NVRAM (примерно как BIOS хранит свои настройки в CMOS, только память энергонезависимая и не сбрасывается отключением батарейки)
Подробнее про записи в спецификации, раздел 3.1
-
-
Загружает исполнимый файл формата .efi (а не код, расположенный хер знает где)
-
GPT является частью спецификации UEFI
-
За счёт CSM (который есть везде) может эмулировать BIOS
Олсо "UEFI BIOS" не существует в природе. Увидите — нассыте на ебало. Потому, что BIOS — штука, характерная исключительно для IBM PC-совместимых динозавров; UEFI же может использоваться и на других (ARM AArch32/64, наспрмер) архитектурах.
Также можно направить струю урины на тех, кто называет UEFI не иначе как EFI. Ибо EFI — это всё-таки предыдущая, интеловская, версия спецификации, отданая народу currentYear-2005 лет назад.
После загрузки BIOS/UEFI пытается передать управление коду/файлу, который будет обнаружен на ЗУ. То, что будет искать BIOS/UEFI, и как он будет это искать, зависит от типа разметки ЗУ. Поэтому для начала проясним ситуацию с ними:
Как MBR, так и GPT в своей сути являются просто списком разделов на данном ЗУ. (Но MBR берёт на себя слишком много и сильно усложняет процесс загрузки)
MBR | GPT | |
---|---|---|
Появление | 1983 | 2010 |
Количество разделов | Изначально — не более 4 | Неограничено. Но шиндовс может только в 128, а линукс — в 255 |
Отказоустойчивость | Информация о разделах хранится в одном месте | Информация о разделах хранится и в начале, и в конце |
Адресация секторов | 32-хбитная | 64-хбитная |
Адресуемое пространство | 2 ТиБ ≈ 2,2 ТБ | 8 ЗиБ ≈ 9,4 ЗБ (ohce много) |
Немного про Advanced Format (диски с секторами по 4096 байт [взамен 512])
Адресуемое пространство — максимальный доступный ("видимый", адресуемый [то есть такой, который можно передать к.-л. программе]) объем при данном типе разметки — вычисляется по формуле:
размер_сектора * 2 ^ кол-во_бит_на_адрес
Так что, 2 ТиБ для MBR не предел. На 4K дисках MBR в теории может адресовать аж 16 ТиБ, а GPT целых 64 ЗиБ.
!!! Поискать случаи использования MBR на дисках AF 2+ТБ, подтверждающие/опровергающие 16 теоретических ТиБ (не было найдено ничего [кроме теоретических выкладок, подобных расположенной выше]. Вообще ничего. Похоже, я нашёл очень сильное кодунство)
Относительно ОС:
- шиндовс: поддержка 4K native наличествует с VistaSP1. А XP (и это логично), ничего не зная про AF, жуёт только маскирующиеся 512e-диски.
- в лениксе как обычно просто, тихо, в рабочем порядке впилили в ядро (2.6.31-ой версии)
С 2011 года все новые линейки HDD, с лёгкой руки IDEMA, пилятся только по технологии AF.
SSD все (за самым малым исключением) , в силу природы своей памяти и плюшек, описаных по ссылке выше, изначально работают с 4-хкилобайтовыми страницами.
Размер сектора в линуксе можно посмотреть через
# fdisk -l /dev/sda
В шиндовс:
fsutil fsinfo ntfsinfo C:
Надо отметить, что тип разметки никак не привязан к накопителю: GPT можно запилить хоть на Seagate Barracuda 80Gb 15-летней давности. Это всего лишь кучка битов, расположенных в нужных местах, поэтому MBR, например, можно преобразовать в GPT абсолютно элементарно.
MBR — просто таблица с данными. Физически располагается в первом секторе (первые 512 байт) ЗУ и содержит следующие элементы:
Структура | Размер (байт) |
---|---|
Исполнимый код | 446 |
Таблица разделов | 4 (записи) x 16 |
Сигнатура | 2 |
Исполнимый код (FSBL): кусок машинных команд, загружаемый BIOS и передающий загрузку дальше по цепочке.
Таблица разделов (HDPT) состоит из 4 записей по 16 байт. Каждая запись содержит следующую информацию о разделе:
- Статус (загрузочный [80h] или нет [00h])
- Расположение на диске
- Тип (07h — NTFS, 0Ch — FAT32, 83h — Linux, etc.)
Сигнатура: (55AAh) определяет, что сектор содержит именно MBR, а не что-то иное.
Разделы идут не сразу после MBR, а с некоторым смещением (64 сектора, 32КБ).
Некоторые хитрые людишки невозбранно используют его [смещение] как дополнителное хранилище для исполнимого кода, не умещающегося в MBR.
Так поступает, например, GRUB
В начале каждого раздела располагается VBR (PBR). Копия MBR по структуре, в ней даже имеется свой загрузочный код.
Есть также и костыль, позволяющий городить дополнительные (логические) разделы — так называемая EBR. Также являющая собой кастрированный (функционально, не по размеру) MBR: используются только 1 и 2 записи из HDPT. Первая описывает раздел, примыкающий к EBR, а вторая ссылается на следующий логический раздел. Получается этакая цепочка. Путь до 2-го логического раздела будет такой: MBR→EBR1→EBR2
Кстати, разницы в структуре между "расширенным" и "логическим" разделом — нет. Их отличает только то, что на "расширенный" ссылается MBR, а на "логический" — EBR.
Как и MBR, и VBR, EBR тоже может содержать в себе загрузочный код, но для загрузки этот момент пользуется только крайне отбитыми личностями, поэтому для нас в этом плане не очень интересна.
Структура — примитивнее некуда:
GPT имеет некоторую обратную совместимость с MBR. Так что при очень сильном желании можно впердолить на GPT загрузчик для MBR.
Но делать этого не рекомендует спецификация. MBR потому и Protective, что выполняет чисто бутафорскую функцию, мешая программам, не могущим в GPT, форматировать ЗУ так, как им вздумается (то есть в MBR, конечно же)
Шиндовс может в GPT начиная с Vista. Впрочем, можно найти драйвер даже для XP (загрузиться в XP с GPT, даже при наличии драйвера, конечно, не выйдет [но это только напрямую. Как известно, ничего невозможного нет, поэтому, после некоторой дозы сильнодействующих таблет0сиков, можно грузануть XP из, например, VHD-образа]).
MBR > GPT | GPT > MBR | |
---|---|---|
С потерей данных | diskpart* | diskpart* |
Без потери данных | gptgen | Paragon |
- Работа с diskpart описана ниже
BIOS | UEFI | |
---|---|---|
MBR | Просто работает (уже 30 лет как, бгг) | Глупо, потому что у GPT довольно много преимуществ |
GPT | Взлетит (при помощи GRUB с нужным модулем или DUET), но это самый наркоманский вариант из всех возможных | Идеал |
Так как BIOS работает с машинным кодом, расположенным по определённому смещению, ни о каких файлах в самом начаде загрузки говорить не призодится.
-
В соответствии с настройками ("First boot device…", "Second…") BIOS выбирает устройство, с которого будет грузиться (жесткий диск, флешка, либо дисковод)
-
С устройства читается первый сектор, в котором располагается MBR
-
Выбирается раздел для загрузки (активный раздел [тот, который 80h])
-
Выполняется исполнимый код из начала MBR (FSBL)
Тут алгоритм сбивается. Из-за отсутствия хоть каких-то вменяемых стандартов на процесс загрузки, каждый загрузчик делает после этого пункта что хочет. Но обычно:
-
Код из MBR передаёт управление коду из VBR на активном разделе
-
VBR, умеющий читать файловую систему раздела, без труда находит и передаёт управление файлу, на котором он завязан (ntldr, grldr, etc. Всё это — SSBL)
-
Заключительный этап SSBL запускает ядро (ntoskrnl.exe [ну или vmlinuz, бгг]) загружаемой ОС
Вкратце, MBR (FSBL) > Boot loader (SSBL) > Ядро ОС
Самые распространенные загрузчики:
NTLDR | BOOTMGR | grub4dos | |
---|---|---|---|
Возможности | Windows XP | Windows7+ | ISO |
Файл | ntldr | bootmgr | grldr |
Настройки | boot.ini | BCD | menu.lst |
Редактирование | Блокнот | bcdedit*, BootIce, Visual BCD Editor | Блокнот |
- bdcedit входит в стандартную поставку Шиндовс
NTLDR
Довольно старый загрузчик. Может загружать шиндошс XP и разные линексы.
BOOTMGR
Загрузчик поновее, посложнее. Записи уже блокнотом не подредактируешь, нужен спецсофт.
Может загружать как XP, так и все последующие шиндовсы. И линексы тоже.
Стандартное расположение файла конфигурации загрузки:
MBR | GPT | |
---|---|---|
Путь | /Boot/BCD | /EFI/Boot/Microsoft/BCD |
Раздел | Активный раздел | ESP |
grub4dos
Появился как ответвление от проекта GRUB Legacy — когда-то умолчательного загрузчика в линексе, к которому прикрутили NTFS и iso9660 (которых на момент форка в оригинале не было) и упихали все модули в один файл.
Могёт в загрузку ISO (важно, чтобы файл был дефрагментирован), а также линексов.
Каждый загрузчик может передавать управление любому другому. Так из grub4dos можно загрузить BOOTMGR, а из NTLDR ядро линекса.
Для того, чтобы загрузить конкретный boot loader, очевидно, необходимо построить правильную цепочку из MBR (и, возможно, VBR). А так же обеспечить наличие файла загрузчика и файла конфигурации на активном разделе.
Некоторые маргинальные загрузчики для MBR:
Могут в NTFS | Полезны в целях реанимации | Просто существуют и работают |
---|---|---|
XorBoot | PLoP | Smart BootManager, GAG |
GPT установлена на систему с UEFI.
- Происходит попытка загрузить файл из первой по приоритету записи UEFI.
- С раздела, тип которого установлен в ESP (EFI System Partition) загружается файл /EFI/boot/bootx64.efi
!!! Уточнить
!!! Дополнить описанием ESP
Загрузчики EFI: systemd-boot, rEFInd, GRUB
Утилиты для редактирования записей UEFI: BootIce, EasyUEFI, efibootmgr (Linux), UEFI Shell
Алярм! Только Win7! Win8+ таких проблем не имеют
UEFI обычно присутствует там, где уже впилены и AHCI, и USB 3.0 то есть то, во что стандартный boot.wim не могёт. У анончика появляется выбор:
-
Пердолить boot.wim для добавления поддержки недостающих функций
(как вариант просто взять boot.wim из установочного образа Win8+)
-
Либо же просто выключить данные фичи на время установки
Думаю, очевидно, какой вариант выберем мы.
AHCI → SATA или же Compatible
USB Legacy → ON
CSM → ON
Зачем? NCQ
Как? Элементарно:
-
Устанавливается этот твик реестра (ни разу не мокрописька. Пруф)
-
Собственно Compatible переключается на AHCI
-
?????
-
PROFIT!
Достаточно переключиться на AHCI и перезагрузиться в безопасном режиме.
Вещь с одной кнопкой. Говорить особо не о чем, поэтому только немного упомяну подводные:
T: Сливает некоторые данные (архитектура и версия ОС, версия программы) при проверке обновления
S: Отключается в "О программе…" → "Обновления"
T: На WinXP не хочет запиливать флешки для UEFI
S: Надо закинуть в папку с руфусом wimgapi.dll . Файл можно достать из:
- WinNTSetup3\Tools\x86 (изначально отсутствует, но программа при первом же запуске его скачивает)
- Win7+ из \WINDOWS\SysWOW64 (если есть только образ Win7+, можно выковырять этот файл из sources\install.wim)
Олсо в Руфусе есть скрытые хоткеи (правда, толку от них…).
Если ты это читаешь, с тобой всё плохо, бгг. Скорее всего, ты собрался сваливать из прыщемирка, так и не сумев слезть с каляски.
Единственный момент, где нужно включить мозг при следовании командам, изложенным ниже — замена в sdX буквы X на букву, которая соответствует флешке. В 90% — это sdb
Под BIOS/UEFI CSM (да, из шапки линекс-треда. Да, это работает, криворукое ты мудило):
sudo dd if=/path/to/windows.iso of=/dev/sdX
sudo ms-sys -7 /dev/sdX
Под UEFI:
Могут быть опечатки!
# Создаём FAT32 на флешке
sudo mkfs.msdos -F 32 /dev/sdX
# Монтируем флешку и образ
sudo mkdir /mnt/{flash,iso}
sudo mount /dev/sdX /mnt/flash
sudo mount windows.iso /mnt/iso
# Копируем файлы с образа на флешку
sudo cp -r /mnt/iso/* /mnt/flash/
Из-за того, что в Win7 загрузчик присутствует, но запихан глубоко в анус, его надобно извлечь. Для этого необходимо наличие в системе p7zip или wimlib (может называться wimlib-imagex)
В Win8+ это исправлено. Следующий блок выполнять нинужно!
!!! Проверить, в какой же версии это исправлено: 8 или 10
# Извлекаем загрузчик из образа:
# Вариант №1 При помощи p7zip
sudo 7z e /mnt/flash/sources/install.wim 1 Windows/Boot/EFI/bootmgfw.efi
# Вариант №2 При помощи wimlib
sudo wimlib-imagex extract /mnt/flash/sources/install.wim 1 Windows/Boot/EFI/bootmgfw.efi \
--dest-dir=/mnt/flash/EFI/Boot
# Переименовываем извлеченный загрузчик
sudo mv /mnt/flash/EFI/Boot/boot{mgfw,x64}.efi
# Размонтируем флешку и образ
sudo sync
sudo umount ./iso ./flash
Можно, конечно, воспользоваться жирненькими пакетами от Acronis, MiniTool или ещё каким парагоном, но следует знать, что в ОС шиндовс есть довольно мощная консольная утилита diskpart.exe
Необходимый минимум:
// "Перемещение" по ЗУ и разделам
list <disk|partition> — показать (подключенные ЗУ) или (разделы на выбранном диске)
select <disk|partition> <X> — выбрать (ЗУ) или (раздел) с номером X
// Операции с таблицей разделов
clean — очистить таблицу разделов ЗУ (затирания нулями самих разделов не происходит)
convert [gpt|mbr] — преобразовать ЗУ в GPT или MBR
// Операции с разделами
create partition primary [size=X] — создать на выбранном ЗУ базовый раздел [размером X МБ]
format fs=<ntfs|fat32|fat> [quick] — создать указанную фаловую систему [не затирая нулями информацию, находившуюся ранее]
// Для лениксоидов: assign — монтировать, remove — размонтировать
assign [letter=X] — назначить выбранному разделу букву [букву X]
remove [letter=X] — удалить букву выбранного раздела [или просто удалить букву X]
На каком-нибудь работающем компухтере создаём папку (например, Soft) на загрузочной флешке и кидаем туда то, что планируем запускать (например, wimlib-imagex.exe для разворачивания системы)
-
Shift+F10
— запускаем командную строкуНа самом деле, эта штука правильно называется интерпретатор командной строки, but who cares?..
-
cd /d X:
— судорожно ищем нашу флешку, подставляя буквы (C, D, E, …) на место X.Проверить, что это именно искомая флешка можно командой
dir
. В списке будет видна папка Soft -
cd Soft
— переходим в папку Soft -
wimlib-imagex.exe
— запускаем то, что на нужноВ командной строке есть автодополнение: достаточно ввести часть имени файла
wimli
и нажать Tab, как содержимое будет дополнено доwimlib-imagex.exe
Самая что ни на есть обычная установка~
- Загрузка минимального Шиндовс (WinPE) из sources\boot.wim. Содержимое образа распаковывается в создаваемый RAM-диск (диск в оперативной памяти, скорость чтения с которого катастрофически выше, чем с HDD)
- Запускается setup.exe из корня RAM-диска
-
Поскольку данный гуидо именно про установку, восстановление рассмотрено не будет. По крайней мере, пока.
Обновление также рассматриваться не будет, ибо зачастую проще установить с нуля.
-
По нажатию на "Настройку диска" установщик ОС шиндовс предоставляет кое-какие возможности для разметки, но пользоваться этим довольно опасно — изменения применяются моментально.
На UEFI ОС шиндовс требует небольшого раздела для создания ESP: !!! Уточнить, с какой целью создаётся раздел на не UEFI-системах
Дальнейшие пункты разбирать смысла не вижу, ибо заполнить поля и кликнуть оставшиеся "Далее" сможет и распоследняя обезьяна. Гораздо интереснее остановиться на тез местах, в которых установщик может внезапно начать копротивляться.
Они логично проистекают из ограничений оригинального установщика:
- Доступны только схемы BIOS+MBR и UEFI+GPT
- Нельзя отказаться от установки загрузчика
Посему для запиливания уникальной™ конфигурации со скайпом и кортанами надобно пользовать другие способы раскатывания ОС на накопитель.
Pro:
- Разворачивание всего-всего
- Возможность установить загрузчик куда угодно (или вообще его не трогать)
Contra:
- Разбивать диск надобно вручную
Отлично запускается из WinPE. Рекомендую пользовать вместе с BootIce.
CSM — Compatibility Support Module
EBR — Extended Boot Record
FSBL — First-stage Boot Loader
HDPT — Hard Drive Partition Table
PBR — Partition Boot Record
POST — Power-On Self-Test
SSBL — Second-stage Boot Loader
VBR — Volume Boot Record