keremet/mkimage-profiles
2
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity
cd88029ecf
mkimage-profiles/sub.in/stage2/Makefile

75 lines
2.0 KiB
Makefile
Raw Normal View History

stage2 based live subprofiles, updated docs - introduced generic stage2 subprofile (non-standalone) - ported installer and rescue over to stage2/{install2,rescue} - initial stage2/live (needs more work for sure) - use make-initrd-propagator - updated and somewhat extended doc/ NB: mind #26133, #26134
2011-08-20 13:55:05 +04:00
# step 4: build a stage2 subprofile (custom livecd)
# NB: stage2 is not standalone but rather a common base
# for all livecd images (installer, live, rescue)
initial rescue image NB: this implementation is awfully cut-n-paste one, there are lots of common code with install2 which are subject to careful surgery
2011-08-18 23:56:12 +04:00
ifndef GLOBAL_BUILDDIR
$(error GLOBAL_BUILDDIR not defined)
endif
default: all
include $(GLOBAL_BUILDDIR)/distcfg.mk
include $(GLOBAL_BUILDDIR)/functions.mk
include $(MKIMAGE_PREFIX)/config.mk
sub.in/stage2: Added copy-tree to stage2 stage2 only allows to run certain scripts and install packages, but sometimes one need just to copy something to stage2 (like stage1 does). How to use: put files under ./files directory with the same structure as on resulting image.
2016-05-23 12:10:22 +03:00
COPY_TREE = ./files
include $(MKIMAGE_PREFIX)/targets.mk
documentation: use paths relative to toplevel dir This change is done to reduce ambiguity in some cases; the previous intention has been to ease navigation when staying in a particular directory, now it's been changed in favour of convenient toplevel `git grep' in fact. Both variants have their pros and cons, I just find myself leaning to this one by now hence the commit. Feel free to provide constructive criticism :) Some path-related bitrot has also been fixed while at that.
2014-03-05 18:09:56 +04:00
# this might have been prepared
# by features.in/stage2/stage1/scripts.d/03-test-kernel
initial rescue image NB: this implementation is awfully cut-n-paste one, there are lots of common code with install2 which are subject to careful surgery
2011-08-18 23:56:12 +04:00
-include $(GLOBAL_BUILDDIR)/squashcfg.mk
stage2 based live subprofiles, updated docs - introduced generic stage2 subprofile (non-standalone) - ported installer and rescue over to stage2/{install2,rescue} - initial stage2/live (needs more work for sure) - use make-initrd-propagator - updated and somewhat extended doc/ NB: mind #26133, #26134
2011-08-20 13:55:05 +04:00
# this should be brought in by corresponding specific stage2 feature
include stage2cfg.mk
COMMON_PACKAGES and SYSTEM_PACKAGES It was clear that "common" isn't very apt for packages that will get *everywhere*, and became apparent when the need for a "base+live packages" variable arrived with powerbutton feature. So: - the former COMMON_PACKAGES are now SYSTEM_PACKAGES; - COMMON_PACKAGES act as "BASE+LIVE_PACKAGES". Note that SYSTEM_PACKAGES also got factored out from stage2 based features into stage2 subprofile itself; cleanups were due as well.
2011-09-03 13:34:53 +04:00
# requisite stuff
added plymouth feature An initial draft of it was done half a year ago but several tricky thingies had kept the code from showing up as it was rather brittle and incomplete. This implementation involves quite a few changes all over the place but finally works good enough for live and installer images. Please pay attention to the versions of these packages: - installer-feature-setup-plymouth (0.3.2-alt1+) - branding-altlinux-sisyphus (20110706-alt2+ if used) - plymouth (0.8.3-alt20.git20110406+) See also: - http://www.altlinux.org/Branding - http://www.altlinux.org/Plymouth
2012-06-13 23:07:10 +04:00
IMAGE_PACKAGES += $(SYSTEM_PACKAGES) $(STAGE2_PACKAGES)
COMMON_PACKAGES and SYSTEM_PACKAGES It was clear that "common" isn't very apt for packages that will get *everywhere*, and became apparent when the need for a "base+live packages" variable arrived with powerbutton feature. So: - the former COMMON_PACKAGES are now SYSTEM_PACKAGES; - COMMON_PACKAGES act as "BASE+LIVE_PACKAGES". Note that SYSTEM_PACKAGES also got factored out from stage2 based features into stage2 subprofile itself; cleanups were due as well.
2011-09-03 13:34:53 +04:00
initial rescue image NB: this implementation is awfully cut-n-paste one, there are lots of common code with install2 which are subject to careful surgery
2011-08-18 23:56:12 +04:00
# here we also try and come up with the stage1 kernel/modules, if any;
# no kernel flavour specified will result in no modules for stage1 vmlinuz
stage1, stage2: allow multiple kernels
2019-10-13 19:30:25 +03:00
# Update: for grub allowed choose kernels
ifeq (,$(filter-out x86_64 aarch64 ppc64le,$(ARCH)))
STAGE1_KFLAVOUR ?= $(KFLAVOURS)
else
initial rescue image NB: this implementation is awfully cut-n-paste one, there are lots of common code with install2 which are subject to careful surgery
2011-08-18 23:56:12 +04:00
STAGE1_KFLAVOUR ?= $(lastword $(KFLAVOURS))
stage1, stage2: allow multiple kernels
2019-10-13 19:30:25 +03:00
endif
initial rescue image NB: this implementation is awfully cut-n-paste one, there are lots of common code with install2 which are subject to careful surgery
2011-08-18 23:56:12 +04:00
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
ifeq (,$(STAGE1_KFLAVOUR))
initial rescue image NB: this implementation is awfully cut-n-paste one, there are lots of common code with install2 which are subject to careful surgery
2011-08-18 23:56:12 +04:00
$(error STAGE1_KFLAVOUR is utterly empty; cannot guess either)
endif
# need kernel modules only (which require corresponding kernel-image);
stage2: 99-elf-stats for squashfs tuning This kind of test was proposed by led@ to gather statistics on chroot's contents going to become squashfs (the script optimizations lowering added overhead from ~10 sec down to a subsecond range were also proposed by him). Intentionally not documented in doc/variables.txt due to the rather lowlevel nature of the probe (at least so far). The knobs involved are SQUASHFS (the additional effort kicks in only for "tight" case) and GLOBAL_SQUASHFS_SORT (must be non-empty for this extra overhead to occur). Additional experimentation is needed to find out whether the difference in squashfs size and performance is worth the trouble (seems the impact is non-zero but pretty minor).
2012-04-06 23:26:54 +04:00
# these go into work chroot; NB: no vmlinuz there (unless live-install)
implemented {THE,BASE,LIVE}_PACKAGES_REGEXP There were STAGE1_PACKAGES_REGEXP and MAIN_PACKAGES_REGEXP but adding more of those was postponed to avoid bloat and bitrot; THE_PACKAGES_REGEXP is needed for use/firmware now and looks like BASE_PACKAGES_REGEXP and LIVE_PACKAGES_REGEXP will be useful before too long either. Docs updated to include stage-specific package related vatiables.
2012-04-10 19:14:01 +04:00
IMAGE_PACKAGES_REGEXP += $(call kpackages, \
fix kpackages() API This function's got its argument order chosen for "aesthetical" reason of $(2) following $(1) in the macros but the logical order is exactly the opposite: we care for kernel flavour much more than for module set (which is dependent upon it). So while silent dropout of kernel-image if KFLAVOURS is set but KMODULES is empty could be fixed by testing for $(2) only, it looks like a good time to fix this discrepancy altogether.
2014-09-18 20:08:08 +04:00
$(STAGE1_KFLAVOUR), \
added plymouth feature An initial draft of it was done half a year ago but several tricky thingies had kept the code from showing up as it was rather brittle and incomplete. This implementation involves quite a few changes all over the place but finally works good enough for live and installer images. Please pay attention to the versions of these packages: - installer-feature-setup-plymouth (0.3.2-alt1+) - branding-altlinux-sisyphus (20110706-alt2+ if used) - plymouth (0.8.3-alt20.git20110406+) See also: - http://www.altlinux.org/Branding - http://www.altlinux.org/Plymouth
2012-06-13 23:07:10 +04:00
$(STAGE1_KMODULES) $(STAGE1_KMODULES_REGEXP) \
fix kpackages() API This function's got its argument order chosen for "aesthetical" reason of $(2) following $(1) in the macros but the logical order is exactly the opposite: we care for kernel flavour much more than for module set (which is dependent upon it). So while silent dropout of kernel-image if KFLAVOURS is set but KMODULES is empty could be fixed by testing for $(2) only, it looks like a good time to fix this discrepancy altogether.
2014-09-18 20:08:08 +04:00
$(STAGE2_KMODULES) $(STAGE2_KMODULES_REGEXP))
initial rescue image NB: this implementation is awfully cut-n-paste one, there are lots of common code with install2 which are subject to careful surgery
2011-08-18 23:56:12 +04:00
make-3.82 adaptation The issue actually hit image.in/Makefile: "metadata" target in features.in/metadata/lib/50-metadata.mk wasn't reached even if features.in/build-distro/lib/90-build-distro.mk would ACK that the "whatever" actions included "metadata"; thus Metadata/pkg-groups.tar wasn't created and the installer silently failed to install the .base system. Let's armour the rest of the cases where the order of inclusion might be important as well.
2012-10-10 17:18:32 +04:00
-include $(sort $(wildcard lib/*.mk))
features.in: generalize lib/ handling From now on, subprofiles can include the lib/*.mk brought in by features just like image.in/ long did.
2012-04-25 15:08:36 +04:00
documentation: use paths relative to toplevel dir This change is done to reduce ambiguity in some cases; the previous intention has been to ease navigation when staying in a particular directory, now it's been changed in favour of convenient toplevel `git grep' in fact. Both variants have their pros and cons, I just find myself leaning to this one by now hence the commit. Feel free to provide constructive criticism :) Some path-related bitrot has also been fixed while at that.
2014-03-05 18:09:56 +04:00
# see also ./scripts.d/99-elf-stats
stage2: 99-elf-stats for squashfs tuning This kind of test was proposed by led@ to gather statistics on chroot's contents going to become squashfs (the script optimizations lowering added overhead from ~10 sec down to a subsecond range were also proposed by him). Intentionally not documented in doc/variables.txt due to the rather lowlevel nature of the probe (at least so far). The knobs involved are SQUASHFS (the additional effort kicks in only for "tight" case) and GLOBAL_SQUASHFS_SORT (must be non-empty for this extra overhead to occur). Additional experimentation is needed to find out whether the difference in squashfs size and performance is worth the trouble (seems the impact is non-zero but pretty minor).
2012-04-06 23:26:54 +04:00
ifdef GLOBAL_SQUASHFS_SORT
ifeq (tight,$(SQUASHFS))
CHROOT_PACKAGES += file
pack-image: PACK_SQUASHFS_OPTS += -sort /.our/elf.lst
pack-image: CLEANUP_OUTDIR=
endif
endif
GLOBAL_SQUASHFS := $(SQUASHFS)
initial rescue image NB: this implementation is awfully cut-n-paste one, there are lots of common code with install2 which are subject to careful surgery
2011-08-18 23:56:12 +04:00
include $(MKIMAGE_PREFIX)/targets.mk
initial features.in/cleanup This is a sort of anti-feature which removes and not builds; still with mkimage-profiles' approach we can at least build up the removal procedures as well. It's what triggered the tagged scripts, BTW.
2011-09-13 20:39:31 +04:00
# NB: it's a collector variable, add()ing to a GLOBAL_ results in lost hair
GLOBAL_CLEANUP_PACKAGES := $(CLEANUP_PACKAGES)
stage2: 99-elf-stats for squashfs tuning This kind of test was proposed by led@ to gather statistics on chroot's contents going to become squashfs (the script optimizations lowering added overhead from ~10 sec down to a subsecond range were also proposed by him). Intentionally not documented in doc/variables.txt due to the rather lowlevel nature of the probe (at least so far). The knobs involved are SQUASHFS (the additional effort kicks in only for "tight" case) and GLOBAL_SQUASHFS_SORT (must be non-empty for this extra overhead to occur). Additional experimentation is needed to find out whether the difference in squashfs size and performance is worth the trouble (seems the impact is non-zero but pretty minor).
2012-04-06 23:26:54 +04:00
all: | $(GLOBAL_DEBUG) \
sub.in/stage2: Added copy-tree to stage2 stage2 only allows to run certain scripts and install packages, but sometimes one need just to copy something to stage2 (like stage1 does). How to use: put files under ./files directory with the same structure as on resulting image.
2016-05-23 12:10:22 +03:00
build-image run-image-scripts copy-tree run-scripts pack-image \
initial rescue image NB: this implementation is awfully cut-n-paste one, there are lots of common code with install2 which are subject to careful surgery
2011-08-18 23:56:12 +04:00
$(GLOBAL_CLEAN_WORKDIR)
initial features.in/cleanup This is a sort of anti-feature which removes and not builds; still with mkimage-profiles' approach we can at least build up the removal procedures as well. It's what triggered the tagged scripts, BTW.
2011-09-13 20:39:31 +04:00
# dummy
stage2-based debug fixup Employed double colon targets to eliminate warning: ignoring old commands for target `debug'
2011-10-23 00:02:22 +04:00
debug:: ;
Reference in New Issue Copy Permalink