/usr, /opt, /var

Это действие не имеет смысла, тебе нужны два раздела - / и /home.

Нужно больше отдельных разделов.

btrfs subvol

если btrfs не допустимо — то (на втором месте) ящитаю что лучше mount -o bind

символические ссылки — субъективно думаю это плохой подход.. но сходу мне сложно сказать почему я так думаю.. :-) [как-то ненаучно получилось с моей стороны]

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

если это не работает — то это выглядет как баг systemd (в той ситуации когда systemd в том числе учавствует как pid-1 и для initrd и pid-1 для основной системы)

нужно звать специалистов по systemd , вообщем..

(но если выяснится что автор-темы не использует systemd (и не использует systemd в initrd) — то НЕ нужно их звать:))

в папках

В мамках.

Вот это читал? TL;DR - бери симлинки. А вообще ты хочешь странного. Уверен, что тебе например нужен вынесенный /opt?

Как в избранном варианте заставить систему загружаться? (Попробовал оба варианта, с наскока не получилось.)

В случае с симлинками ничего сложного. Просто создаешь один раздел, в нем свои /opt, и кидаешь с них симлинки на корень. Можно даже после установки это сделать, а не во время.

IMHO /usr нет смысла выносить на отдельный раздел

Если речь не о десктопе, то /var, /tmp, /opt, /home на отдельные разделы ( с lvm это не сложно )

по «mount -o bind»

наверное так лучше.

нужно звать специалистов по systemd , вообщем..

кстати Леннарт не осилил отдельный /usr/, потому не взлетит ИМХО

(сам Леннарт кричит, что дескать это не баг, а типа фича)

наверное

Шел бы ты отсюда со своим «наверное», советчик. То у тебя в openssh защита от дудоса, то откровенно вредные советы маскируешь под «наверное». Деградант.

1. Насчет символических ссылок.

Но ведь если следующее по-умолчанию так,

ll /
total 49
lrwxrwxrwx   1 root root     7 окт 25 22:41 bin -> usr/bin
...
lrwxrwxrwx   1 root root     7 окт 25 22:41 lib -> usr/lib
lrwxrwxrwx   1 root root     7 окт 25 22:41 lib64 -> usr/lib
...
lrwxrwxrwx   1 root root     7 окт 25 22:41 sbin -> usr/bin
...
drwxr-xr-x  12 root root  4096 ноя  1 23:16 usr

2. "mount -o bind" — да, там чтото не работает при загрузке. Systemd используется везде и всюду (Archlinux default). Значит как-то заставить вовремя монтировать /dev/disk/by-label/systpart на /new_root/mnt/systpart, чтобы потом уже биндить /new_root/mnt/systpart/usr на /new_root/usr... ССЗБ?

Отдельный /usr на отдельном разделе нормально работает.

И под lvm на отдельном /dev/vg0/lvusr тоже все ок.

Но ведь если следующее по-умолчанию так,

[...]

да.. хороший аргумент. принимаю!

Systemd используется везде и всюду (Archlinux default)

в Арчике же в initrd по умолчанию используется bash (в качестве pid-1). нужно /etc/mkinitcpio.conf редактировать чтобы было бы systemd

откровенно вредные советы маскируешь под «наверное». Деградант.

а что не так, умный ты наш?

Мне нравится. Но не работает. Или я должен сомневаться из-за того, что эта ссылка ведет в итоге на другой раздел?

Что у тебя не работает? Как делаешь? Ты можешь нормально, логами сказать? У нас таких решений в легаси куча. Мувить разделы лень, кончилось место где-нибудь в /var и /www, воткнули дополнительный диск побольше, директориям сделали mv на новый диск, и ln -s /disk3/var /var, и для /www. Полет нормальный.

Бинд не трогай, есть шансы напороться на подводные камни. Потом охуеешь их вылавливать.

в Арчике же в initrd по умолчанию используется bash (в качестве pid-1). нужно /etc/mkinitcpio.conf редактировать чтобы было бы systemd

Ну ок. Значит не везде используется. Но как запилить правильное монтирование?

В треде ссылка есть. Читать умеешь?

Отдельный /usr на отдельном разделе нормально работает.

починили? Ну хорошо, ок, я не в курсе, что там сейчас с systemd.

Логами не умею=( А вот еще, говорят, в chroot'е ссылки не работать будут.

Ну ок. Значит не везде используется. Но как запилить правильное монтирование?

добавить новый самодельный hook для mkinitcpio . думаю это не должно быть сложно

(думаю hook писать проще даже чем создавать новую тему на LOR .. однако так как тема уже создана, то мне например было бы интересно почему это не способно работать из коробки сразу %))

Мы про разделы или чруты? Какбе разные вещи.

А зачем, собственно? Раньше это имело смысл делать, чтобы /usr был в read-only, а у тебя всё в одну кучу с /var.

говорят, в chroot'е ссылки не работать будут.

ты главное симлинки *всегда* делай как «relative» а не как «absolute». и в этом случае chroot будет нормально работать

Уверен, что тебе например нужен вынесенный /opt?

У меня там texlive with custom builded binaries живут, да еще и разных версий, так что там целые гиги говн пусть отдельно лежат.

В случае с симлинками ничего сложного... Можно даже после установки это сделать, а не во время.

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

как «relative» а не как «absolute»

Это я догадался.

Возможно это стоило сказать раньше. Где именно у тебя чрут, и зачем он там?

Где именно у тебя чрут, и зачем он там?

я думаю автор темы имеет ввиду что chroot происходит в момент когда initrd передаёт управление настоящему корню (хотя на самом деле там происходит pivot_root , а не chroot , но думаю суть понятна)

Чрут во время установки, а также может случиться в случае починки и загрузки с live usb (или из emergency shell), короче чтобы на всякий случай работало. Хотя, с relative symlinks должно заработать.

А как насчет «mount -o bind», что там покрутить надо-то?

Читать умеешь?

местами.

Backups and other file copies will pick all copies. It becomes difficult to specify that you want to copy a filesystem: you'll end up copying the bind-mounted files twice. Searches with find, grep -r, locate, etc., will traverse all the copies, and so on.

я не вижу смысла в бекапе всего корня вместе с /usr. У меня Slackware Linux, зачем её бекапить, если она лежит на многочисленных зеркалах? Причём последние версии файлов, а не протухший бекап.

Что касается grep/find, то я не настолько туп, что-бы грепать ВЕСЬ корень. Если мне нужно что-то, то я _знаю_, в /var или в /usr это искать. Потому такой проблемы в рассматриваемом случае быть не может.

Only root can manipulate bind mounts.

Во первых это неправда. С опцией users любой пользователь может монтировать такие каталоги. Во вторых, я не думаю, что у простого юзера возникнет нужда размонтировать /usr, /var, или /opt. Т.ч. это в данном случае хорошо.

Whatever you're trying to do, it's far more likely that symlinks are the right tool, than bind mounts being the right tool.

в общем случае — да, конечно.

Касательно каталогов /usr, /var и /opt — нет.

ЗЫЖ детка, умерь пожалуйста свой юношеский максимализм. Каждый инструмент хорош для своей задачи. Симлинки я постоянно использую, у меня в хомяке их два десятка ЕМНИП. Но тут другой случай.

Ммм. Ну не знаю. Возможно только с /usr проблема вылезет. /var по симлинку как я писал выше у меня много где есть. Без проблем. /usr надо потестить.

Раньше это имело смысл делать, чтобы /usr был в read-only

профит ещё и в том, что злоумышленник не может сделать хардлинк из /usr в /tmp или /var/tmp.

а у тебя всё в одну кучу с /var.

действительно, в этом нет смысла ИМХО. Но если уж так хочется, то логичнее делать bind, а не симлинки в /usr. ИМХО.

Детка, ты до последнего мне в прошлом треде упрямился, утверждая что в openssh изкоробки защита от брутфорса. И при этом понтовался как тазик. Но как оказалось твоя «защита» это MaxAuthTries. Думаешь после такого тебя можно воспринимать серьезно?

Во вторых, я не думаю, что у простого юзера возникнет нужда размонтировать /usr, /var, или /opt

Твоя думалка барахлит.

в общем случае — да, конечно. Касательно каталогов /usr, /var и /opt — нет.

Яснопонятно. Пшел вон.

ты главное симлинки *всегда* делай как «relative» а не как «absolute». и в этом случае chroot будет нормально работать

смотря КУДА. Если хочется ссылку из chroot'а наружу, то _никакой_ симлинк НЕ сработает, симлинки ведут только внутрь.

Но в данном случае это не имеет значения.

А как насчет «mount -o bind», что там покрутить надо-то?

всё тоже самое — думаю нужно сделать hook для mkinitcpio , который бы:

сначало ждал бы появления /dev/disk/by-label/systpart

poll_device /dev/disk/by-label/systpart

потом бы монтировал бы его в /new_root/mnt/systpart/

mount /dev/disk/by-label/systpart /new_root/mnt/systpart/

ну и потом бы монтировал бы всякие -o bind

mount --bind /new_root/mnt/systpart/usr/ /new_root/usr/
mount --bind /new_root/mnt/systpart/var/ /new_root/var/
mount --bind /new_root/mnt/systpart/opt/ /new_root/opt/

примерно так..

это bash-версия (не подходит для systemd-версии initrd)

примерно написал , для понятности сути.. может быть пару опечаток сделал :-)

# P.S.: но как я выше писал — в этом вопросе — мне было бы более интересно — почему это может НЕ работать из коробки (но для systemd-версии initrd, а не для bash-версии initrd), и быть может где-то какой-то баг! который требует исправления...

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

ты немного не так понял. На самом деле, у тебя по любому не заработает chroot, пока ты

либо не сделаешь mount --bind /usr /chroot/usr

либо не сделаешь внутри chroot _свой_ второй /usr.

При этом симлинки просто неудобны, т.к. тебе нужно будет делать не mount --bind /usr, а mount --bind /mnt/other/usr (т.е. туда, куда ведёт симлинк).

Кому?

сделай по аналогии с этим образцом — /usr/lib/initcpio/hooks/usr

например сделай файл /usr/lib/initcpio/hooks/my_parts

и в нём напиши

#!/usr/bin/ash

run_latehook() {
    # сюда команды!!
    # сюда команды!!
    # сюда команды!!
    # сюда команды!!
    #     (отсюда https://goo.gl/j1ZEGK )
}

и в /etc/mkinitcpio.conf пропиши свой «my_parts» :) в HOOKS

далее mkinitcpio -p linux (ну ты понял вообщем)

и чо, будет работать?

Мне.

Яснопонятно. Пшел вон.

слив засчитан.

и чо, будет работать?

не знаю. вот ты и расскажи нам :-)

ну и там погляди чтобы это не конфликтовало бы с /etc/fstab (туда тоже все эти -o bind нужно прописывать, думаю)

перед тем как начнёшь экспериментировать — перед тем как начнёшь делать свой hook — проверь может уже созданные хуки работают хорошо, но их нужно включить.. проверь как работает systemd-версия initrd (это тоже ввиде хука оформлено. hook так и называется «systemd»)

Мамке своей зачти. Ты кроме «ненужно» ни одного аргумента не привел. А по ссылке их много.

Ну, я делал (при установке) так:

mount /dev/disk/by-label/part /mnt/mnt/part
...
mkdir /mnt/mnt/part/usr
cd /mnt
ln -s mnt/part/usr usr
...
pacstrap /mnt base # установка
genfstab -p /mnt >> /mnt/etc/fstab
arch-chroot /mnt
...
exit
reboot

должно же работать (без всяких биндов)?

Зачем?

Ты кроме «ненужно» ни одного аргумента не привел.

учись читать.

А по ссылке их много.

ссылка не про то совсем.

cd /mnt; ln -s mnt/part/usr usr

ну у тебя симлинк ведёт внутрь chroot, конечно так будет работать.

Не будет, если ты симлинк направишь наружу, cd /mnt; ln -s ../usr usr. А ты внутрь chroot'а уже смонтировал свой part.

Перечитай исходное и 20:57:25, там обновлено.

если ты симлинк направишь наружу

я так не буду. честно-честно.

* LVM не предлагать

Ты какой-то дурной.

Согласен. Но у меня mmcblk, и на нем почему то lvm не работает ("lvmetad что-то там failed", тотчас-же созданные тома не lvscan'ятся). Да и на общем размере в 20G и, к тому же, на одном единственном физическом носителе применять lvm вообще избыточно, на мой взгляд.

я так не буду. честно-честно.

делай, я разрешаю. Сам по себе симлинк == текстовый файл из одной строки, в которой записан путь. если сделать симлинк ln -s ../usr usr, то он будет работать пока корень .., но когда корень сдвинется, симлинк будет указывать сам на себя (broken symbolic link). Именно по этому симлинки — не всегда хорошо, они имеют свойство ломаться. Каталог bind сломаться не может, он хорошо приколочен. Это и плюс и минус. Обычно минус, потому обычно юзают симлинки.