Вливаясь на hda при подключенном sda, сказал поселить всё на hda; при установке загрузчика по умолчанию был выбран sda. Это несущественный вопрос, но при прочих равных будет чуточку лучше выбирать по умолчанию девайс, где /boot или /. Возможно решать после 4.0, думаю. Спасибо!
Это сейчас воспроизводится.
(In reply to comment #1) Это сейчас воспроизводится?
Не знаю, надо проверить. На стенде как раз hda+sda сейчас и стоит.
Это сейчас воспроизводится? Если нет, то INVALID.
Значит уже не актуально
Не факт, скорее NEEDINFO... ладно, если вспомню и успею проверить, то посмотрю. Последний раз некоторый "тест" получился с sda/sdb: SATA-диск и USB Flash; загрузчик из Junior установился нормально, другое дело, что на флэшку поселили своп. Но это другая сказка. :]
qawanted: Перед тем как менять статус этой баги, получите `fdisk -l` с конфигурации на которой воспроизвелось. Без этой информации найти ошибку в модуле будет сложно.
У меня сейчас на стенде подходящая конфигурация. Тебе ж интересней на сизифном образе, правильно? (есть ещё M40)
Гм. 1) актуально для alterator-lilo-0.2-alt6 2) опять ide+sata, разбивка "снести всё" встала на sata, а вот загрузчик по умолчанию попытался бы встать на ide (переставил на sata).
Created attachment 2571 [details] `fdisk -l` вывод fdisk -l из уже установленной системы
А что в этом желании загрузчика плохого ? ... это же первый диск по выводу fdisk.
Можно конечно дать приоритет диску с корнем, но где гарантия что он первый и что он загрузится после ребута ?
(In reply to comment #12) > Можно конечно дать приоритет диску с корнем, но где гарантия что он первый и что > он загрузится после ребута ? Логично, в биосе второй диск с корнем может не стоять в последовательности загрузки вообще и выяснить это невозможно. Думаю что от модуля просят "ложной" фичи и предлагаю багу закрыть ;) Не надо смешивать понятия: "диск где система" и "диск с которого умеет грузиться комп" ...
(In reply to comment #11) > А что в этом желании загрузчика плохого ? ... > это же первый диск по выводу fdisk. Этот вывод, как сегодня выяснили -- всего лишь следствие порядка загрузки модулей... Кстати, корень точно так же мог оказаться на hda -- поведение /vm для меня тут слегка загадочно, хотя и "одобрямс" за исключением выноса hda подчистую. (In reply to comment #13) > > Можно конечно дать приоритет диску с корнем, но где гарантия что он первый > > и что он загрузится после ребута ? Гарантии нет, но разумности в среднем больше. > Логично, в биосе второй диск с корнем может не стоять в последовательности > загрузки вообще и выяснить это невозможно. Насколько понимаю, именно так. Но. Многодисковые сетапы не являются тривиальным случаем, поэтому вообще говоря -- можно ожидать некоторой осведомлённости от ставящего. При этом среди таких случаев у меня и по знакомым обычно загрузка нацелена всё-таки на тот диск, где корень. > Думаю что от модуля просят "ложной" фичи и предлагаю багу закрыть ;) Я не буду особо брыкаться, но предлагаю в таком случае перевесить на меня -- типа, "тебе надо" ;) > Не надо смешивать понятия: "диск где система" > и "диск с которого умеет грузиться комп" ... По крайней мере на сейчас возможно проверять (lilo -t) то, куда собираемся "ткнуть пальцем" по умолчанию, не показывая результатов облома вида Lilo test: Fatal: Bios device code 0x80 is being used by two disks /dev/sda (0x0800) and /dev/hda (0x0300) в окошечке _после_ согласия с предложенным дефолтом, а меняя дефолт на следующий по порядку и проверяя его. Боюсь, у нас действительно нет менее бинарного способа определения того, "прокатит" или нет.
Я этим модулем больше не занимаюсь. На нового разработчика. Reassign => slazav@
lilo -T bios в инсталяторе не катит, почему-то. Так что я сейчас не умею определять диск, с которого будет грузиться система.
/proc всякий там точно смонтирован?
(В ответ на комментарий №16) > lilo -T bios в инсталяторе не катит, почему-то. Так что я сейчас не умею > определять диск, с которого будет грузиться система. lilo -T bios (а также vol-ID, geom, EBDA) работают только в том случае, если ядро было загружено через lilo (загрузчик оставляет в памяти данные, которые потом читает /sbin/lilo). Теоретически можно написать модуль для syslinux, который будет собирать аналогичную информацию, но польза от него в установщике сомнительна, поскольку для загрузки самого установщика может потребоваться изменение конфигурации загрузочных устройств в BIOS, в результате чего собранная информация не будет соответствовать конфигурации, используемой при обычной загрузке (в частности, в случае install-flash практически гарантированно номер 0x80 получит флешка).
Видимо, alterator-lilo следует считать заброшенным. На nobody@
Пакет alterator-lilo удалён из Сизифа заданием 337507.100 (30.12.2023, has_not_been_used_for_many_years), неактуально.
