virtual-appliance/Makefile

421 lines
13 KiB
Makefile
Raw Normal View History

2012-12-29 17:29:42 +01:00
CHROOT = $(CURDIR)/vabuild
APPLIANCE ?= base
I learned a lot about Makefiles :D So, basically I re-architeched things a bit: The appliance/Makefile.inc fiels are now appliance/Makefile (again). The main Makefile will call "make -C appliance preinstall" and "postinstall" (and in future "clean"). So I got rid of the ugly make variables/include thing. Some of the main Makefile's variables are exported to the sub-makes. Appliances don't really need $(APPLIANCE) anymore as the appliance directory is their CWD. Added some new targets and smarter targets. I can do more with this, but it's a big improvment from last time. Still learning a lot of Makefile magic (been reading other people's Makefiles). Verified that "make -j3" works (at least on the base appliance) but will kill your hard drive :D Introduced "profiles" Which are files with variables you want to override. The file will be "include"ed by the main Makefile. For example, I have a file, "local.cfg" that looks like this: --- 8< ----------------------------- CHROOT = /var/scratch/marduk/vabuild HEADLESS = YES PRUNE_CRITICAL = NO VIRTIO = YES TIMEZONE = EST5EDT DISK_SIZE = 60.0G SWAP_SIZE = 48 PKGDIR = /var/scratch/packages NBD_DEV = /dev/nbd8 all: qcow --- 8< ------------------------------ Then, e.g. i can run "make PROFILE=local APPLIANCE=kde". If you don't specify a PROFILE variable, then it will default to the empty string, which means the main Makefile will attempt to include .cfg So, for example i have: $ ln -s local.cfg .cfg $ make APPLIANCE=kde Don't set PROFILE inside your .cfg file (why would you?). Also, if the [pro]file does not exist, the include fails silently. I will put this info in the wiki eventually...
2010-11-14 00:22:18 +01:00
HOSTNAME = $(APPLIANCE)
RAW_IMAGE = $(HOSTNAME).img
QCOW_IMAGE = $(HOSTNAME).qcow
VMDK_IMAGE = $(HOSTNAME).vmdk
XVA_IMAGE = $(HOSTNAME).xva
LST_FILE = $(HOSTNAME)-packages.lst
STAGE4_TARBALL = stage4/$(HOSTNAME)-stage4.tar.xz
I learned a lot about Makefiles :D So, basically I re-architeched things a bit: The appliance/Makefile.inc fiels are now appliance/Makefile (again). The main Makefile will call "make -C appliance preinstall" and "postinstall" (and in future "clean"). So I got rid of the ugly make variables/include thing. Some of the main Makefile's variables are exported to the sub-makes. Appliances don't really need $(APPLIANCE) anymore as the appliance directory is their CWD. Added some new targets and smarter targets. I can do more with this, but it's a big improvment from last time. Still learning a lot of Makefile magic (been reading other people's Makefiles). Verified that "make -j3" works (at least on the base appliance) but will kill your hard drive :D Introduced "profiles" Which are files with variables you want to override. The file will be "include"ed by the main Makefile. For example, I have a file, "local.cfg" that looks like this: --- 8< ----------------------------- CHROOT = /var/scratch/marduk/vabuild HEADLESS = YES PRUNE_CRITICAL = NO VIRTIO = YES TIMEZONE = EST5EDT DISK_SIZE = 60.0G SWAP_SIZE = 48 PKGDIR = /var/scratch/packages NBD_DEV = /dev/nbd8 all: qcow --- 8< ------------------------------ Then, e.g. i can run "make PROFILE=local APPLIANCE=kde". If you don't specify a PROFILE variable, then it will default to the empty string, which means the main Makefile will attempt to include .cfg So, for example i have: $ ln -s local.cfg .cfg $ make APPLIANCE=kde Don't set PROFILE inside your .cfg file (why would you?). Also, if the [pro]file does not exist, the include fails silently. I will put this info in the wiki eventually...
2010-11-14 00:22:18 +01:00
VIRTIO = NO
TIMEZONE = UTC
DISK_SIZE = 6.0G
SWAP_SIZE = 30
SWAP_FILE = $(CHROOT)/.swap
ARCH = amd64
2012-12-23 08:32:28 +01:00
KERNEL_CONFIG = kernel.config.$(ARCH)
MAKEOPTS = -j10 -l10
I learned a lot about Makefiles :D So, basically I re-architeched things a bit: The appliance/Makefile.inc fiels are now appliance/Makefile (again). The main Makefile will call "make -C appliance preinstall" and "postinstall" (and in future "clean"). So I got rid of the ugly make variables/include thing. Some of the main Makefile's variables are exported to the sub-makes. Appliances don't really need $(APPLIANCE) anymore as the appliance directory is their CWD. Added some new targets and smarter targets. I can do more with this, but it's a big improvment from last time. Still learning a lot of Makefile magic (been reading other people's Makefiles). Verified that "make -j3" works (at least on the base appliance) but will kill your hard drive :D Introduced "profiles" Which are files with variables you want to override. The file will be "include"ed by the main Makefile. For example, I have a file, "local.cfg" that looks like this: --- 8< ----------------------------- CHROOT = /var/scratch/marduk/vabuild HEADLESS = YES PRUNE_CRITICAL = NO VIRTIO = YES TIMEZONE = EST5EDT DISK_SIZE = 60.0G SWAP_SIZE = 48 PKGDIR = /var/scratch/packages NBD_DEV = /dev/nbd8 all: qcow --- 8< ------------------------------ Then, e.g. i can run "make PROFILE=local APPLIANCE=kde". If you don't specify a PROFILE variable, then it will default to the empty string, which means the main Makefile will attempt to include .cfg So, for example i have: $ ln -s local.cfg .cfg $ make APPLIANCE=kde Don't set PROFILE inside your .cfg file (why would you?). Also, if the [pro]file does not exist, the include fails silently. I will put this info in the wiki eventually...
2010-11-14 00:22:18 +01:00
PRUNE_CRITICAL = NO
REMOVE_PORTAGE_TREE = YES
ENABLE_SSHD = NO
CHANGE_PASSWORD = YES
I learned a lot about Makefiles :D So, basically I re-architeched things a bit: The appliance/Makefile.inc fiels are now appliance/Makefile (again). The main Makefile will call "make -C appliance preinstall" and "postinstall" (and in future "clean"). So I got rid of the ugly make variables/include thing. Some of the main Makefile's variables are exported to the sub-makes. Appliances don't really need $(APPLIANCE) anymore as the appliance directory is their CWD. Added some new targets and smarter targets. I can do more with this, but it's a big improvment from last time. Still learning a lot of Makefile magic (been reading other people's Makefiles). Verified that "make -j3" works (at least on the base appliance) but will kill your hard drive :D Introduced "profiles" Which are files with variables you want to override. The file will be "include"ed by the main Makefile. For example, I have a file, "local.cfg" that looks like this: --- 8< ----------------------------- CHROOT = /var/scratch/marduk/vabuild HEADLESS = YES PRUNE_CRITICAL = NO VIRTIO = YES TIMEZONE = EST5EDT DISK_SIZE = 60.0G SWAP_SIZE = 48 PKGDIR = /var/scratch/packages NBD_DEV = /dev/nbd8 all: qcow --- 8< ------------------------------ Then, e.g. i can run "make PROFILE=local APPLIANCE=kde". If you don't specify a PROFILE variable, then it will default to the empty string, which means the main Makefile will attempt to include .cfg So, for example i have: $ ln -s local.cfg .cfg $ make APPLIANCE=kde Don't set PROFILE inside your .cfg file (why would you?). Also, if the [pro]file does not exist, the include fails silently. I will put this info in the wiki eventually...
2010-11-14 00:22:18 +01:00
HEADLESS = NO
EXTERNAL_KERNEL = NO
UDEV = YES
Baselayout-2/openrc compatibility and stage4 tarballs. The first major change here is the support of baselayout-2/openrc. So far Gentoo has not released a stage3 tarball with baselayout-2, but I've tested this enough that I feel it works even when doing an upgrade. The baselayout-1 stuff has been converted, however it is recommended to not use this until baselayout-2 is available in Gentoo stage3s as I don't want to support converting, or you can do this: stage4 tarball support. I'm not sure why I didn't support this before. Now not only can stage4 tarballs be build, instead of or in addition to virtual appliance images, but stage4 tarballs can also be used in lieu of a stage3. There is a new "stage4" make target, and also when building the Makefile will first look for stage4/<appliance>-stage4.tar.bz2 and if that exists use it instead of the Gentoo stage3. If you specify stage4 as a target and also already have a stage4, then the Makefile will unpack the stage4 into the chroot, perform updates, and then re-create the stage4 based on the updates (atomically). In addition there is a new Makefile variable, SOFTWARE. The default value is "1" meaning it will call the software target (thereby installing/updatein software), but if you set SOFTWARE=0, then the software phase will not be run. This can allow, for example, to build a VM image from a stage4 without performing software updates, in effect a straight stage4 to image for quick image building. Since most appliances are pretty much based on the "base" appliance, one could imply copy the base stage4 to the new appliance stage4 and start from there, instead of having to start from a vanilla stage3, for example: # cp stage4/base-stage4.tar.bz2 stage4/kde-stage4.tar.bz2 # make APPLIANCE=kde stage4 Will take the already existing base stage4 and simply update it to kde, which will be easier/faster than starting from a stage3. There are still some tweaks that need to be done for the stage4 support. Specifically Makefile targets need to be written with the assumption that they may be called more than once (e.g. updating a stage4 or going from stage4 to image with SOFTWARE=1). For the most part things work according to that assumption, but there are a few things that need to be tweeked, such as the inittab settings if one is building a "headed" image but it's based off a headless stage4. New appliance authors should also write their "preinstall" and "postinstall" targets with the assmption that it may be called more than once.
2011-05-18 02:44:04 +02:00
SOFTWARE = 1
PKGLIST = 0
I learned a lot about Makefiles :D So, basically I re-architeched things a bit: The appliance/Makefile.inc fiels are now appliance/Makefile (again). The main Makefile will call "make -C appliance preinstall" and "postinstall" (and in future "clean"). So I got rid of the ugly make variables/include thing. Some of the main Makefile's variables are exported to the sub-makes. Appliances don't really need $(APPLIANCE) anymore as the appliance directory is their CWD. Added some new targets and smarter targets. I can do more with this, but it's a big improvment from last time. Still learning a lot of Makefile magic (been reading other people's Makefiles). Verified that "make -j3" works (at least on the base appliance) but will kill your hard drive :D Introduced "profiles" Which are files with variables you want to override. The file will be "include"ed by the main Makefile. For example, I have a file, "local.cfg" that looks like this: --- 8< ----------------------------- CHROOT = /var/scratch/marduk/vabuild HEADLESS = YES PRUNE_CRITICAL = NO VIRTIO = YES TIMEZONE = EST5EDT DISK_SIZE = 60.0G SWAP_SIZE = 48 PKGDIR = /var/scratch/packages NBD_DEV = /dev/nbd8 all: qcow --- 8< ------------------------------ Then, e.g. i can run "make PROFILE=local APPLIANCE=kde". If you don't specify a PROFILE variable, then it will default to the empty string, which means the main Makefile will attempt to include .cfg So, for example i have: $ ln -s local.cfg .cfg $ make APPLIANCE=kde Don't set PROFILE inside your .cfg file (why would you?). Also, if the [pro]file does not exist, the include fails silently. I will put this info in the wiki eventually...
2010-11-14 00:22:18 +01:00
ACCEPT_KEYWORDS = amd64
DASH = NO
I learned a lot about Makefiles :D So, basically I re-architeched things a bit: The appliance/Makefile.inc fiels are now appliance/Makefile (again). The main Makefile will call "make -C appliance preinstall" and "postinstall" (and in future "clean"). So I got rid of the ugly make variables/include thing. Some of the main Makefile's variables are exported to the sub-makes. Appliances don't really need $(APPLIANCE) anymore as the appliance directory is their CWD. Added some new targets and smarter targets. I can do more with this, but it's a big improvment from last time. Still learning a lot of Makefile magic (been reading other people's Makefiles). Verified that "make -j3" works (at least on the base appliance) but will kill your hard drive :D Introduced "profiles" Which are files with variables you want to override. The file will be "include"ed by the main Makefile. For example, I have a file, "local.cfg" that looks like this: --- 8< ----------------------------- CHROOT = /var/scratch/marduk/vabuild HEADLESS = YES PRUNE_CRITICAL = NO VIRTIO = YES TIMEZONE = EST5EDT DISK_SIZE = 60.0G SWAP_SIZE = 48 PKGDIR = /var/scratch/packages NBD_DEV = /dev/nbd8 all: qcow --- 8< ------------------------------ Then, e.g. i can run "make PROFILE=local APPLIANCE=kde". If you don't specify a PROFILE variable, then it will default to the empty string, which means the main Makefile will attempt to include .cfg So, for example i have: $ ln -s local.cfg .cfg $ make APPLIANCE=kde Don't set PROFILE inside your .cfg file (why would you?). Also, if the [pro]file does not exist, the include fails silently. I will put this info in the wiki eventually...
2010-11-14 00:22:18 +01:00
M4 = m4
2012-05-25 18:33:40 +02:00
EMERGE = /usr/bin/emerge --jobs=4
I learned a lot about Makefiles :D So, basically I re-architeched things a bit: The appliance/Makefile.inc fiels are now appliance/Makefile (again). The main Makefile will call "make -C appliance preinstall" and "postinstall" (and in future "clean"). So I got rid of the ugly make variables/include thing. Some of the main Makefile's variables are exported to the sub-makes. Appliances don't really need $(APPLIANCE) anymore as the appliance directory is their CWD. Added some new targets and smarter targets. I can do more with this, but it's a big improvment from last time. Still learning a lot of Makefile magic (been reading other people's Makefiles). Verified that "make -j3" works (at least on the base appliance) but will kill your hard drive :D Introduced "profiles" Which are files with variables you want to override. The file will be "include"ed by the main Makefile. For example, I have a file, "local.cfg" that looks like this: --- 8< ----------------------------- CHROOT = /var/scratch/marduk/vabuild HEADLESS = YES PRUNE_CRITICAL = NO VIRTIO = YES TIMEZONE = EST5EDT DISK_SIZE = 60.0G SWAP_SIZE = 48 PKGDIR = /var/scratch/packages NBD_DEV = /dev/nbd8 all: qcow --- 8< ------------------------------ Then, e.g. i can run "make PROFILE=local APPLIANCE=kde". If you don't specify a PROFILE variable, then it will default to the empty string, which means the main Makefile will attempt to include .cfg So, for example i have: $ ln -s local.cfg .cfg $ make APPLIANCE=kde Don't set PROFILE inside your .cfg file (why would you?). Also, if the [pro]file does not exist, the include fails silently. I will put this info in the wiki eventually...
2010-11-14 00:22:18 +01:00
M4_DEFS = -D HOSTNAME=$(HOSTNAME)
M4C = $(M4) $(M4_DEFS)
NBD_DEV = /dev/nbd0
USEPKG = --usepkg --binpkg-respect-use=y
RSYNC_MIRROR = rsync://rsync.gtlib.gatech.edu/gentoo/
EMERGE_RSYNC = NO
I learned a lot about Makefiles :D So, basically I re-architeched things a bit: The appliance/Makefile.inc fiels are now appliance/Makefile (again). The main Makefile will call "make -C appliance preinstall" and "postinstall" (and in future "clean"). So I got rid of the ugly make variables/include thing. Some of the main Makefile's variables are exported to the sub-makes. Appliances don't really need $(APPLIANCE) anymore as the appliance directory is their CWD. Added some new targets and smarter targets. I can do more with this, but it's a big improvment from last time. Still learning a lot of Makefile magic (been reading other people's Makefiles). Verified that "make -j3" works (at least on the base appliance) but will kill your hard drive :D Introduced "profiles" Which are files with variables you want to override. The file will be "include"ed by the main Makefile. For example, I have a file, "local.cfg" that looks like this: --- 8< ----------------------------- CHROOT = /var/scratch/marduk/vabuild HEADLESS = YES PRUNE_CRITICAL = NO VIRTIO = YES TIMEZONE = EST5EDT DISK_SIZE = 60.0G SWAP_SIZE = 48 PKGDIR = /var/scratch/packages NBD_DEV = /dev/nbd8 all: qcow --- 8< ------------------------------ Then, e.g. i can run "make PROFILE=local APPLIANCE=kde". If you don't specify a PROFILE variable, then it will default to the empty string, which means the main Makefile will attempt to include .cfg So, for example i have: $ ln -s local.cfg .cfg $ make APPLIANCE=kde Don't set PROFILE inside your .cfg file (why would you?). Also, if the [pro]file does not exist, the include fails silently. I will put this info in the wiki eventually...
2010-11-14 00:22:18 +01:00
KERNEL = gentoo-sources
PACKAGE_FILES = $(wildcard $(APPLIANCE)/package.*)
I learned a lot about Makefiles :D So, basically I re-architeched things a bit: The appliance/Makefile.inc fiels are now appliance/Makefile (again). The main Makefile will call "make -C appliance preinstall" and "postinstall" (and in future "clean"). So I got rid of the ugly make variables/include thing. Some of the main Makefile's variables are exported to the sub-makes. Appliances don't really need $(APPLIANCE) anymore as the appliance directory is their CWD. Added some new targets and smarter targets. I can do more with this, but it's a big improvment from last time. Still learning a lot of Makefile magic (been reading other people's Makefiles). Verified that "make -j3" works (at least on the base appliance) but will kill your hard drive :D Introduced "profiles" Which are files with variables you want to override. The file will be "include"ed by the main Makefile. For example, I have a file, "local.cfg" that looks like this: --- 8< ----------------------------- CHROOT = /var/scratch/marduk/vabuild HEADLESS = YES PRUNE_CRITICAL = NO VIRTIO = YES TIMEZONE = EST5EDT DISK_SIZE = 60.0G SWAP_SIZE = 48 PKGDIR = /var/scratch/packages NBD_DEV = /dev/nbd8 all: qcow --- 8< ------------------------------ Then, e.g. i can run "make PROFILE=local APPLIANCE=kde". If you don't specify a PROFILE variable, then it will default to the empty string, which means the main Makefile will attempt to include .cfg So, for example i have: $ ln -s local.cfg .cfg $ make APPLIANCE=kde Don't set PROFILE inside your .cfg file (why would you?). Also, if the [pro]file does not exist, the include fails silently. I will put this info in the wiki eventually...
2010-11-14 00:22:18 +01:00
WORLD = $(APPLIANCE)/world
EXTRA_WORLD =
I learned a lot about Makefiles :D So, basically I re-architeched things a bit: The appliance/Makefile.inc fiels are now appliance/Makefile (again). The main Makefile will call "make -C appliance preinstall" and "postinstall" (and in future "clean"). So I got rid of the ugly make variables/include thing. Some of the main Makefile's variables are exported to the sub-makes. Appliances don't really need $(APPLIANCE) anymore as the appliance directory is their CWD. Added some new targets and smarter targets. I can do more with this, but it's a big improvment from last time. Still learning a lot of Makefile magic (been reading other people's Makefiles). Verified that "make -j3" works (at least on the base appliance) but will kill your hard drive :D Introduced "profiles" Which are files with variables you want to override. The file will be "include"ed by the main Makefile. For example, I have a file, "local.cfg" that looks like this: --- 8< ----------------------------- CHROOT = /var/scratch/marduk/vabuild HEADLESS = YES PRUNE_CRITICAL = NO VIRTIO = YES TIMEZONE = EST5EDT DISK_SIZE = 60.0G SWAP_SIZE = 48 PKGDIR = /var/scratch/packages NBD_DEV = /dev/nbd8 all: qcow --- 8< ------------------------------ Then, e.g. i can run "make PROFILE=local APPLIANCE=kde". If you don't specify a PROFILE variable, then it will default to the empty string, which means the main Makefile will attempt to include .cfg So, for example i have: $ ln -s local.cfg .cfg $ make APPLIANCE=kde Don't set PROFILE inside your .cfg file (why would you?). Also, if the [pro]file does not exist, the include fails silently. I will put this info in the wiki eventually...
2010-11-14 00:22:18 +01:00
CRITICAL = $(APPLIANCE)/critical
# Allow appliance to override variables
Baselayout-2/openrc compatibility and stage4 tarballs. The first major change here is the support of baselayout-2/openrc. So far Gentoo has not released a stage3 tarball with baselayout-2, but I've tested this enough that I feel it works even when doing an upgrade. The baselayout-1 stuff has been converted, however it is recommended to not use this until baselayout-2 is available in Gentoo stage3s as I don't want to support converting, or you can do this: stage4 tarball support. I'm not sure why I didn't support this before. Now not only can stage4 tarballs be build, instead of or in addition to virtual appliance images, but stage4 tarballs can also be used in lieu of a stage3. There is a new "stage4" make target, and also when building the Makefile will first look for stage4/<appliance>-stage4.tar.bz2 and if that exists use it instead of the Gentoo stage3. If you specify stage4 as a target and also already have a stage4, then the Makefile will unpack the stage4 into the chroot, perform updates, and then re-create the stage4 based on the updates (atomically). In addition there is a new Makefile variable, SOFTWARE. The default value is "1" meaning it will call the software target (thereby installing/updatein software), but if you set SOFTWARE=0, then the software phase will not be run. This can allow, for example, to build a VM image from a stage4 without performing software updates, in effect a straight stage4 to image for quick image building. Since most appliances are pretty much based on the "base" appliance, one could imply copy the base stage4 to the new appliance stage4 and start from there, instead of having to start from a vanilla stage3, for example: # cp stage4/base-stage4.tar.bz2 stage4/kde-stage4.tar.bz2 # make APPLIANCE=kde stage4 Will take the already existing base stage4 and simply update it to kde, which will be easier/faster than starting from a stage3. There are still some tweaks that need to be done for the stage4 support. Specifically Makefile targets need to be written with the assumption that they may be called more than once (e.g. updating a stage4 or going from stage4 to image with SOFTWARE=1). For the most part things work according to that assumption, but there are a few things that need to be tweeked, such as the inittab settings if one is building a "headed" image but it's based off a headless stage4. New appliance authors should also write their "preinstall" and "postinstall" targets with the assmption that it may be called more than once.
2011-05-18 02:44:04 +02:00
-include $(APPLIANCE)/$(APPLIANCE).cfg
# Allow user to override variables
-include $(profile).cfg
I learned a lot about Makefiles :D So, basically I re-architeched things a bit: The appliance/Makefile.inc fiels are now appliance/Makefile (again). The main Makefile will call "make -C appliance preinstall" and "postinstall" (and in future "clean"). So I got rid of the ugly make variables/include thing. Some of the main Makefile's variables are exported to the sub-makes. Appliances don't really need $(APPLIANCE) anymore as the appliance directory is their CWD. Added some new targets and smarter targets. I can do more with this, but it's a big improvment from last time. Still learning a lot of Makefile magic (been reading other people's Makefiles). Verified that "make -j3" works (at least on the base appliance) but will kill your hard drive :D Introduced "profiles" Which are files with variables you want to override. The file will be "include"ed by the main Makefile. For example, I have a file, "local.cfg" that looks like this: --- 8< ----------------------------- CHROOT = /var/scratch/marduk/vabuild HEADLESS = YES PRUNE_CRITICAL = NO VIRTIO = YES TIMEZONE = EST5EDT DISK_SIZE = 60.0G SWAP_SIZE = 48 PKGDIR = /var/scratch/packages NBD_DEV = /dev/nbd8 all: qcow --- 8< ------------------------------ Then, e.g. i can run "make PROFILE=local APPLIANCE=kde". If you don't specify a PROFILE variable, then it will default to the empty string, which means the main Makefile will attempt to include .cfg So, for example i have: $ ln -s local.cfg .cfg $ make APPLIANCE=kde Don't set PROFILE inside your .cfg file (why would you?). Also, if the [pro]file does not exist, the include fails silently. I will put this info in the wiki eventually...
2010-11-14 00:22:18 +01:00
inroot := chroot $(CHROOT)
ifeq ($(ARCH),x86)
inroot := linux32 $(inroot)
endif
stage4-exists := $(wildcard $(STAGE4_TARBALL))
software-deps := stage3
Baselayout-2/openrc compatibility and stage4 tarballs. The first major change here is the support of baselayout-2/openrc. So far Gentoo has not released a stage3 tarball with baselayout-2, but I've tested this enough that I feel it works even when doing an upgrade. The baselayout-1 stuff has been converted, however it is recommended to not use this until baselayout-2 is available in Gentoo stage3s as I don't want to support converting, or you can do this: stage4 tarball support. I'm not sure why I didn't support this before. Now not only can stage4 tarballs be build, instead of or in addition to virtual appliance images, but stage4 tarballs can also be used in lieu of a stage3. There is a new "stage4" make target, and also when building the Makefile will first look for stage4/<appliance>-stage4.tar.bz2 and if that exists use it instead of the Gentoo stage3. If you specify stage4 as a target and also already have a stage4, then the Makefile will unpack the stage4 into the chroot, perform updates, and then re-create the stage4 based on the updates (atomically). In addition there is a new Makefile variable, SOFTWARE. The default value is "1" meaning it will call the software target (thereby installing/updatein software), but if you set SOFTWARE=0, then the software phase will not be run. This can allow, for example, to build a VM image from a stage4 without performing software updates, in effect a straight stage4 to image for quick image building. Since most appliances are pretty much based on the "base" appliance, one could imply copy the base stage4 to the new appliance stage4 and start from there, instead of having to start from a vanilla stage3, for example: # cp stage4/base-stage4.tar.bz2 stage4/kde-stage4.tar.bz2 # make APPLIANCE=kde stage4 Will take the already existing base stage4 and simply update it to kde, which will be easier/faster than starting from a stage3. There are still some tweaks that need to be done for the stage4 support. Specifically Makefile targets need to be written with the assumption that they may be called more than once (e.g. updating a stage4 or going from stage4 to image with SOFTWARE=1). For the most part things work according to that assumption, but there are a few things that need to be tweeked, such as the inittab settings if one is building a "headed" image but it's based off a headless stage4. New appliance authors should also write their "preinstall" and "postinstall" targets with the assmption that it may be called more than once.
2011-05-18 02:44:04 +02:00
ifneq ($(SOFTWARE),0)
software-deps += build-software
Baselayout-2/openrc compatibility and stage4 tarballs. The first major change here is the support of baselayout-2/openrc. So far Gentoo has not released a stage3 tarball with baselayout-2, but I've tested this enough that I feel it works even when doing an upgrade. The baselayout-1 stuff has been converted, however it is recommended to not use this until baselayout-2 is available in Gentoo stage3s as I don't want to support converting, or you can do this: stage4 tarball support. I'm not sure why I didn't support this before. Now not only can stage4 tarballs be build, instead of or in addition to virtual appliance images, but stage4 tarballs can also be used in lieu of a stage3. There is a new "stage4" make target, and also when building the Makefile will first look for stage4/<appliance>-stage4.tar.bz2 and if that exists use it instead of the Gentoo stage3. If you specify stage4 as a target and also already have a stage4, then the Makefile will unpack the stage4 into the chroot, perform updates, and then re-create the stage4 based on the updates (atomically). In addition there is a new Makefile variable, SOFTWARE. The default value is "1" meaning it will call the software target (thereby installing/updatein software), but if you set SOFTWARE=0, then the software phase will not be run. This can allow, for example, to build a VM image from a stage4 without performing software updates, in effect a straight stage4 to image for quick image building. Since most appliances are pretty much based on the "base" appliance, one could imply copy the base stage4 to the new appliance stage4 and start from there, instead of having to start from a vanilla stage3, for example: # cp stage4/base-stage4.tar.bz2 stage4/kde-stage4.tar.bz2 # make APPLIANCE=kde stage4 Will take the already existing base stage4 and simply update it to kde, which will be easier/faster than starting from a stage3. There are still some tweaks that need to be done for the stage4 support. Specifically Makefile targets need to be written with the assumption that they may be called more than once (e.g. updating a stage4 or going from stage4 to image with SOFTWARE=1). For the most part things work according to that assumption, but there are a few things that need to be tweeked, such as the inittab settings if one is building a "headed" image but it's based off a headless stage4. New appliance authors should also write their "preinstall" and "postinstall" targets with the assmption that it may be called more than once.
2011-05-18 02:44:04 +02:00
endif
I learned a lot about Makefiles :D So, basically I re-architeched things a bit: The appliance/Makefile.inc fiels are now appliance/Makefile (again). The main Makefile will call "make -C appliance preinstall" and "postinstall" (and in future "clean"). So I got rid of the ugly make variables/include thing. Some of the main Makefile's variables are exported to the sub-makes. Appliances don't really need $(APPLIANCE) anymore as the appliance directory is their CWD. Added some new targets and smarter targets. I can do more with this, but it's a big improvment from last time. Still learning a lot of Makefile magic (been reading other people's Makefiles). Verified that "make -j3" works (at least on the base appliance) but will kill your hard drive :D Introduced "profiles" Which are files with variables you want to override. The file will be "include"ed by the main Makefile. For example, I have a file, "local.cfg" that looks like this: --- 8< ----------------------------- CHROOT = /var/scratch/marduk/vabuild HEADLESS = YES PRUNE_CRITICAL = NO VIRTIO = YES TIMEZONE = EST5EDT DISK_SIZE = 60.0G SWAP_SIZE = 48 PKGDIR = /var/scratch/packages NBD_DEV = /dev/nbd8 all: qcow --- 8< ------------------------------ Then, e.g. i can run "make PROFILE=local APPLIANCE=kde". If you don't specify a PROFILE variable, then it will default to the empty string, which means the main Makefile will attempt to include .cfg So, for example i have: $ ln -s local.cfg .cfg $ make APPLIANCE=kde Don't set PROFILE inside your .cfg file (why would you?). Also, if the [pro]file does not exist, the include fails silently. I will put this info in the wiki eventually...
2010-11-14 00:22:18 +01:00
ifeq ($(PRUNE_CRITICAL),YES)
Baselayout-2/openrc compatibility and stage4 tarballs. The first major change here is the support of baselayout-2/openrc. So far Gentoo has not released a stage3 tarball with baselayout-2, but I've tested this enough that I feel it works even when doing an upgrade. The baselayout-1 stuff has been converted, however it is recommended to not use this until baselayout-2 is available in Gentoo stage3s as I don't want to support converting, or you can do this: stage4 tarball support. I'm not sure why I didn't support this before. Now not only can stage4 tarballs be build, instead of or in addition to virtual appliance images, but stage4 tarballs can also be used in lieu of a stage3. There is a new "stage4" make target, and also when building the Makefile will first look for stage4/<appliance>-stage4.tar.bz2 and if that exists use it instead of the Gentoo stage3. If you specify stage4 as a target and also already have a stage4, then the Makefile will unpack the stage4 into the chroot, perform updates, and then re-create the stage4 based on the updates (atomically). In addition there is a new Makefile variable, SOFTWARE. The default value is "1" meaning it will call the software target (thereby installing/updatein software), but if you set SOFTWARE=0, then the software phase will not be run. This can allow, for example, to build a VM image from a stage4 without performing software updates, in effect a straight stage4 to image for quick image building. Since most appliances are pretty much based on the "base" appliance, one could imply copy the base stage4 to the new appliance stage4 and start from there, instead of having to start from a vanilla stage3, for example: # cp stage4/base-stage4.tar.bz2 stage4/kde-stage4.tar.bz2 # make APPLIANCE=kde stage4 Will take the already existing base stage4 and simply update it to kde, which will be easier/faster than starting from a stage3. There are still some tweaks that need to be done for the stage4 support. Specifically Makefile targets need to be written with the assumption that they may be called more than once (e.g. updating a stage4 or going from stage4 to image with SOFTWARE=1). For the most part things work according to that assumption, but there are a few things that need to be tweeked, such as the inittab settings if one is building a "headed" image but it's based off a headless stage4. New appliance authors should also write their "preinstall" and "postinstall" targets with the assmption that it may be called more than once.
2011-05-18 02:44:04 +02:00
COPY_ARGS = --exclude-from=rsync-excludes \
--exclude-from=rsync-excludes-critical
I learned a lot about Makefiles :D So, basically I re-architeched things a bit: The appliance/Makefile.inc fiels are now appliance/Makefile (again). The main Makefile will call "make -C appliance preinstall" and "postinstall" (and in future "clean"). So I got rid of the ugly make variables/include thing. Some of the main Makefile's variables are exported to the sub-makes. Appliances don't really need $(APPLIANCE) anymore as the appliance directory is their CWD. Added some new targets and smarter targets. I can do more with this, but it's a big improvment from last time. Still learning a lot of Makefile magic (been reading other people's Makefiles). Verified that "make -j3" works (at least on the base appliance) but will kill your hard drive :D Introduced "profiles" Which are files with variables you want to override. The file will be "include"ed by the main Makefile. For example, I have a file, "local.cfg" that looks like this: --- 8< ----------------------------- CHROOT = /var/scratch/marduk/vabuild HEADLESS = YES PRUNE_CRITICAL = NO VIRTIO = YES TIMEZONE = EST5EDT DISK_SIZE = 60.0G SWAP_SIZE = 48 PKGDIR = /var/scratch/packages NBD_DEV = /dev/nbd8 all: qcow --- 8< ------------------------------ Then, e.g. i can run "make PROFILE=local APPLIANCE=kde". If you don't specify a PROFILE variable, then it will default to the empty string, which means the main Makefile will attempt to include .cfg So, for example i have: $ ln -s local.cfg .cfg $ make APPLIANCE=kde Don't set PROFILE inside your .cfg file (why would you?). Also, if the [pro]file does not exist, the include fails silently. I will put this info in the wiki eventually...
2010-11-14 00:22:18 +01:00
else
Baselayout-2/openrc compatibility and stage4 tarballs. The first major change here is the support of baselayout-2/openrc. So far Gentoo has not released a stage3 tarball with baselayout-2, but I've tested this enough that I feel it works even when doing an upgrade. The baselayout-1 stuff has been converted, however it is recommended to not use this until baselayout-2 is available in Gentoo stage3s as I don't want to support converting, or you can do this: stage4 tarball support. I'm not sure why I didn't support this before. Now not only can stage4 tarballs be build, instead of or in addition to virtual appliance images, but stage4 tarballs can also be used in lieu of a stage3. There is a new "stage4" make target, and also when building the Makefile will first look for stage4/<appliance>-stage4.tar.bz2 and if that exists use it instead of the Gentoo stage3. If you specify stage4 as a target and also already have a stage4, then the Makefile will unpack the stage4 into the chroot, perform updates, and then re-create the stage4 based on the updates (atomically). In addition there is a new Makefile variable, SOFTWARE. The default value is "1" meaning it will call the software target (thereby installing/updatein software), but if you set SOFTWARE=0, then the software phase will not be run. This can allow, for example, to build a VM image from a stage4 without performing software updates, in effect a straight stage4 to image for quick image building. Since most appliances are pretty much based on the "base" appliance, one could imply copy the base stage4 to the new appliance stage4 and start from there, instead of having to start from a vanilla stage3, for example: # cp stage4/base-stage4.tar.bz2 stage4/kde-stage4.tar.bz2 # make APPLIANCE=kde stage4 Will take the already existing base stage4 and simply update it to kde, which will be easier/faster than starting from a stage3. There are still some tweaks that need to be done for the stage4 support. Specifically Makefile targets need to be written with the assumption that they may be called more than once (e.g. updating a stage4 or going from stage4 to image with SOFTWARE=1). For the most part things work according to that assumption, but there are a few things that need to be tweeked, such as the inittab settings if one is building a "headed" image but it's based off a headless stage4. New appliance authors should also write their "preinstall" and "postinstall" targets with the assmption that it may be called more than once.
2011-05-18 02:44:04 +02:00
COPY_ARGS = --exclude-from=rsync-excludes
I learned a lot about Makefiles :D So, basically I re-architeched things a bit: The appliance/Makefile.inc fiels are now appliance/Makefile (again). The main Makefile will call "make -C appliance preinstall" and "postinstall" (and in future "clean"). So I got rid of the ugly make variables/include thing. Some of the main Makefile's variables are exported to the sub-makes. Appliances don't really need $(APPLIANCE) anymore as the appliance directory is their CWD. Added some new targets and smarter targets. I can do more with this, but it's a big improvment from last time. Still learning a lot of Makefile magic (been reading other people's Makefiles). Verified that "make -j3" works (at least on the base appliance) but will kill your hard drive :D Introduced "profiles" Which are files with variables you want to override. The file will be "include"ed by the main Makefile. For example, I have a file, "local.cfg" that looks like this: --- 8< ----------------------------- CHROOT = /var/scratch/marduk/vabuild HEADLESS = YES PRUNE_CRITICAL = NO VIRTIO = YES TIMEZONE = EST5EDT DISK_SIZE = 60.0G SWAP_SIZE = 48 PKGDIR = /var/scratch/packages NBD_DEV = /dev/nbd8 all: qcow --- 8< ------------------------------ Then, e.g. i can run "make PROFILE=local APPLIANCE=kde". If you don't specify a PROFILE variable, then it will default to the empty string, which means the main Makefile will attempt to include .cfg So, for example i have: $ ln -s local.cfg .cfg $ make APPLIANCE=kde Don't set PROFILE inside your .cfg file (why would you?). Also, if the [pro]file does not exist, the include fails silently. I will put this info in the wiki eventually...
2010-11-14 00:22:18 +01:00
endif
ifeq ($(REMOVE_PORTAGE_TREE),YES)
COPY_ARGS += --exclude=usr/portage
endif
ifeq ($(CHANGE_PASSWORD),YES)
ifdef ROOT_PASSWORD
change_password = $(inroot) usermod -p '$(ROOT_PASSWORD)' root
else
change_password = $(inroot) passwd -d root; $(inroot) passwd -e root
endif
endif
gcc_config = $(inroot) gcc-config 1
export APPLIANCE ACCEPT_KEYWORDS CHROOT EMERGE HEADLESS M4 M4C inroot
2010-11-30 03:29:04 +01:00
export HOSTNAME MAKEOPTS PRUNE_CRITICAL TIMEZONE USEPKG WORLD OVERLAY
I learned a lot about Makefiles :D So, basically I re-architeched things a bit: The appliance/Makefile.inc fiels are now appliance/Makefile (again). The main Makefile will call "make -C appliance preinstall" and "postinstall" (and in future "clean"). So I got rid of the ugly make variables/include thing. Some of the main Makefile's variables are exported to the sub-makes. Appliances don't really need $(APPLIANCE) anymore as the appliance directory is their CWD. Added some new targets and smarter targets. I can do more with this, but it's a big improvment from last time. Still learning a lot of Makefile magic (been reading other people's Makefiles). Verified that "make -j3" works (at least on the base appliance) but will kill your hard drive :D Introduced "profiles" Which are files with variables you want to override. The file will be "include"ed by the main Makefile. For example, I have a file, "local.cfg" that looks like this: --- 8< ----------------------------- CHROOT = /var/scratch/marduk/vabuild HEADLESS = YES PRUNE_CRITICAL = NO VIRTIO = YES TIMEZONE = EST5EDT DISK_SIZE = 60.0G SWAP_SIZE = 48 PKGDIR = /var/scratch/packages NBD_DEV = /dev/nbd8 all: qcow --- 8< ------------------------------ Then, e.g. i can run "make PROFILE=local APPLIANCE=kde". If you don't specify a PROFILE variable, then it will default to the empty string, which means the main Makefile will attempt to include .cfg So, for example i have: $ ln -s local.cfg .cfg $ make APPLIANCE=kde Don't set PROFILE inside your .cfg file (why would you?). Also, if the [pro]file does not exist, the include fails silently. I will put this info in the wiki eventually...
2010-11-14 00:22:18 +01:00
unexport PKGDIR ARCH NBD_DEV
2010-07-09 05:22:37 +02:00
all: image
$(RAW_IMAGE):
qemu-img create -f raw $(RAW_IMAGE) $(DISK_SIZE)
partitions: $(RAW_IMAGE)
@./echo Creating partition layout
2011-10-04 18:36:19 +02:00
parted -s $(RAW_IMAGE) mklabel gpt
parted -s $(RAW_IMAGE) mkpart primary 1 $(DISK_SIZE)
I learned a lot about Makefiles :D So, basically I re-architeched things a bit: The appliance/Makefile.inc fiels are now appliance/Makefile (again). The main Makefile will call "make -C appliance preinstall" and "postinstall" (and in future "clean"). So I got rid of the ugly make variables/include thing. Some of the main Makefile's variables are exported to the sub-makes. Appliances don't really need $(APPLIANCE) anymore as the appliance directory is their CWD. Added some new targets and smarter targets. I can do more with this, but it's a big improvment from last time. Still learning a lot of Makefile magic (been reading other people's Makefiles). Verified that "make -j3" works (at least on the base appliance) but will kill your hard drive :D Introduced "profiles" Which are files with variables you want to override. The file will be "include"ed by the main Makefile. For example, I have a file, "local.cfg" that looks like this: --- 8< ----------------------------- CHROOT = /var/scratch/marduk/vabuild HEADLESS = YES PRUNE_CRITICAL = NO VIRTIO = YES TIMEZONE = EST5EDT DISK_SIZE = 60.0G SWAP_SIZE = 48 PKGDIR = /var/scratch/packages NBD_DEV = /dev/nbd8 all: qcow --- 8< ------------------------------ Then, e.g. i can run "make PROFILE=local APPLIANCE=kde". If you don't specify a PROFILE variable, then it will default to the empty string, which means the main Makefile will attempt to include .cfg So, for example i have: $ ln -s local.cfg .cfg $ make APPLIANCE=kde Don't set PROFILE inside your .cfg file (why would you?). Also, if the [pro]file does not exist, the include fails silently. I will put this info in the wiki eventually...
2010-11-14 00:22:18 +01:00
parted -s $(RAW_IMAGE) set 1 boot on
qemu-nbd -c $(NBD_DEV) "`realpath $(RAW_IMAGE)`"
sleep 3
mkfs.ext4 -O sparse_super,^has_journal -L "$(APPLIANCE)"_root -m 0 $(NBD_DEV)p1
2010-07-09 05:22:37 +02:00
touch partitions
I learned a lot about Makefiles :D So, basically I re-architeched things a bit: The appliance/Makefile.inc fiels are now appliance/Makefile (again). The main Makefile will call "make -C appliance preinstall" and "postinstall" (and in future "clean"). So I got rid of the ugly make variables/include thing. Some of the main Makefile's variables are exported to the sub-makes. Appliances don't really need $(APPLIANCE) anymore as the appliance directory is their CWD. Added some new targets and smarter targets. I can do more with this, but it's a big improvment from last time. Still learning a lot of Makefile magic (been reading other people's Makefiles). Verified that "make -j3" works (at least on the base appliance) but will kill your hard drive :D Introduced "profiles" Which are files with variables you want to override. The file will be "include"ed by the main Makefile. For example, I have a file, "local.cfg" that looks like this: --- 8< ----------------------------- CHROOT = /var/scratch/marduk/vabuild HEADLESS = YES PRUNE_CRITICAL = NO VIRTIO = YES TIMEZONE = EST5EDT DISK_SIZE = 60.0G SWAP_SIZE = 48 PKGDIR = /var/scratch/packages NBD_DEV = /dev/nbd8 all: qcow --- 8< ------------------------------ Then, e.g. i can run "make PROFILE=local APPLIANCE=kde". If you don't specify a PROFILE variable, then it will default to the empty string, which means the main Makefile will attempt to include .cfg So, for example i have: $ ln -s local.cfg .cfg $ make APPLIANCE=kde Don't set PROFILE inside your .cfg file (why would you?). Also, if the [pro]file does not exist, the include fails silently. I will put this info in the wiki eventually...
2010-11-14 00:22:18 +01:00
mounts: stage3
@./echo Creating chroot in $(CHROOT)
I learned a lot about Makefiles :D So, basically I re-architeched things a bit: The appliance/Makefile.inc fiels are now appliance/Makefile (again). The main Makefile will call "make -C appliance preinstall" and "postinstall" (and in future "clean"). So I got rid of the ugly make variables/include thing. Some of the main Makefile's variables are exported to the sub-makes. Appliances don't really need $(APPLIANCE) anymore as the appliance directory is their CWD. Added some new targets and smarter targets. I can do more with this, but it's a big improvment from last time. Still learning a lot of Makefile magic (been reading other people's Makefiles). Verified that "make -j3" works (at least on the base appliance) but will kill your hard drive :D Introduced "profiles" Which are files with variables you want to override. The file will be "include"ed by the main Makefile. For example, I have a file, "local.cfg" that looks like this: --- 8< ----------------------------- CHROOT = /var/scratch/marduk/vabuild HEADLESS = YES PRUNE_CRITICAL = NO VIRTIO = YES TIMEZONE = EST5EDT DISK_SIZE = 60.0G SWAP_SIZE = 48 PKGDIR = /var/scratch/packages NBD_DEV = /dev/nbd8 all: qcow --- 8< ------------------------------ Then, e.g. i can run "make PROFILE=local APPLIANCE=kde". If you don't specify a PROFILE variable, then it will default to the empty string, which means the main Makefile will attempt to include .cfg So, for example i have: $ ln -s local.cfg .cfg $ make APPLIANCE=kde Don't set PROFILE inside your .cfg file (why would you?). Also, if the [pro]file does not exist, the include fails silently. I will put this info in the wiki eventually...
2010-11-14 00:22:18 +01:00
mkdir -p $(CHROOT)
if [ ! -e mounts ] ; then \
2010-07-10 02:22:55 +02:00
mount -t proc none $(CHROOT)/proc; \
mount -o bind /dev $(CHROOT)/dev; \
mount -o bind /var/tmp $(CHROOT)/var/tmp; \
fi
touch mounts
2013-08-25 11:24:46 +02:00
portage-snapshot.tar.bz2:
@./echo You do not have a portage snapshot. Consider \"make sync_portage\"
@exit 1
sync_portage:
@./echo Grabbing latest portage snapshot
2013-08-25 11:24:46 +02:00
rsync --no-motd -L $(RSYNC_MIRROR)/snapshots/portage-latest.tar.bz2 portage-snapshot.tar.bz2
2013-08-25 11:24:46 +02:00
portage: portage-snapshot.tar.bz2 stage3
@./echo Unpacking portage snapshot
rm -rf $(CHROOT)/usr/portage
2013-08-25 11:24:46 +02:00
tar xjf portage-snapshot.tar.bz2 -C $(CHROOT)/usr
ifeq ($(EMERGE_RSYNC),YES)
@./echo Syncing portage tree
$(inroot) emerge --sync --quiet
endif
ifdef PKGDIR
mkdir -p $(CHROOT)/var/portage/packages
mount -o bind "$(PKGDIR)" $(CHROOT)/var/portage/packages
endif
touch portage
preproot: stage3 mounts portage fstab
cp -L /etc/resolv.conf $(CHROOT)/etc/
Baselayout-2/openrc compatibility and stage4 tarballs. The first major change here is the support of baselayout-2/openrc. So far Gentoo has not released a stage3 tarball with baselayout-2, but I've tested this enough that I feel it works even when doing an upgrade. The baselayout-1 stuff has been converted, however it is recommended to not use this until baselayout-2 is available in Gentoo stage3s as I don't want to support converting, or you can do this: stage4 tarball support. I'm not sure why I didn't support this before. Now not only can stage4 tarballs be build, instead of or in addition to virtual appliance images, but stage4 tarballs can also be used in lieu of a stage3. There is a new "stage4" make target, and also when building the Makefile will first look for stage4/<appliance>-stage4.tar.bz2 and if that exists use it instead of the Gentoo stage3. If you specify stage4 as a target and also already have a stage4, then the Makefile will unpack the stage4 into the chroot, perform updates, and then re-create the stage4 based on the updates (atomically). In addition there is a new Makefile variable, SOFTWARE. The default value is "1" meaning it will call the software target (thereby installing/updatein software), but if you set SOFTWARE=0, then the software phase will not be run. This can allow, for example, to build a VM image from a stage4 without performing software updates, in effect a straight stage4 to image for quick image building. Since most appliances are pretty much based on the "base" appliance, one could imply copy the base stage4 to the new appliance stage4 and start from there, instead of having to start from a vanilla stage3, for example: # cp stage4/base-stage4.tar.bz2 stage4/kde-stage4.tar.bz2 # make APPLIANCE=kde stage4 Will take the already existing base stage4 and simply update it to kde, which will be easier/faster than starting from a stage3. There are still some tweaks that need to be done for the stage4 support. Specifically Makefile targets need to be written with the assumption that they may be called more than once (e.g. updating a stage4 or going from stage4 to image with SOFTWARE=1). For the most part things work according to that assumption, but there are a few things that need to be tweeked, such as the inittab settings if one is building a "headed" image but it's based off a headless stage4. New appliance authors should also write their "preinstall" and "postinstall" targets with the assmption that it may be called more than once.
2011-05-18 02:44:04 +02:00
$(inroot) sed -i 's/root:.*/root::9797:0:::::/' /etc/shadow
cp fstab $(CHROOT)/etc/fstab
echo hostname=\"$(HOSTNAME)\" > $(CHROOT)/etc/conf.d/hostname
echo $(HOSTNAME) > $(CHROOT)/etc/hostname
touch preproot
2013-08-26 23:21:17 +02:00
stage3-$(ARCH)-latest.tar.bz2:
@./echo You do not have a portage stage3 tarball. Consider \"make sync_stage3\"
@exit 1
sync_stage3:
rsync --no-motd $(RSYNC_MIRROR)/releases/`echo $(ARCH)|sed 's/i.86/x86/'`/autobuilds/latest-stage3.txt latest-stage3.txt
rsync --no-motd $(RSYNC_MIRROR)/releases/`echo $(ARCH)|sed 's/i.86/x86/'`/autobuilds/`grep stage3 latest-stage3.txt| grep -v hardened| grep -v multilib|tail -n1` stage3-$(ARCH)-latest.tar.bz2
stage3: stage3-$(ARCH)-latest.tar.bz2
2010-11-06 09:41:15 +01:00
mkdir -p $(CHROOT)
ifdef stage4-exists
@./echo Using stage4 tarball: $(STAGE4_TARBALL)
tar xapf "$(STAGE4_TARBALL)" -C $(CHROOT)
else
@./echo Using stage3 tarball
2013-08-26 23:21:17 +02:00
tar xjpf stage3-$(ARCH)-latest.tar.bz2 -C $(CHROOT)
endif
touch stage3
compile_options: portage make.conf.$(ARCH) locale.gen $(PACKAGE_FILES)
cp make.conf.$(ARCH) $(CHROOT)/etc/portage/make.conf
ifdef PKGDIR
echo PKGDIR="/var/portage/packages" >> $(CHROOT)/etc/portage/make.conf
endif
echo ACCEPT_KEYWORDS=$(ACCEPT_KEYWORDS) >> $(CHROOT)/etc/portage/make.conf
2012-12-23 08:32:28 +01:00
-[ -f "$(APPLIANCE)/make.conf" ] && cat "$(APPLIANCE)/make.conf" >> $(CHROOT)/etc/portage/make.conf
2013-07-22 15:13:55 +02:00
$(inroot) eselect profile set 1
cp locale.gen $(CHROOT)/etc/locale.gen
$(inroot) locale-gen
mkdir -p $(CHROOT)/etc/portage
ifdef PACKAGE_FILES
cp $(PACKAGE_FILES) $(CHROOT)/etc/portage/
endif
touch compile_options
base_system: mounts compile_options
touch base_system
2010-07-09 05:22:37 +02:00
kernel: base_system $(KERNEL_CONFIG) kernel.sh
$(inroot) cp /usr/share/zoneinfo/$(TIMEZONE) /etc/localtime
Baselayout-2/openrc compatibility and stage4 tarballs. The first major change here is the support of baselayout-2/openrc. So far Gentoo has not released a stage3 tarball with baselayout-2, but I've tested this enough that I feel it works even when doing an upgrade. The baselayout-1 stuff has been converted, however it is recommended to not use this until baselayout-2 is available in Gentoo stage3s as I don't want to support converting, or you can do this: stage4 tarball support. I'm not sure why I didn't support this before. Now not only can stage4 tarballs be build, instead of or in addition to virtual appliance images, but stage4 tarballs can also be used in lieu of a stage3. There is a new "stage4" make target, and also when building the Makefile will first look for stage4/<appliance>-stage4.tar.bz2 and if that exists use it instead of the Gentoo stage3. If you specify stage4 as a target and also already have a stage4, then the Makefile will unpack the stage4 into the chroot, perform updates, and then re-create the stage4 based on the updates (atomically). In addition there is a new Makefile variable, SOFTWARE. The default value is "1" meaning it will call the software target (thereby installing/updatein software), but if you set SOFTWARE=0, then the software phase will not be run. This can allow, for example, to build a VM image from a stage4 without performing software updates, in effect a straight stage4 to image for quick image building. Since most appliances are pretty much based on the "base" appliance, one could imply copy the base stage4 to the new appliance stage4 and start from there, instead of having to start from a vanilla stage3, for example: # cp stage4/base-stage4.tar.bz2 stage4/kde-stage4.tar.bz2 # make APPLIANCE=kde stage4 Will take the already existing base stage4 and simply update it to kde, which will be easier/faster than starting from a stage3. There are still some tweaks that need to be done for the stage4 support. Specifically Makefile targets need to be written with the assumption that they may be called more than once (e.g. updating a stage4 or going from stage4 to image with SOFTWARE=1). For the most part things work according to that assumption, but there are a few things that need to be tweeked, such as the inittab settings if one is building a "headed" image but it's based off a headless stage4. New appliance authors should also write their "preinstall" and "postinstall" targets with the assmption that it may be called more than once.
2011-05-18 02:44:04 +02:00
echo $(TIMEZONE) > "$(CHROOT)"/etc/timezone
ifneq ($(EXTERNAL_KERNEL),YES)
@./echo Configuring kernel
cp $(KERNEL_CONFIG) $(CHROOT)/root/kernel.config
cp kernel.sh $(CHROOT)/tmp/kernel.sh
KERNEL=$(KERNEL) EMERGE="$(EMERGE)" USEPKG="$(USEPKG)" MAKEOPTS="$(MAKEOPTS)" \
$(inroot) /bin/sh /tmp/kernel.sh
rm -f $(CHROOT)/tmp/kernel.sh
endif
touch kernel
2010-07-09 05:22:37 +02:00
I learned a lot about Makefiles :D So, basically I re-architeched things a bit: The appliance/Makefile.inc fiels are now appliance/Makefile (again). The main Makefile will call "make -C appliance preinstall" and "postinstall" (and in future "clean"). So I got rid of the ugly make variables/include thing. Some of the main Makefile's variables are exported to the sub-makes. Appliances don't really need $(APPLIANCE) anymore as the appliance directory is their CWD. Added some new targets and smarter targets. I can do more with this, but it's a big improvment from last time. Still learning a lot of Makefile magic (been reading other people's Makefiles). Verified that "make -j3" works (at least on the base appliance) but will kill your hard drive :D Introduced "profiles" Which are files with variables you want to override. The file will be "include"ed by the main Makefile. For example, I have a file, "local.cfg" that looks like this: --- 8< ----------------------------- CHROOT = /var/scratch/marduk/vabuild HEADLESS = YES PRUNE_CRITICAL = NO VIRTIO = YES TIMEZONE = EST5EDT DISK_SIZE = 60.0G SWAP_SIZE = 48 PKGDIR = /var/scratch/packages NBD_DEV = /dev/nbd8 all: qcow --- 8< ------------------------------ Then, e.g. i can run "make PROFILE=local APPLIANCE=kde". If you don't specify a PROFILE variable, then it will default to the empty string, which means the main Makefile will attempt to include .cfg So, for example i have: $ ln -s local.cfg .cfg $ make APPLIANCE=kde Don't set PROFILE inside your .cfg file (why would you?). Also, if the [pro]file does not exist, the include fails silently. I will put this info in the wiki eventually...
2010-11-14 00:22:18 +01:00
$(SWAP_FILE): preproot
ifneq ($(SWAP_SIZE),0)
@./echo Creating swap file: $(SWAP_FILE)
I learned a lot about Makefiles :D So, basically I re-architeched things a bit: The appliance/Makefile.inc fiels are now appliance/Makefile (again). The main Makefile will call "make -C appliance preinstall" and "postinstall" (and in future "clean"). So I got rid of the ugly make variables/include thing. Some of the main Makefile's variables are exported to the sub-makes. Appliances don't really need $(APPLIANCE) anymore as the appliance directory is their CWD. Added some new targets and smarter targets. I can do more with this, but it's a big improvment from last time. Still learning a lot of Makefile magic (been reading other people's Makefiles). Verified that "make -j3" works (at least on the base appliance) but will kill your hard drive :D Introduced "profiles" Which are files with variables you want to override. The file will be "include"ed by the main Makefile. For example, I have a file, "local.cfg" that looks like this: --- 8< ----------------------------- CHROOT = /var/scratch/marduk/vabuild HEADLESS = YES PRUNE_CRITICAL = NO VIRTIO = YES TIMEZONE = EST5EDT DISK_SIZE = 60.0G SWAP_SIZE = 48 PKGDIR = /var/scratch/packages NBD_DEV = /dev/nbd8 all: qcow --- 8< ------------------------------ Then, e.g. i can run "make PROFILE=local APPLIANCE=kde". If you don't specify a PROFILE variable, then it will default to the empty string, which means the main Makefile will attempt to include .cfg So, for example i have: $ ln -s local.cfg .cfg $ make APPLIANCE=kde Don't set PROFILE inside your .cfg file (why would you?). Also, if the [pro]file does not exist, the include fails silently. I will put this info in the wiki eventually...
2010-11-14 00:22:18 +01:00
dd if=/dev/zero of=$(SWAP_FILE) bs=1M count=$(SWAP_SIZE)
/sbin/mkswap $(SWAP_FILE)
else
sed -i '/swap/d' $(CHROOT)/etc/fstab
endif
I learned a lot about Makefiles :D So, basically I re-architeched things a bit: The appliance/Makefile.inc fiels are now appliance/Makefile (again). The main Makefile will call "make -C appliance preinstall" and "postinstall" (and in future "clean"). So I got rid of the ugly make variables/include thing. Some of the main Makefile's variables are exported to the sub-makes. Appliances don't really need $(APPLIANCE) anymore as the appliance directory is their CWD. Added some new targets and smarter targets. I can do more with this, but it's a big improvment from last time. Still learning a lot of Makefile magic (been reading other people's Makefiles). Verified that "make -j3" works (at least on the base appliance) but will kill your hard drive :D Introduced "profiles" Which are files with variables you want to override. The file will be "include"ed by the main Makefile. For example, I have a file, "local.cfg" that looks like this: --- 8< ----------------------------- CHROOT = /var/scratch/marduk/vabuild HEADLESS = YES PRUNE_CRITICAL = NO VIRTIO = YES TIMEZONE = EST5EDT DISK_SIZE = 60.0G SWAP_SIZE = 48 PKGDIR = /var/scratch/packages NBD_DEV = /dev/nbd8 all: qcow --- 8< ------------------------------ Then, e.g. i can run "make PROFILE=local APPLIANCE=kde". If you don't specify a PROFILE variable, then it will default to the empty string, which means the main Makefile will attempt to include .cfg So, for example i have: $ ln -s local.cfg .cfg $ make APPLIANCE=kde Don't set PROFILE inside your .cfg file (why would you?). Also, if the [pro]file does not exist, the include fails silently. I will put this info in the wiki eventually...
2010-11-14 00:22:18 +01:00
2012-12-16 16:49:21 +01:00
sysconfig: preproot acpi.start $(SWAP_FILE) $(CHROOT)/etc/fstab $(CHROOT)/etc/conf.d/hostname
I learned a lot about Makefiles :D So, basically I re-architeched things a bit: The appliance/Makefile.inc fiels are now appliance/Makefile (again). The main Makefile will call "make -C appliance preinstall" and "postinstall" (and in future "clean"). So I got rid of the ugly make variables/include thing. Some of the main Makefile's variables are exported to the sub-makes. Appliances don't really need $(APPLIANCE) anymore as the appliance directory is their CWD. Added some new targets and smarter targets. I can do more with this, but it's a big improvment from last time. Still learning a lot of Makefile magic (been reading other people's Makefiles). Verified that "make -j3" works (at least on the base appliance) but will kill your hard drive :D Introduced "profiles" Which are files with variables you want to override. The file will be "include"ed by the main Makefile. For example, I have a file, "local.cfg" that looks like this: --- 8< ----------------------------- CHROOT = /var/scratch/marduk/vabuild HEADLESS = YES PRUNE_CRITICAL = NO VIRTIO = YES TIMEZONE = EST5EDT DISK_SIZE = 60.0G SWAP_SIZE = 48 PKGDIR = /var/scratch/packages NBD_DEV = /dev/nbd8 all: qcow --- 8< ------------------------------ Then, e.g. i can run "make PROFILE=local APPLIANCE=kde". If you don't specify a PROFILE variable, then it will default to the empty string, which means the main Makefile will attempt to include .cfg So, for example i have: $ ln -s local.cfg .cfg $ make APPLIANCE=kde Don't set PROFILE inside your .cfg file (why would you?). Also, if the [pro]file does not exist, the include fails silently. I will put this info in the wiki eventually...
2010-11-14 00:22:18 +01:00
@echo $(VIRTIO)
Baselayout-2/openrc compatibility and stage4 tarballs. The first major change here is the support of baselayout-2/openrc. So far Gentoo has not released a stage3 tarball with baselayout-2, but I've tested this enough that I feel it works even when doing an upgrade. The baselayout-1 stuff has been converted, however it is recommended to not use this until baselayout-2 is available in Gentoo stage3s as I don't want to support converting, or you can do this: stage4 tarball support. I'm not sure why I didn't support this before. Now not only can stage4 tarballs be build, instead of or in addition to virtual appliance images, but stage4 tarballs can also be used in lieu of a stage3. There is a new "stage4" make target, and also when building the Makefile will first look for stage4/<appliance>-stage4.tar.bz2 and if that exists use it instead of the Gentoo stage3. If you specify stage4 as a target and also already have a stage4, then the Makefile will unpack the stage4 into the chroot, perform updates, and then re-create the stage4 based on the updates (atomically). In addition there is a new Makefile variable, SOFTWARE. The default value is "1" meaning it will call the software target (thereby installing/updatein software), but if you set SOFTWARE=0, then the software phase will not be run. This can allow, for example, to build a VM image from a stage4 without performing software updates, in effect a straight stage4 to image for quick image building. Since most appliances are pretty much based on the "base" appliance, one could imply copy the base stage4 to the new appliance stage4 and start from there, instead of having to start from a vanilla stage3, for example: # cp stage4/base-stage4.tar.bz2 stage4/kde-stage4.tar.bz2 # make APPLIANCE=kde stage4 Will take the already existing base stage4 and simply update it to kde, which will be easier/faster than starting from a stage3. There are still some tweaks that need to be done for the stage4 support. Specifically Makefile targets need to be written with the assumption that they may be called more than once (e.g. updating a stage4 or going from stage4 to image with SOFTWARE=1). For the most part things work according to that assumption, but there are a few things that need to be tweeked, such as the inittab settings if one is building a "headed" image but it's based off a headless stage4. New appliance authors should also write their "preinstall" and "postinstall" targets with the assmption that it may be called more than once.
2011-05-18 02:44:04 +02:00
ifeq ($(VIRTIO),YES)
sed -i 's/sda/vda/' $(CHROOT)/etc/fstab
Baselayout-2/openrc compatibility and stage4 tarballs. The first major change here is the support of baselayout-2/openrc. So far Gentoo has not released a stage3 tarball with baselayout-2, but I've tested this enough that I feel it works even when doing an upgrade. The baselayout-1 stuff has been converted, however it is recommended to not use this until baselayout-2 is available in Gentoo stage3s as I don't want to support converting, or you can do this: stage4 tarball support. I'm not sure why I didn't support this before. Now not only can stage4 tarballs be build, instead of or in addition to virtual appliance images, but stage4 tarballs can also be used in lieu of a stage3. There is a new "stage4" make target, and also when building the Makefile will first look for stage4/<appliance>-stage4.tar.bz2 and if that exists use it instead of the Gentoo stage3. If you specify stage4 as a target and also already have a stage4, then the Makefile will unpack the stage4 into the chroot, perform updates, and then re-create the stage4 based on the updates (atomically). In addition there is a new Makefile variable, SOFTWARE. The default value is "1" meaning it will call the software target (thereby installing/updatein software), but if you set SOFTWARE=0, then the software phase will not be run. This can allow, for example, to build a VM image from a stage4 without performing software updates, in effect a straight stage4 to image for quick image building. Since most appliances are pretty much based on the "base" appliance, one could imply copy the base stage4 to the new appliance stage4 and start from there, instead of having to start from a vanilla stage3, for example: # cp stage4/base-stage4.tar.bz2 stage4/kde-stage4.tar.bz2 # make APPLIANCE=kde stage4 Will take the already existing base stage4 and simply update it to kde, which will be easier/faster than starting from a stage3. There are still some tweaks that need to be done for the stage4 support. Specifically Makefile targets need to be written with the assumption that they may be called more than once (e.g. updating a stage4 or going from stage4 to image with SOFTWARE=1). For the most part things work according to that assumption, but there are a few things that need to be tweeked, such as the inittab settings if one is building a "headed" image but it's based off a headless stage4. New appliance authors should also write their "preinstall" and "postinstall" targets with the assmption that it may be called more than once.
2011-05-18 02:44:04 +02:00
sed -i 's:clock_hctosys="YES":clock_hctosys="NO":g' "$(CHROOT)/etc/conf.d/hwclock"
sed -i '/^rc_sys=/d' "$(CHROOT)/etc/rc.conf"
echo 'rc_sys=""' >> "$(CHROOT)/etc/rc.conf"
endif
ifeq ($(HEADLESS),YES)
sed -i 's/^#s0:/s0:/' $(CHROOT)/etc/inittab
sed -ri 's/^(c[0-9]:)/\#\1/' $(CHROOT)/etc/inittab
2012-05-25 18:33:40 +02:00
rm -f $(CHROOT)/etc/runlevels/boot/termencoding
rm -f $(CHROOT)/etc/runlevels/boot/keymaps
endif
Baselayout-2/openrc compatibility and stage4 tarballs. The first major change here is the support of baselayout-2/openrc. So far Gentoo has not released a stage3 tarball with baselayout-2, but I've tested this enough that I feel it works even when doing an upgrade. The baselayout-1 stuff has been converted, however it is recommended to not use this until baselayout-2 is available in Gentoo stage3s as I don't want to support converting, or you can do this: stage4 tarball support. I'm not sure why I didn't support this before. Now not only can stage4 tarballs be build, instead of or in addition to virtual appliance images, but stage4 tarballs can also be used in lieu of a stage3. There is a new "stage4" make target, and also when building the Makefile will first look for stage4/<appliance>-stage4.tar.bz2 and if that exists use it instead of the Gentoo stage3. If you specify stage4 as a target and also already have a stage4, then the Makefile will unpack the stage4 into the chroot, perform updates, and then re-create the stage4 based on the updates (atomically). In addition there is a new Makefile variable, SOFTWARE. The default value is "1" meaning it will call the software target (thereby installing/updatein software), but if you set SOFTWARE=0, then the software phase will not be run. This can allow, for example, to build a VM image from a stage4 without performing software updates, in effect a straight stage4 to image for quick image building. Since most appliances are pretty much based on the "base" appliance, one could imply copy the base stage4 to the new appliance stage4 and start from there, instead of having to start from a vanilla stage3, for example: # cp stage4/base-stage4.tar.bz2 stage4/kde-stage4.tar.bz2 # make APPLIANCE=kde stage4 Will take the already existing base stage4 and simply update it to kde, which will be easier/faster than starting from a stage3. There are still some tweaks that need to be done for the stage4 support. Specifically Makefile targets need to be written with the assumption that they may be called more than once (e.g. updating a stage4 or going from stage4 to image with SOFTWARE=1). For the most part things work according to that assumption, but there are a few things that need to be tweeked, such as the inittab settings if one is building a "headed" image but it's based off a headless stage4. New appliance authors should also write their "preinstall" and "postinstall" targets with the assmption that it may be called more than once.
2011-05-18 02:44:04 +02:00
echo 'modules="dhclient"' > $(CHROOT)/etc/conf.d/net
2012-12-16 16:49:21 +01:00
echo 'config_eth0="udhcpc"' >> $(CHROOT)/etc/conf.d/net
echo 'dhcp_eth0="release"' >> $(CHROOT)/etc/conf.d/net
$(inroot) ln -nsf net.lo /etc/init.d/net.eth0
Baselayout-2/openrc compatibility and stage4 tarballs. The first major change here is the support of baselayout-2/openrc. So far Gentoo has not released a stage3 tarball with baselayout-2, but I've tested this enough that I feel it works even when doing an upgrade. The baselayout-1 stuff has been converted, however it is recommended to not use this until baselayout-2 is available in Gentoo stage3s as I don't want to support converting, or you can do this: stage4 tarball support. I'm not sure why I didn't support this before. Now not only can stage4 tarballs be build, instead of or in addition to virtual appliance images, but stage4 tarballs can also be used in lieu of a stage3. There is a new "stage4" make target, and also when building the Makefile will first look for stage4/<appliance>-stage4.tar.bz2 and if that exists use it instead of the Gentoo stage3. If you specify stage4 as a target and also already have a stage4, then the Makefile will unpack the stage4 into the chroot, perform updates, and then re-create the stage4 based on the updates (atomically). In addition there is a new Makefile variable, SOFTWARE. The default value is "1" meaning it will call the software target (thereby installing/updatein software), but if you set SOFTWARE=0, then the software phase will not be run. This can allow, for example, to build a VM image from a stage4 without performing software updates, in effect a straight stage4 to image for quick image building. Since most appliances are pretty much based on the "base" appliance, one could imply copy the base stage4 to the new appliance stage4 and start from there, instead of having to start from a vanilla stage3, for example: # cp stage4/base-stage4.tar.bz2 stage4/kde-stage4.tar.bz2 # make APPLIANCE=kde stage4 Will take the already existing base stage4 and simply update it to kde, which will be easier/faster than starting from a stage3. There are still some tweaks that need to be done for the stage4 support. Specifically Makefile targets need to be written with the assumption that they may be called more than once (e.g. updating a stage4 or going from stage4 to image with SOFTWARE=1). For the most part things work according to that assumption, but there are a few things that need to be tweeked, such as the inittab settings if one is building a "headed" image but it's based off a headless stage4. New appliance authors should also write their "preinstall" and "postinstall" targets with the assmption that it may be called more than once.
2011-05-18 02:44:04 +02:00
$(inroot) ln -nsf /etc/init.d/net.eth0 /etc/runlevels/default/net.eth0
$(inroot) rm -f /etc/runlevels/boot/consolefont
2012-12-16 16:49:21 +01:00
cp -a acpi.start $(CHROOT)/etc/local.d
2010-07-09 05:22:37 +02:00
touch sysconfig
systools: sysconfig compile_options
@./echo Installing standard system tools
2012-05-25 18:33:40 +02:00
$(inroot) $(EMERGE) -n $(USEPKG) app-admin/metalog
$(inroot) /sbin/rc-update add metalog default
ifeq ($(DASH),YES)
2012-12-16 16:49:21 +01:00
if ! test -e "$(STAGE4_TARBALL)"; \
Baselayout-2/openrc compatibility and stage4 tarballs. The first major change here is the support of baselayout-2/openrc. So far Gentoo has not released a stage3 tarball with baselayout-2, but I've tested this enough that I feel it works even when doing an upgrade. The baselayout-1 stuff has been converted, however it is recommended to not use this until baselayout-2 is available in Gentoo stage3s as I don't want to support converting, or you can do this: stage4 tarball support. I'm not sure why I didn't support this before. Now not only can stage4 tarballs be build, instead of or in addition to virtual appliance images, but stage4 tarballs can also be used in lieu of a stage3. There is a new "stage4" make target, and also when building the Makefile will first look for stage4/<appliance>-stage4.tar.bz2 and if that exists use it instead of the Gentoo stage3. If you specify stage4 as a target and also already have a stage4, then the Makefile will unpack the stage4 into the chroot, perform updates, and then re-create the stage4 based on the updates (atomically). In addition there is a new Makefile variable, SOFTWARE. The default value is "1" meaning it will call the software target (thereby installing/updatein software), but if you set SOFTWARE=0, then the software phase will not be run. This can allow, for example, to build a VM image from a stage4 without performing software updates, in effect a straight stage4 to image for quick image building. Since most appliances are pretty much based on the "base" appliance, one could imply copy the base stage4 to the new appliance stage4 and start from there, instead of having to start from a vanilla stage3, for example: # cp stage4/base-stage4.tar.bz2 stage4/kde-stage4.tar.bz2 # make APPLIANCE=kde stage4 Will take the already existing base stage4 and simply update it to kde, which will be easier/faster than starting from a stage3. There are still some tweaks that need to be done for the stage4 support. Specifically Makefile targets need to be written with the assumption that they may be called more than once (e.g. updating a stage4 or going from stage4 to image with SOFTWARE=1). For the most part things work according to that assumption, but there are a few things that need to be tweeked, such as the inittab settings if one is building a "headed" image but it's based off a headless stage4. New appliance authors should also write their "preinstall" and "postinstall" targets with the assmption that it may be called more than once.
2011-05-18 02:44:04 +02:00
then $(inroot) $(EMERGE) -n $(USEPKG) app-shells/dash; \
echo /bin/dash >> $(CHROOT)/etc/shells; \
2012-12-16 16:49:21 +01:00
$(inroot) chsh -s /bin/sh root; \
Baselayout-2/openrc compatibility and stage4 tarballs. The first major change here is the support of baselayout-2/openrc. So far Gentoo has not released a stage3 tarball with baselayout-2, but I've tested this enough that I feel it works even when doing an upgrade. The baselayout-1 stuff has been converted, however it is recommended to not use this until baselayout-2 is available in Gentoo stage3s as I don't want to support converting, or you can do this: stage4 tarball support. I'm not sure why I didn't support this before. Now not only can stage4 tarballs be build, instead of or in addition to virtual appliance images, but stage4 tarballs can also be used in lieu of a stage3. There is a new "stage4" make target, and also when building the Makefile will first look for stage4/<appliance>-stage4.tar.bz2 and if that exists use it instead of the Gentoo stage3. If you specify stage4 as a target and also already have a stage4, then the Makefile will unpack the stage4 into the chroot, perform updates, and then re-create the stage4 based on the updates (atomically). In addition there is a new Makefile variable, SOFTWARE. The default value is "1" meaning it will call the software target (thereby installing/updatein software), but if you set SOFTWARE=0, then the software phase will not be run. This can allow, for example, to build a VM image from a stage4 without performing software updates, in effect a straight stage4 to image for quick image building. Since most appliances are pretty much based on the "base" appliance, one could imply copy the base stage4 to the new appliance stage4 and start from there, instead of having to start from a vanilla stage3, for example: # cp stage4/base-stage4.tar.bz2 stage4/kde-stage4.tar.bz2 # make APPLIANCE=kde stage4 Will take the already existing base stage4 and simply update it to kde, which will be easier/faster than starting from a stage3. There are still some tweaks that need to be done for the stage4 support. Specifically Makefile targets need to be written with the assumption that they may be called more than once (e.g. updating a stage4 or going from stage4 to image with SOFTWARE=1). For the most part things work according to that assumption, but there are a few things that need to be tweeked, such as the inittab settings if one is building a "headed" image but it's based off a headless stage4. New appliance authors should also write their "preinstall" and "postinstall" targets with the assmption that it may be called more than once.
2011-05-18 02:44:04 +02:00
fi
$(inroot) ln -sf dash /bin/sh
endif
2010-07-09 05:22:37 +02:00
touch systools
2013-08-26 23:21:17 +02:00
grub: stage3 grub.conf kernel
ifneq ($(EXTERNAL_KERNEL),YES)
@./echo Installing Grub
$(inroot) $(EMERGE) -nN $(USEPKG) sys-boot/grub-static
cp grub.conf $(CHROOT)/boot/grub/grub.conf
ifeq ($(VIRTIO),YES)
sed -i 's/sda/vda/' $(CHROOT)/boot/grub/grub.conf
endif
ifeq ($(HEADLESS),YES)
sed -i -f grub-headless.sed $(CHROOT)/boot/grub/grub.conf
endif
endif
2010-07-09 05:22:37 +02:00
touch grub
Baselayout-2/openrc compatibility and stage4 tarballs. The first major change here is the support of baselayout-2/openrc. So far Gentoo has not released a stage3 tarball with baselayout-2, but I've tested this enough that I feel it works even when doing an upgrade. The baselayout-1 stuff has been converted, however it is recommended to not use this until baselayout-2 is available in Gentoo stage3s as I don't want to support converting, or you can do this: stage4 tarball support. I'm not sure why I didn't support this before. Now not only can stage4 tarballs be build, instead of or in addition to virtual appliance images, but stage4 tarballs can also be used in lieu of a stage3. There is a new "stage4" make target, and also when building the Makefile will first look for stage4/<appliance>-stage4.tar.bz2 and if that exists use it instead of the Gentoo stage3. If you specify stage4 as a target and also already have a stage4, then the Makefile will unpack the stage4 into the chroot, perform updates, and then re-create the stage4 based on the updates (atomically). In addition there is a new Makefile variable, SOFTWARE. The default value is "1" meaning it will call the software target (thereby installing/updatein software), but if you set SOFTWARE=0, then the software phase will not be run. This can allow, for example, to build a VM image from a stage4 without performing software updates, in effect a straight stage4 to image for quick image building. Since most appliances are pretty much based on the "base" appliance, one could imply copy the base stage4 to the new appliance stage4 and start from there, instead of having to start from a vanilla stage3, for example: # cp stage4/base-stage4.tar.bz2 stage4/kde-stage4.tar.bz2 # make APPLIANCE=kde stage4 Will take the already existing base stage4 and simply update it to kde, which will be easier/faster than starting from a stage3. There are still some tweaks that need to be done for the stage4 support. Specifically Makefile targets need to be written with the assumption that they may be called more than once (e.g. updating a stage4 or going from stage4 to image with SOFTWARE=1). For the most part things work according to that assumption, but there are a few things that need to be tweeked, such as the inittab settings if one is building a "headed" image but it's based off a headless stage4. New appliance authors should also write their "preinstall" and "postinstall" targets with the assmption that it may be called more than once.
2011-05-18 02:44:04 +02:00
build-software: systools issue etc-update.conf $(CRITICAL) $(WORLD)
@./echo Building $(APPLIANCE)-specific software
I learned a lot about Makefiles :D So, basically I re-architeched things a bit: The appliance/Makefile.inc fiels are now appliance/Makefile (again). The main Makefile will call "make -C appliance preinstall" and "postinstall" (and in future "clean"). So I got rid of the ugly make variables/include thing. Some of the main Makefile's variables are exported to the sub-makes. Appliances don't really need $(APPLIANCE) anymore as the appliance directory is their CWD. Added some new targets and smarter targets. I can do more with this, but it's a big improvment from last time. Still learning a lot of Makefile magic (been reading other people's Makefiles). Verified that "make -j3" works (at least on the base appliance) but will kill your hard drive :D Introduced "profiles" Which are files with variables you want to override. The file will be "include"ed by the main Makefile. For example, I have a file, "local.cfg" that looks like this: --- 8< ----------------------------- CHROOT = /var/scratch/marduk/vabuild HEADLESS = YES PRUNE_CRITICAL = NO VIRTIO = YES TIMEZONE = EST5EDT DISK_SIZE = 60.0G SWAP_SIZE = 48 PKGDIR = /var/scratch/packages NBD_DEV = /dev/nbd8 all: qcow --- 8< ------------------------------ Then, e.g. i can run "make PROFILE=local APPLIANCE=kde". If you don't specify a PROFILE variable, then it will default to the empty string, which means the main Makefile will attempt to include .cfg So, for example i have: $ ln -s local.cfg .cfg $ make APPLIANCE=kde Don't set PROFILE inside your .cfg file (why would you?). Also, if the [pro]file does not exist, the include fails silently. I will put this info in the wiki eventually...
2010-11-14 00:22:18 +01:00
$(MAKE) -C $(APPLIANCE) preinstall
cp etc-update.conf $(CHROOT)/etc/
if test `stat -c "%s" $(WORLD)` -ne 0 ; then \
2012-12-16 16:49:21 +01:00
$(inroot) $(EMERGE) $(USEPKG) --update --newuse --deep `cat $(WORLD)` $(EXTRA_WORLD); \
else \
true; \
fi
$(gcc_config)
@./echo Running revdep-rebuild
# Need gentoolkit to run revdep-rebuild
2013-08-26 23:21:17 +02:00
$(inroot) emerge $(USEPKG) @preserved-rebuild
2010-07-09 05:22:37 +02:00
cp issue $(CHROOT)/etc/issue
$(gcc_config)
$(inroot) $(EMERGE) $(USEPKG) --update --newuse --deep world
$(inroot) $(EMERGE) --depclean --with-bdeps=n
$(gcc_config)
EDITOR=/usr/bin/nano $(inroot) etc-update
I learned a lot about Makefiles :D So, basically I re-architeched things a bit: The appliance/Makefile.inc fiels are now appliance/Makefile (again). The main Makefile will call "make -C appliance preinstall" and "postinstall" (and in future "clean"). So I got rid of the ugly make variables/include thing. Some of the main Makefile's variables are exported to the sub-makes. Appliances don't really need $(APPLIANCE) anymore as the appliance directory is their CWD. Added some new targets and smarter targets. I can do more with this, but it's a big improvment from last time. Still learning a lot of Makefile magic (been reading other people's Makefiles). Verified that "make -j3" works (at least on the base appliance) but will kill your hard drive :D Introduced "profiles" Which are files with variables you want to override. The file will be "include"ed by the main Makefile. For example, I have a file, "local.cfg" that looks like this: --- 8< ----------------------------- CHROOT = /var/scratch/marduk/vabuild HEADLESS = YES PRUNE_CRITICAL = NO VIRTIO = YES TIMEZONE = EST5EDT DISK_SIZE = 60.0G SWAP_SIZE = 48 PKGDIR = /var/scratch/packages NBD_DEV = /dev/nbd8 all: qcow --- 8< ------------------------------ Then, e.g. i can run "make PROFILE=local APPLIANCE=kde". If you don't specify a PROFILE variable, then it will default to the empty string, which means the main Makefile will attempt to include .cfg So, for example i have: $ ln -s local.cfg .cfg $ make APPLIANCE=kde Don't set PROFILE inside your .cfg file (why would you?). Also, if the [pro]file does not exist, the include fails silently. I will put this info in the wiki eventually...
2010-11-14 00:22:18 +01:00
$(MAKE) -C $(APPLIANCE) postinstall
ifeq ($(UDEV),NO)
rm -f $(CHROOT)/etc/runlevels/sysinit/udev
$(inroot) $(EMERGE) -c sys-fs/udev
else
ln -sf /etc/init.d/udev $(CHROOT)/etc/runlevels/sysinit/udev
endif
ifeq ($(ENABLE_SSHD),YES)
$(inroot) /sbin/rc-update add sshd default
endif
$(change_password)
ifeq ($(PRUNE_CRITICAL),YES)
$(inroot) $(EMERGE) -C `cat $(CRITICAL)`
ifeq ($(DASH),YES)
2012-12-16 16:49:21 +01:00
$(inroot) $(EMERGE) -c app-shells/bash
endif
endif
Baselayout-2/openrc compatibility and stage4 tarballs. The first major change here is the support of baselayout-2/openrc. So far Gentoo has not released a stage3 tarball with baselayout-2, but I've tested this enough that I feel it works even when doing an upgrade. The baselayout-1 stuff has been converted, however it is recommended to not use this until baselayout-2 is available in Gentoo stage3s as I don't want to support converting, or you can do this: stage4 tarball support. I'm not sure why I didn't support this before. Now not only can stage4 tarballs be build, instead of or in addition to virtual appliance images, but stage4 tarballs can also be used in lieu of a stage3. There is a new "stage4" make target, and also when building the Makefile will first look for stage4/<appliance>-stage4.tar.bz2 and if that exists use it instead of the Gentoo stage3. If you specify stage4 as a target and also already have a stage4, then the Makefile will unpack the stage4 into the chroot, perform updates, and then re-create the stage4 based on the updates (atomically). In addition there is a new Makefile variable, SOFTWARE. The default value is "1" meaning it will call the software target (thereby installing/updatein software), but if you set SOFTWARE=0, then the software phase will not be run. This can allow, for example, to build a VM image from a stage4 without performing software updates, in effect a straight stage4 to image for quick image building. Since most appliances are pretty much based on the "base" appliance, one could imply copy the base stage4 to the new appliance stage4 and start from there, instead of having to start from a vanilla stage3, for example: # cp stage4/base-stage4.tar.bz2 stage4/kde-stage4.tar.bz2 # make APPLIANCE=kde stage4 Will take the already existing base stage4 and simply update it to kde, which will be easier/faster than starting from a stage3. There are still some tweaks that need to be done for the stage4 support. Specifically Makefile targets need to be written with the assumption that they may be called more than once (e.g. updating a stage4 or going from stage4 to image with SOFTWARE=1). For the most part things work according to that assumption, but there are a few things that need to be tweeked, such as the inittab settings if one is building a "headed" image but it's based off a headless stage4. New appliance authors should also write their "preinstall" and "postinstall" targets with the assmption that it may be called more than once.
2011-05-18 02:44:04 +02:00
software: $(software-deps)
ifneq ($(PKGLIST),0)
echo \# > $(LST_FILE)
echo \# Gentoo Virtual Appliance \"$(APPLIANCE)\" package list >> $(LST_FILE)
echo \# Generated `date -u` >> $(LST_FILE)
echo \# >> $(LST_FILE)
(cd "$(CHROOT)"/var/db/pkg ; /bin/ls -1d */*) >> $(LST_FILE)
endif
2010-07-09 05:22:37 +02:00
touch software
device-map: $(RAW_IMAGE)
echo '(hd0) ' $(RAW_IMAGE) > device-map
image: $(STAGE4_TARBALL) partitions device-map grub.shell motd.sh
@./echo Installing files to $(RAW_IMAGE)
2010-07-09 05:22:37 +02:00
mkdir -p loop
mount -o noatime $(NBD_DEV)p1 loop
2013-08-26 23:21:17 +02:00
tar -aSxf $(STAGE4_TARBALL) --numeric-owner $(COPY_ARGS) -C loop
./motd.sh $(EXTERNAL_KERNEL) $(VIRTIO) $(DISK_SIZE) $(SWAP_SIZE) $(UDEV) $(DASH) $(ARCH) > loop/etc/motd
ifneq ($(EXTERNAL_KERNEL),YES)
2010-07-09 05:22:37 +02:00
loop/sbin/grub --device-map=device-map --no-floppy --batch < grub.shell
endif
umount -l loop
2010-07-09 05:22:37 +02:00
rmdir loop
qemu-nbd -d $(NBD_DEV)
2010-07-09 05:22:37 +02:00
2013-08-26 23:21:17 +02:00
$(QCOW_IMAGE): image
@./echo Creating $(QCOW_IMAGE)
2010-07-09 05:22:37 +02:00
qemu-img convert -f raw -O qcow2 -c $(RAW_IMAGE) $(QCOW_IMAGE)
qcow: $(QCOW_IMAGE)
$(XVA_IMAGE): image
@./echo Creating $(XVA_IMAGE)
xva.py --disk=$(RAW_IMAGE) --is-hvm --memory=256 --vcpus=1 --name=$(APPLIANCE) \
--filename=$(XVA_IMAGE)
xva: $(XVA_IMAGE)
2010-07-09 05:22:37 +02:00
$(VMDK_IMAGE): image
@./echo Creating $(VMDK_IMAGE)
2010-07-09 05:22:37 +02:00
qemu-img convert -f raw -O vmdk $(RAW_IMAGE) $(VMDK_IMAGE)
vmdk: $(VMDK_IMAGE)
2013-08-26 23:21:17 +02:00
stage4: software kernel rsync-excludes rsync-excludes-critical grub
@./echo Creating stage4 tarball: $(STAGE4_TARBALL)
Baselayout-2/openrc compatibility and stage4 tarballs. The first major change here is the support of baselayout-2/openrc. So far Gentoo has not released a stage3 tarball with baselayout-2, but I've tested this enough that I feel it works even when doing an upgrade. The baselayout-1 stuff has been converted, however it is recommended to not use this until baselayout-2 is available in Gentoo stage3s as I don't want to support converting, or you can do this: stage4 tarball support. I'm not sure why I didn't support this before. Now not only can stage4 tarballs be build, instead of or in addition to virtual appliance images, but stage4 tarballs can also be used in lieu of a stage3. There is a new "stage4" make target, and also when building the Makefile will first look for stage4/<appliance>-stage4.tar.bz2 and if that exists use it instead of the Gentoo stage3. If you specify stage4 as a target and also already have a stage4, then the Makefile will unpack the stage4 into the chroot, perform updates, and then re-create the stage4 based on the updates (atomically). In addition there is a new Makefile variable, SOFTWARE. The default value is "1" meaning it will call the software target (thereby installing/updatein software), but if you set SOFTWARE=0, then the software phase will not be run. This can allow, for example, to build a VM image from a stage4 without performing software updates, in effect a straight stage4 to image for quick image building. Since most appliances are pretty much based on the "base" appliance, one could imply copy the base stage4 to the new appliance stage4 and start from there, instead of having to start from a vanilla stage3, for example: # cp stage4/base-stage4.tar.bz2 stage4/kde-stage4.tar.bz2 # make APPLIANCE=kde stage4 Will take the already existing base stage4 and simply update it to kde, which will be easier/faster than starting from a stage3. There are still some tweaks that need to be done for the stage4 support. Specifically Makefile targets need to be written with the assumption that they may be called more than once (e.g. updating a stage4 or going from stage4 to image with SOFTWARE=1). For the most part things work according to that assumption, but there are a few things that need to be tweeked, such as the inittab settings if one is building a "headed" image but it's based off a headless stage4. New appliance authors should also write their "preinstall" and "postinstall" targets with the assmption that it may be called more than once.
2011-05-18 02:44:04 +02:00
mkdir -p stage4
mkdir -p gentoo
mount -o bind $(CHROOT) gentoo
tar -aScf "$(STAGE4_TARBALL).tmp.xz" --numeric-owner $(COPY_ARGS) -C gentoo --one-file-system .
Baselayout-2/openrc compatibility and stage4 tarballs. The first major change here is the support of baselayout-2/openrc. So far Gentoo has not released a stage3 tarball with baselayout-2, but I've tested this enough that I feel it works even when doing an upgrade. The baselayout-1 stuff has been converted, however it is recommended to not use this until baselayout-2 is available in Gentoo stage3s as I don't want to support converting, or you can do this: stage4 tarball support. I'm not sure why I didn't support this before. Now not only can stage4 tarballs be build, instead of or in addition to virtual appliance images, but stage4 tarballs can also be used in lieu of a stage3. There is a new "stage4" make target, and also when building the Makefile will first look for stage4/<appliance>-stage4.tar.bz2 and if that exists use it instead of the Gentoo stage3. If you specify stage4 as a target and also already have a stage4, then the Makefile will unpack the stage4 into the chroot, perform updates, and then re-create the stage4 based on the updates (atomically). In addition there is a new Makefile variable, SOFTWARE. The default value is "1" meaning it will call the software target (thereby installing/updatein software), but if you set SOFTWARE=0, then the software phase will not be run. This can allow, for example, to build a VM image from a stage4 without performing software updates, in effect a straight stage4 to image for quick image building. Since most appliances are pretty much based on the "base" appliance, one could imply copy the base stage4 to the new appliance stage4 and start from there, instead of having to start from a vanilla stage3, for example: # cp stage4/base-stage4.tar.bz2 stage4/kde-stage4.tar.bz2 # make APPLIANCE=kde stage4 Will take the already existing base stage4 and simply update it to kde, which will be easier/faster than starting from a stage3. There are still some tweaks that need to be done for the stage4 support. Specifically Makefile targets need to be written with the assumption that they may be called more than once (e.g. updating a stage4 or going from stage4 to image with SOFTWARE=1). For the most part things work according to that assumption, but there are a few things that need to be tweeked, such as the inittab settings if one is building a "headed" image but it's based off a headless stage4. New appliance authors should also write their "preinstall" and "postinstall" targets with the assmption that it may be called more than once.
2011-05-18 02:44:04 +02:00
umount gentoo
rmdir gentoo
mv "$(STAGE4_TARBALL).tmp.xz" "$(STAGE4_TARBALL)"
Baselayout-2/openrc compatibility and stage4 tarballs. The first major change here is the support of baselayout-2/openrc. So far Gentoo has not released a stage3 tarball with baselayout-2, but I've tested this enough that I feel it works even when doing an upgrade. The baselayout-1 stuff has been converted, however it is recommended to not use this until baselayout-2 is available in Gentoo stage3s as I don't want to support converting, or you can do this: stage4 tarball support. I'm not sure why I didn't support this before. Now not only can stage4 tarballs be build, instead of or in addition to virtual appliance images, but stage4 tarballs can also be used in lieu of a stage3. There is a new "stage4" make target, and also when building the Makefile will first look for stage4/<appliance>-stage4.tar.bz2 and if that exists use it instead of the Gentoo stage3. If you specify stage4 as a target and also already have a stage4, then the Makefile will unpack the stage4 into the chroot, perform updates, and then re-create the stage4 based on the updates (atomically). In addition there is a new Makefile variable, SOFTWARE. The default value is "1" meaning it will call the software target (thereby installing/updatein software), but if you set SOFTWARE=0, then the software phase will not be run. This can allow, for example, to build a VM image from a stage4 without performing software updates, in effect a straight stage4 to image for quick image building. Since most appliances are pretty much based on the "base" appliance, one could imply copy the base stage4 to the new appliance stage4 and start from there, instead of having to start from a vanilla stage3, for example: # cp stage4/base-stage4.tar.bz2 stage4/kde-stage4.tar.bz2 # make APPLIANCE=kde stage4 Will take the already existing base stage4 and simply update it to kde, which will be easier/faster than starting from a stage3. There are still some tweaks that need to be done for the stage4 support. Specifically Makefile targets need to be written with the assumption that they may be called more than once (e.g. updating a stage4 or going from stage4 to image with SOFTWARE=1). For the most part things work according to that assumption, but there are a few things that need to be tweeked, such as the inittab settings if one is building a "headed" image but it's based off a headless stage4. New appliance authors should also write their "preinstall" and "postinstall" targets with the assmption that it may be called more than once.
2011-05-18 02:44:04 +02:00
2013-08-26 23:21:17 +02:00
$(STAGE4_TARBALL):
stage4
Baselayout-2/openrc compatibility and stage4 tarballs. The first major change here is the support of baselayout-2/openrc. So far Gentoo has not released a stage3 tarball with baselayout-2, but I've tested this enough that I feel it works even when doing an upgrade. The baselayout-1 stuff has been converted, however it is recommended to not use this until baselayout-2 is available in Gentoo stage3s as I don't want to support converting, or you can do this: stage4 tarball support. I'm not sure why I didn't support this before. Now not only can stage4 tarballs be build, instead of or in addition to virtual appliance images, but stage4 tarballs can also be used in lieu of a stage3. There is a new "stage4" make target, and also when building the Makefile will first look for stage4/<appliance>-stage4.tar.bz2 and if that exists use it instead of the Gentoo stage3. If you specify stage4 as a target and also already have a stage4, then the Makefile will unpack the stage4 into the chroot, perform updates, and then re-create the stage4 based on the updates (atomically). In addition there is a new Makefile variable, SOFTWARE. The default value is "1" meaning it will call the software target (thereby installing/updatein software), but if you set SOFTWARE=0, then the software phase will not be run. This can allow, for example, to build a VM image from a stage4 without performing software updates, in effect a straight stage4 to image for quick image building. Since most appliances are pretty much based on the "base" appliance, one could imply copy the base stage4 to the new appliance stage4 and start from there, instead of having to start from a vanilla stage3, for example: # cp stage4/base-stage4.tar.bz2 stage4/kde-stage4.tar.bz2 # make APPLIANCE=kde stage4 Will take the already existing base stage4 and simply update it to kde, which will be easier/faster than starting from a stage3. There are still some tweaks that need to be done for the stage4 support. Specifically Makefile targets need to be written with the assumption that they may be called more than once (e.g. updating a stage4 or going from stage4 to image with SOFTWARE=1). For the most part things work according to that assumption, but there are a few things that need to be tweeked, such as the inittab settings if one is building a "headed" image but it's based off a headless stage4. New appliance authors should also write their "preinstall" and "postinstall" targets with the assmption that it may be called more than once.
2011-05-18 02:44:04 +02:00
umount:
@./echo Attempting to unmount chroot mounts
ifdef PKGDIR
umount -l $(CHROOT)/var/portage/packages
endif
umount -l $(CHROOT)/var/tmp
umount -l $(CHROOT)/dev
umount -l $(CHROOT)/proc
I learned a lot about Makefiles :D So, basically I re-architeched things a bit: The appliance/Makefile.inc fiels are now appliance/Makefile (again). The main Makefile will call "make -C appliance preinstall" and "postinstall" (and in future "clean"). So I got rid of the ugly make variables/include thing. Some of the main Makefile's variables are exported to the sub-makes. Appliances don't really need $(APPLIANCE) anymore as the appliance directory is their CWD. Added some new targets and smarter targets. I can do more with this, but it's a big improvment from last time. Still learning a lot of Makefile magic (been reading other people's Makefiles). Verified that "make -j3" works (at least on the base appliance) but will kill your hard drive :D Introduced "profiles" Which are files with variables you want to override. The file will be "include"ed by the main Makefile. For example, I have a file, "local.cfg" that looks like this: --- 8< ----------------------------- CHROOT = /var/scratch/marduk/vabuild HEADLESS = YES PRUNE_CRITICAL = NO VIRTIO = YES TIMEZONE = EST5EDT DISK_SIZE = 60.0G SWAP_SIZE = 48 PKGDIR = /var/scratch/packages NBD_DEV = /dev/nbd8 all: qcow --- 8< ------------------------------ Then, e.g. i can run "make PROFILE=local APPLIANCE=kde". If you don't specify a PROFILE variable, then it will default to the empty string, which means the main Makefile will attempt to include .cfg So, for example i have: $ ln -s local.cfg .cfg $ make APPLIANCE=kde Don't set PROFILE inside your .cfg file (why would you?). Also, if the [pro]file does not exist, the include fails silently. I will put this info in the wiki eventually...
2010-11-14 00:22:18 +01:00
touch umount
2010-07-09 05:22:37 +02:00
2010-11-06 09:41:15 +01:00
remove_checkpoints:
rm -f mounts compile_options base_system portage sync_portage
2013-08-26 23:21:17 +02:00
rm -f parted kernel grub stage3 software preproot sysconfig systools partitions device-map
2010-11-06 09:41:15 +01:00
clean: umount remove_checkpoints
rm -f umount
rm -rf --one-file-system loop
rm -rf --one-file-system gentoo
rm -rf --one-file-system $(CHROOT)
2010-07-09 05:22:37 +02:00
realclean: clean
I learned a lot about Makefiles :D So, basically I re-architeched things a bit: The appliance/Makefile.inc fiels are now appliance/Makefile (again). The main Makefile will call "make -C appliance preinstall" and "postinstall" (and in future "clean"). So I got rid of the ugly make variables/include thing. Some of the main Makefile's variables are exported to the sub-makes. Appliances don't really need $(APPLIANCE) anymore as the appliance directory is their CWD. Added some new targets and smarter targets. I can do more with this, but it's a big improvment from last time. Still learning a lot of Makefile magic (been reading other people's Makefiles). Verified that "make -j3" works (at least on the base appliance) but will kill your hard drive :D Introduced "profiles" Which are files with variables you want to override. The file will be "include"ed by the main Makefile. For example, I have a file, "local.cfg" that looks like this: --- 8< ----------------------------- CHROOT = /var/scratch/marduk/vabuild HEADLESS = YES PRUNE_CRITICAL = NO VIRTIO = YES TIMEZONE = EST5EDT DISK_SIZE = 60.0G SWAP_SIZE = 48 PKGDIR = /var/scratch/packages NBD_DEV = /dev/nbd8 all: qcow --- 8< ------------------------------ Then, e.g. i can run "make PROFILE=local APPLIANCE=kde". If you don't specify a PROFILE variable, then it will default to the empty string, which means the main Makefile will attempt to include .cfg So, for example i have: $ ln -s local.cfg .cfg $ make APPLIANCE=kde Don't set PROFILE inside your .cfg file (why would you?). Also, if the [pro]file does not exist, the include fails silently. I will put this info in the wiki eventually...
2010-11-14 00:22:18 +01:00
${RM} $(RAW_IMAGE) $(QCOW_IMAGE) $(VMDK_IMAGE)
2010-11-06 23:46:07 +01:00
distclean:
2010-11-06 09:41:15 +01:00
rm -f *.qcow *.img *.vmdk
2010-11-06 23:46:07 +01:00
rm -f latest-stage3.txt stage3-*-latest.tar.bz2
2013-08-25 11:24:46 +02:00
rm -f portage-snapshot.tar.bz2
2010-11-06 23:46:07 +01:00
2013-09-17 01:26:48 +02:00
help:
@./echo 'Help targets (this is not a comprehensive list)'
@echo
@echo 'sync_portage - Download the latest portage snapshot'
@echo 'sync_stage3 - Download the latest stage3 tarball'
@echo 'stage4 - Build a stage4 tarball'
@echo 'software - Build software into a chroot'
@echo 'clean - Unmount chroot and clean directory'
@echo 'realclean - Clean and remove image files'
@./echo 'Images'
@echo 'image - Build a raw VM image from stage4'
@echo 'qcow - Build a qcow VM image from a raw image'
@echo 'vmdk - Build a vmdk image from a raw image'
@echo 'xva - Build an xva image from a raw image'
@./echo 'Variables'
@echo 'APPLIANCE= - The appliance to build'
@echo 'HOSTNAME= - Hostname to give appliance'
@echo 'TIMEZONE= - Timezone to set for the appliance'
@echo 'CHROOT= - The directory to build the chroot'
@echo 'DISK_SIZE= - Size of the disk image'
@echo 'SWAP_SIZE= - Size of the swap file'
@echo 'ARCH= - Architecture to build for (x86 or amd64)'
@echo 'VIRTIO=YES - Configure the stage2/image to use virtio'
@echo 'EXTERNAL_KERNEL=YES - Do not build a kernel in the image'
@echo 'HEADLESS=YES - Build a headless (serial console) image.'
@echo 'REMOVE_PORTAGE_TREE=NO - Do not exclude the portage tree from the image'
@echo 'PKGDIR= - Directory to use/store binary packages'
@echo 'NBD_DEV=/dev/nbd0 - NBD device to use when manipulating images'
@echo 'ENABLE_SSHD=YES - Enable sshd to start automatically in the image'
@echo
@./echo 'Example'
@echo 'make APPLIANCE=mongodb HEADLESS=YES VIRTIO=YES stage4 qcow clean'
.PHONY: qcow vmdk clean realclean distclean remove_checkpoints stage4 build-software image stage4 help