There are use cases when having this common knob would be desirable.

I've long wanted to have this nice helper around in m-p too
but might have set the bar too high.

The "prorper integration" idea was to have the script check
just those pkglists which are relevant for a given image IIRC.

Let's toss it in to begin.

This code started breeding within pkg.in/*/Makefile,
and it was lacking both E2K (as a generic alias,
not just "e2k or e2kv4") _and_ the ability to negate
selection, as in "everywhere but not on any e2k").

Let's fix all of that at once, and parallelize sed
execution as well; my tests with 1000-line file
containing "a b c d@!E2K e@e2k f g@!X86 h i@IA32"
lines show roughly 3x higher CPU load and lower
execution time (~0.3 sec vs ~0.9 sec on 801-PC).

And turn that code snippet into a proper filter
with inline edit capability (I've dropped the exit
trap as failing to mv signals a disaster anyway).

This commit fixes duplication of root device entry in /etc/fstab
and changes LABEL=ROOT entry with the proper one if found.

Apparently this didn't hurt qemu images much though...

This allows one not to hope that only the packages of the desired
loader will be installed.

Should be done this way in the first place it seems.

NB: 07-kernel change breaks multi-kernel setup!

Breaks: 650e92bf

Sometimes REPORT=1 just wasn't passed to make, and the build.log
saved is noisy and harder to compare through diff(1); let's move
the implementation out of the makefile and into a standalone
script so it can be reused like this:

  BUILDDIR=$(sed -rn "s/^mki-image-scripts: export GLOBAL_BUILDDIR='(.*)'$/\1/p" build/build.log
  bin/cleanlog < build/build.log > build/reports/clean.log

See "export GLOBAL_BUILDDIR=" line in the particular log
(grabbing that one from stdin is not exactly trivial though).

Currently, only e2k requires specific disk partitioning.

INITRD_MODULES is reset further down the script.

Fixes: be75d3c3

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.

These commits are temporary, so we do not care about stuff like
trailing whitespaces at all.

An initial (and quite naive) implementation was done
for conf.d/ files but features do need it as well --
which became obvious during a casual inspection of
distro/alt-workstation's target graph (which occured
broken).

The code is a messy hackery unfortunately, regexes used
are fragile regarding e.g. [A-Z_] in target names.
Read with care.

NB: lib/ might need this too but it's rather stable
    and contains some special cases that would obstruct
    the regexes even more...

There's yet another m-p target class, ve/*; and
let's put a semicolon after anything else, too.

Manual BUILDDIR specification isn't exactly obvious
from this script (aiming to derive it automatically),
so at least point those interested at QUICKSTART
they might have long forgotten already or, gasp,
not even started reading.

- add output to console=ttS0 for run in cloud

Either /etc/hasher-priv/system or /etc/hasher-priv/user.d/$USER
must contain at least "allowed_mountpoints=/proc" for mkimage
to work for mkimage-profiles; thanks Daniil Golovanov for
providing feedback indicating the lack of the corresponding
checks.

The sort key field value has been off-by-one apparently,
"6" corresponds to "capacity" field of df -PT output
while the "available" one was meant:

Filesystem     Type  1024-blocks     Used Available Capacity Mounted on
/dev/sda9      ext4     15350768 12799972   1747980      88% /
tmpfs          tmpfs     1967204    27396   1939808       2% /tmp

1              2               3        4         5       6

This lapse has been five years old, looks like it's only
been masked by lower available space limit *and* filesystem
ordering by type so far.  It didn't hit me even now, rather
inspected the code while implementing volumes-profile-starterkit...

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.

Seeing tagged/base+rescue~ in build.log isn't particularly
heart-warming; while other editors but the one leaving tilda
marked backups and .sw* swap files might exist let's do this
step at this time.

Wonder what changed though, this used not to happen before.

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.