Changing ROOTFS owner causes a problem:
created image's root directory is owned
by user executing make instead of root.

Changing WORKDIR owner is unnecessary
because it will be removed anyways.

The original commit broke system tar2fs use by accidentally
moving TOPDIR definition into a separate shell execution;
thanks iv@ for spotting and fixing it promptly.
Co-authored-by: Ivan A. Melnikov" <iv@altlinux.org>

...for vm images; BIOS one tested, EFI one untested yet
but will be required for AArch64 VMs it seems.

No sense to "provide" choice when there's none.

...so that umounts can happen reliably.
Reported-by: Gleb Fotengauer-Malinovskiy <glebfm@altlinux.org>

This one supports multiple kernels (and tweaks boot
labels aiming to simplify target kernel selection
for the CPU at hand) instead of an earlier attempt
to fill in a template.

No need for the template so just drop it.

This was crucial for e2k rescue image supporting
multiple CPU versions but can be useful elsewhere.

The current state made vm images belong to root group,
no reason to not change those to the primary group of
the user building an image.

kpartx -d -s could fail in some circumstances,
make a safety cleanup call more verbose.

Somewhat ARM-like with only the bootloader bits
standing out; Elbrus 2000 firmware can read ext2
and boot the kernel directly.

No need to deduce kernel version again,
just save it in a temporary file.

The main reason to change what worked is
that e2k kernel-image package has Linux bits
named as image-$kver and not vmlinuz-$kver;
the guessing logic taking all of this into
account resulted in non-aesthetic patch.

NB: there's a duplicating script within
    kernel feature; it wasn't easy to avoid
    this and it might differ when handling
    multiple kernels, I didn't think much
    about this now as vm images tend to ship
    with the sole one.

- add output to console=ttS0 for run in cloud

Yet another age old bug: `sfdisk -l' is mimicking what
a person does by hand but the script is rather interested
in what `sfdisk -g' provides, that is, geometry.

And it's stupid enough to only grok C locale.

Looks like there's a race condition somewhere: this script
will fail to clean up after itself when considerable background
load is inflicted upon the host it's running on (e.g. LA ~16
on a 8-core, single-disk system).

Note that this commit is NOT enough to win that race
but just a step in the right direction...

It's unwise to skip the common storage driver,
and vagrant (which uses virtualbox by default)
is likely to crash and burn as well.

The check introduced by commit d7689f30 while rewriting tar2vm
(which presumed x86) was subtly broken: it checked for *host*
binary before preparing *chroot* configuration file for it.

Wonder how many build servers run lilo over here that this BUG
has managed to evade attention for almost two years...

Forward-port of b84182c5cb684afbd30ed1f9e5b6f89f55b4b53f
commit extended to handle /boot as well.

Thanks glebfm@ for spotting that it's = instead of +=
as it goes in all the other places; I remember no good
reason to overwrite the potentially preexisting contents.

Really no need to test and sleep when there's sync mode.

Factor of 2 is not enough for kernel upgrade due to filesystem overhead.
Add BOOT_SIZE_FACTOR on top of that.

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".