Bug 21491 - bad lilo.conf for lvm root with two or more hdd
: bad lilo.conf for lvm root with two or more hdd
Status: CLOSED WONTFIX
: Sisyphus
(All bugs in Sisyphus/bootloader-utils)
: unstable
: all Linux
: P3 normal
Assigned To:
:
:
:
:
:
  Show dependency tree
 
Reported: 2009-09-09 11:20 by
Modified: 2010-10-01 01:38 (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2009-09-09 11:20:55
Лило в своей работе использует трансформацию имени устройства в major:minor и в
таком виде передает его ядру в параметре root=. В случае корневого раздела на
lvm (предполагаю что это верно и для других вариантов использования
device-mapper) комбинация major:minor легко разъезжается при наличии второго
диска с отдельным volume group. Решением является передача параметра root через
append или addappend, в таком случае ядро получает символьное описание
устройства с корневым разделом и уже на совести initrd его найти в системе.
Опыт других дистрибутивов и мои эксперименты не выявили регрессий при этом
варианте.
------- Comment #1 From 2009-09-09 12:03:12 -------
(In reply to comment #0)
> Лило в своей работе использует трансформацию имени устройства в major:minor и в
> таком виде передает его ядру в параметре root=.

Если root в lilo.conf указан в виде
root="UUID=..."
то lilo передаёт эту информацию ядру в символьном виде.

Попробуйте
http://git.altlinux.org/people/ldv/packages/?p=bootloader-utils.git;a=commit;h=0.3.3-alt1-1-g14e61df
------- Comment #2 From 2009-09-09 12:13:03 -------
Тоже вариант, но uuid совсем не дружелюбный способ задания информации. И совсем
не работает для lvm root, если воспользоваться lilo-22.8 с патчами от
suse/fedora/mandriva, так их вариант взрывает при наличии /dev/dm-[0-9]*
устройств, если с помощью правил udev эти устройства переместить в другое
место, то initrd не может найти rootfs. В принципе вариант, lilo-22.8 от PLD не
обладает этим недостатком, но я с ним не проверял uuid. Сегодня проверю и
отпишусь. Но append/addappend работает с любым lilo и используется повсеместно.
------- Comment #3 From 2009-09-09 13:00:48 -------
Кажется, это предложение затрагивает и alterator-lilo. Но я пока не понял, чем
для него плох root=UUID=, как сейчас, так что пока подожду что-либо делать.

Интересно, а что оказывается в /proc/mounts при передаче root через append?

(На эту тему есть еще комментарии vsu в #20292 - как lilo передает ядру
параметр root и что с ним делает initrd...)

> Попробуйте
Хм, странный коммит. Количество скобок и палок странное.
------- Comment #4 From 2009-09-09 13:10:23 -------
(В ответ на комментарий №3)
> Кажется, это предложение затрагивает и alterator-lilo. Но я пока не понял, чем
> для него плох root=UUID=, как сейчас, так что пока подожду что-либо делать.
Тем, что не работает для root на lvm без отдельного /boot.
Только проверил, root по uuid не находится, сейчас сделаю кастомный initrd с
ls, постараюсь понять что не так...
> 
> Интересно, а что оказывается в /proc/mounts при передаче root через append?
Тоже, что и при прямой передаче root=.
Этот параметр влияет на логику работы initrd
------- Comment #5 From 2009-09-09 13:43:14 -------
(In reply to comment #3)
> > Попробуйте
> Хм, странный коммит. Количество скобок и палок странное.

cut-n-paste error, пробовать надо
http://git.altlinux.org/people/ldv/packages/?p=bootloader-utils.git;a=commit;h=0.3.3-alt1-1-gfa15069
------- Comment #6 From 2009-09-09 14:45:49 -------
Добрался посмотреть с кастомным initrd. /dev/disk/by-uuid вообще отсутствует,
когда все диски на lvm. Вероятно проблема в правилах udev, который не
пересканирует диски после инициализации lvm, но в udev я не разбираюсь... Так
что apped/addappend пока что единственный рабочий вариант.
------- Comment #7 From 2009-09-20 03:11:27 -------
Если root="UUID=..." пойдёт в виде append'а, то от initrd всё равно потребуется
поддержка UUID'ов.  Таким образом получается, что append= в случае
использования UUID'ов ничем не лучше того, что installkernel делал всегда.
------- Comment #8 From 2010-10-01 01:38:22 -------
Apparently wontfix.