2011-07-07 03:40:20 +02:00
|
|
|
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
|
2011-06-23 15:09:41 +02:00
|
|
|
XVA_IMAGE = $(HOSTNAME).xva
|
2011-06-25 19:44:02 +02:00
|
|
|
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
|
2010-12-20 05:04:11 +01:00
|
|
|
REMOVE_PORTAGE_TREE = YES
|
2011-01-21 00:17:32 +01:00
|
|
|
ENABLE_SSHD = NO
|
2010-12-20 05:04:11 +01:00
|
|
|
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
|
2011-02-05 06:06:23 +01:00
|
|
|
EXTERNAL_KERNEL = NO
|
2011-04-02 15:56:19 +02:00
|
|
|
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
|
2011-06-23 03:42:59 +02:00
|
|
|
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
|
2011-04-06 16:25:05 +02:00
|
|
|
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
|
2011-06-25 04:48:07 +02:00
|
|
|
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
|
2011-06-29 06:43:12 +02:00
|
|
|
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
|
|
|
|
|
|
2011-06-29 06:43:12 +02:00
|
|
|
# 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
|
2011-06-29 06:43:12 +02:00
|
|
|
|
|
|
|
|
# Allow user to override variables
|
2010-12-07 02:19:37 +01:00
|
|
|
-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
|
|
|
|
2011-02-25 05:20:38 +01:00
|
|
|
inroot := chroot $(CHROOT)
|
2011-06-29 06:43:12 +02:00
|
|
|
stage4-exists := $(wildcard $(STAGE4_TARBALL))
|
|
|
|
|
software-deps := stage3
|
2011-02-25 05:20:38 +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
|
|
|
ifneq ($(SOFTWARE),0)
|
2011-06-29 06:43:12 +02:00
|
|
|
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
|
|
|
|
|
|
2011-06-29 06:43:12 +02:00
|
|
|
ifeq ($(REMOVE_PORTAGE_TREE),YES)
|
|
|
|
|
COPY_ARGS += --exclude=usr/portage
|
|
|
|
|
endif
|
|
|
|
|
|
2010-12-20 05:04:11 +01:00
|
|
|
ifeq ($(CHANGE_PASSWORD),YES)
|
2011-01-12 04:47:14 +01:00
|
|
|
ifdef ROOT_PASSWORD
|
2011-02-25 05:20:38 +01:00
|
|
|
change_password = $(inroot) usermod -p '$(ROOT_PASSWORD)' root
|
2011-01-12 04:47:14 +01:00
|
|
|
else
|
2011-02-25 05:20:38 +01:00
|
|
|
change_password = $(inroot) passwd -d root; $(inroot) passwd -e root
|
2011-01-12 04:47:14 +01:00
|
|
|
endif
|
2010-12-20 05:04:11 +01:00
|
|
|
endif
|
|
|
|
|
|
2011-02-25 05:20:38 +01:00
|
|
|
gcc_config = $(inroot) gcc-config 1
|
2010-11-27 22:43:40 +01:00
|
|
|
|
2011-04-02 15:56:19 +02:00
|
|
|
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)
|
|
|
|
|
|
2010-11-05 04:10:54 +01:00
|
|
|
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
|
2010-07-10 20:04:04 +02:00
|
|
|
|
2010-10-03 17:29:27 +02:00
|
|
|
qemu-nbd -c $(NBD_DEV) $(RAW_IMAGE)
|
2010-07-10 20:04:04 +02:00
|
|
|
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)
|
2010-07-10 20:04:04 +02:00
|
|
|
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; \
|
2010-07-10 20:04:04 +02:00
|
|
|
fi
|
|
|
|
|
touch mounts
|
|
|
|
|
|
2011-01-20 03:16:13 +01:00
|
|
|
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
|
2011-01-20 03:16:13 +01:00
|
|
|
touch sync_portage
|
|
|
|
|
|
|
|
|
|
portage: sync_portage stage3
|
2010-11-05 06:53:07 +01:00
|
|
|
tar xjf portage-latest.tar.bz2 -C $(CHROOT)/usr
|
2011-06-29 06:43:12 +02:00
|
|
|
ifdef PKGDIR
|
|
|
|
|
mkdir -p $(CHROOT)/var/portage/packages
|
|
|
|
|
mount -o bind "$(PKGDIR)" $(CHROOT)/var/portage/packages
|
|
|
|
|
endif
|
2010-07-10 20:04:04 +02:00
|
|
|
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
|
2010-07-10 20:04:04 +02:00
|
|
|
touch preproot
|
|
|
|
|
|
2010-11-06 09:41:15 +01:00
|
|
|
stage3:
|
|
|
|
|
mkdir -p $(CHROOT)
|
2011-06-29 06:43:12 +02:00
|
|
|
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
|
2010-07-10 20:04:04 +02:00
|
|
|
touch stage3
|
|
|
|
|
|
2010-11-05 06:53:07 +01:00
|
|
|
compile_options: portage make.conf locale.gen $(PACKAGE_FILES)
|
2010-07-10 20:04:04 +02:00
|
|
|
cp make.conf $(CHROOT)/etc/make.conf
|
2011-06-29 06:43:12 +02:00
|
|
|
ifdef PKGDIR
|
|
|
|
|
echo PKGDIR="/var/portage/packages" >> $(CHROOT)/etc/make.conf
|
|
|
|
|
endif
|
2010-09-18 08:43:14 +02:00
|
|
|
echo ACCEPT_KEYWORDS=$(ACCEPT_KEYWORDS) >> $(CHROOT)/etc/make.conf
|
2010-07-10 20:04:04 +02:00
|
|
|
cp locale.gen $(CHROOT)/etc/locale.gen
|
2011-02-25 05:20:38 +01:00
|
|
|
$(inroot) locale-gen
|
2010-07-10 20:04:04 +02:00
|
|
|
mkdir -p $(CHROOT)/etc/portage
|
2011-06-29 06:43:12 +02:00
|
|
|
ifdef PACKAGE_FILES
|
|
|
|
|
cp $(PACKAGE_FILES) $(CHROOT)/etc/portage/
|
|
|
|
|
endif
|
2010-07-10 20:04:04 +02:00
|
|
|
touch compile_options
|
|
|
|
|
|
|
|
|
|
base_system: mounts compile_options
|
|
|
|
|
touch base_system
|
2010-07-09 05:22:37 +02:00
|
|
|
|
2011-06-29 06:43:12 +02:00
|
|
|
kernel: base_system $(KERNEL_CONFIG) kernel.sh
|
2011-02-25 05:20:38 +01:00
|
|
|
$(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
|
2011-02-05 06:06:23 +01:00
|
|
|
ifneq ($(EXTERNAL_KERNEL),YES)
|
2011-06-29 06:43:12 +02:00
|
|
|
cp $(KERNEL_CONFIG) $(CHROOT)/root/kernel.config
|
2011-07-18 00:10:57 +02:00
|
|
|
cp kernel.sh $(CHROOT)/tmp/kernel.sh
|
2011-06-29 06:43:12 +02:00
|
|
|
KERNEL=$(KERNEL) EMERGE="$(EMERGE)" USEPKG="$(USEPKG)" MAKEOPTS="$(MAKEOPTS)" \
|
2011-07-18 00:10:57 +02:00
|
|
|
$(inroot) /bin/sh /tmp/kernel.sh
|
|
|
|
|
rm -f $(CHROOT)/tmp/kernel.sh
|
2011-02-05 06:06:23 +01:00
|
|
|
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
|
2011-06-23 03:42:59 +02:00
|
|
|
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)
|
2011-06-29 06:43:12 +02:00
|
|
|
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
|
2011-06-29 06:43:12 +02:00
|
|
|
ifeq ($(HEADLESS),YES)
|
2011-07-01 19:58:26 +02:00
|
|
|
sed -i 's/^#s0:/s0:/' $(CHROOT)/etc/inittab
|
2011-06-29 06:43:12 +02:00
|
|
|
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
|
2010-12-17 03:03:48 +01:00
|
|
|
echo 'dhcp_eth0="release"' >> $(CHROOT)/etc/conf.d/net
|
2011-02-25 05:20:38 +01:00
|
|
|
$(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
|
|
|
|
|
|
2010-07-10 20:04:04 +02:00
|
|
|
systools: sysconfig compile_options
|
2011-02-25 05:20:38 +01:00
|
|
|
$(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
|
2011-02-25 05:20:38 +01:00
|
|
|
$(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
|
2011-04-23 04:20:01 +02:00
|
|
|
$(inroot) $(EMERGE) -n $(USEPKG) net-misc/dhcp
|
2011-04-06 16:25:05 +02:00
|
|
|
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
|
2011-06-27 12:43:59 +02:00
|
|
|
endif
|
2010-07-09 05:22:37 +02:00
|
|
|
touch systools
|
2010-07-10 20:04:04 +02: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
|
|
|
grub: stage3 grub.conf kernel partitions
|
2011-02-05 06:06:23 +01:00
|
|
|
ifneq ($(EXTERNAL_KERNEL),YES)
|
2011-02-25 05:20:38 +01:00
|
|
|
$(inroot) $(EMERGE) -nN $(USEPKG) sys-boot/grub
|
2010-07-10 20:04:04 +02:00
|
|
|
cp grub.conf $(CHROOT)/boot/grub/grub.conf
|
2011-06-29 06:43:12 +02:00
|
|
|
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
|
2011-02-05 06:06:23 +01:00
|
|
|
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
|
2010-07-10 22:03:39 +02:00
|
|
|
cp etc-update.conf $(CHROOT)/etc/
|
2010-11-06 22:49:19 +01:00
|
|
|
|
|
|
|
|
# some packages, like, tar need xz-utils to unpack, but it not part of
|
|
|
|
|
# the stage3 so may not be installed yet
|
2011-02-25 05:20:38 +01:00
|
|
|
$(inroot) $(EMERGE) -1n $(USEPKG) app-arch/xz-utils
|
2010-11-06 22:49:19 +01:00
|
|
|
|
2011-02-25 05:20:38 +01:00
|
|
|
$(inroot) $(EMERGE) $(USEPKG) --update --newuse --deep `cat $(WORLD)`
|
2010-11-27 22:43:40 +01:00
|
|
|
$(gcc_config)
|
2010-11-06 22:49:19 +01:00
|
|
|
|
|
|
|
|
# Need gentoolkit to run revdep-rebuild
|
2011-02-25 05:20:38 +01:00
|
|
|
$(inroot) $(EMERGE) -1n $(USEPKG) app-portage/gentoolkit
|
|
|
|
|
$(inroot) revdep-rebuild -i
|
2010-11-06 22:49:19 +01:00
|
|
|
|
2010-07-09 05:22:37 +02:00
|
|
|
cp issue $(CHROOT)/etc/issue
|
2010-11-27 22:43:40 +01:00
|
|
|
$(gcc_config)
|
2011-02-25 05:20:38 +01:00
|
|
|
$(inroot) $(EMERGE) $(USEPKG) --update --newuse --deep world
|
2011-04-02 15:56:19 +02:00
|
|
|
# Per bug #357009
|
2011-06-08 13:23:19 +02:00
|
|
|
$(inroot) eselect python update --ignore 3.*
|
2011-02-25 05:20:38 +01:00
|
|
|
$(inroot) $(EMERGE) --depclean --with-bdeps=n
|
2010-11-27 22:43:40 +01:00
|
|
|
$(gcc_config)
|
2011-02-25 05:20:38 +01:00
|
|
|
$(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
|
2011-06-29 06:43:12 +02:00
|
|
|
ifeq ($(ENABLE_SSHD),YES)
|
|
|
|
|
$(inroot) /sbin/rc-update add sshd default
|
|
|
|
|
endif
|
2010-12-20 05:04:11 +01:00
|
|
|
$(change_password)
|
2011-07-15 17:25:54 +02:00
|
|
|
ifeq ($(PRUNE_CRITICAL),YES)
|
2011-06-29 06:43:12 +02:00
|
|
|
$(inroot) $(EMERGE) -C `cat $(CRITICAL)`
|
2011-07-18 00:10:57 +02:00
|
|
|
ifeq ($(DASH),YES)
|
|
|
|
|
$(inroot) $(EMERGE) -C app-shells/bash
|
|
|
|
|
endif
|
2011-06-29 06:43:12 +02:00
|
|
|
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
|
|
|
|
2011-06-29 06:43:12 +02:00
|
|
|
software: $(software-deps)
|
2011-06-23 03:42:59 +02:00
|
|
|
ifneq ($(PKGLIST),0)
|
2011-06-27 12:43:59 +02:00
|
|
|
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)
|
2011-06-23 03:42:59 +02:00
|
|
|
endif
|
2010-07-09 05:22:37 +02:00
|
|
|
touch software
|
|
|
|
|
|
|
|
|
|
device-map: $(RAW_IMAGE)
|
|
|
|
|
echo '(hd0) ' $(RAW_IMAGE) > device-map
|
|
|
|
|
|
2011-07-18 00:10:57 +02:00
|
|
|
image: kernel software device-map grub.shell grub dev.tar.bz2 motd.sh
|
2010-07-09 05:22:37 +02:00
|
|
|
mkdir -p loop
|
2010-11-05 06:53:07 +01:00
|
|
|
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/
|
2011-07-12 22:15:55 +02:00
|
|
|
./motd.sh $(EXTERNAL_KERNEL) $(VIRTIO) $(DISK_SIZE) $(SWAP_SIZE) $(UDEV) $(DASH) $(ARCH) > loop/etc/motd
|
2011-02-05 06:06:23 +01:00
|
|
|
ifneq ($(EXTERNAL_KERNEL),YES)
|
2010-07-09 05:22:37 +02:00
|
|
|
loop/sbin/grub --device-map=device-map --no-floppy --batch < grub.shell
|
2011-04-02 15:56:19 +02:00
|
|
|
endif
|
|
|
|
|
ifeq ($(UDEV),NO)
|
2011-06-23 03:42:59 +02:00
|
|
|
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
|
2011-09-16 16:37:35 +02:00
|
|
|
else
|
2011-07-21 12:32:09 +02:00
|
|
|
ln -sf /etc/init.d/udev loop/etc/runlevels/sysinit/udev
|
2011-02-05 06:06:23 +01:00
|
|
|
endif
|
2010-07-09 05:22:37 +02:00
|
|
|
umount gentoo
|
2010-11-05 06:53:07 +01:00
|
|
|
rmdir gentoo
|
|
|
|
|
umount loop
|
2010-07-09 05:22:37 +02:00
|
|
|
sleep 3
|
|
|
|
|
rmdir loop
|
2010-10-03 17:29:27 +02:00
|
|
|
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)
|
|
|
|
|
|
2011-06-23 15:09:41 +02:00
|
|
|
$(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
|
2011-06-29 06:43:12 +02:00
|
|
|
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
|
2011-06-29 06:43:12 +02:00
|
|
|
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)
|
|
|
|
|
|
|
|
|
|
|
2010-11-05 13:06:13 +01:00
|
|
|
umount:
|
2011-06-29 06:43:12 +02:00
|
|
|
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:
|
2011-01-20 03:16:13 +01:00
|
|
|
rm -f mounts compile_options base_system portage sync_portage
|
2011-02-05 06:06:23 +01:00
|
|
|
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
|
2011-01-23 13:48:58 +01:00
|
|
|
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-05 13:06:13 +01:00
|
|
|
|
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
|