стало интересно, если я вынесу асё из корня, это всё смонтирую в фс в памяти, отсоединю хард с / (по сути пустым) - будет ли система видеть все смонтированные к корню разделы и функционировать? или доступ к /dev /sys и /mnt заблокируется?
Тогда можно будет провернуть мегакрутую штуку: избавиться от корневой системы на диске вообще. Корневая ФС будет в tmpfs, к ней монтируются /usr, /var и /home с диска, а также виртуальные /proc, /sys, /dev, tmpfs в /tmp. А чтобы было не обязательно делать этому всему хозяйству (/usr, /var, /home) 3 отдельных раздела, можно заюзать subvolumes в каком-нибудь btrfs.
Всё будет работать, но нужно грамотно запилить initramfs и выполнить монтирование оттуда.
Не будет работать. Даже если ты смонтируешь абсолютно все каталоги первого уровня на другие носители, точке монтирования / тоже нужно где-то быть. Хотя я бы посмотрел видео с реакцией системы на внезапную пропажу корня. Это можно сделать проще: поставить в виртуалке какой-нибудь Линукс, загрузить его и отключить виртуальный хард.
Можно ещё из initramfs временно смонтировать ФС, смонтировать в другой каталог tmpfs, скопировать всю реальную ФС в tmpfs, размонтировать реальную ФС и сделать корнем tmpfs. Так сделано в Tiny Core Linux, это очень просто.
Можно. Только воткнуть в /etc fstab (и возможно кое-что еще), чтобы ядро знало, что и как монтировать. Ну, а на etc, лежащее отдельным разделом, в /etc/fstab (что на корне) прописать force (или как там этот ключ называется, который в непустые директории позволяет монтировать).
У меня когда-то так был организован «распределенный доступ» в компьютерном классе: в /etc/ на каждом компьютере были ссылочки на passwd, shadow, groups и т.п., лежащие в другой директории; в /home был только один пользователь. Затем по NFS монтировался «хомяк» и директория с passwd и т.п.
А вообще, не понимаю, нафига выносить /etc на отдельный раздел…
А зачем пустому корню какой-то носитель? Не, ну, конечно, не надо ничего отсоединять, не отмонтировав это. Я не знаю, будет ли тогда работать, надо с флешкой проверить. А вообще tmpfs в корень — и всё работает.
Затем, что «пустой корень» - это точка монтирования всех каталогов первого уровня.
Это не повод выделять ему место на диске.
Кстати, если выдернуть винт во время работы, то можно будет открывать файлы, которые остались в page cache. Поэтому, наверное, будет работать система, в которой выдернуть корень, в который смонтировано всё остальное, но за стабильность такой работы никто не ручается.
Тогда можно будет провернуть мегакрутую штуку: избавиться от корневой системы на диске вообще.
я как раз это хотел провернуть. тогда и инитрамфс для старта тоже не нужен, если все модули в /boot. только мне не совсем понятно, если корня не будет, как он будет создаваться в памяти при старте? и можно ли будет во время работы такой системы монтировать новый носитель непосредственно к корню(/FLASH_DISK) и полноценно с ним работать?
Я как-то по ошибке не тот жесткий диск выдернул (вместо диска с кино дернул диск с системой). Буквально через полминуты у меня произошло конкретное зависание системы.
Вообще-то он здесь критически важен, потому что он как раз будет всё монтировать — ядро с настолько хитрым монтированием не справится.
если корня не будет
Корень есть всегда. Его не будет на диске.
как он будет создаваться в памяти при старте?
Initramfs смонтирует tmpfs в какой-то каталог, после этого сделает switch_root в него.
и можно ли будет во время работы такой системы монтировать новый носитель непосредственно к корню(/FLASH_DISK) и полноценно с ним работать?
Можно монтировать всё, что можно в обычной системе. Можно монтировать подкаталоги корня. В принципе, можно смонтировать и поверх корня другую ФС, но файлы видно не будет (будет видно старый корень), при этом я сейчас так сделал и у меня не получается отмонтировать :)
Буквально через полминуты у меня произошло конкретное зависание системы.
Где-то на ЛОРе я видел тред, в котором у кого-то (ЕМНИП, у KRoN73) на сервере вышел из строя винт, но доступ по ssh остался и запускались команды, оставшиеся в кэше.
ксли модули будут в /boot/modules ядро их не увидит?
Открою тебе тайну: ядро не знает, где лежат его модули. Более того, ему пофигу, где они лежат. Модули можно загрузить через insmod из любого места, но обычно модули загружают через modprobe, который обычно смотрит в /lib/modules, но это место, конечно, можно изменить.
И самое главное: модулей не будет в /boot/modules, пока ничего не смонтировано. Пока ничего не смотировано, никакого /boot и в помине нет. После монтирования tmpfs в / файловая система всё так же пуста, каталоги нужно создать, а потом в них монтировать всё остальное. Поэтому, если нужны какие-то модули, их надо класть в initramfs.
разве он нужен не только для монтирования /usr/lib/modules?
Для этого initramfs нужна в последнюю очередь. В первую очередь она нужна тогда, когда с монтированием не справляется ядро само, и это именно наш случай. Ядро же способно просто взять какое-то блочное устройство, модуль поддержки которого вкомпилен в образ ядра, смонтировать его в корень и запустить оттуда любой поддерживаемый исполняемый файл с PID=1.
я имел ввиду что если корня не будет на диске, но он будет в памяти, можно создать /mnt? или надо будет делать ещё отдельный /mnt?
Конечно, можно создавать любые файлы и каталоги в tmpfs.
например на nilfs2 для сохранения истории изменений
Парочка вопросов:
Для неё есть fsck, исправляющий ошибки?
Правильно ли я понимаю, что место постепенно занимается и его нельзя освободить из-за полного лога изменений? Или же можно оставлять последние N версий файла?
ЕМНИП, эффект тот же, что и при rm -rf /*, ничего не находит. Я пробовал флешку выдергивать. Ну и никакого восстановления при втыкании ее обратно можно уже не ждать, естественно.
понятно. осталось освоить этот initramfs. а в линуксе же минимум 3 какие-то фс для оперативной памяти, какая лучше? и последний вопрос: вот есть допустим на разделе опции nomtime, noatime, на быстродействие фс в ram эти опции оказывают влюяние, или если я буду использовать ram fs мне глубоко побоку на notail, nomtime? или на ram fs для каждого монтируемого раздела могут создаваться свои оции фс поверх изначальных?
а в линуксе же минимум 3 какие-то фс для оперативной памяти, какая лучше?
Лучше сделать архив cpio и сжать его чем-нибудь, например, gzip'ом. Сейчас так принято делать initramfs.
на быстродействие фс в ram эти опции оказывают влюяние
В корневой tmpfs будет всего лишь несколько каталогов, в которые уже примонтировано всё остальное. По сути, никакого серьёзного I/O там не будет, тем более оно в ОЗУ, поэтому я думаю, что пофиг на опции монтирования.
или на ram fs для каждого монтируемого раздела могут создаваться свои оции фс поверх изначальных?
Для каждой примонтированной ФС, конечно, свои опции. Их уже имеет смысл выставлять. А при чём тут ramfs?
o_O Как ты их потом в разные каталоги монтировать будешь? Тут без bind не обойтись, а это 3 монтирования вместо 2, если бы они были разными разделами. Лучше таки разделить.
а заместо noexec на каталоге хомяка правами_доступа -x сделаю.
Это ничем не поможет, потому что noexec делают, чтобы нельзя было выполнить файл, лежащий на этой ФС, а права доступа юзер всегда себе может поменять.
У этого есть плюс - если на tmpfs оставить всё, что нужно для mount и udev, то можно будет при повторном подключении системного диска всё примонтировать назад и продолжить работу. Таким образом получится система устойчивая к пропаданию системного диска. Полезно для LiveCD и особенно LiveUSB.
У меня такое было на реальном железе - во время работы раскрошился хард. Линукс продолжал работать. Я понял, что хард сдох только по тому, что не мог запускать прилодения, в консоли автодополнение перестало работать и ls подвисал. Зато firefox с гуглом помогли мне продиагностировать порблему и почитать маны по замене харда в моем ноуте.
При таком раскладе ведь можно будет временно записать что-нибудь в корень? Просто иногда бывают дебианопроблемы, единственным выходом из которых является слака^Wустановка пакета в обход пакетного менеджера, например, так:
root@localhost:/# ar x ~/Downloads/mycoolpackage.deb
root@localhost:/# tar xzf data.tar.gz
При таком раскладе ведь можно будет временно записать что-нибудь в корень?
Ну да, насколько места в tmpfs хватит.
Просто иногда бывают дебианопроблемы, единственным выходом из которых является слака^Wустановка пакета в обход пакетного менеджера, например, так:
Не очень понял, как корень в tmpfs поможет этой проблеме. Если так сделать, то запишется же на диск, потому что каталоги смонтированы. А если записать именно на tmpfs, то файлов видно не будет, потому что сверху смонтированы другие ФС, если не использовать overlayfs или аналоги типа aufs2.
Не очень понял, как корень в tmpfs поможет этой проблеме.
Помочь никак не может, я боялся что может помешать.
Если так сделать, то запишется же на диск, потому что каталоги смонтированы.
Мне как раз это и нужно было. В корень нужно только временно извлечь deb-пакет, представляющий собой архив ar. Затем извлечь полученный тарбол data.tar.gz, который содержит в себе директории ./opt и ./usr/share с файлами пакета, которые во время распаковки сами распихиваются по необходимым директориям на диске.
К такому изврату приходится прибегать, когда нужно поставить программу, которая доступна только в виде deb-пакета, но при этом имеет кучу ненужных зависимостей, хотя бы одну из которых невозможно удовлетворить. Например guitar hero непонятно зачем зависит от gksu:i386, который мне не удалось нормально поставить в ubuntu 12.04 amd64, несмотря на хваленый multiarch; а getlibs + симлинки на 32-битные либы не подходят, так как пакетному менеджеру на них пофиг.
Вообще меня жутко бесит, когда программы, которые ставятся в /opt распространяются в дурацких пакетах, и при этом нельзя скачать нормальный тарбол. Из примеров такого чудачества могу привести libreoffice и уже упоминаемый выше guitar hero.
решил поделиться, на мой взгляд, видением идеальной разметки диска (имена разделов на вкус и цвет, но эти имена я выбрал для быстроты и удобства, и прошу их особо не критиковать):
с = раздел для компиляции(т.к в генту_буке пишут что /var/portage/cache может занимать гигабайты) 00 = для свопа, гибернации и слепков системы 0 = (аля boot) ядро, модули x = аля usr - = там будут редкоиспользуемые и необходимые только для старта элементы usr, чтоб не забивать ими память ' = аля etc; но нужные только во время старта файлы в - " = хомяк
и так в памяти всегда будет только хомяк, часть /etc(кроме загрузочных скриптов) и /usr (кроме редкоиспользуемых программ типа записи cd dvd)
Щто? С каких пор опции монтирования откуда-то наследуются?
При монтировании каждой ФС задаются опции монтирования для неё и только для неё. Таким образом, есть свои опции монтирования на корень и на каждую точку монтирования.
я правильно понял, что при монтировании фс в tmpfs создаются свои опции, отличные от тех, что в fstab? есть на диске / и /home в нём же, при этом получится смонтировать хомяк с noexec, правильно? просто решил по-другому разметить. если всё-равно монтируешь всё со своими опциями, то какой смысл избавляться от корня?