On Sun, Oct 17, 2010 at 9:01 PM, Gregory Woodbury <redwolfe@xxxxxxxxx> wrote: > I'd like to see your setup instructions again. > Here is a copy of a set of notes I created some a months ago - you may well need to adapt for your own use: "These notes relate only to using mock/pungi for Fedora install iso builds, not revisor..... these are my own notes and I usually work and adapt as I go. Some of this you may want to use your own flavour for i.e. YMMV! - however I have / and /opt as separate partitions, and I have /home as a directory under /opt and bind mount to /home - that way I keep the system separate from user and other non-system areas. I then place my build area in /opt as you will see below and bind mount it to the normal system area that is the default for building under mock. I am also building under a system that runs selinux fully enforcing - if you are using selinux permissive or switched off then you may not need to take the same level of care with the selinux parts of the notes. If you do *not* have the same partition and directory structure as I have then you will need to adapt for your own system. Preparation: Install the package - mock into the main system via yum or packagekit. yum install mock Pungi can be installed within the chroot once mock is set up. I usually install pungi in the main system but usually only run it from within the mock chroot. Make sure user is in group mock (relogin after to make sure shell has group mock) i.e. gpasswd -a your-username mock Best to make an selinux equivalent for /opt/Local/mock to /var/lib/mock Then bind mount the new area So as root do: semanage fcontext -a -e /var/lib/mock /opt/Local/mock restorecon -vR /opt/Local/mock That way the system security contexts are set in the bind mounted area to be the same as those in the original mock area. This minimises the chance of avc denials in the build system. cd /var/lib mv mock mock.DIST mkdir mock Check contexts and ownership/permissions are same for mock and mock.DIST Then add a line to /etc/fstab /opt/Local/mock /var/lib/mock none bind 0 0 Then mount /var/lib/mock Now the new mock area will be mounted on boot. The required .cfg files are in /etc/mock Make a new file as needed with new repos as say fedora-13-i386-my-own.cfg In that file - edit to change the repos to suit as necessary. The latest version of the files are in http://git.fedorahosted.org/git/?p=mock.git;a=tree So put the appropriate .cfg file in /etc/mock Then as user do $ mock -r fedora-13-i386-my-own --init $ mock -r fedora-13-i386-my-own --install pungi $ mock -r fedora-13-i386-my-own --install spin-kickstarts $ mock -r fedora-13-i386-my-own --install vim Now the mock chrooted area is set up. (by hand as root cp your own kickstart file to the mock chroot area in /usr/share/spin-kickstarts within the chroot) As user $ mock -r fedora-13-i386-my-own --shell Then to start the build pungi -c /usr/share/spin-kickstarts/fedora-install-f13-my-own.ks --destdir=/compose --nosplitmedia --nosource May also need to add --force to reset the cache. This is the case if re-building after a failed or successful build. Remember to delete the /compose/20100514 or equivalent directory if you are short of disc space for the build area. pungi -c /usr/share/spin-kickstarts/fedora-install-f13-my-own.ks --destdir=/compose --nosplitmedia --nosource --force Can of course exit the shell with exit Can also run in screen and detach to leave the screen session running when controlling remotely. Once the build process is complete you should find the files in /compose either from within the chroot or drill down from /var/lib/mock from outside the chroot. I hope this gets you going OK - do note that you have to set up the repo definitions both in the .cfg files as well as in the kickstart files otherwise the build will not work. At present for F13 the repo is a fork of the development repo in directory f13. Once we get close to F13 release then the normal f13 repo sitting under releases will get populated and you will need to change the repo definitions. Also make sure that the updates repo and updates-testing repos are also defined otherwise the build will not find the latest version of packages." I now use a corresponding scheme to build f14 - and this will need adapting once the updates repo for f14 becomes active in a few days when the main repo gets frozen. You will need separate guidance on using revisor - but I don't currently use that package for building isos since my need is to make DVD install isos that are as current as possible. I hope this helps. -- mike c -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
