Исправление user_id_68054, (текущая версия) :
Может ты мне разъяснишь, а то мне непонятно. КАК могут измениться эти номера _между_ загрузками?
в обычной линуксовской жизни — номера разделов спонтанно поменяться не могут...
однако бяка может случиться — если в жизни имеет место быть второй системой — Microsoft Windows :-) ..
[*** ага, без Microsoft не обошлось... дальше можно не читать :) ***]
во время операции Disk Management (в Microsoft Windows, или в момент установки Microsoft Windows на компьютер) — происходит сортировка номеров разделов.
внутри утилит из пакета GPT_fdisk (gdisk,sgdisk) — тоже есть функция сортировки нормеров разделов, однако сама эта функция (в отличии от Microsoft Windows) САМОПРОИЗВОЛЬНО вызваться НЕ может, без ведома владельца компьютера :-)
риторический вопрос:
каким образом сортировка номеров разделов может всё накосячить (?), как это может произойти именно на практике?
ответ:
в случае если у пользователя есть небольшое свободное место где-то ПЕРЕД /boot/-разделом [например свободное пространство в пару гигобайт на двухтебибайтном диске (2TiB), почти не заметный пустячок :)]...
то во время устновки Microsoft Windows — говноустановщик запишет на это свободное пространство какой-то свой служебный говнораздел (непонятного назначения), и затем отсортирует номера разделов (молча, без спроса).
в итоге /boot/-раздел увеличит свой номер как минимум на 1 единицу :) ..
GRUB (GRUB2) уже после этого не загрузится (сразу говорю что раздел «BIOS Boot Partition {21686148-6449-6E6F-744E-656564454649}» тут не причём, эти данные НЕ затираются).
а зачем их вообще искать во время загрузки? Что это даёт, и кому? Почему нельзя жёстко прописать номера LBA секторов, как в lilo?
особо много я не экспериментировал с Lilo, но я подозреваю что Lilo не подгружает свой конфигурационный файл — динамически.
после каждого изменения конфигурационного файла приходится заново внедрять загрузчик в жёсткий диск? это ведь так?
GRUB (GRUB2) подгружает свой конфигурационный файл (и модули) — динамически во время загрузки. это касается кстате не только файла /boot/grub/grub.cfg но также и файла /boot/grub/custom.cfg
риторический вопрос:
и всё же почему раздел с конфигурационный файлом и модулями — идентифицируется по своему номеру, а не через номер_LBA_сектора?
ответ:
я не знаю, но видемо разработчики GRUB (GRUB2) — либо не задумывались на эту тему, либо считают что идентификация /boot/-раздела через номер_LBA_сектора — является костыльным и НЕ элегантным решением :) .. тут я могу только выразить свои догадки. точно сказать не могу... см.. Какие загрузчики ОС Вы используете? (комментарий)
Исходная версия user_id_68054, :
Может ты мне разъяснишь, а то мне непонятно. КАК могут измениться эти номера _между_ загрузками?
в обычной линуксовской жизни — номера разделов спонтанно поменяться не могут...
однако бяка может случиться — если в жизни имеет место быть второй системой — Microsoft Windows :-) ..
[*** ага, без Microsoft не обошлось... дальше можно не читать :) ***]
во время операции Disk Management (в Microsoft Windows, или в момент установки Microsoft Windows на компьютер) — происходит сортировка номеров разделов.
внутри утилит из пакета GPT_fdisk (gdisk,sgdisk) — тоже есть функция сортировки нормеров разделов, однако сама эта функция (в отличии от Microsoft Windows) САМОПРОИЗВОЛЬНО вызваться НЕ может, без ведома владельца компьютера :-)
риторический вопрос:
каким образом сортировка номеров разделов может всё накосячить (?), как это может произойти именно на практике?
ответ:
в случае если у пользователя есть небольшое свободное место где-то ПЕРЕД /boot/-разделом [например свободное пространство в пару гигобайт на двухтебибайтном диске (2TiB), почти не заметный пустячок :)]...
то во время устновки Microsoft Windows — говноустановщик запишет на это свободное пространство какой-то свой служебный говнораздел (непонятного назначения), и затем отсортирует номера разделов (молча, без спроса).
GRUB (GRUB2) уже после этого не загрузится (сразу говорю что раздел «BIOS Boot Partition {21686148-6449-6E6F-744E-656564454649}» тут не причём, эти данные НЕ затираются).
а зачем их вообще искать во время загрузки? Что это даёт, и кому? Почему нельзя жёстко прописать номера LBA секторов, как в lilo?
особо много я не экспериментировал с Lilo, но я подозреваю что Lilo не подгружает свой конфигурационный файл — динамически.
после каждого изменения конфигурационного файла приходится заново внедрять загрузчик в жёсткий диск? это ведь так?
GRUB (GRUB2) подгружает свой конфигурационный файл (и модули) — динамически во время загрузки. это касается кстате не только файла /boot/grub/grub.cfg но также и файла /boot/grub/custom.cfg
риторический вопрос:
и всё же почему раздел с конфигурационный файлом и модулями — идентифицируется по своему номеру, а не через номер_LBA_сектора?
ответ:
я не знаю, но видемо разработчики GRUB (GRUB2) — либо не задумывались на эту тему, либо считают что идентификация /boot/-раздела через номер_LBA_сектора — является костыльным и НЕ элегантным решением :) .. тут я могу только выразить свои догадки. точно сказать не могу... см.. Какие загрузчики ОС Вы используете? (комментарий)