[devel] разбивалка диска (почему-то было: Шаги инсталлятора)
Leonid Krivoshein
klark.devel на gmail.com
Чт Июн 21 22:43:52 MSK 2018
21.06.2018 12:36, Alexey V. Vissarionov пишет:
> On 2018-06-21 11:17:43 +0300, Michael Shigorin wrote:
>
> >> решил пока сильно шашкой не размахивать, а осилить "маленький,
> >> но важный кусочек", связанный с разбивкой диска,
> > Это ни разу не "маленький", а САМЫЙ (с большим отрывом) сложный
> > кусок инсталятора для разработчика и для пользователя тоже.
>
> Самым сложным при этом является вопрос "чего хочу?", на который
> приходится отвечать пользователю.
При написании такого бэкэнда с нуля мне бы очень хотелось реализовать
несколько вещей. Во-первых, обеспечить хотя бы тот функционал, что мы
имеем на сейчас через libevms. Во-вторых, обеспечить возможность
расширения базового функционала. В-третьих, очень хочется не нарушать
семантики существующих командных интерфейсов работы с дисками (sfdisk,
mdadm, lvm, dmsetup, losetup, cryptsetup). В четвёртых, хотелось бы
обеспечить функционал для работы с кнопками "отменить" и "вернуть" на
любое число шагов в дополнении к ранее оговоренной кнопке "применить". В
пятых, с чего я собственно и начал, хотелось бы иметь возможность
разбивать не только реальные диски "на живую", но и планировать будущую
разбивку с последующей записью в файл или скрипт на вполне себе
"выдуманных" блочных устройствах. А уж чего там хочет пользователь,
какими подсказками или дефолтами ему это обеспечит фронтэнд
инсталлятора, меня пока точно не касается.
> > Его сложность обусловлена, с одной стороной, огромным
> > наследием самых разных устройств
>
> Практически все современные блочные устройства, используемые для
> размещения корневой ФС, позволяют работать с ними точно так же,
> как с жесткими дисками, а эти методы не менялись более 20 лет.
В плане достаточных и необходимых знаний о блочном устройстве -- да. Но
подходы по организации работы с ними как раз в последние годы достаточно
сильно менялись, хотя конечно речь о новых возможностях, которые мы не
привыкли активно использовать, в том числе на этапе инсталляции или
массового развёртывания. Например, отложенная запись на backing-device,
integrity (совместно с шифрованием), кэширование (lvm), replay log имени
Facebook, да я наверное всего сходу не перечислю.
> > Известных мне работающих "машинок состояния", которые умеют
> > "держать в уме" нюансы устройств/разбивок/ФС -- ровно два: libevms
> > (апстрим давно умер) и libparted (который, помнится, сделали из
> > партеда дебианщики для своего инсталятора).
>
> Лично я не доверяю ни тому, ни другому. Поэтому просто озвучу хотелку:
> нужна возможность запустить терминал и сделать вручную все необходимое
> (в вышеприведенном примере это будет монтирование /dev/md0 в /target и
> /dev/md1 в /target/home).
С таким выбором согласен. Для скриптов/автоматики sfdisk лучше прочих,
пригоден для разметки MBR/GPT и не только. sfdisk/fdisk/cgdisk/gdisk
основаны на libfdisk из linux-utils. На текущий момент код там очень
качественный, много переносов из ядра. Если не доверять ему, тогда
вообще непонятно, чему доверять. В некоторых наших инсталляторах нет ни
mdadm, ни lvm, графический фронтэнд работает напрямую через libevms. Но
то, что ты хочешь, он делать умеет, хотя монтируется у нас всё всегда в
/mnt/destination. Надеюсь, к 8.3 исправится ситуация с установкой grub
на md-raid (на сейчас только в этом небольшой затык, пакет к этому
готов, но установочных образов 8.3 с ним на борту в природе ещё не
появились).
--
Best regards,
Leonid Krivoshein.
Подробная информация о списке рассылки Devel