Монтирование разделов, выполняемое из initrd

cast gentoo_root

Не вижу в драфте что решено делать с /lib/modules

Это только механизм. А что делать с /lib/modules это уже политика. В частности, может быть решение «в лоб»: можно в пакет дистрибутива, задающий базовую разметку файловой системы, затолкать симлинк /lib/modules -> /boot/lib/modules

1.

из переменной rootdev.

Зачем rootdev, когда есть root=... ?

Анализируется файл /etc/fstab. Если в нём

Что мешает примонтировать всё?

выполняется новый алгоритм

2. Предложи Поттерингу, он любит костыли.

Зачем rootdev, когда есть root=... ?

Однофигственно.

Что мешает примонтировать всё?

А давай ты сам догадаешься, что мешает примонтировать весь fstab в момент работы initramfs?

что мешает примонтировать весь fstab в момент работы initramfs?

Кривые руки, ваш К.О.

Проходи мимо, самим жрать нечего.

Надо ещё как-то указывать опции монтирования. Причём разные для разных ФС. Например, /usr и /boot монтировать в ro, /home в rw,nodev, для /tmp в tmpfs указать размер. /etc можно было бы тоже в ro, если бы там не было всяких левых файликов типа /etc/resolv.conf. Хотя можно его переместить в /tmp и сделать симлинк.

Ещё тип ФС надо указывать (иначе tmpfs не смонтируется или какой-нибудь сферический ntfs-3g в вакууме неправильно смонтируется). Далее, нужны аналоги опций rootwait и rootdelay для всех ФС. Если всё это пихать в командную строку ядра, то получится слишком громоздко (это всё равно, что запихать туда /etc/fstab), поэтому лучше этот fslayout положить в файл, который будет в initrd.

Кстати, надо что-то сделать ещё и с /etc/fstab в плане выпиливания. Сейчас это свалка точек монтирования всевозможных ФС (виртуальных, локальных, сетевых, всяких gmailfs, obexfs, несуществующих флешек и т.п.), причём некоторые записи могут быть, а могут не быть (виртуальные ФС, корень). Из-за этого системе инициализации приходится на каждом этапе загрузки (монтирование виртуальных ФС, монтирование корня, монтирование локальных ФС, монтирование сетевых ФС) проверять, есть ли такая запись в fstab (если нет, то делать fallback, а если есть, то монтировать по fstab), и отсеивать лишние (особенно костыльно отсеивать сетевые ФС от локальных, потому что сейчас это делается тупо проверкой по списку, который может меняться в будущем, что может вызвать проблемы). Поэтому в fstab надо внести однозначность (чтобы не было «подразумевающихся» точек монтирования типа /proc, /sys, /dev, /dev/pts, /dev/shm, /run, которые можно и не писать — надо их писать обязательно) и сделать чёткое разделение по типам ФС (возможно, разные файлы fstab.virtual, fstab.system, fstab.local, fstab.net).

Предполагается, что всё, что монтируется из initrd и не являтся tmpfs, монтируется в ro. Нам же потом еще целостность проверять.

Если всё это пихать в командную строку ядра, то получится слишком громоздко (это всё равно, что запихать туда /etc/fstab), поэтому лучше этот fslayout положить в файл, который будет в initrd.

Предполагается, что гибкость параметра fslayout нужна для того, чтобы можно было адекватно управлять загрузкой из параметров ядра. «root=» нам уже не достаточен, а плодить usr=, etc= и т.п. — это явный фейл. Поэтому гибкий формат.

Я считаю, в файл fslayout не нужен. Задача initramfs — обеспечить доступность кода (/usr) и конфигурации (/etc) загружаемой системы. Плюс к этому, нужно обспечить доступность модулей ядра, если они валяются отдельно. Исходя из этого рисуем разные юзкейзы:

* Все есть в fstab, надо просто смонтировать раздел, на котором он лежит.

* Грузим кустомное ядро, из загрузчика перекрываем дефолтную точку монтирования для /boot, чтобы получить доступ к модулям.

* В fstab ничего нет или там левые данные, «систему» собрали по частям из того, что было, и грузим с полностью кустомной раскладкой точек монтирования.

и т.п.

Кстати, надо что-то сделать ещё и с /etc/fstab в плане выпиливания. Сейчас это свалка точек монтирования всевозможных ФС (виртуальных, локальных, сетевых, всяких gmailfs, obexfs, несуществующих флешек и т.п.), причём некоторые записи могут быть, а могут не быть (виртуальные ФС, корень).

А ничего с ним не сделать, на нём довольно много всего завязано. Единственное, что приходит в голову, сделать /etc/newcoolfstab в нескучном формате и генерировать из него fstab автоматически для совместимости. Но и это вызовет неиллюзорные приступы баттхерта у очень многих.

/etc можно было бы тоже в ro, если бы там не было всяких левых файликов типа /etc/resolv.conf

Это уже проблемы системы после загрузки, пусть она их решает сама. Может смонтировать сверху unionfs и тэпэ.

Предполагается, что всё, что монтируется из initrd и не являтся tmpfs, монтируется в ro.

ro — это не единственная опция монтирования. Ещё одна критическая опция — subvol. Без неё не получится правильно смонтировать btrfs. Поэтому опции монтирования тоже надо указывать, от них никуда не денешься. И про аналог rootwait для всех ФС не надо забывать, иначе не получится загрузиться с USB-флешки или USB-винчестера.

Предполагается, что гибкость параметра fslayout нужна для того, чтобы можно было адекватно управлять загрузкой из параметров ядра.

А зачем так делать? Сегодня загрузился с одними разделами, завтра с другими, послезавтра опять с первыми?

* Все есть в fstab, надо просто смонтировать раздел, на котором он лежит.

С этим справится и файл fslayout.

* Грузим кустомное ядро, из загрузчика перекрываем дефолтную точку монтирования для /boot, чтобы получить доступ к модулям.

Ничего перекрывать не надо, модули находятся в разных каталогах даже сейчас. Кастомное ядро загружается вообще без никакого геморроя.

* В fstab ничего нет или там левые данные, «систему» собрали по частям из того, что было, и грузим с полностью кустомной раскладкой точек монтирования.

А что мешало при такой сборке системы в самом конце сделать chroot туда, отредактировать fslayout и сделать update-initramfs?

Неубедительные юзкейсы, всё это делается и без простыни в параметрах ядра.

А ничего с ним не сделать, на нём довольно много всего завязано.

На нём ничего не завязано, кроме системы инициализации. Да, её придётся изменить, но это же и есть конечная цель — убрать костыли из системы инициализации.

Единственное, что приходит в голову, сделать /etc/newcoolfstab в нескучном формате и генерировать из него fstab автоматически для совместимости.

Это не решит ни одной проблемы.

Юзкейсы вполне убедительные. Раньше у тебя была полноценная система на одной ФС — бинари, конфиги, ошметки модули ядра. Теперь всё это растаскивается на 3 ФС. Чтобы загрузиться, тебе, потенциально, надо указать 3 устройства. Вот и думай.

сделать update-initramfs?

Да-да, перенёс систему с sda2 на sda3 — обнови initramfs. Очень Ъшно, чо.

Ещё одна критическая опция — subvol. Без неё не получится правильно смонтировать btrfs.

Корень на btrfs возможен? Как он монтируется?

Ничего перекрывать не надо, модули находятся в разных каталогах даже сейчас. Кастомное ядро загружается вообще без никакого геморроя.

«Угадай девайс с модулями ядра через астрал и получи приз!»

Раньше у тебя была полноценная система на одной ФС — бинари, конфиги, ошметки модули ядра. Теперь всё это растаскивается на 3 ФС.

… и делается update-initramfs.

Да-да, перенёс систему с sda2 на sda3 — обнови initramfs. Очень Ъшно, чо.

Какая разница: отредактировать /etc/default/grub и выполнить update-grub или отредактировать /etc/fslayout и выполнить update-initramfs?

Корень на btrfs возможен? Как он монтируется?

Да, возможен, у меня даже так было. В командной строке ядра: «root=/dev/sda1 ro rootfstype=btrfs rootflags=subvol=@» (если том с корневой ФС называется «@»). Я так делал в убунте, там его монтировал initrd, но и без initrd должно работать, потому что все эти опции поддерживаются ядром.

«Угадай девайс с модулями ядра через астрал и получи приз!»

Внезапно, он же прописан в fslayout (в любом виде, будь то файл или командная строка ядра).

… и делается update-initramfs.

...а еще лучше зашить в сорцы и пересобирать каждый раз.

Какая разница: отредактировать /etc/default/grub и выполнить update-grub или отредактировать /etc/fslayout и выполнить update-initramfs?

Действительно никакой, если забыть про тот маленький фактик, что чтобы загрузить любое ядро с любыми параметрами, не нужно выполнять никаких update-grub. Добро пожаловать в XXI век.

В командной строке ядра: «root=/dev/sda1 ro rootfstype=btrfs rootflags=subvol=@» (если том с корневой ФС называется «@»)

И flags наверняка могут содержать запятые. Ммм, надо что-то придумать...

Внезапно, он же прописан в fslayout (в любом виде, будь то файл или командная строка ядра).

Ты ж мои юзкейзы не убедительными посчитал.

Да-да, перенёс систему с sda2 на sda3 — обнови initramfs. Очень Ъшно, чо.

Действительно никакой, если забыть про тот маленький фактик, что чтобы загрузить любое ядро с любыми параметрами, не нужно выполнять никаких update-grub. Добро пожаловать в XXI век.

Т.е. ты предлагаешь после переноса системы с sda2 на sda3 (кстати, зачем так делать?) каждый раз загружаться ручками из консоли граба?

И flags наверняка могут содержать запятые. Ммм, надо что-то придумать...

А точка монтирования может содержать вообще любые символы, кроме '\0'. Если бы это было в файле с bash-синтаксисом в виде переменных, то ничего не надо было бы придумывать.

Ты ж мои юзкейзы не убедительными посчитал.

Причём они здесь?

Т.е. ты предлагаешь после переноса системы с sda2 на sda3 (кстати, зачем так делать?) каждый раз загружаться ручками из консоли граба?

Я предлагаю воспользоваться здравым смыслом. Система — это ядро + юзерланд + конфиги. У пользователя должна оставаться возможность после любой жопы, приведшей к разрушению конфига загрузки, выполнить восход солнца вручную, а не бежать к соседу за livecd. А это подразумевает, что пускающий скрипт должен уметь получать информацию о точках монтирования из параметров ядра.

А раз он это будет уметь, внутри initramfs никакой конфиг точек монтирования не нужен.

А точка монтирования может содержать вообще любые символы, кроме '\0'.

А давай мы не будем заниматься поиском невероятных частных случаев? Повторю еще раз, задача алгоритма — обеспечить доступность 3-х компонентов, необходимых для запуска системы. В отличие от философского вопроса «много ли спецсимволов содержится в слове usr», вопрос о запятых в параметрах монтирования не является высосанным из пальца.

Если бы это было в файле с bash-синтаксисом в виде переменных

Я кроме как выматериться, не знаю, что сказать. У тебя есть fstab. Пиши туда любые параметры как душе угодно. Какой bash-скрипт? Какие переменные? Ты как не поймёшь, нетривиальные способы запуска системы как раз и нужны для случая, когда НИ ОДИН из сохраненных в каком-либо файле вариантов не подходит. При помощи чего ты собрался править конфиги (еще и лежащие внутри архива), когда у тебя система не запускается, алё.

Ну и сама идея засунуть bash в initramfs — это я даже не знаю...

У пользователя должна оставаться возможность после любой жопы, приведшей к разрушению конфига загрузки, выполнить восход солнца вручную, а не бежать к соседу за livecd.

При нарушении работоспособности системы у нас 2 варианта: либо повредился initrd, либо не повредился. Если он повредился, то система всё равно не загрузится, где бы ни был fslayout. Если initrd не повредился, то fslayout, хранящийся в файле в initrd, тоже не повредился. Если при этом файловая система повреждена так, что комп не загрузится, редактирование fslayout нас всё равно не спасёт. Сейчас во все initrd кладут полный busybox с шеллом и минимальным набором программ для восстановления незагружающейся системы. Восстанавливать всё равно придётся из initrd. И даже если понадобится отредактировать fslayout (если вдруг у нас есть раздел с бекапом), то это можно будет сделать и из initrd, зайдя в его шелл.

При помощи чего ты собрался править конфиги (еще и лежащие внутри архива), когда у тебя система не запускается, алё.

Например, при помощи vi из busybox, лежащего в этом архиве.

Ну и сама идея засунуть bash в initramfs — это я даже не знаю...

ЕМНИП, в арче отказались от использования в initrd busybox'а и кладут туда полноценные программы.

У тебя есть fstab. Пиши туда любые параметры как душе угодно. Какой bash-скрипт? Какие переменные?

Насчёт переменных я слегка погорячился — просто нужен такой формат конфигов, чтобы в нём можно было записать любое возможное значение любого параметра (точка монтирования, опции монтирования, путь к устройству и т.п.). Например, можно поддерживать экранирование, как в bash или C (синтаксис C даже лучше, там нет такой свалки из костылей, как в баше). Это я подразумевал под bash-синтаксисом. А в том же fstab хз, как сделать пробел в пути к точке монтирования, и нет гарантии, что это будет работать и с mount, и с systemd и с ещё миллионом программ, читающих fstab, если это вообще возможно.

При нарушении работоспособности системы у нас 2 варианта
[многабуков поскипано]

Извини, но это всё — пустая словесная эквилибристика. Если тебе ни разу не случалось загружаться, вводя вручную параметры в grub, я даже не знаю...

vi из busybox

Ну вот нахрен?

Немного философии:
initramfs — это костыль. Идеальная сферическая система должна быть способна грузиться без него. Но поскольку это не так, это всё равно не значит, что надо толкать туда что попало. Там должен лежать минимум необходимого, а все настройки, по возможности, — либо в параметрах ядра, либо в /etc. Нет НИ ОДНОЙ причины, почему этот файл fslayout там вообще должен быть.

Ну хорошо, пусть он там будет. Хрен с ним, мне как-то без разницы.

ЕМНИП, в арче отказались от использования в initrd busybox'а и кладут туда полноценные программы.

Мда, когда я говорил, что отказ федоры от поддержки загрузки без монтирования /usr может, как вариант, привести к тому, что в initramfs засунут всё, что раньше лежало в корне, я как-то не подумал, что ты воспримешь эту мысль как руководство к действию.

Засовывать bash в initramfs в Арче, слава богу, еще никому не пришло в голову.

Итого в сухом остатке: надо уметь передавать опции монтирования.

fstab хз, как сделать пробел в пути

Вот я и говорю, эту штуку можно пофиксить только изобретением нового конфига в нескучном формате. А ты не «решит проблем, решит проблем»... :-P

Но это вообще оффтоп в треде.

Извини, но это всё — пустая словесная эквилибристика.

Если с одного раза не понял, могу проще: нет никакой разницы между тем, как отредактировать fslayout: через граб или через текстовый редактор в initramfs.

Там должен лежать минимум необходимого

Нет НИ ОДНОЙ причины, почему этот файл fslayout там вообще должен быть.

/0, fslayout как раз необходим для загрузки.

Засовывать bash в initramfs в Арче, слава богу, еще никому не пришло в голову.

Проверить не могу, ибо комп с арчем загнулся, поэтому придётся поверить на слово. Но я точно помню, что туда кладут полноценную glibc, а от klibc отказались.

Там должен лежать минимум необходимого

Если туда положить только необходимое для загрузки, то как будешь восстанавливаться после повреждения ФС без liveCD? Как минимум, в initrd надо положить ещё и необходимое для восстановления. Логично, что там будет текстовый редактор.

А ты не «решит проблем, решит проблем»... :-P

Я про это говорил:

и генерировать из него fstab автоматически для совместимости.

Если поддерживать костыльный fstab, то от костылей никогда не избавимся.

А вообще, fslayout — это тоже костыль. Приходится или насиловать командную строку ядра, или привлекать файлы, которые надо синхронизировать со всеми initrd при их изменении. initrd генерируется для каждого ядра отдельно, при этом получается одинаковой на 90%, а отличающиеся 10% — это модули ядра. Нужен принципиально новый механизм для передачи информации от загрузчика ядру. По сути, это информация 3 видов: конфиги (одинаковы для всех ядер), модули (разные для разных ядер) и initramfs (одинаковая для всех ядер), которая содержит в себе программы, которые парсят конфиги, переданные загрузчиком, и выполняют сложное монтирование и проверку ФС перед этим. Спецификация multiboot поддерживает загрузку в память вместе с ядром дополнительных файлов (они там названы модулями). Если бы Linux грузился по multiboot, а не своим костылём, умеющим только initramfs, то можно было бы допилить граб, чтобы в нём задавался fslayout в удобном виде с возможностью редактирования, и этот fslayout передавался бы ядру как конфиг.