хороший девиз

Я уже ни хрена не понимаю :(

Во время бута squashfs есть, а aufs(overlayfs) ... докличешься, если монтировать не настоящий /usr, а /usr_test; в таком случае всё срабатывает и монтируется.

И это не решение Вашего вопроса?!

mount монтирует файлы устройств* с ФС в точку монтирования. «Сферическую» ФС «в вакууме» смонтировать невозможно, а Вы пытаетесь.

Теперь ещё больше не понимаю :)

Ещё раз суть: Скваш, лежащий в /usr_squash/usr_2018_11.sfs, смонтирован в точку /usr_squash/sq. Вроде всё нормально. Теперь, при помощи монтирования overlayfs, объединяю содержимое /usr_squash/sq (в качестве которого смонтирован скваш) и две реальных директории на диске: /usr_squash/upd и /usr_squash/tmp. Это получается, если ИЛИ система уже загружена, ИЛИ точкой монтирования этой объединённой системы указана /usr_test (не /usr).

Т. е. Вы хотите сказать, что на тот момент точка монтирования /usr не существует, а специально созданный мной для тестов /usr_test существует? Но они же вроде совершенно равноправны. И то, и другое существует в качестве полноправной реальной директории, нет?

Я грешил на то, что в /usr лежит что-то, необходимое для успешного монтирования. И если поверх его реального содержимого попытаться оверлейфс монтировать, оно сначала станет недоступным, а потом уже система обнаружит, что не может завершить задачу монтирования. Но на запущенной системе же оно прокатывает.

Или я не понял, что Вы имели в виду?

я Вас тоже не очень понял...

«реальный» /usr где располагается (как монтируется)? В fstab что прописано?

Что-то похожее делается при запуске любого* liveUSB. Система монтируется из файла с ФС squashfs и «как бы» может модифицироваться. Возможно проще будет разобраться как там устроено.

А, с этим всё просто. Стандартная для Lubuntu структура — обычная ext, смонтированная как /, и в ней всё от /usr до /home.

В LiveCD посмотрел, стало только ещё непонятнее (хотя, казалось бы…) Там просто смело монтируется overlay / с типом overlay. Без какого-либо указания, откуда брать верхнюю и нижнюю часть. Как это работает, я даже примерно представить затрудняюсь.

На пробу попробовал вообще примонтировать скваш прямо в /usr (кроме того, что он же примонтирован в /usr_squash/sq). Внезапно, это прокатило, и система-инвалид (с read-only /usr) успешно стартовала. В этой калечной системе сделал руками sudo mount -t overlayfs -o defaults,lowerdir=/usr_squash/sq,upperdir=/usr_squash/upd,workdir=/usr_squash/tmp overlayfs /usr и это тоже сработало. Получилась такая хтонь: в ext'шке есть «настоящий» /usr (с полным стандартным набором), поверх него при помощи fstab смонтирован read-only squashfs (с ним же, но неизменным), а когда с этим зоопарком загрузились, сверху руками оказался натянут ещё и overlayfs (в котором наконец-то что-то можно менять). Будет ли это работать, если содержимое «настоящего» /usr убрать окончательно (оставить только саму точку монтирования), я не знаю.

Разумеется, это не решение (/usr получает актуальное содержимое только после загрузки, что есть абсурд). И через fstab такая матрёшка тоже не хочет монтироваться (система так и загружается с read-only /usr, потому что первая половина проходит нормально и скваш монтируется как /usr, а вот вторая почему-то соглашается только вручную). Смущённый fstab'ом из LiveCD, пробовал писать и overlay, и overlayfs. Failed.

Поэтому фундаментальный (AKA нубский AKA азбучный) вопрос: а сколько вообще раз выполняется монтирование содержимого fstab в Lubuntu? Ощущение, что он пытается один раз в самом начале загрузки, а потом уже в середине всё это же перемонтирует ещё раз. Иначе я этот полтергейст объяснить не могу.

На пробу попробовал вообще примонтировать скваш прямо в /usr

чем не устраивает? если ты монтируешь куда-то, то потом надо mount --bind /source_dir /dest_dir. При старте /usr read-only вызывает проблемы?

mount монтирует файл (у тебя файл с squashfs) в точку монтирования (у тебя /usr). Зачем ты монтируешь его ещё куда-то? это лишнее («ненужно»©)

В LiveCD посмотрел

что смотрел? там тоже в несколько этапов монтируется.

сервис напиши для монтирования «2-й части» с «автоматизацией» пока не разобрался: совет «отменяется».

/root/usr

???

Зачем ты монтируешь его ещё куда-то

Скваш read-only. Чтобы сохранить изменения, нужен верхний read-write слой. Видимо, так ТС делает возможность отката /usr.

И не только.

В общем, по пунктам:

1) Монтирую поверх реального /usr хотя бы потому, что мне система нужна живая и сносить содержимое реального /usr, не обеспечив работоспособности сжатого, было бы несколько опрометчиво. Когда будет как часики, разумеется, старый грохну (в том и смысл сжатия). Да, диагностически это не столь достоверно (там втихую что-то из реального /usr может продолжать использоваться), но пока даже до ложноположительного результата далеко.

2) Просто скваш меня не устраивает по той очевидной причине, что первое же прилетевшее обновление из репов надо будет куда-то приткнуть, а скваш, очевидно, RO. И, очевидно, верхний RW-слой должен быть смонтирован сразу, а не когда уже до иксов всё загрузилось, иначе все хэндлы, которые система наоткрывает по ходу загрузки, так и останутся к старым версиям файлов (т. е. напрямую к сквашному /usr, а не к примонтированному верхнему слою).

Сейчас я грешу на то, что на ранней стадии загрузки у системы отсутствуют какие-то возможности. Скажем, что-то ещё не загружено и загрузить его можно только из /usr. Что это может быть? Модуль? Или ещё что-нибудь? Если я или монтирую поверх /usr прямо скваш (который не нуждается в постоянном присутствии /usr), или монтирую оверлей поверх /usr_test (который не приводит к временному пропаданию содержимого /usr), или монтирую оверлей уже в иксах (когда это неведомое что-то уже по какой-то причине загружено и не требуется лезть за ним в /usr), порочный круг разрывается.

И сразу вопрос. Если мне придётся для решения вопроса собрать своё ядро, что будет, когда с обновлениями прилетит свежее? Всё брякнется и потребует каждый раз выбирать в grub старое ядро, грузиться с ним и пересобирать заново со своими опциями?

Ещё один эксперимент, вдохновлённый вот этим вот https://unix.stackexchange.com/questions/198542/what-happens-when-you-mount-o...

Создаю в /tmp на пробу /tmp/Main, /tmp/RO и /tmp/Tmp. В /tmp/Main кладу файлик mountmeover.sh, содержащий строчку

mount -t overlayfs -o defaults,lowerdir=/tmp/RO,upperdir=/tmp/Main,workdir=/tmp/Tmp/ overlayfs /tmp/Main

И получается, что Main сам себе является верхним RW-слоем: всё, что я туда пишу и/или меняю, потом ложится в настоящий /tmp/Main. И когда я это дело отмонтировал, оно там и лежало :)

Разумеется, всё содержимое /tmp/RO туда честно добавилось. Если я что-то из него менял, обновлённая версия ложилась в /tmp/Main (который настоящий) и когда я это дело отмонтировал, оно тоже там и лежало. Т. е. оверлей работает как ему и положено.

Т. е. стадии, когда всё заработает и мне надо будет удалять реальное непожатое содержимое /usr, я пока не боюсь. Если окажется, что там лежат важные бинарники, без которых не может быть выполнено монтирование таблицы fstab, то я просто их там оставлю и упраздню сущность /usr_squash/upd (а верхним RW-слоем сделаю «настоящий» /usr, который реально лежит в корневой ext'шке, и поверх которого же и монтируется оверлей). Если это прокатит так же, как прокатило в /tmp/Main, то все они будут доступны и до монтирования, и после. И если они тоже обновятся, то именно новые версии будут по этому пути и до монтирования, и после.

Но до этой стадии ещё далеко :( судя по тому, что оно не монтируется даже когда всё вокруг доступно, не удалено и вообще бери-не-хочу (а оно и не хочет).

/root/usr

???

Меня вот этот рут тоже пренемало удивил, если честно. Вроде бы гуглёж помог мне понять, что это потому, что жалоба исходит от initramfs. Т. е. у него как бы свой /, а то, что у него называется /root/, потом станет нашим / (когда он все модули загрузит и т. д.)

Т. е. получается, что именно initramfs споткнулся об поставленную мной задачу смонтировать оверлей поверх /usr. Но почему? Initramfs не умеет в overlayfs, а полноценное ядро умеет?

Ну или я всё неправильно понял из своего гуглежа, а половину сам придумал. Такое тоже вероятно.

а в Initramfs у тебя есть всё необходимое для монтирования сквошфээсов и оверлеев? Если нет, то он просто не может обойтись без оригинального /usr для монтирования.

я тоже не сразу распарсил первый пост...

Зачем ты монтируешь его ещё куда-то

это про

/usr_squash/usr_2018_11.sfs /usr_squash/sq squashfs loop,ro 0 0
overlayfs /usr overlayfs defaults,lowerdir=/usr_squash/sq,upperdir=/usr_squash/upd,workdir=/usr_squash/tmp 0 0

вполне можно squashfs монтировать сразу поверх /usr, а потом «выполнять» сверху оверлеи

Если нет, то он просто не может обойтись без оригинального /usr

Точно именно так? У меня сейчас ощущение, что всё ещё хуже. Даже имея его на месте, он не может примонтировать оверлеи. Т. е. ему нужно именно при себе всё иметь. Он куда-то пишет лог ошибок, кроме консоли, в которой за доли секунды пролетает? Не нашёл, пардон :(

И что теперь делать, чтобы не пересобирать ядро с каждой обновкой — изучать initramfs-tools, настройки update-initramfs? Просто не наделать бы так, чтобы закат и восход Солнца стали осуществляться вручную :)

изучать initramfs-tools, настройки update-initramfs?

А ты хотел как-то без этого обойтись? хех... Ну молодёжь... :)

Именно с их изучения и надо было начинать.

Да не то что бы… хотел понять, что именно изучать :-D Старые хау-тушки вообще советовали в ядро жёстко вкомпилить поддержку.

Чем отличается написание хука в /etc/initramfs-tools/hooks (со строчками manual_add_modules ИмяМодуля) от добавления в etc/initramfs-tools/modules строчки с «ИмяМодуля»?

Говорят, dpkg сам запускает update-initramfs -u -k all (если затронуты имеющие отношение пакеты), значит ли это, что при автообновлении ядра затребованные мной модули будут автодобавляться в initramfs?

Да, примерно так. Но я давно извращениями не занимался, может в новых ядрах и всяких системдах всё по другому стало. Вообще раньше ведь были отдельные директории /bin, /lib/, /tmp, /usr/bin, /usr/lib, /var/lib, /var/tmp и прочая и прочая. Раньше и порядок загрузки другой был. А теперь - всё стало переусложнённым.

Удачи в изучении, хотя, скоро это всё станет ненужным и толку от этих знаний?

Nick_what_is_again 30.11.2018 17:15:23

/usr_squash/usr_2018_11.sfs   /usr_squash/sq   squashfs   loop,ro   0 0
overlayfs /usr overlayfs defaults,lowerdir=/usr_squash/sq,upperdir=/usr_squash/upd,workdir=/usr_squash/tmp 0 0

Уточни. Вот так не прокатывает?

/usr_squash/usr_2018_11.sfs   /usr_squash/sq   squashfs   loop,ro   0 0
overlayfs /usr overlayfs defaults,lowerdir=/usr_squash/sq,upperdir=/usr_squash/upd,workdir=/usr 0 0

Интересует: workdir=/usr

А также интересует вариант:

/usr_squash/usr_2018_11.sfs   /usr_squash/sq   squashfs   loop,ro   0 0
aufs /usr aufs nodev,noatime,dirs=/usr_squash/upd=rw:/usr_squash/sq=ro 0 0

Поздняк, сказал Возняк… Я ему и файл хука подложил, и строчку добавил. И для одного ядра инитрамфс пересобрал.

Теперь, когда я с ним гружусь, он доходит аж до середины. Наверное, теперь инитрамфс нормально его цепляет. Так и не понял, куда отчитывается инитрамфс.

Веселуха теперь начинается позже: пишет «Failed to start Remount Root and Kernel File Systems». Парой строк выше, кстати, mount /usr OK.

Я мог что-то намудрить с правами доступа на всю эту ёлку-пирамидку из монтирований?

И я правильно понимаю, что он всё-таки не один раз монтирует содержимое фстаба (сам сидя ещё на инитрамфс), а его по второму разу перемонтирует в ходе загрузки? Слово Remount очень подозрительное…

Слово Remount очень подозрительное

Означает ошибку первой попытки монтирования.

Заходи с livecd. Правь fstab взад.

Ну вот, я нарушил священный принцип «не проверять больше одной гипотезы за один раз» и теперь у меня свежеустановленная 18-я :-/

Начинаем цирк сначала…

Итак, как мне посмотреть логи первой попытки монтирования? Я что-то вообще ничего не смог нагуглить про то, что куда и как логирует инитрамфс. И куда он в принципе может что-то логировать, если по какой-то причине не смог нормально смонтировать хард.

Возьми squashmount и не мучайся

Не совсем верно. / смонтировался, значит с логированием проблем быть не должно.

Но с логированием fstab действительно есть затруднения. В syslog только съёмные устройства, в других то же. В boot только debugfs и cryptmount. Так что концов не сыщешь.

И всё-таки. Какой из двух вариантов, предложенных мной, дал сбой. Интересует конечно второй (aufs).

aufs nodev,noatime

Эти параметры критичны? Просто не помню, как именно я пробовал раньше (с ними или без). И он выдал то же самое, что на оверлейфс — что нет такого девайса.

А в этот раз я успел всё развалить раньше, чем второй раз попробовал :(

Чем больше читаю https://unix.stackexchange.com/questions/92720/does-initramfs-use-etc-fstab тем страшнее :-D Я уже вообще во всём сомневаюсь :(

Эти параметры критичны?

Не уверен. Пробуй также пользовать /etc/modules. Укажи в нём всё:

loop
squashfs
aufs
overlayfs

Крайний вариант.

Печалька, что с squashfs не получилось.

Но если очень нужна компрессия, попробуй fusecompress в виде:

# echo "fusecompress#/.compress  /usr   fuse    noauto    0       0" > /etc/fstab
# mkdir /.compress
# mv -fr /usr /usr.src
# mkdir /usr
# fusecompress /.compress /usr
# mv -frv /usr.src/* /usr

Плюсы:

• fuse
• простая схема работы fusecompress в отличии от squashfs+{overlayfs,aufs}

Минусы:

• не проверено
• не оптимизируется «файловая таблица» (очень большой минус).

PS: Сам fusecompress надо вынести из /usr со всеми требуемыми им либами, либо скопировать их в /.compress, чтобы они были без сжатия.

Пока вроде дело не в скваше. Создаю заново (на новой системе) пустые каталоги, добавляю строчку

overlayfs /usr overlayfs defaults,lowerdir=/usr_squash/sq,upperdir=/usr,workdir=/usr_squash/tmp 0 0

Модуль, кстати, называется просто overlay (посмотрел в модулях, плюс апдейт инитрамфс-а на слово overlay реагирует и пишет, что добавил, а на слово overlayfs — нет). Первым делом, конечно, во фстабе обозвал девайс overlay вместо overlayfs — неее, опять привет, спасательная консоль %) Чувствую, где-то ещё что-то надо упомянуть, чтобы эта зараза загружалась. Кроме самого его добавления в initramfs и упоминания в /etc/modules.

Кстати, модулей squash* я вообще не нашёл. Подозреваю, что это потому, что она не модулем, а жёстко вшита. И что именно поэтому она сама по себе (без оверлея) успешно из фстаба работает.

а верхний RW-слой — это и есть сам /usr

Не катит, /usr - точка монтирования для overlayfs. Это логически неверно: смонтировать /usr в /usr. Даже bind такое не может.

Nick_what_is_again (30.11.2018 17:15:23)

/usr_squash/usr_2018_11.sfs   /usr_squash/sq   squashfs   loop,ro   0 0
# overlayfs /usr overlayfs defaults,lowerdir=/usr_squash/sq,upperdir=/usr_squash/upd,workdir=/usr_squash/tmp 0 0

Раскомментирую вторую строчку на загруженной системе, запускаю sudo mount -a, оно прекрасно цепляется.

mount: mounting overlayfs on /root/usr failed: No such device.
mount: mounting aufs on /root/usr failed: No such device

Хочешь сказать, что в новых версиях overlayfs и aufs, есть нечто, лежащее в /usr, без чего они отказываются работать? Интересно. Это с systemd никак не связано?

PS: Не стоит ли тогда пересобрать overlayfs исключив из процесса сборки systemd? Что-то типа --without-systemd?

https://github.com/vaeth/squashmount

squashmount неплохой скрипт, но для /usr не подходит вообще. Этот скрипт, как я вижу, изначально заточен под /usr/portage и в деле постоянного обновления образа портежей он наверняка хорош. Но на образе «тела системы» (/usr) не сработает.

Катит-катит :) Вот, можно попробовать:

sudo mount -t overlay -o defaults,lowerdir=/tmp/lo,upperdir=/tmp/hi,workdir=/tmp/tm overlayfs /tmp/hi

Причём у меня перестал принимать -t overlayfs, требует строго -t overlay (после переустановки на более свежую LTS).

Хотя, судя по всему, катит не всегда: https://github.com/systemd/systemd/issues/3076 хотя в теории должно прокатывать и пожёстче: https://unix.stackexchange.com/questions/235869/overlayfs-is-mounting-foo-low...

Ну не знаю, как так он у тебя не сработает, если я его сам использовал больше двух лет. :)

У него даже в примере конфига есть (закомментированный) пресет для /usr.

Причём у меня перестал принимать -t overlayfs, требует строго -t overlay

Потому что в ядре было две разных реализации OverlayFS (старая работала так себе — у меня часто с ней бывали проблемы при использовании squashmount, поэтому я накатывал на ядро AuFS-патчи и использовал AuFS вместо OverlayFS). Новая реализация (ЕМНИП, с ядра 3.18) работала хорошо, и необходимости использовать AuFS не возникало.

::вывалился обратно из пространственно-временно́й дыры::

Потому что в ядре было две разных реализации OverlayFS

А, вот оно что, спасибо :)

даже в примере конфига есть (закомментированный) пресет для /usr

Рискнуть, что ли… просто если не получается руками, понятно, что откатывать. А если что-то пойдёт не так со скриптом, который по большей части чёрный ящик, то системе будет гроб. Опять :(

Пока дежурная версия — ни хрена я не добавил в инитрамфс :( Попытался добавить, а оно взяло и не добавилось. Поэтому работает только скваш, который в ядре вшитый, а оверлей (который модулем) и в ус не дует.

Хочешь сказать, что в новых версиях overlayfs и aufs, есть нечто, лежащее в /usr, без чего они отказываются работать?

И вообще склоняюсь к мысли, что может использоваться только то, что есть на инитрамфс, а весь /usr — он что есть, что его нет. Просто если он споткнулся на /usr, то я про это вскоре узнаю по «методу навигатора Пиркса» («о разгерметизации вы легко догадаетесь по отсутствию кислорода»). А если гавкнулся на /usr_test, то он его потом всё-таки смонтирует — ну, когда будет корневую точку монтирования перемещать с корня инитрамфс на «настоящий» корень. И я останусь в святом неведении насчёт того, что /root/usr_test точно так же не монтировался, как /root/usr, потому что

с логированием fstab действительно есть затруднения […] концов не сыщешь.

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

::зевок:: театр одного актёра и цирк одного клоуна продолжается… Вытащил старенький четверопень и на него взгромоздил 18.04, чтобы развязать руки. Там сказал волшебные слова

sudo apt-get install build-essential kernel-package libncurses-dev libssl-dev
sudo apt-get install linux-source
cd /usr/src
sudo tar xjf linux-source-какоетаместь.tar.bz2
cd linux-source-какоетаместь
sudo make oldconfig
sudo make menuconfig
sudo make-kpkg clean
sudo make-kpkg --initrd --append-to-version=-overlayfs kernel_image kernel_headers

Ага, прямо вот кто бы мог подумать. Прямо открытие века. Открыв второе веко, я «озвездил» оверлей и выполнил завершающие команды. Влепил это ядро, вбил в етц/фстаб снова вожделенный /usr и в этот раз вместо граблей в меня прилетел топор. Инитрамфс в этот раз прекрасно всосал эту строчку, но ласково мне ответил, что не может, потому что верхняя директория доступна только как read-only!!! Нижнюю и рабочую, к слову, он вообще не нашёл. Я попробовал их записать не как /usr_squash/итакдалее, а как /root/usr_squash/итакдалее, т. е. относительно инитрамфсовского рута, а не настоящего. Вроде увиделись, но как-то через раз, что очень странно. Ощущение, что оверлейфс вообще не рассчитывали на такие применения :( А самое обидное, что у меня мозга не хватило «озвездить» сразу и aufs тоже. Сейчас снова нудно пересобирается ядро, в этот раз aufs тоже я сделал «вшитым» вместо модульного, попробую теперь им франкенштейна сшить, если кто-нибудь мне вдруг резко не откроет глаза на то, как правильно задавать оверлейфсу параметры.