keremet/mkimage-profiles
2
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity
2e36347f71
mkimage-profiles/features.in/pack/config.mk

56 lines
1.3 KiB
Makefile
Raw Normal View History

initial specific VM formats support Raw disk images are convenient and universal but there are custom formats like Qemu's qcow2 providing additional features, e.g. copy-on-write or space savings. All of this ultimately belongs to mkimage but in the mean time has been implemented here as well.
2012-06-19 17:51:56 +04:00
### this might really belong to build-*...
initial build-vm feature Yes, mkimage-profiles is now able to build VM disk images. So far the support is pretty basic: - a single hard drive image with a single partition/FS - only stock root password is configurable - LILO is hardwired as a bootloader The resulting images tend to boot under qemu/kvm though. Please see doc/vm.txt for the warning regarding additional privileges and setup required. This was started back in February but I still hoped to avoid sudo/privileged helper (and libguestfs is almost as undistributable as can be)... Thanks: - http://blog.quinthar.com/2008/07/building-1gb-bootable-qemu-image-using.html - Alexey Morarash who reworked that as https://github.com/tuxofil/linsygen - led@, legion@, vitty@, aen@ for providing advice and inspiration
2012-06-18 22:00:32 +04:00
# distributions
official {distro,ve}/* support This is quite a large-scale change since mkimage-profiles got used to baking distributions over the last year, and virtual environments are quite different, so e.g. image.in/Makefile had to be split in two with the main part of it moved into features.in/iso/lib/. Short overview: - features.in/Makefile: lib/ support (supporting VE images requires dynamic modifications to image.in/Makefile before starting the build; the most natural way to achieve that seems to use features mechanism along with makefile include dir) - packaging format related part moved into features.in/pack (should be better prepared for diversity either) - features.in/iso renamed to features.in/build-distro - features.in/ve renamed to features.in/build-ve + NB: these could not be merged as e.g. features.in/build due to completely different script hooks - lib/image.mk renamed to lib/build.mk - image, config, log postprocessing moved downstream - added a sort of a topping in the form of lib/sugar.mk - assorted style fixups (like ifeq usage) - clean.mk: reliability fix (the problem was observed by Oleg Ivanov and me too but finally it did get the attention quantum) - reviewed, updated and extended docs + QUICKSTART: should be[come] a step-by-step guide (thanks Leo-sp50 for prodiving feedback)
2011-10-06 12:46:31 +04:00
DISTRO_EXTS := .iso
pack: ensure e2k support on e2k The culprit is that e2k has exactly one kernel flavour available at the moment, elbrus-def (there used to be per-CPU flavours in p8 times -- elbrus-{4c,8c,1cp} -- but these aren't needed anymore), but there are no std-def/un-def kernels or provides available. There's more to it, but lacking a kernel is critical. Maybe other arches might do similar things when needed, or maybe this gets reverted in favour of a more generic approach; but patching all starterkits or messing with p9.mk per-arch (while leaving out regular builds or any other image that might just build) looks worse.
2020-08-21 18:23:38 +03:00
use/pack::
introduced add_feature function The features might get copy-pasted (or even copied-and-pruned) when initialized; there's an unneccessary duplication of the function name in the line adding it to FEATURES list, thus prone to being forgotten and causing some havoc later on. It was wrong in the first place but tackling this with some double-colon rules ran into terminality issues, and further tortures were considered unneccessary. The current solution isn't perfect (no completely transparent function name registration upon corresponding target being called) but at least it is an improvement...
2011-11-16 19:58:42 +04:00
@$(call add_feature)
official {distro,ve}/* support This is quite a large-scale change since mkimage-profiles got used to baking distributions over the last year, and virtual environments are quite different, so e.g. image.in/Makefile had to be split in two with the main part of it moved into features.in/iso/lib/. Short overview: - features.in/Makefile: lib/ support (supporting VE images requires dynamic modifications to image.in/Makefile before starting the build; the most natural way to achieve that seems to use features mechanism along with makefile include dir) - packaging format related part moved into features.in/pack (should be better prepared for diversity either) - features.in/iso renamed to features.in/build-distro - features.in/ve renamed to features.in/build-ve + NB: these could not be merged as e.g. features.in/build due to completely different script hooks - lib/image.mk renamed to lib/build.mk - image, config, log postprocessing moved downstream - added a sort of a topping in the form of lib/sugar.mk - assorted style fixups (like ifeq usage) - clean.mk: reliability fix (the problem was observed by Oleg Ivanov and me too but finally it did get the attention quantum) - reviewed, updated and extended docs + QUICKSTART: should be[come] a step-by-step guide (thanks Leo-sp50 for prodiving feedback)
2011-10-06 12:46:31 +04:00
pack: ensure e2k support on e2k The culprit is that e2k has exactly one kernel flavour available at the moment, elbrus-def (there used to be per-CPU flavours in p8 times -- elbrus-{4c,8c,1cp} -- but these aren't needed anymore), but there are no std-def/un-def kernels or provides available. There's more to it, but lacking a kernel is critical. Maybe other arches might do similar things when needed, or maybe this gets reverted in favour of a more generic approach; but patching all starterkits or messing with p9.mk per-arch (while leaving out regular builds or any other image that might just build) looks worse.
2020-08-21 18:23:38 +03:00
ifeq (,$(filter-out e2k%,$(ARCH)))
use/pack:: use/e2k; @:
endif
rework isoboot support beyond x86 Every .iso was assumed to be bootable since the very beginning[*], and isoboot images were deemed to be x86 isolinux ones; this didn't change with basic ppc/armh support as I never ran into hardware that would _boot_ those ISOs, not only run the code, and it was only e2k isodata project that finally forced this refactoring. It's still not perfect: pack and syslinux features still end up somewhat interwoven, and too much places care for architecture the image is being built for (instead of archdep features tossing their appropriate bits and pieces in). Should help: - any-arch regarding isodata images; - {x86,aarch64}/efi by decoupling isoboot and isolinux; - ppc{,64} as introducing yaboot support will be easier now; - mipsel{,64} too, hopefully. * I knew of school addon images baked with mkimage-profiles-desktop but postponed and then neglected the whole problem for years...
2018-07-25 15:40:56 +03:00
# fallback type is isodata, might get set elsewhere to produce bootable iso
use/pack/iso: use/pack
@$(call try,IMAGE_PACKTYPE,isodata)
official {distro,ve}/* support This is quite a large-scale change since mkimage-profiles got used to baking distributions over the last year, and virtual environments are quite different, so e.g. image.in/Makefile had to be split in two with the main part of it moved into features.in/iso/lib/. Short overview: - features.in/Makefile: lib/ support (supporting VE images requires dynamic modifications to image.in/Makefile before starting the build; the most natural way to achieve that seems to use features mechanism along with makefile include dir) - packaging format related part moved into features.in/pack (should be better prepared for diversity either) - features.in/iso renamed to features.in/build-distro - features.in/ve renamed to features.in/build-ve + NB: these could not be merged as e.g. features.in/build due to completely different script hooks - lib/image.mk renamed to lib/build.mk - image, config, log postprocessing moved downstream - added a sort of a topping in the form of lib/sugar.mk - assorted style fixups (like ifeq usage) - clean.mk: reliability fix (the problem was observed by Oleg Ivanov and me too but finally it did get the attention quantum) - reviewed, updated and extended docs + QUICKSTART: should be[come] a step-by-step guide (thanks Leo-sp50 for prodiving feedback)
2011-10-06 12:46:31 +04:00
initial build-vm feature Yes, mkimage-profiles is now able to build VM disk images. So far the support is pretty basic: - a single hard drive image with a single partition/FS - only stock root password is configurable - LILO is hardwired as a bootloader The resulting images tend to boot under qemu/kvm though. Please see doc/vm.txt for the warning regarding additional privileges and setup required. This was started back in February but I still hoped to avoid sudo/privileged helper (and libguestfs is almost as undistributable as can be)... Thanks: - http://blog.quinthar.com/2008/07/building-1gb-bootable-qemu-image-using.html - Alexey Morarash who reworked that as https://github.com/tuxofil/linsygen - led@, legion@, vitty@, aen@ for providing advice and inspiration
2012-06-18 22:00:32 +04:00
# virtual environments
Enable ubifs packing of result. An example for sam9x25-ek: make \ PACK_UBI_MIN_IO_SIZE=2KiB \ PACK_UBIFS_OPTS="-e 124KiB -c 1984" \ PACK_UBI_OPTS="-p 128KiB -s 2048" \ PACK_UBI_VOL_TYPE=dynamic \ PACK_UBI_VOL_NAME=rootfs \ PACK_UBI_VOL_FLAGS=autoresize \ HSH_EXCLUDE_DOCS=1 ARCH=arm APTCONF=apt.conf.sisyphus.arm ve/generic.ubifs https://bugzilla.altlinux.org/show_bug.cgi?id=27994#c0
2012-11-17 22:45:27 +04:00
VE_ARCHIVES := tar cpio ubifs
added support for cpio and xz Actually this is the proper rewrite that was looming ever since tgz support was introduced: there are multiple archive formats supported by mkimage, and there are multiple compression methods available as well. So the bullet got bitten yet again along with the "goal parser" which should be more straightforward by now. Thanks dkr@ and mithraen@ for the inspiration of this evening.
2011-11-25 00:13:31 +04:00
VE_COMPRESSORS := gz xz# there's no sense in bzip2 by now
VE_ZIPS := $(call addsuffices, \
$(addprefix .,$(VE_COMPRESSORS)), \
$(VE_ARCHIVES))# tar.gz cpio.xz ...
VE_EXTS := $(sort $(addprefix .,$(VE_ARCHIVES) $(VE_ZIPS)))# .tar .tar.gz ...
official {distro,ve}/* support This is quite a large-scale change since mkimage-profiles got used to baking distributions over the last year, and virtual environments are quite different, so e.g. image.in/Makefile had to be split in two with the main part of it moved into features.in/iso/lib/. Short overview: - features.in/Makefile: lib/ support (supporting VE images requires dynamic modifications to image.in/Makefile before starting the build; the most natural way to achieve that seems to use features mechanism along with makefile include dir) - packaging format related part moved into features.in/pack (should be better prepared for diversity either) - features.in/iso renamed to features.in/build-distro - features.in/ve renamed to features.in/build-ve + NB: these could not be merged as e.g. features.in/build due to completely different script hooks - lib/image.mk renamed to lib/build.mk - image, config, log postprocessing moved downstream - added a sort of a topping in the form of lib/sugar.mk - assorted style fixups (like ifeq usage) - clean.mk: reliability fix (the problem was observed by Oleg Ivanov and me too but finally it did get the attention quantum) - reviewed, updated and extended docs + QUICKSTART: should be[come] a step-by-step guide (thanks Leo-sp50 for prodiving feedback)
2011-10-06 12:46:31 +04:00
added support for cpio and xz Actually this is the proper rewrite that was looming ever since tgz support was introduced: there are multiple archive formats supported by mkimage, and there are multiple compression methods available as well. So the bullet got bitten yet again along with the "goal parser" which should be more straightforward by now. Thanks dkr@ and mithraen@ for the inspiration of this evening.
2011-11-25 00:13:31 +04:00
# generate rules for archive/compressor combinations
define PACK_containers
use/pack/$(1): use/pack
@$$(call set,IMAGE_PACKTYPE,$(1))
endef
define PACK_compressors
use/pack/$(1).$(2): use/pack/$(1)
@$$(call set,IMAGE_COMPRESS,$(2))
endef
build-vm, pack: implement tar, tar.gz, tar.xz support for vm/* target build-vm ceases to be a target for building only virtual machine images. Now it can be used to build tarballs designed for installation on real machines. This commit is the result of transferring the required functionality from build-mr (mipsel rootfs) by Ivan Melnikov <iv@altlinux.org>. NB: mike@ strongly objected to this dilution but gave up eventually; the whole kernel/build-vm/tar2fs/pack mess should be split into distinct layers busy with their own responsibilities: 1) a tarball with kernel is done without tar2fs at all (and no build-vm bits should be needed either, maybe it's worth splitting and renaming as "vm" meaning disk image for some armh board is grossly misleading); 2) a tarball with kernel can be further (multi-)packed as, well, (compressed) tarball and a disk image (only the latter one should employ build-vm/tar2fs); 3) compression should be done in pack feature style, preferably described once and not duplicated all over the profile for every single new kind of its output. In the mean time, running into this and moving no further starts to hurt more than it could help.
2019-05-19 09:23:16 +03:00
ifeq (ve,$(IMAGE_CLASS))
added support for cpio and xz Actually this is the proper rewrite that was looming ever since tgz support was introduced: there are multiple archive formats supported by mkimage, and there are multiple compression methods available as well. So the bullet got bitten yet again along with the "goal parser" which should be more straightforward by now. Thanks dkr@ and mithraen@ for the inspiration of this evening.
2011-11-25 00:13:31 +04:00
$(foreach c,$(VE_ARCHIVES), \
$(eval $(call PACK_containers,$(c))) \
$(foreach z,$(VE_COMPRESSORS), \
$(eval $(call PACK_compressors,$(c),$(z)))))
build-vm, pack: implement tar, tar.gz, tar.xz support for vm/* target build-vm ceases to be a target for building only virtual machine images. Now it can be used to build tarballs designed for installation on real machines. This commit is the result of transferring the required functionality from build-mr (mipsel rootfs) by Ivan Melnikov <iv@altlinux.org>. NB: mike@ strongly objected to this dilution but gave up eventually; the whole kernel/build-vm/tar2fs/pack mess should be split into distinct layers busy with their own responsibilities: 1) a tarball with kernel is done without tar2fs at all (and no build-vm bits should be needed either, maybe it's worth splitting and renaming as "vm" meaning disk image for some armh board is grossly misleading); 2) a tarball with kernel can be further (multi-)packed as, well, (compressed) tarball and a disk image (only the latter one should employ build-vm/tar2fs); 3) compression should be done in pack feature style, preferably described once and not duplicated all over the profile for every single new kind of its output. In the mean time, running into this and moving no further starts to hurt more than it could help.
2019-05-19 09:23:16 +03:00
endif
initial build-vm feature Yes, mkimage-profiles is now able to build VM disk images. So far the support is pretty basic: - a single hard drive image with a single partition/FS - only stock root password is configurable - LILO is hardwired as a bootloader The resulting images tend to boot under qemu/kvm though. Please see doc/vm.txt for the warning regarding additional privileges and setup required. This was started back in February but I still hoped to avoid sudo/privileged helper (and libguestfs is almost as undistributable as can be)... Thanks: - http://blog.quinthar.com/2008/07/building-1gb-bootable-qemu-image-using.html - Alexey Morarash who reworked that as https://github.com/tuxofil/linsygen - led@, legion@, vitty@, aen@ for providing advice and inspiration
2012-06-18 22:00:32 +04:00
build-vm, pack: implement tar, tar.gz, tar.xz support for vm/* target build-vm ceases to be a target for building only virtual machine images. Now it can be used to build tarballs designed for installation on real machines. This commit is the result of transferring the required functionality from build-mr (mipsel rootfs) by Ivan Melnikov <iv@altlinux.org>. NB: mike@ strongly objected to this dilution but gave up eventually; the whole kernel/build-vm/tar2fs/pack mess should be split into distinct layers busy with their own responsibilities: 1) a tarball with kernel is done without tar2fs at all (and no build-vm bits should be needed either, maybe it's worth splitting and renaming as "vm" meaning disk image for some armh board is grossly misleading); 2) a tarball with kernel can be further (multi-)packed as, well, (compressed) tarball and a disk image (only the latter one should employ build-vm/tar2fs); 3) compression should be done in pack feature style, preferably described once and not duplicated all over the profile for every single new kind of its output. In the mean time, running into this and moving no further starts to hurt more than it could help.
2019-05-19 09:23:16 +03:00
# extensions for buld-vm
vm: Add ability to build .img.xz So we are can to build compressed img files.
2021-04-27 17:24:35 +03:00
VM_EXTS := .tar .tar.gz .tar.xz .img .img.xz .qcow2 .qcow2c .vdi .vmdk .vhd
build-vm, main.mk, pack: add recovery.tar recovery.tar needed for tavolga (mipsel). This commit is the result of transferring the required functionality from build-mr (mipsel rootfs). This change uses external tool to build Tavolga-compatible recovery.tar. This simplifies the logic and avoids having recovery workdir in the profile. After this change, m-p will require tavolga-image-tools >= 3.0.
2019-05-19 12:39:04 +03:00
VM_TAVOLGA_EXTS := .recovery.tar
build-vm, pack: implement tar, tar.gz, tar.xz support for vm/* target build-vm ceases to be a target for building only virtual machine images. Now it can be used to build tarballs designed for installation on real machines. This commit is the result of transferring the required functionality from build-mr (mipsel rootfs) by Ivan Melnikov <iv@altlinux.org>. NB: mike@ strongly objected to this dilution but gave up eventually; the whole kernel/build-vm/tar2fs/pack mess should be split into distinct layers busy with their own responsibilities: 1) a tarball with kernel is done without tar2fs at all (and no build-vm bits should be needed either, maybe it's worth splitting and renaming as "vm" meaning disk image for some armh board is grossly misleading); 2) a tarball with kernel can be further (multi-)packed as, well, (compressed) tarball and a disk image (only the latter one should employ build-vm/tar2fs); 3) compression should be done in pack feature style, preferably described once and not duplicated all over the profile for every single new kind of its output. In the mean time, running into this and moving no further starts to hurt more than it could help.
2019-05-19 09:23:16 +03:00
ifeq (vm,$(IMAGE_CLASS))
initial build-vm feature Yes, mkimage-profiles is now able to build VM disk images. So far the support is pretty basic: - a single hard drive image with a single partition/FS - only stock root password is configurable - LILO is hardwired as a bootloader The resulting images tend to boot under qemu/kvm though. Please see doc/vm.txt for the warning regarding additional privileges and setup required. This was started back in February but I still hoped to avoid sudo/privileged helper (and libguestfs is almost as undistributable as can be)... Thanks: - http://blog.quinthar.com/2008/07/building-1gb-bootable-qemu-image-using.html - Alexey Morarash who reworked that as https://github.com/tuxofil/linsygen - led@, legion@, vitty@, aen@ for providing advice and inspiration
2012-06-18 22:00:32 +04:00
initial specific VM formats support Raw disk images are convenient and universal but there are custom formats like Qemu's qcow2 providing additional features, e.g. copy-on-write or space savings. All of this ultimately belongs to mkimage but in the mean time has been implemented here as well.
2012-06-19 17:51:56 +04:00
$(VM_EXTS:.%=use/pack/%): use/pack; @:
build-vm, pack: implement tar, tar.gz, tar.xz support for vm/* target build-vm ceases to be a target for building only virtual machine images. Now it can be used to build tarballs designed for installation on real machines. This commit is the result of transferring the required functionality from build-mr (mipsel rootfs) by Ivan Melnikov <iv@altlinux.org>. NB: mike@ strongly objected to this dilution but gave up eventually; the whole kernel/build-vm/tar2fs/pack mess should be split into distinct layers busy with their own responsibilities: 1) a tarball with kernel is done without tar2fs at all (and no build-vm bits should be needed either, maybe it's worth splitting and renaming as "vm" meaning disk image for some armh board is grossly misleading); 2) a tarball with kernel can be further (multi-)packed as, well, (compressed) tarball and a disk image (only the latter one should employ build-vm/tar2fs); 3) compression should be done in pack feature style, preferably described once and not duplicated all over the profile for every single new kind of its output. In the mean time, running into this and moving no further starts to hurt more than it could help.
2019-05-19 09:23:16 +03:00
build-vm, main.mk, pack: add recovery.tar recovery.tar needed for tavolga (mipsel). This commit is the result of transferring the required functionality from build-mr (mipsel rootfs). This change uses external tool to build Tavolga-compatible recovery.tar. This simplifies the logic and avoids having recovery workdir in the profile. After this change, m-p will require tavolga-image-tools >= 3.0.
2019-05-19 12:39:04 +03:00
ifeq (mipsel,$(ARCH))
use/pack/recovery.tar: use/pack/tar; @:
endif
build-vm, pack: implement tar, tar.gz, tar.xz support for vm/* target build-vm ceases to be a target for building only virtual machine images. Now it can be used to build tarballs designed for installation on real machines. This commit is the result of transferring the required functionality from build-mr (mipsel rootfs) by Ivan Melnikov <iv@altlinux.org>. NB: mike@ strongly objected to this dilution but gave up eventually; the whole kernel/build-vm/tar2fs/pack mess should be split into distinct layers busy with their own responsibilities: 1) a tarball with kernel is done without tar2fs at all (and no build-vm bits should be needed either, maybe it's worth splitting and renaming as "vm" meaning disk image for some armh board is grossly misleading); 2) a tarball with kernel can be further (multi-)packed as, well, (compressed) tarball and a disk image (only the latter one should employ build-vm/tar2fs); 3) compression should be done in pack feature style, preferably described once and not duplicated all over the profile for every single new kind of its output. In the mean time, running into this and moving no further starts to hurt more than it could help.
2019-05-19 09:23:16 +03:00
endif
Reference in New Issue Copy Permalink