Существует разница между логическими и физическими путями к каталогам, с которыми вы столкнулись.
cd /home/me/opencv/build
Это поместит вас в логический каталог /home/me/opencv/build
, но физически вы на самом деле в /media/me/pendrive/opencv/build
благодаря символической ссылке.
ls..
покажет вам содержимое физического родительского каталога /media/me/pendrive/opencv
.
Путь к физическому каталогу — это путь к логическому каталогу со всеми разрешенными символическими ссылками. Они одинаковы, если путь к логическому каталогу не содержит только символические ссылки.
См. также разницу между pwd -L
и pwd -P
, находясь в каталоге сборки (и прочитав pwd
руководство ).
cd
также имеет флаги -L
и -P
(и -L
по умолчанию ).
Первоначально я думал, что проблема связана с тем, как я запрограммировал сценарий, запускаемый контейнером Docker, для создания chroot.
В док-контейнере можно создать 32-битный -chroot. Мне пришлось запустить привилегированный контейнер , иначе я не смог бы смонтировать необходимые каталоги/файловые системы (Ex:/proc
)в chroot (И получил бы ошибки ).
Мне пришлось немного изменить шаги, которые я использовал:
docker run -t --rm --name "chrootTest" -v $(pwd):/root/<CHROOT_SCRIPT_DIR> --privileged --workdir /root/<CHROOT_SCRIPT_DIR> <IMAGE>:<TAG>./build-chroot.sh <CHROOT_DIR_LOCATION>
/dev
или /sys
для модификаций chroot, которые я делаю.(Изменения заключаются в удалении каталогов/файлов/символических ссылок иapt-get install
-добавлении некоторых зависимостей. Мне нужно было смонтировать только /proc
для этих действий, но если вы делаете что-то другое, вам может понадобиться смонтировать другие каталоги.)<CHROOT_DIR_LOCATION>
и копирует resolve.conf
с хоста в незаархивированную файловую систему, а также создает все необходимые каталоги для монтирования. chroot "$CHROOT_DIR_LOCATION" /bin/bash <<'EOF'... EOF
tar
запускаю файловую систему chroot и удаляю рабочий каталог <CHROOT_DIR_LOCATION>
, сценарий завершается, а контейнер докеров удаляется. Из-за монтирования тома tar-архив с вновь созданным chroot все еще существует на хосте, выполняющем команду docker.
Я использую docker для внесения изменений в Live CD установщика Ubuntu. Он содержит среду casper/filesystem.squashfs
, похожую на среду chroot
; т. е. это полная корневая файловая система, которая записывается в целевую файловую систему во время установки. Я вношу изменения в filesystem.squashfs
вот так:
# extract installer iso
$ osirrox -indev ubuntu-18.04.4-desktop-amd64.iso -extract././ubuntu-18.04.4-desktop-amd64.d
# extract filesystem squashfs
$ unsquashfs ubuntu-18.04.4-desktop-amd64.d/casper/filesystem.squashfs
# create filesystem tarball
$ tar -cf squashfs-root.tar -C squashfs-root.
# create docker image
$ docker image import squashfs-root.tar squashfs-root:latest
# create docker container, make changes inside
$ docker run --name squashfs-mine squashfs-root sh -c 'touch /etc/my.conf'
К этому моменту теперь -остановленный контейнер squashfs-mine
содержит исходную файловую систему вместе со всеми изменениями, выполненными во время ее run
. Теперь вы можете export
использовать файловую систему контейнера как tar-архив:
# extract filesystem tarball
$ docker export -o squashfs-mine.tar squashfs-mine
В моем случае я хотел бы сгенерировать новый filesystem.squashfs
в исходное содержимое *.iso
и повторно -упаковать*.iso
:
# populate filesystem directory
$ tar -xf squashfs-mine.tar --one-top-level
# create filesystem squashfs
$ mksquashfs squashfs-mine ubuntu-18.04.4-desktop-amd64.d/casper/filesystem.squashfs
# re-pack iso
$ xorriso -as mkisofs... -o ubuntu-18.04.4-desktop-amd64.iso ubuntu-18.04.4-desktop-amd64.d
...но ваши потребности, вероятно, другие.