Какой из proc, sys и т.д. должен быть, связывают - смонтированный (или не) когда chrooting в “заменяющее” распределение?

Необходимо будет propably выполнить что-то как rsync -avun --delete в обоих направлениях.

Но что Вы на самом деле пытаетесь выполнить?

Обновление:

rsync -avun --delete $TARGET $SOURCE |grep "^deleting " даст Вам список файлов, которые не существуют в целевом каталоге.

"grep удаляют", потому что каждая строка печатает: удаление.. файл..

rsync -avun $SOURCE $TARGET даст Вам список "различных" файлов (включая новые файлы).

9
13.04.2017, 15:37
3 ответа

/etc/resolv.conf копируется для не потери DNSs.

/lib/modules копируется потому что, потому что может быть необходимо использовать некоторый аппаратный компонент, который не должен присутствовать во время установки chroot. Необходимо помнить, что исходный вопрос, к которому Вы обращаетесь в Вашем OP, касается замены ОС NAS с Дугой Linux. Вам таким образом будут нужны драйверы для Ethernet, возможно беспроводная связь, различные компоненты USB, и так далее. Копирование/lib/modules папки гарантирует, что новая среда сможет справиться со своими будущими задачами.

Вы действительно правы относительно перемонтирования по сравнению со связанный смонтированным. Страница Arch Linux Wiki на chroot действительно использует перемонтирование и связанный смонтированный, как Вы указываете согласно ответу на сообщение, к которому Вы обращаетесь:

cd /mnt/arch
mount -t proc proc proc/
mount -t sysfs sys sys/
mount -o bind /dev dev/
mount -t devpts pts dev/pts/

(Я думаю, что это показывает, что синтаксис Ваших строк, скопированных с этого сообщения, является неправильным: dev, который будет смонтирован, предшествует точке монтирования).

Однако страница справочника Ubuntu на chroot рассказывает другую историю:

sudo mount -o bind /proc /var/chroot/proc

Здесь/proc, связывают - смонтированный, не повторно смонтированный.

Я на самом деле попробовал обе вещи, и после краткого тестового прогона, я был неспособен к notie любое различие. Не большая часть теста, по общему признанию, и я буду таким образом считать так здесь, что она не должна иметь большую часть значения.

9
27.01.2020, 20:06
  • /etc/resolv.conf - Вам нужен этот файл для разрешения запросов DNS. Это не необходимо при некоторых обстоятельствах:

    1. клиент DHCP доступен в chroot, это действительно становится выполняемым, и сервер DHCP возвращает соответствующую информацию (который обычно имеет место).

    2. Вы не интересуетесь сетями (или более точно делающие запросы DNS из обычных приложений, которые полагаются /etc/resolv.conf) изнутри chroot.

  • /lib/modules/$(uname -r) - имеет смысл в случае, если Вы, возможно, должны были бы загрузить любые дополнительные модули для активного ядра. Без этого Вы застряли бы с тем, что у Вас в настоящее время есть выполнение. Следовательно, если Вы намереваетесь выполнить chrooted систему в течение более длительного времени, необходимо, вероятно, сделать это. С другой стороны, в таком случае, вероятно, необходимо использовать pivot_root вместо этого (который является тем, что обычно initrd делает в конце его жизни). Если просто необходимо сделать это, например, устанавливать загрузчик от chroot, это не должно быть необходимо (так как все необходимые драйверы должны быть загружены, чтобы Вы смогли сделать сам chroot так или иначе).

  • /proc и /dev довольно очевидны - они содержат интерфейсы базовой системы.

  • /sys был IIRC не, который широко использовал назад в 2007, который является тем, чем Slackware (который самим довольно консервативен) датировано практическое руководство. В эти дни Ваша система, вероятно, перестанет работать так или иначе без него (например, после того как что-то пытается перечислить некоторые аппаратные средства типа).

  • /dev/pts - за эти годы было несколько изменений в как /dev дерево обрабатывается. В какой-то момент устройства в /dev/pts были обработаны devfs - посмотрите, например, этот поток LKML для обсуждения возможных проблем.

  • свяжите монтирование - существуют некоторые интересные аспекты, связывают, монтируется (скорее приятно объясненный в mount(8) страница справочника). Например, если Вы имеете:

    /some/device on /x/a (rw)
    /x/a/A on /x/b (rw)
    

    и затем повторно смонтируйтесь /x/a только для чтения, Вы не сможете изменить что-либо в /x/B. Который понятен, но мог бы поймать Вас врасплох впервые. Другой хороший вопрос - то, что должно произойти с /x/b в вышеупомянутом примере, когда Вы umount /x/a. Для меня это совсем не очевидно, что можно все еще получить доступ к дереву под ним. Следовательно свяжите монтирование, может быть хитрым. Функционально, при использовании в целой файловой системе это - то же.

  • другие вещи от /etc/ - определенно имеет смысл копировать соответствующую конфигурацию, которая полезна. Копирование, например. /etc/passwd, /etc/shadow, /etc/groups может иметь смысл, а также ключи сервера для sshd.

6
27.01.2020, 20:06
  • 1
    , который Оба ответа об одинаково хорошем - таким образом, я бросил монету который принять... –  Tobias Kienzler 05.11.2013, 10:05

/procуправляет процессами и sysизменяет параметры ядра или информацию о доступе к текущему ядру.

Теперь, принимая во внимание, чтоbindподразумевает двунаправленный характер, procне должен монтироваться вне chroot как лучшее решение.

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

/dev/ptsуже доступны, так как /devмонтируется как bind -, но являются частью chroot, поэтому рекомендуется перемонтировать новый ptsкак mount -t devpts none /mnt/drive/dev/pts.

0
27.01.2020, 20:06

Теги

Похожие вопросы