mkimage-profiles

keremet/mkimage-profiles

Fork 0

Commit Graph

Author	SHA1	Message	Date
Michael Shigorin	d7689f30c7	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-06-17 19:29:11 +04:00
Michael Shigorin	cb764516eb	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 16:06:15 +03:00

Author

SHA1

Message

Date

Michael Shigorin

d7689f30c7

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-06-17 19:29:11 +04:00

Michael Shigorin

cb764516eb

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 16:06:15 +03:00

2 Commits