вопрос про вынос /etc на другой раздел

я правильно понял, что при монтировании фс в tmpfs создаются свои опции, отличные от тех, что в fstab?

Смотря как монтировать. Если монтировать руками командой mount, то используются те опции, которые переданы параметром -o. Если же просто «mount /path/to/mountpoint» или «mount -a», то читается /etc/fstab. Ничего не мешает tmpfs записать в fstab.

есть на диске / и /home в нём же, при этом получится смонтировать хомяк с noexec, правильно?

Да.

А нахуа?

$ du -sh /etc
4.5M	/etc

чтоб /etc было одним разделом(рэйзер), а всё остальное другим(ext4)

Да он целиком (всё что используется) в кэше будет; изголяться стоило бы в случае портежа:

$ du -sh /mnt/1/p/portage
355M	/mnt/1/p/portage

а вот например есть каталог /a, в нём подкакталог /b и ещё несколько файлов- можно ли смонтировать в tmpfs каталоги /a и /b, чтоб каталог /b не занимал двойной объём памяти? или и так не будет?

а вот например есть каталог /a, в нём подкакталог /b и ещё несколько файлов- можно ли смонтировать в tmpfs каталоги /a и /b, чтоб каталог /b не занимал двойной объём памяти?

По-моему, ты не до конца понимаешь, что происходит при монтировании tmpfs, да и вообще как работает монтирование. Если есть каталог /a/b и в нём несколько файлов — то нафига в /a и /a/b монтировать tmpfs? При монтировании tmpfs в /a там окажется пустой каталог.

то нафига в /a и /a/b монтировать tmpfs?

наоборот В tmpfs монтировать /a /b

наоборот В tmpfs монтировать /a /b

Всё-таки почитай ещё раз про монтирование. Смонтировать можно что-то куда-то. Что-то — это либо блочное устройство, либо нечто абстрактное (зависящее от ФС) в случае nodev-файловой системы (tmpfs является nodev). Куда-то — это всегда каталог в VFS. Tmpfs — это тип файловой системы, а не каталог.

ладно. /a /b в / который уже в tmpfs. будет ли b занимать двойной объём памяти?

Эмм... Вынести на раздел, и создать /etc/fstab на основном разделе?

будет ли b занимать двойной объём памяти?

Если монтировать так, то не будет:

mount -t tmpfs tmpfs /a
mkdir /a/b
mount -t tmpfs tmpfs /a/b

Если честно, не могу даже представить, как надо смонтировать, чтобы что-то занимало двойной объём памяти. Боюсь, что это невозможно (если, конечно, не хранить файлы под точками монтирования на нижних ФС, например, смонтировав ФС поверх непустого каталога).

Если честно, не могу даже представить, как надо смонтировать, чтобы что-то занимало двойной объём памяти

если на диске есть каталог /a/b надо смонтировать ОТДЕЛЬНО /a, потом ОТДЕЛЬНО /b . т.е есть /etc , в НЁМ /home, нужно смонтировать хоме -o noexec, при этом /etc БЕЗ noexec

если на диске есть каталог /a/b надо смонтировать ОТДЕЛЬНО /a, потом ОТДЕЛЬНО /b . т.е есть /etc , в НЁМ /home, нужно смонтировать хоме -o noexec, при этом /etc БЕЗ noexec

o_O А при чём тут вообще tmpfs?

т.е есть /etc , в НЁМ /home

Зачем так делать?

на диске есть каталог /a/b

Т.е. есть диск, на нём единственный каталог /etc, в котором ещё и /etc/home? Мда…

mount /dev/нужный_файл /mnt
ln -s mnt/etc /
ln -s mnt/etc/home /

или так:

mount /dev/нужный_файл /mnt
mount --bind /mnt/etc /etc
mount --bind /mnt/etc/home /home

нужно смонтировать хоме -o noexec, при этом /etc БЕЗ noexec

К тому же это не получится, потому что и etc, и etc/home на одной ФС, а не на разных.

К тому же это не получится, потому что и etc, и etc/home на одной ФС, а не на разных.

толи я тебя не понял, толи ты меня...
хочу систему разместить на двух разделах - на одном /etc (при этом в его корне лежит хомяк), на втором всё остальное. нужно будет монтировать /etc, затем хомяк с опцией noexec. (и /etc и хому в память). возможно ли смонтировать /home, который находится в уже смонтированном в tmpfs /etc к корню tmpfs но с другой опцией? если реально, то не будет ли хом занимать двоёной объём, он ведь ещё и в /etc смонтирован?

Если на этот раз я правильно понял, то как-то так (не проверял):

mkdir -p /etc
mount -t tmpfs tmpfs /etc
mount /dev/там_где_etc /mnt
tar cf - -C /mnt . --exclude ./home | tar xf - -C /etc
mkdir -p /home
mount -t tmpfs tmpfs /home -o noexec
tar cf - -C /mnt/home . | tar xf -C /home # или просто cp -a /mnt/home/. /home/
umount /mnt

к корню tmpfs

смонтированном в tmpfs /etc

А в чём смысл этого действия, если корень тоже в tmpfs?

А в чём смысл этого действия, если корень тоже в tmpfs?

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

Я о том, зачем отделять /etc от корня? Сделай /home отдельным разделом, а /etc не отделяй.

потому что всё остальное хочу ext4, а етц с хомой - reiser

или под /usr reiser будет лучше чем e4?

потому что всё остальное хочу ext4, а етц с хомой - reiser

А в чём сакральный смысл сего? Я бы ещё понял nilfs2 на /etc, но зачем reiser?

ну в /etc много мелких файлов, вроде рэйзер как раз для этого

Я как-то [...] вместо диска с кино дернул диск с системой.
у меня произошло конкретное зависание системы

Линукс не готов для десктопа:)

Мастдайка бы в этом случае вообще мог сдохнуть…

ну в /etc много мелких файлов, вроде рэйзер как раз для этого

«Ну много» это сколько миллионов?

У меня 2.516. Давайте меряться пиписьками.

на моём опыте почему-то всегда когда я ставил / на рейзер, система быстрее работала, чем когда на e4. хотя может дистры кривые или руки

2113 mint10 x64

а нужен ли тогда initrd вообще, если можно на одном разделе разместить загрузочные скрипты и несколько бинарей, нужных только для монтирования, а в конфигах инита преред запуском демонов с другого носителя просто прописать монтирование бинарями с этого носителя, а потом какой-нить chroot? или это будет не совсем правильно? просто если можно так будет сделать, то initrd окажется велосипедом

Боюсь, ты впустую тратишь своё время. Усилий на рубль, а результата - на копейку.

лучше скажи, нужен ли вообще initrd. т.е можно ли ПОСЛЕ передачи управления ядру подмонтировать другой / с другими /etc /bin и остальными БДж и Ш без каких либо CCЗБ-ностей?

Что значит «другой» с «другими»?

ну то есть по сути полностью сменить корень на подмонтированный раздел. как бы chroot, но я не знаю, вдруг у чрута есть какие-нибудь недостатки, что лучше не использовать его для полнофункциональной смены корня. т.е просто пытаюсь выяснить, можно ли обойтись без initrd для запуска системы, раскиданой по разным разделам/устройствам с помощью базового комплекта бинарей, необходимых для подмонтирования каталогов /bin /etc с внешнего, ещё не подмонтированного устройства/раздела. или всё равно менее костыльным вариантом будет каждый раз создавать initrd для каждого ядра? просто хочется один раз создать бинарный миникомплект, который сможет подгружать нужное ядро с любого устройства на любом компе, заместо того чтобы на каждом компе каждый раз initrd делать, тем более наверняка компактней и шустрее получтся

Я всё равно ничего не понял.

ёпрст. можно ли обойтись без инитрд если нужно запустить систему, у которой и /boot и /bin и /lib и /etc находятся на разных разделах, созданием в разделе с /etc комплекта бинарей, необходимых для замены initrd?

Вряд ли.

ну если chroot сработает, то почему не получится? или под chrootом лучше не сидеть?

У меня такое чувство, что ты сам не понимаешь, о чём говоришь.

можно ли обойтись без инитрд если нужно запустить систему, у которой и /boot и /bin и /lib и /etc находятся на разных разделах, созданием в разделе с /etc комплекта бинарей, необходимых для замены initrd?

Можно запихнуть аналог initramfs в подкаталог в /etc и передать ядру параметр типа init=/etc/preinit/init. Только придётся скрипты руками писать. Просто распаковать initramfs в /etc/preinit не получится — без изменений работать не будет.

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

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

Только придётся скрипты руками писать. Просто распаковать initramfs в /etc/preinit не получится — без изменений работать не будет.

где бы по-подробней узнать про это? и как бы это всё сделать более корректно или initd окажется менее костыльным вариантом?

где бы по-подробней узнать про это?

В принципе, там очевидно всё. Нужно сделать то же, что делается в initrd (смонтировать всё, что нужно, и exec'нуть /sbin/init), но учесть то, что пути к программам другие, т.е. /etc/preinit/bin вместо /bin и т.п. И ещё switch_root в конце не нужен.

Для примера можно почитать содержимое каталога /lib/preinit и скрипта /etc/preinit в OpenWrt, но это не простой пример, на котором можно понять суть, и он там не заменяет initrd, а просто является частью процесса загрузки.

или initd окажется менее костыльным вариантом?

Моё мнение, что лучше использовать initrd, чем пытаться сгородить какой-то костыль-велосипед в файловой системе, который будет выполнять задачу initrd вместо него. В данных условиях даже не получится сэкономить на дублировании бинарников, потому что тут хватит урезанного busybox'а, который после загрузки будет бесполезен.

ну кагбы инитрд это оно и есть только сжатое в один маленький файл. в инитрд можно и полную систему запихать.

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

можно даже прыгнуть на другое ядро...

но зачем если инитрд делает всё это куда деликатнее?

дело не в чруте а в том что для решения задачи предпочтительно использовать утилиты созданные для её решения, тоесть инитрд.

//забивать отвёрткой гвозди это тоже очень можно.