Короткий ответ - существует насколько я знаю не из поля рабочее решение для Ваших конкретных требований. Необходимо будет скорректировать каждый initramfs каждого распределения для поддержки определенных потребностей.
Длинный ответ - да это возможно. В наше время большинство дистрибутивов Linux использует initramfs, который будет загружен в память загрузчиком и затем распакован ядром. Там это будет работать /sbin/init
который ответственен за установку раннего пространства пользователя (работающий udev, загружая модули, стартовый Плимут, прося crypto пароль, настраивая сеть для сети монтируется, … Вы называют его). Поскольку можно запустить собственные скрипты и оценить пользовательскую начальную загрузку parmaters.
Если Вы используете Debian (должно быть то же с Ubuntu), необходимо смочь поместить сценарий в /etc/initramfs-tools/scripts/init-bottom/
который будет executded, прежде чем init будет запущен. Для получения дополнительной информации о сценарии, различные каталоги и расположение взглянули на initramfs-инструменты человека. Необходимо будет корректироваться rootmnt
и добавьте целевой каталог.
(Непротестированный) сценарий образца, который должен быть установлен любой как /etc/initramfs-tools/scripts/local-bottom/00-myroot
или /usr/share/initramfs-tools/scripts/init-top/00-myroot
:
#!/bin/sh -e
PREREQS=""
prereqs() { echo "$PREREQS"; }
case "$1" in
prereqs)
prereqs
exit 0
;;
esac
for opt in $(cat /proc/cmdline); do
case $opt in
rootdir=*)
new_mntdir="${opt#rootdir=}"
;;
esac
done
if [ -n "$new_mntdir" ] ; then
echo rootmnt="$rootmnt/$new_mntdir" >> /conf/param.conf
fi
Идея состоит в том, чтобы корректироваться rootmnt
который используется в initramfs init
сценарий для запущения/выполнения реального init. Поскольку корневое устройство уже смонтировано в init-bootom
этап можно просто корректировать/изменять целевой каталог.
Для использования этого сценария просто добавляют новый параметр начальной загрузки, копируют сценарий, делают это исполняемым файлом, повторно создают initramfs и добавляют параметр начальной загрузки для дистрибутива Linux, например. rootdir=/Ubuntu_Precise
.
Восходящий поток решил включить acl
и user_xattr
по умолчанию и удалите их, как монтируют опции (noacl
/ nouser_xattr
все еще допустимы mount
опции следовательно их показывают).
Некоторые типы файловой системы поддерживают ACLs без опции монтирования, другие только с опцией монтирования. Для ext2/ext3/ext4 некоторые опции монтирования по умолчанию включая acl/noacl хранятся в файловой системе (Вы видите это в tune2fs -l /dev/BLOCK_DEVICE | grep '^Default mount options:'
). Как отмечено don_crissti, для ext4, показывается ли вариант или не зависит от версии ядра (так как ядро 2.6.39, acl
значения по умолчанию на том, независимо от того, что файловая система говорит). Файловые системы, такие как vfat и minix не имеют никакой поддержки ACL. Файловые системы, такие как tmpfs, xfs и zfs всегда поддерживают ACLs.
Если Вы не хотите создать и поддержать большую таблицу типов файловой системы, версий, команды для проверки значений по умолчанию и версий ядра, нет никакого способа определить, поддерживает ли файловая система ACLs через опции монтирования или характеристики файловой системы. Вы не можете сказать чистым наблюдением с getfacl
любой, поскольку это будет всегда, по крайней мере, сообщать о полномочиях Unix. Даже если файловая система поддерживает ACLs, она не может поддерживать типы ACL, которые Вы хотите. Таким образом, Ваш лучший выбор состоит в том, чтобы звонить setfacl
(или базовые API C) чтобы попытаться установить ACL, Вы хотите. Если ошибочное состояние будет EOPNOTSUPP (Операция, не поддерживаемая), то Вы будете знать, что файловая система не поддерживает (этот тип) ACLs.