virtual-appliance/Makefile

353 lines
9.7 KiB
Makefile
Raw Normal View History

CHROOT = $(PWD)/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
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
STAGE4_TARBALL = stage4/$(HOSTNAME)-stage4.tar.bz2
2010-11-05 04:17:00 +01:00
KERNEL_CONFIG = kernel.config
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
MAKEOPTS = -j4
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
EMERGE = /usr/bin/emerge
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/
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
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)
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)
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) mklabel msdos
parted -s $(RAW_IMAGE) mkpart primary ext2 0 $(DISK_SIZE)
parted -s $(RAW_IMAGE) set 1 boot on
qemu-nbd -c $(NBD_DEV) $(RAW_IMAGE)
sleep 3
2011-02-21 13:13:24 +01:00
mkfs.ext4 -O sparse_super,^has_journal -L "$(APPLIANCE)"_root $(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
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
sync_portage:
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
rsync --no-motd -L $(RSYNC_MIRROR)/snapshots/portage-latest.tar.bz2 portage-latest.tar.bz2
touch sync_portage
portage: sync_portage stage3
tar xjf portage-latest.tar.bz2 -C $(CHROOT)/usr
ifdef PKGDIR
mkdir -p $(CHROOT)/var/portage/packages
mount -o bind "$(PKGDIR)" $(CHROOT)/var/portage/packages
endif
touch portage
preproot: stage3 mounts portage
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
touch preproot
2010-11-06 09:41:15 +01:00
stage3:
mkdir -p $(CHROOT)
ifdef stage4-exists
tar xjpf "$(STAGE4_TARBALL)" -C $(CHROOT)
else
rsync --no-motd $(RSYNC_MIRROR)/releases/`echo $(ARCH)|sed 's/i.86/x86/'`/autobuilds/latest-stage3.txt .
rsync --no-motd $(RSYNC_MIRROR)/releases/`echo $(ARCH)|sed 's/i.86/x86/'`/autobuilds/`tail -n 1 latest-stage3.txt` stage3-$(ARCH)-latest.tar.bz2
tar xjpf stage3-$(ARCH)-latest.tar.bz2 -C $(CHROOT)
endif
touch stage3
compile_options: portage make.conf locale.gen $(PACKAGE_FILES)
cp make.conf $(CHROOT)/etc/make.conf
ifdef PKGDIR
echo PKGDIR="/var/portage/packages" >> $(CHROOT)/etc/make.conf
endif
echo ACCEPT_KEYWORDS=$(ACCEPT_KEYWORDS) >> $(CHROOT)/etc/make.conf
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)
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
dd if=/dev/zero of=$(SWAP_FILE) bs=1M count=$(SWAP_SIZE)
/sbin/mkswap $(SWAP_FILE)
$(CHROOT)/etc/fstab: fstab preproot
2010-07-09 05:22:37 +02:00
cp fstab $(CHROOT)/etc/fstab
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
$(CHROOT)/etc/conf.d/hostname: preproot
echo hostname=\"$(HOSTNAME)\" > $(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
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
sysconfig: preproot $(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
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
echo 'config_eth0="dhcp"' >> $(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
2010-07-09 05:22:37 +02:00
touch sysconfig
systools: sysconfig compile_options
$(inroot) $(EMERGE) -n $(USEPKG) app-admin/syslog-ng
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) /sbin/rc-update add syslog-ng default
$(inroot) $(EMERGE) -n $(USEPKG) sys-power/acpid
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) /sbin/rc-update add acpid default
$(inroot) $(EMERGE) -n $(USEPKG) net-misc/dhcp
ifeq ($(DASH),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
if ! test -e "$(STAGE4_TARBALL)"; \
then $(inroot) $(EMERGE) -n $(USEPKG) app-shells/dash; \
echo /bin/dash >> $(CHROOT)/etc/shells; \
$(inroot) chsh -s /bin/dash root; \
fi
$(inroot) ln -sf dash /bin/sh
endif
2010-07-09 05:22:37 +02:00
touch systools
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
grub: stage3 grub.conf kernel partitions
ifneq ($(EXTERNAL_KERNEL),YES)
$(inroot) $(EMERGE) -nN $(USEPKG) sys-boot/grub
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)
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/
# some packages, like, tar need xz-utils to unpack, but it not part of
# the stage3 so may not be installed yet
$(inroot) $(EMERGE) -1n $(USEPKG) app-arch/xz-utils
$(inroot) $(EMERGE) $(USEPKG) --update --newuse --deep `cat $(WORLD)`
$(gcc_config)
# Need gentoolkit to run revdep-rebuild
$(inroot) $(EMERGE) -1n $(USEPKG) app-portage/gentoolkit
$(inroot) revdep-rebuild -i
2010-07-09 05:22:37 +02:00
cp issue $(CHROOT)/etc/issue
$(gcc_config)
$(inroot) $(EMERGE) $(USEPKG) --update --newuse --deep world
# Per bug #357009
2011-06-08 13:23:19 +02:00
$(inroot) eselect python update --ignore 3.*
$(inroot) $(EMERGE) --depclean --with-bdeps=n
$(gcc_config)
$(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 ($(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)
$(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: kernel software device-map grub.shell grub dev.tar.bz2 motd.sh
2010-07-09 05:22:37 +02:00
mkdir -p loop
mount -o noatime $(NBD_DEV)p1 loop
2010-07-09 05:22:37 +02:00
mkdir -p gentoo
mount -o bind $(CHROOT) gentoo
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
rsync -ax $(COPY_ARGS) gentoo/ 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
ifeq ($(UDEV),NO)
tar jxf dev.tar.bz2 -C loop/dev
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
rm -f loop/etc/runlevels/sysinit/udev
else
ln -sf /etc/init.d/udev loop/etc/runlevels/sysinit/udev
endif
2010-07-09 05:22:37 +02:00
umount gentoo
rmdir gentoo
umount loop
2010-07-09 05:22:37 +02:00
sleep 3
rmdir loop
qemu-nbd -d $(NBD_DEV)
2010-07-09 05:22:37 +02:00
touch image
$(QCOW_IMAGE): $(RAW_IMAGE) image
qemu-img convert -f raw -O qcow2 -c $(RAW_IMAGE) $(QCOW_IMAGE)
qcow: $(QCOW_IMAGE)
$(XVA_IMAGE): $(RAW_IMAGE) 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): $(RAW_IMAGE) image
qemu-img convert -f raw -O vmdk $(RAW_IMAGE) $(VMDK_IMAGE)
vmdk: $(VMDK_IMAGE)
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
$(STAGE4_TARBALL): software kernel rsync-excludes rsync-excludes-critical
mkdir -p stage4
mkdir -p gentoo
mount -o bind $(CHROOT) gentoo
tar -jScf "$(STAGE4_TARBALL).tmp" --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" "$(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
stage4: $(STAGE4_TARBALL)
umount:
ifdef PKGDIR
umount $(CHROOT)/var/portage/packages
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
umount $(CHROOT)/var/tmp
umount $(CHROOT)/dev
umount $(CHROOT)/proc
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
rm -f parted kernel grub stage3 software preproot sysconfig systools image partitions device-map
2010-11-06 09:41:15 +01:00
clean: umount remove_checkpoints
rm -f umount
2010-11-21 01:51:27 +01:00
rm -rf loop gentoo
2010-07-09 05:22:37 +02:00
rm -rf gentoo
rm -rf $(CHROOT)
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
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
rm -f *-stage4.tar.bz2
2010-11-06 09:41:15 +01:00
rm -f portage-latest.tar.bz2
2010-11-06 23:46:07 +01:00
2011-06-08 13:23:19 +02:00
.PHONY: qcow vmdk clean realclean distclean remove_checkpoints stage4 build-software