Загрузить систему Linux от подкаталога на разделе?

Короткий ответ - существует насколько я знаю не из поля рабочее решение для Ваших конкретных требований. Необходимо будет скорректировать каждый initramfs каждого распределения для поддержки определенных потребностей.

Длинный ответ - да это возможно. В наше время большинство дистрибутивов Linux использует initramfs, который будет загружен в память загрузчиком и затем распакован ядром. Там это будет работать /sbin/init который ответственен за установку раннего пространства пользователя (работающий udev, загружая модули, стартовый Плимут, прося crypto пароль, настраивая сеть для сети монтируется, … Вы называют его). Поскольку можно запустить собственные скрипты и оценить пользовательскую начальную загрузку parmaters.

Пример для Debian

Если Вы используете 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.

Начальная загрузка другого Linux, не смешивая с таблицей разделов интересна в различных целях, альтернативное решение к совместно используемой файловой системе состоит в том, чтобы использовать объемы цикла, здесь для нескольких изменений было нужно предположение, что у Вас есть/debian файл/объем цикла в/dev/sdb1 файловую систему (я использую текущий GNU/Debian sid/unstable и для основной OS и для цикла OS).

/etc/grub.d/40_custom: # outside from loop volume
menuentry 'label' --class gnu-linux --class gnu --class os {
    ...
    loopback loop (hd2,msdos1)/debian
    linux   (loop)/boot/vmlinuz root=/dev/sdb1 loop=/debian ro
    initrd  (loop)/boot/initrd
}

Аргументы, определенные в личинку как командная строка Linux, установлены на ENV initrd/init, таким образом:

ROOT=/dev/sdb1
rootmnt=/root
loop=/debian 

цикл позволяет монтировать объем по "себе", поток сценария по умолчанию делают a mount /dev/sdb1 /root мы просто дополнительно повторно монтируем/dev/sdb1 как rw, если это был ro, затем всегда добавляют a mount -o loop /root/debian /root.

/etc/initramfs-tools/scripts/local-bottom/loop: # inside the loop volume
#!/bin/sh

[ "$1" = "prereqs" ] && echo && exit 0

if [ -n "${loop}" ]; then
        if [ "${readonly}" = "y" ]; then
                roflag=-r
                mount -o remount,rw ${ROOT} ${rootmnt}
        else
                roflag=-w
        fi
        mount ${roflag} -o loop ${rootmnt}${loop} ${rootmnt}
fi

Должен также предварительно загрузить некоторый модуль в initram (затем не забывают выполнять обновление-initramfs),

/etc/initramfs-tools/modules: # inside the loop volume
...
loop
ext4

Не знайте, насколько использование действий влияния цикла или тратит впустую ресурсы, я задаюсь вопросом, если монтирование ext4 по ext4 удваивает вероятности отказа файловой системы, но предполагает, что некоторая настройка могла быть сделана. Возможно, существует лучший способ использовать цикл, меньше hackish, если там сообщен мне, потому что я не нашел.

Это не ответ, но я хочу прояснить некоторую мысль об ответе и комментариях Ulrich (я не могу прокомментировать выше).

Решение, которое предлагает Ulrich, "может" работать (непротестированный все же), но затем Вы получите non-remountable файловую систему. Как обходное решение (по моему скромному мнению, ужасный) можно смонтировать фс как rw прежде chrooting (как предложено здесь), но быть осторожны относительно поврежденных init сценариев. Я предполагаю, что это обходное решение имеет больше побочных эффектов (как поврежденная фс, пытаясь повторно смонтировать ro и перестав работать).

Я использую ядро 3.2 с ext4 и монтирую, что уже смонтированный dev в chroot все еще дает EBUSY, как прокомментировал psusi.

Вот два способа, которые работают в ubuntu focus&bionic (и, вероятно, в других местах ). у меня недостаточно представителей, чтобы прокомментировать, но bionic :/usr/share/initramfs -tools/init ищет /etc/fstab для /usr сразу после вызова mountroot и перед вызовом *-нижних сценариев, поэтому добавление нижнего сценария инициализации -(, как предлагается в другом ответе здесь ), «слишком поздно». вместо этого я рекомендую эти:

#!/bin/bash -f
#copyleft 2018 greg mott

#set a subdirectory as root (so multiple installs don't need partitions)
#these work in ubuntu bionic, might need tweaking to work elsewhere
#1st choice:  tweak initramfs-tools/scripts/local
#   pro:  $sub becomes root directly, nothing gets any chance to see the partition root
#   con:  requires the subdirectory's initramfs/initrd to be tweaked and rebuilt
#2nd choice:  specify this scriptfile as init= on the kernel commandline
#   pro:  no need to rebuild initramfs
#   con:  bin/bash in partition root must be executable by $sub/vmlinux (partition root older than $sub likely will work)
#   con:  if the partition root etc/fstab mounts /usr, the $sub initramfs will mount the partition root /usr
#   con:  additional initramfs scripts might also look in the partition root rather than $sub

#for either choice copy /etc/grub.d/40_custom to /etc/grub.d/07_custom and add one or more menuentries that specify subroot:
#menuentry "subroot foo" {
#     echo "subroot foo"
#              sub=/foo
#             uuid=22e7c84a-a416-43e9-ae9d-ee0119fc3894         #use your partition's uuid
#     search --no-floppy --fs-uuid --set=root $uuid
#            linux $sub/vmlinuz ro root=UUID=$uuid subroot=$sub
#     echo "initrd $sub/initrd.img"
#           initrd $sub/initrd.img      #works in recent releases where the /initrd.img softlink is relative
#}

#for the 2nd choice, in addition to subroot= on the kernel commandline also specify:
#   init=/path/to/script        #pathname from partition root to this scriptfile (chmod 744)

#for the 1st choice, the tweak for bionic:/usr/share/initramfs-tools/scripts/local is replace:
#          mount ${roflag} ${FSTYPE:+-t ${FSTYPE} }${ROOTFLAGS} ${ROOT} ${rootmnt}
#          mountroot_status="$?"
#with:
#          set -x
#          karg=" $(cat<proc/cmdline) " m=${karg#* subroot=}
#          [ "$m" = "$karg" ]||subroot=${m%% *}                                  #extract subroot from kernel commandline
#          [ $subroot ]&&part=part||part=$rootmnt                                #no subroot, just mount partition as root
#          mkdir part
#          mount ${roflag} ${FSTYPE:+-t ${FSTYPE} }${ROOTFLAGS} ${ROOT} $part&&  #mount partition
#             if [ "$subroot" ]
#             then mount --bind part/$subroot $rootmnt&&                         #mount subroot
#                  umount part                       #&&sleep 15                 #unmount partition root (uncomment &&sleep for time to watch)
#             fi
#          mountroot_status="$?"
#          [ $mountroot_status = 0 ]||sleep 90                                   #if error pause to see it
#          set +x
#once you've edited /usr/share/initramfs-tools/scripts/local, update-initramfs -u will rebuild for the current kernel,
#and it will automatically build into every new initrd/initramfs installed thereafter

subroot(){ karg=" $(cat<proc/cmdline) " m=${karg#* subroot=}
           [ "$m" = "$karg" ]||subroot=${m%% *}                 #extract subroot from kernel commandline
           [ $subroot ]||return 0                               #no subroot, just proceed in partition root
           while read -r m r m
           do for m in $M x                                     #build list of what's already mounted
              do    [[ $r = $m* ]]&&break                       #exclude subtrees (eg dev/**)
              done||[[ $r = /   ]]||M=$M\ $r                    #exclude /
           done<proc/mounts
           (set -x;mount --bind $subroot mnt)||{ set -x         #mount subroot
                                                 sleep 30          #if not found pause to see error
                                                 return 0;}        #then reincarnate as partition root init
           for m in $M
           do (set -x;mount -n --move $m mnt$m)||return         #move listed mounts to subroot
           done
           set -x
           cd           mnt&&
           pivot_root. mnt&&                                   #subroot becomes root
           umount -l    mnt&&                                   #unmount partition root
          #sleep 15        &&                                   #so far so good?  uncomment for time to look
           exec chroot. init "$@"                              #reincarnate as subroot init
}
subroot "$@"&&exec init "$@"||exec bash                         #land in a shell if moves or pivot fail