Это сейчас воспроизводится.

(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), неактуально.