Many cloud providers pass metadata via cdrom. Generator used by the
cloud-init to determine a datasource works before loading modules. So cdrom
modules must be loaded in the initrd.
Other linux distributions enable cdrom modules in the kernel.

1) systemd-settings-disable-kill-user-processes - server systems should not
   kill processes after user exit;
2) apt-scripts - for apt-dedup;
3) update-kernel - to update kernel on vm cloud image.

For vm and ve targets do not require the vconsole-setup-kludge package.
For them the problem displaying non-ASCII characters in tty is not actual.
Suggested-by: obirvalger@

Some images will now be better off with GRUB;
rework ve/.bare while at that (splitting the
image targets appropriately).

These have appeared in desktop.mk, regular.mk, vm.mk
over time, and there are two problems around.

The minor one is that mixins have been introduced as
handy reusable bits close in context of their use;
this practically means that they fall under the same
class restrictions as their parent targets, that is
a mixin coming from regular.mk will only be available
for "distro" IMAGE_CLASS, and so on.

The major one is probably the worst design flaw in m-p:
building images from ground up, where ground is a valid
standalone buildable target as well.

Life has shown that we rather want to build up images
the other way around, choosing what essentials go in first
and then fitting the fine details along with the packaging.

The first sign of this difference appeared with ARMv7 Simply:
we had a well-built configuration aiming for x86 ISO, still
we needed roughly the same app/environment configuration
put into armh disk image.

Those platforms were different enough that we didn't actually
plan shipping *lots* of distributions but the problem was clear,
and it was much alike to the one that sprang m-p to life in the
first place (when we had a range of "common" distros and needed
to create and maintain a set of "school" ones that mostly had
similar or even identical difference to their respective base
ones -- and we couldn't do something like conf.d/p8.mk does now).

So mixins are going to become the softer way to turn m-p's
target configuration chain upside down to considerable extent:
build up what you're going to mix into the various deliverables,
and make it as portable across image classes, hardware platforms,
repository branches as feasible so that total maintenance effort
needed goes down or at least doesn't spike too bad.

And here's the first strike at that.

This one has been clearly duplicated before.

(amended with a later fixup)

The resulting image size will be less than the specified maximal one
as it's thin-provided with contents taking up what they do.

This should be built as vagrant-base.vdi (xz before publishing).

It's been ignored since the introduction of deflogin feature
and removal of build-vm specific ROOTPW variable handling;
might be adjusted to mandate this for vm/bare too, have to
think it over.

It's not as bare as it should be due to interactivesystem
being slightly more than it ought to.

No need to require udev-rule-generator-net explicitly here,
it's been factored out into that feature.

This PoC will boot into locale and credentials setup GUI once
and should boot as usual ever since, that is into lightdm
in this case.

I don't see any reason to use systemd within VM images,
and it would stick its journal as a syslog implementation
when not ditched explicitly :-/

IOW one has every right to expect that package manager
is set up already in a networked virtual machine.

This one was replaced by the net feature completely
and has been declared obsolete since 1.1.1 (a month ago).

A few remaining users trivially adjusted.

There was no need to split carrying over the pubkey
and tightening up permissions on the file and its parent
directory to be done in two separate scripts; this should
be more generic now as a bonus.

Users adjusted accordingly.

It's pretty frustrating to be able to ssh into a vm
while being unable to administer it knowing the rootpw...

lib/*.mk aren't going to be parsed for build targets
in the near future; and the early placement of those
targets was superseded by a dedicated configuration
snippet directory so just move these bits there.

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

See http://www.opennet.ru/openforum/vsluhforumID3/86239.html#1
for a query that has led to this one; in particular,
- xdm dropped (won't log in root and there are no users yet);
- network is brought up and configured via DHCP by default;
- apt-get works out-of-box;
- default image size is twice the chroot size.

Some images were unbuildable (at least without special setup,
like ve/centos), unusable or just not useful in any meaningful way
(like distro/live-isomd5sum); as these tend to get any attention
during experiments, I decided to put them together in a separate
configuration file that would be effectively skipped if DEBUG
is not requested.

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

It appears that reusing installer-feature-*-stage3 packages
is perfectly fine with VM images; these just need to be removed
after the package scripts they carry have worked out.

After we have built a bare virtual machine image successfully
some variations are due, and these are to be described here.