11429 2007-04-09 18:51:53 +0400 [FR][4.1] default MBR in one-of-a-few-disks setup 2010-11-03 15:29:35 +0300 1 1 4 Development Sisyphus alterator-lilo unstable all Linux NEW P2 enhancement --- 12100 1 mike nobody boyarsh mike rom_as sbolshakov vsu qa-sisyphus oldest_to_newest 48506 0 mike 2007-04-09 18:51:54 +0400 Вливаясь на hda при подключенном sda, сказал поселить всё на hda; при установке загрузчика по умолчанию был выбран sda. Это несущественный вопрос, но при прочих равных будет чуточку лучше выбирать по умолчанию девайс, где /boot или /. Возможно решать после 4.0, думаю. Спасибо! 58027 1 legion 2007-11-11 21:58:42 +0300 Это сейчас воспроизводится. 58028 2 legion 2007-11-11 21:59:04 +0300 (In reply to comment #1) Это сейчас воспроизводится? 58034 3 mike 2007-11-11 23:45:45 +0300 Не знаю, надо проверить. На стенде как раз hda+sda сейчас и стоит. 58743 4 legion 2007-11-28 08:55:50 +0300 Это сейчас воспроизводится? Если нет, то INVALID. 59412 5 legion 2007-12-12 12:17:30 +0300 Значит уже не актуально 59622 6 mike 2007-12-16 13:57:57 +0300 Не факт, скорее NEEDINFO... ладно, если вспомню и успею проверить, то посмотрю. Последний раз некоторый "тест" получился с sda/sdb: SATA-диск и USB Flash; загрузчик из Junior установился нормально, другое дело, что на флэшку поселили своп. Но это другая сказка. :] 68274 7 legion 2008-04-14 14:56:44 +0400 qawanted: Перед тем как менять статус этой баги, получите `fdisk -l` с конфигурации на которой воспроизвелось. Без этой информации найти ошибку в модуле будет сложно. 68297 8 mike 2008-04-14 18:31:06 +0400 У меня сейчас на стенде подходящая конфигурация. Тебе ж интересней на сизифном образе, правильно? (есть ещё M40) 68374 9 mike 2008-04-15 20:32:49 +0400 Гм. 1) актуально для alterator-lilo-0.2-alt6 2) опять ide+sata, разбивка "снести всё" встала на sata, а вот загрузчик по умолчанию попытался бы встать на ide (переставил на sata). 68375 10 2571 mike 2008-04-15 20:34:30 +0400 Created attachment 2571 `fdisk -l` вывод fdisk -l из уже установленной системы 68388 11 legion 2008-04-16 01:15:15 +0400 А что в этом желании загрузчика плохого ? ... это же первый диск по выводу fdisk. 68389 12 legion 2008-04-16 01:17:12 +0400 Можно конечно дать приоритет диску с корнем, но где гарантия что он первый и что он загрузится после ребута ? 68414 13 inger 2008-04-16 11:09:05 +0400 (In reply to comment #12) > Можно конечно дать приоритет диску с корнем, но где гарантия что он первый и что > он загрузится после ребута ? Логично, в биосе второй диск с корнем может не стоять в последовательности загрузки вообще и выяснить это невозможно. Думаю что от модуля просят "ложной" фичи и предлагаю багу закрыть ;) Не надо смешивать понятия: "диск где система" и "диск с которого умеет грузиться комп" ... 68490 14 mike 2008-04-17 00:37:50 +0400 (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) в окошечке _после_ согласия с предложенным дефолтом, а меняя дефолт на следующий по порядку и проверяя его. Боюсь, у нас действительно нет менее бинарного способа определения того, "прокатит" или нет. 69534 15 legion 2008-05-08 19:22:07 +0400 Я этим модулем больше не занимаюсь. На нового разработчика. Reassign => slazav@ 85870 16 slazav 2009-02-14 15:49:55 +0300 lilo -T bios в инсталяторе не катит, почему-то. Так что я сейчас не умею определять диск, с которого будет грузиться система. 85875 17 mike 2009-02-14 18:24:17 +0300 /proc всякий там точно смонтирован? 85877 18 vsu 2009-02-14 18:36:38 +0300 (В ответ на комментарий №16) > lilo -T bios в инсталяторе не катит, почему-то. Так что я сейчас не умею > определять диск, с которого будет грузиться система. lilo -T bios (а также vol-ID, geom, EBDA) работают только в том случае, если ядро было загружено через lilo (загрузчик оставляет в памяти данные, которые потом читает /sbin/lilo). Теоретически можно написать модуль для syslinux, который будет собирать аналогичную информацию, но польза от него в установщике сомнительна, поскольку для загрузки самого установщика может потребоваться изменение конфигурации загрузочных устройств в BIOS, в результате чего собранная информация не будет соответствовать конфигурации, используемой при обычной загрузке (в частности, в случае install-flash практически гарантированно номер 0x80 получит флешка). 114803 19 slazav 2010-11-03 15:29:35 +0300 Видимо, alterator-lilo следует считать заброшенным. На nobody@ 2571 2008-04-15 20:34:30 +0400 2008-04-15 20:34:30 +0400 `fdisk -l` fdisk-l text/plain 721 mike CkRpc2sgL2Rldi9oZGE6IDgwLjAgR0IsIDgwMDI2MzYxODU2IGJ5dGVzCjE2IGhlYWRzLCA2MyBz ZWN0b3JzL3RyYWNrLCAxNTUwNjEgY3lsaW5kZXJzClVuaXRzID0gY3lsaW5kZXJzIG9mIDEwMDgg KiA1MTIgPSA1MTYwOTYgYnl0ZXMKRGlzayBpZGVudGlmaWVyOiAweDAwMDAwMDAwCgogICBEZXZp Y2UgQm9vdCAgICAgIFN0YXJ0ICAgICAgICAgRW5kICAgICAgQmxvY2tzICAgSWQgIFN5c3RlbQoK RGlzayAvZGV2L3NkYTogODAuMCBHQiwgODAwMjUyODAwMDAgYnl0ZXMKMjU1IGhlYWRzLCA2MyBz ZWN0b3JzL3RyYWNrLCA5NzI5IGN5bGluZGVycwpVbml0cyA9IGN5bGluZGVycyBvZiAxNjA2NSAq IDUxMiA9IDgyMjUyODAgYnl0ZXMKRGlzayBpZGVudGlmaWVyOiAweDQyMTZlYTM2CgogICBEZXZp Y2UgQm9vdCAgICAgIFN0YXJ0ICAgICAgICAgRW5kICAgICAgQmxvY2tzICAgSWQgIFN5c3RlbQov ZGV2L3NkYTEgICAqICAgICAgICAgICAxICAgICAgICAgMTI4ICAgICAxMDI4MTI4KyAgODIgIExp bnV4IHN3YXAgLyBTb2xhcmlzCi9kZXYvc2RhMiAgICAgICAgICAgICAxMjkgICAgICAgICA2NTAg ICAgIDQxOTI5NjUgICA4MyAgTGludXgKL2Rldi9zZGE0ICAgICAgICAgICAgIDY1MSAgICAgICAg OTcyOSAgICA3MjkyNzA2NysgICA1ICBFeHRlbmRlZAovZGV2L3NkYTUgICAgICAgICAgICAgNjUx ICAgICAgICA5NzI5ICAgIDcyOTI3MDM2ICAgODMgIExpbnV4Cg==