Эта часть справочной страницы вводит в заблуждение. Как правило, вам нужен другой порядок, как описано в man 8 pivot_root
.
cd new_root # chdir(new_root);
pivot_root. put_old # pivot_root(".", put_old);
exec chroot. # chroot(".");
Это, кажется, еще одна тонкая деталь с pivot_root
. Хотя смысл pivot_root
состоит в том, чтобы изменить пространство имен монтирования, код ядра , по-видимому, говорит, что корневая файловая система, которую он перемещает, определяется корнем каждого -процесса, а это то, что chroot
наборы.
В результате мы сталкиваемся с ошибкой «новый _корень или поместите _старый в текущую корневую файловую систему».
Эта тонкая деталь pivot_root
необходима для того, чтобы он работал вообще на современном Linux. Если бы он был определен для работы с корневым монтированием пространства имен монтирования, он попытался бы переместить специальную rootfs
файловую систему, которую вы обычно не видите . Но это не разрешено, потому что rootfs всегда должен быть корневым монтированием пространства имен .
Мы можем подтвердить, что pivot_root
работает таким образом, продолжив пример следующим образом.
# unshare -m
# mount --bind / /mnt
# cd /mnt
# chroot /mnt
# pivot_root. mnt
pivot_root: failed to change root from `.' to `mnt': Device or resource busy
# exit # leave chroot
# mount --bind. mnt
# cd mnt
# mount --bind /proc proc
# findmnt | grep mnt
└─/mnt /dev/mapper/alan_dell_2016-fedora ext4 rw,relatime,seclabel
└─/mnt /dev/mapper/alan_dell_2016-fedora ext4 rw,relatime,seclabel
└─/mnt/proc proc proc rw,nosuid,nodev,noexec,relatime
# chroot /mnt # re-enter chroot
# cd /mnt
# pivot_root. mnt # this one works
# exit # leave chroot
# findmnt | grep mnt
└─/mnt /dev/mapper/alan_dell_2016-fedora ext4 rw,relatime,seclabel
├─/mnt/mnt /dev/mapper/alan_dell_2016-fedora ext4 rw,relatime,seclabel
└─/mnt/proc /dev/mapper/alan_dell_2016-fedora[/proc] ext4 rw,relatime,seclabel
Второй вызов pivot_root
работает. Но это никак не повлияло на корень пространства имен монтирования. Глядя снаружи на chroot
, он поменял местами /mnt
и /mnt/mnt
.
В конце концов, это выглядело как «осиротевшие» файлы, по-видимому, связанные с монтированием NFS в контейнеры в то время, когда сервер NFS был недоступен. После того, как я идентифицировал и удалил эти(e4defrag
и )lsof
, они больше не зависали, т.е. снова вели себя так, как ожидалось.