mkimage-profiles/features.in/build-vm/generate.mk

# copy tar2fs helper into generated profile to enable standalone builds

all:
	@install -pD $(MKIMAGE_PROFILES)/bin/tar2fs $(BUILDDIR)/bin/tar2fs
tar2vm: rewrote as tar2fs Overview of the changes: - ARM support: separate ext2 /boot, no LILO - avoid race condition with devmapper - trap ERR so that -e in shebang doesn't result in extra cleanup hassle - configurable root filesystem type (ext4 by default) - jumps through parted hoops Details: 1. LILO is x86-specific while the rest of the script can be used to prepare e.g. Marvell ArmadaXP or CuBox images; we can generally count on uboot supporting ext2 for relatively sane platforms but not ext4 that would be a better root filesystem performance-wise. 2. Apparently /dev/mapper/loopXpY can be still missing at the time when kpartx returns and pop up a bit later... sit there, wait and check for it. 3. If something went wrong with any command of the script it would bail out due to -e in shebang; it is now better to clean up the loopback device and its mappings in this situation either. 4. One size doesn't fit all, really. 5. The parted sizing was sloppy as in broken, now it's just half insane. Someone's decision to stick units and auto-alignment knobs into a single one was apparently hilarious... http://www.gnu.org/software/parted/manual/parted.html#unit Manual loop/dm cleanup is described in documentation just in case. /boot size meter is suboptimal in terms of additional I/O incurred, will be most likely rewritten to make use of advance "du -s". 2013-05-29 17:56:12 +04:00			`# copy tar2fs helper into generated profile to enable standalone builds`
build-vm: standalone build is a must, too The problem was spotted by Alexander Bandura: bin/tar2vm wasn't present in the generated profile. I considered extending features.in/Makefile to include bin/ alongside lib/ but that would make the helper's location unpredictable (unless BUILDDIR is specified explicitly) so restricting sudoers would be harder; worse yet, the copied file would come with write access for the user building an image. The implications in restricted case are complex enough anyways so the recommended implementation would only include a fixed readonly location like /usr/share/mkimage-profiles/bin/tar2vm as laid out in doc/vm.txt, and that means it's in the metaprofile not a generated profile. 2012-07-18 17:06:15 +04:00
			`all:`
tar2vm: rewrote as tar2fs Overview of the changes: - ARM support: separate ext2 /boot, no LILO - avoid race condition with devmapper - trap ERR so that -e in shebang doesn't result in extra cleanup hassle - configurable root filesystem type (ext4 by default) - jumps through parted hoops Details: 1. LILO is x86-specific while the rest of the script can be used to prepare e.g. Marvell ArmadaXP or CuBox images; we can generally count on uboot supporting ext2 for relatively sane platforms but not ext4 that would be a better root filesystem performance-wise. 2. Apparently /dev/mapper/loopXpY can be still missing at the time when kpartx returns and pop up a bit later... sit there, wait and check for it. 3. If something went wrong with any command of the script it would bail out due to -e in shebang; it is now better to clean up the loopback device and its mappings in this situation either. 4. One size doesn't fit all, really. 5. The parted sizing was sloppy as in broken, now it's just half insane. Someone's decision to stick units and auto-alignment knobs into a single one was apparently hilarious... http://www.gnu.org/software/parted/manual/parted.html#unit Manual loop/dm cleanup is described in documentation just in case. /boot size meter is suboptimal in terms of additional I/O incurred, will be most likely rewritten to make use of advance "du -s". 2013-05-29 17:56:12 +04:00			`@install -pD $(MKIMAGE_PROFILES)/bin/tar2fs $(BUILDDIR)/bin/tar2fs`