При выборе установки в MBR, в конфигурацию lilo попадает строка вида boot="/dev/sdX" По крайней мере, это касается инсталлятора Server 4.0 Из-за того, что в 2.6.27 меняется тип некоторых устройств (hda -> sda) и плохо предсказуем порядок их определения, надо начинать привязываться к чему-то ещё. Например, /dev/disk/by-id/..., но тут следует помнить комментарий Сергея Власова: "между 2.6.18 и более новыми ядрами эти идентификаторы могут меняться, если название модели диска слишком длинное (например, как у Hitachi) - в старых ядрах это поле при использовании драйверов libata обрезалось до 16 символов, в то время как в ATA допускается до 40 символов." Ещё, как вариант, можно запретить ставить загрузчик в MBR, тогда можно будет пользоваться UUID.
уже в 4.1 это исправлено...
Понятно. Вот инсталлятор от 4.1 не вышло попробовать пока. А в 4.0 проапдейчено на будущее ?
в 4.0 это вряд ли будет. Слишком далеко ушел alterator вообще и alterator-lilo в частности... Но ведь и 2.6.27 в 4.0, вроде, не ожидается...
На проблему можно наступить с помощью dist-upgrade...
Кажется, что при таком gist-upgrade 1. придется поменять источник на 4.1 или т.п. (иначе откуда возьмется новое ядро?) 2. можно наступить и на много других проблем 3. ядро, вроде, не должно само обновиться, а вот alterator-lilo - да.
Это всё так, только вот lilo.conf автоматом не исправится... Если на базе 4.0 ещё планируется выпуск дистрибутивов, было бы лучше, если бы инсталлятор создавал конфиг, который будет работоспособен в 2.6.27. Судя по http://www.altlinux.org/Main_Page, ещё планируется, минимум, 4.0 Children.
(In reply to comment #6) > Это всё так, только вот lilo.conf автоматом не исправится... Да. Это, действительно, проблема, на которую можно налететь при обновлении 4.0 -> Sisyphus (в 4.1 нет ядра .27). И на уже установленных системах новый alterator-lilo не поможет. > Если на базе 4.0 ещё > планируется выпуск дистрибутивов, было бы лучше, если бы инсталлятор > создавал конфиг, который будет работоспособен в 2.6.27. Судя по > http://www.altlinux.org/Main_Page, ещё планируется, минимум, 4.0 Children. Что-то не верится ни в будущие дистрибутивы на 4.0 ни в 2.6.27 в 4.0...
(In reply to comment #7) > Да. Это, действительно, проблема, на которую можно налететь при обновлении 4.0 > -> Sisyphus (в 4.1 нет ядра .27). Что хуже, при обновлении 4.1 -> 5.0, что в дистрибутивах-таки должно поддерживаться. При обновлении Server 4.0 на Server 5.0, когда он будет, тоже это вылезет.
> Что хуже, при обновлении 4.1 -> 5.0, что в дистрибутивах-таки должно > поддерживаться. 1. В 4.1 lilo.conf уже создается правильно. 2. alterator-lilo из 4.1 все правильно запишет. Если его запустят. Но кто будет переписывать существующий lilo.conf при обновлении? > При обновлении Server 4.0 на Server 5.0, когда он будет, тоже это вылезет. насколько я знаю, server сначала будет 4.1
(In reply to comment #9) > 1. В 4.1 lilo.conf уже создается правильно. Во 4.1.0 тоже, или при апгрейде требуется сначала поставить все апдейты? > насколько я знаю, server сначала будет 4.1 Server? Не OfficeServer?
> > 1. В 4.1 lilo.conf уже создается правильно. > > Во 4.1.0 тоже, или при апгрейде требуется сначала поставить все апдейты? Да, в 4.1.0, наверное, этого может еще не быть. При апгрейде lilo.conf сам никак не исправится. > > насколько я знаю, server сначала будет 4.1 > > Server? Не OfficeServer? Да, я перепутал. Все-таки, видимо не стоит переносить alterator-lilo в 4.0. Но можно подумать про скрипты, которые запускаются при обновлении ядра, на тему исправления lilo.conf. Но я сейчас про них вообще ничего не знаю :)
Тогда куда бы баг перевешать?
