# [SOLVED] GRUB Error 17

## CerberUA

Итак, amd64-система с 4-мя "винтами" (1 IDE и 3 SATA) и SATA DVD-RW:

HDD 200GB Seagate IDE - разъём IDE Primary Master

DVD-RW Pioneer SATA - разъём SATA-1

HDD 320GB Seagate SATA - разъём SATA-2

HDD 500GB Samsung SATA - разъём SATA-3

HDD 1TB Samsung SATA - разъём SATA-4

"Винты" именно в таком порядке отображаются в BIOS, как в Default CMOS config., так и в HDD boot order.

Основной загрузочный - 200GB IDE, на нем установлена WinXP x64. На 320GB SATA стояла Gentoo:

/dev/sda1 - swap

/dev/sda2 - ext3, /

/dev/sda3, /dev/sda5, /dev/sda6 - NTFS разделы

Генту ставил по хендбуку, вполне осознанно, вдумчиво. GRUB прописывал вручную: root (hd1,1); setup (hd0). Он мне вежливо по TAB'у подсказывал, что все верно, что hd1,1 - ext2, что stage все нашел. И все было хорошо. К тому же, т.к. раздел с Виндой - hd0,0, то в grub.conf играться с ремаппингом не было нужды. Все работало, и было счастье. 

Одно было плохо - маловато я места для Генты отдал, да и разделов сильно не нарежешь: первичных всего 2, а логических между NTFS'ами не воткнешь. И вот тут началось...

 Из под Винды в Acronis Disk Director'е я удалил разделы с Генту (sda1 и sda2), первичный NTFS (sda3) уменьшил в размерах и превратил из первичного в логический (sda3->sda5, sda5->sda6, sda6->sda7). И стало у меня около 40GB неразмеченного пространства и 3 свободных номера под первичные разделы. С виндового загрузочного диска с помощью "fdisk /mbr" MBR на 200GB IDE был очищен от GRUB. Все вроде в норме, "винды" грузятся, проблем с доступом к "обработанным" разделам нет (даже "буквы" не сбились, т.к. вручную назначены изначально).

 Далее дисковые операции проводились из-под Генты с minimal-live-cd. С помощью fdisk на 320GB SATA (/dev/sda)созданы:

/dev/sda1 - 100MB для /boot

/dev/sda2 - 2GB для swap

/dev/sda3 - 5GB для /

С помощью parted расширенный раздел был растянут на все оставшееся свободное место и уже в нем через fdisk были созданы (с учетом финальной правки порядка номеров):

/dev/sda5 - 2GB для /tmp

/dev/sda6 - оставшиеся 31GB для /home

NTFS-ы стали sda7,8,9 соответственно. Флаг "загрузочный" установлен для раздела /dev/sda1. Сообщений об ошибках, сбоях и несоответствиях не было.

Далее согласно хендбуку и накопленному опыту была выполнено форматирование (sda1 и sda5 - ext2, sda3 и sda6 - ext4), установка и предварительная настройка Генту. Конфиг ядра (с поддержкой ext4), grub.conf и fstab использованы от предыдущей Генту с соответствующей правкой касательно /dev/sda. Соответственно был установлен и сам GRUB:

```
# emerge -va grub

# grub

grub> root (hd1,0)

grub> setup (hd0)

grub> quit

```

Все вроде в норме, файловые системы соответствуют, stage-файлы найдены, загрузчик установлен. Делаю reboot...

```
GRUB Loading stage1.5

GRUB loading, please wait...

Error 17

```

Пробовал подсовывать другие root (x,y), другие setup (x) и даже setup (x,y), править root (x,y) в grub.conf - безрезультатно и ошибочно, даже приходилось лечить "виндовыми" fdisk /mbr и fixboot.

А вот теперь САМОЕ интересное: стоило физически отключить 500GB и 1TB SATA винты - система стартовала, и Винды, и Генту.

И вот теперь я абсолютно не могу понять, каким образом эти винты рушат порядок загрузки? Они физически подключены последними, в БИОСе обнаруживаются последними, в порядке загрузки стоят последними, с gentoo-minimal-cd из-под chroot'а GRUB их видит последними! (hd2 и hd3). 

Может кто-то сможет это объяснить, ибо я уже готов расписаться в бессилии? Также буду благодарен за советы и рекомендации по излечению...

----------

## CerberUA

Продолжение...

Для полного счастья прописал GRUB еще и на 320GB SATA, указав все-же root (x,y) так, будто этот винт стоит 2-м, т.е. 

grub> root (hd1,0)

grub> setup (hd1)

grub> quit

chroot exit, umount, reboot... Error 17. Что, собственно, логично, ибо эти действия - полная шизофрения.

Ну и напоследок ставлю 320-ник с Гентой в БИОСе первым в список загрузки - вуаля! Ошибки нет, черный экран, через полминуты сообщение о невозможности загрузки Винды. Перезагрузка, черный экран, кнопка вниз, Enter, Gentoo тоже не грузится.

Ну, тут уже все понятно: черный экран - потому что в grub.conf неправильный путь к splash-image, ОСи не грузятся по той же самой причине. Ну ничего, правим ручками, запускаем Gentoo и правим уже по-настоящему. Перезагрузка, проверка - все в норме.

Так что проблему я решил, а точнее обошел. Истинные же причины так и остались непонятными.

----------

## fank

столкнулся несколько лет назад с похожей проблемой

дело все в том, что есть некий удивительный баг с тем, что ядро и биос и виндовс (одну из экзотических разновидностей мне и нужно было загружать с помощью линукса) по разному понимают геометрию дисков, очередность их именования и соответственно, критерии выполнения первых 446 байт MBR

проблема была только с матерями asus p5ld

решил таким грязным и страшным хаком, что в присутствии приличных людей вербально вопроизвести это безобрание никогда не решусь

----------

