rootfs scripts are also run when building live image. But assigning
BASE_BOOTARGS to live is not required, since the arguments are
copied from STAGE1_BOOTARGS by the installer.

Chroot can be two or one, work or image.
Package lists of work chroot cannot take into account packages that
will be installed into it after run-scripts.

By default, GRUB_TERMINAL_OUTPUT='gfxterm' is configured.
This creates problems for virtual machines and single-board computers,
since they need output to console.

The config for generating a generic initrd can be interesting because
it will allow you to return the initrd to its original generic state.

Variables in cmdline override variables from /etc/initrd.mk
See also: https://lists.altlinux.org/pipermail/make-initrd/2021-September/000533.html

This is necessary for the 'rootfs' initrd feature to work properly

This is a standard set of initrd features.

This features not needed for auto-detect.
We also add features not only to initrd.mk, but also specify them
explicitly in the command.

The entry in /etc/fstab about the mount parameters of the root
partition needs to be done not only for builds with u-boot.
But, if the record already exists, then it will not be added.
The file system type is set by the variable VM_FSTYPE.

Since packet sorting is enabled by default, then
the order in KFLAVORS has ceased to matter.
Kernels are always installed in alphabetical order.
Therefore, it makes no sense to sort by buildtime.
See-also: https://bugzilla.altlinux.org/show_bug.cgi?id=30806

Also fixed my typo. When creating a symlink, the variable
$kver was used, i.e. the entire list of kernels, not the
last value $KVER of the list.

Not used by systemd and looks obsolete generally
as sysvinit-based disk images aren't really targeting
low-resource systems these days _by default_ but rather
_can_ target those as well; feel free to reconstruct
these "RAM saving" bits as a part of e.g. lowmem patch.

The problem at hand is that different kernels can have
varying module sets, and it makes sense to put four of
those at once sometimes; so avoid silly build breakage.

KFLAVOURS can describe more than one kernel, get iterator back.

Fixes: 27674e29

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

Breaks: 650e92bf

...if it's a systemd-based image; no real error then.

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

It has no VM hypervisor so far, the images are intended
for bare metal execution.

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.

It's probably a good year to get rid of this reference practice
resulting in a known sort of misdocumentation over time :-/

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.

The feature officially introduces the "engineering passwords"
including empty ones which have been around since forever but
weren't properly managed (and still are not, at least until
there are no stray passwd/chpasswd/usermod calls in both the
profile, installer-features and all the other related parts).

It is based on an m-p-d init3-users script by stanv@ but was
cleaned up and restructured in a pretty severe manner; thanks
glebfm@ for additional discussion.

This also cleans up the kludge previously stuck into build-vm.

Note that vm/icewm sports graphical autologin now as well as
the default root password (which can be overridden by passing
ROOTPW=... to make but it is a change from the previous state
of affairs indeed).

This subprofile is akin to THE_* variables family: the configuration
bits and script hooks sitting there influence whatever chroot is
declared to be the user facing one in the end, whether it comes
from vm image or live subprofile.

The services feature ought to be a changeset of its own which would
be based on rootfs and become the base for ve/vm changes but I chose
to just do it atomically; some pre-existing duplicates are pruned now.

A virtual machine isn't very useful if there are no means
to access it; let's bring up the basic networking and provide
root SSH access via pre-existing public key.

As the remote access with known default credentials is roughly
equivalent to just lending one's VMs to anyone with network
access to it, the fallback root password is now exterminated;
you have to provide one (or a long enough random string
if you plan to use keys only, see e.g. apg utility).

There's no need to disable console as it's emulated too,
and it still can be helpful or just convenient.

Yes, mkimage-profiles is now able to build VM disk images.
So far the support is pretty basic:

- a single hard drive image with a single partition/FS
- only stock root password is configurable
- LILO is hardwired as a bootloader

The resulting images tend to boot under qemu/kvm though.

Please see doc/vm.txt for the warning regarding additional
privileges and setup required.  This was started back in
February but I still hoped to avoid sudo/privileged helper
(and libguestfs is almost as undistributable as can be)...

Thanks:

- http://blog.quinthar.com/2008/07/building-1gb-bootable-qemu-image-using.html
- Alexey Morarash who reworked that as https://github.com/tuxofil/linsygen
- led@, legion@, vitty@, aen@ for providing advice and inspiration