Я интересуюсь созданием моего собственного ремикса Ubuntu и делал так с Ubuntu Мини-Ремикс ISO.
Чтобы сделать это, я монтирую образ диска и chroot в него способом, подобным этому руководству.
Моя иерархия каталогов для моих сборок как такова:
home
|
\builds
|
+build(n)
| |
| +mnt
| +extract-cd
| +edit
| \&
|
+build(n+1)
| |
| \&
|
\sources (various debfiles/ISOs)
Каждой сборке установили $HOME на./edit/root, таким образом, что-либо выше иерархия (./mnt./extract-cd, и т.д.) недоступно chroot среде.
Существует ли путь к пакетам, загруженным Кв. chroot, которая будет зеркально отражена к a, например, ~/builds/cache (или, еще лучше, ~/builds/cache / [версия человечности]) каталог, который мог затем использоваться в качестве репозитория для других сборок?
Такая установка сохранила бы меня много пропускной способности, так как только пакеты, которые еще не были загружены/зеркально отражены на репозиторий, должны будут вытянуть от сети.
Так или иначе, спасибо заранее за любые предложения/помогать.
Я закончил тем, что использовал ответ user7134, наряду с некоторой информацией отсюда.
Так как его ответ не полностью выполнил то, что я имел в виду, я пишу свой собственный ответ. Тем не менее, я даю ему щедрость, так как она указала на меня к правильному пути.
Способ решить проблему является этим: после луга CD к build(n)
каталог, прежде chrooting в сборку, выполненную
`sudo mount --bind /home/[username]/builds/cache edit/var/cache/apt/archives`
Это будет эффективно кэшировать пакеты, что chrooted создают загрузки.
Возобновите сборку как нормальная. Нет никакой потребности, еще, сделать наш repo, поскольку не было бы ничего в нем.
После того, как законченный со сборкой, при размонтировании вещей и очистке chroot, типа
umount /var/cache/apt/archives
Мы можем затем сделать repo для использования в будущих сборках.
Для этого создайте файл repobuild.sh,
который будет похож на это:
#! /bin/bash
cd /home/[username]/builds/cache
dpkg-scanpackages . /dev/null | gzip -9c > Packages.gz
Сделайте наш исполняемый файл сценария путем выполнения chmod u+x /home/[username]/repobuild.sh
и запущенный скрипт: /home/[username]/repobuild.sh
Перейдите о подготовке к chroot в новую сборку, удостоверившись монтироваться /home/[username]/builds/cache
в edit/var/cache/apt/archives
как показано выше.
Chroot в edit
и затем добавьте
deb file:/var/cache/apt/archives ./
кому: /etc/apt/sources.list
Выполненная Кв. - получает обновление, и Вы сделаны. Теперь можно использовать кэшируемые пакеты путем ввода apt-get install [packagename],
как Вы обычно был бы.
Следует иметь в виду, что каждый раз пакет добавляется к cache
каталог, repobuild.sh
должен будет быть повторно выполнен, если Вы хотите использовать кэшируемый пакет.
Я никогда не использовал Ubuntu Мини-Ремикс ISO, но существует несколько способов, которыми я раньше выполнял это при выполнении vmbuilder сборок:
РЕДАКТИРОВАНИЕ: сам apt-cahcer-ng не должен быть настроен всегда - просто устанавливают его с помощью sudo apt-get install apt-cacher-ng
. Существуют некоторые усовершенствованные опции конфигурации, в которых я никогда не нуждался. Можно найти инструкции, как настроить клиенты (сборки) для использования кэша здесь .
Одна стратегия, которая могла бы работать, будет состоять в том, чтобы смонтироваться (с - связывают опцию), общая папка к кэшу пакета chroot. Этот кэш расположен в /var/cache/apt/archives/
Используя этот метод, сделал бы его так, чтобы любая команда, выполненная способным, работала с общим локальным архивом.
sudo mount --bind ~/builds/cache <chroot location>/var/cache/apt/archives
sudo mount --bind ~/builds/cache <another chroot location>/var/cache/apt/archives
, Который сделал бы ~/builds/cache и способный архив обоих chroot, работающий против того же каталога.
sudo mount --bind /var/cache/apt/archives <chroot location>/var/cache/apt/archives
sudo mount --bind /var/cache/apt/archives <another chroot location>/var/cache/apt/archives
Подобный первому, но теперь основной установке и обоим chroots будет использовать тот же способный архив, т.е., склонный во всех трех посмотрит в том же месте для загруженных .deb файлов.
(я думал, пакеты непосредственно не заботятся о выпуске человечности, просто версии связанных пакетов. Таким образом, Вы, возможно, не должны волноваться об отдельных папках для каждого выпуска, и Вы могли даже возможно использовать архив пакета локальной установки.)
Наконец, и значительно, в разделе о чистке chroot при подготовке к заключительной сборке, Вы не хотите работать склонный чистый. С тех пор склонный теперь использует ту же папку через всю установку chroots, этот путь, склонный чистый, будет чрезвычайно ясный архив для всего chroots сразу. Вместо этого в chroot, выполненном:
umount /var/cache/apt/archives
Это будет эффективно "склонный чистый" архив от просто chroot, куда команда выполняется при оставлении общей папки нетронутой.
, следующее является прямой копией с man mount
страница. Смотрите на него для полного объяснения монтирования - связывают, и возможно видеть, что другие способы использовать связывают.
The bind mounts.
Since Linux 2.4.0 it is possible to remount part of the file
hierarchy somewhere else. The call is:
mount --bind olddir newdir
or by using this fstab entry:
/olddir /newdir none bind
After this call the same contents are accessible in two places.
One can also remount a single file (on a single file). It's
also possible to use the bind mount to create a mountpoint from
a regular directory, for example:
mount --bind foo foo
The bind mount call attaches only (part of) a single filesystem,
not possible submounts. The entire file hierarchy including
submounts is attached a second place by using:
mount --rbind olddir newdir
Note that the filesystem mount options will remain the same as
those on the original mount point, and cannot be changed by
passing the -o option along with --bind/--rbind. The mount
options can be changed by a separate remount command, for exam‐
ple:
mount --bind olddir newdir
mount -o remount,ro newdir
Note that the behavior of the remount operation depends on the
/etc/mtab file. The first command stores the 'bind' flag in the
/etc/mtab file and the second command reads the flag from the
file. If you have a system without the /etc/mtab file or if you
explicitly define source and target for the remount command
(then mount(8) does not read /etc/mtab), then you have to use
the bind flag (or option) for the remount command too. For
example:
mount --bind olddir newdir
mount -o remount,ro,bind olddir newdir
Note that remount,ro,bind will create a read-only mountpoint
(VFS entry), but the original filesystem superblock will still
be writable, meaning that the olddir will be writable, but the
newdir will be read-only.