EFI/UEFI is mostly about partitioning and bootloader setup,
at least from a distribution's point of view; so the
appropriate tools should be handy and firmware interface
module should not be exterminated from installer images
but get autoloaded instead.

Please note that while there exists 32-bit x86 EFI
we don't bother with it at the time being: it's relevant
to some irrelevant Xeon systems as well as for the older
Intel Macs (<2008) that are long out of fashion anyways.
That is, initially we deal with x86_64 EFI only.

systemd is a tricky beast: getting it to actually launch gdm
required considerable effort on the part of stupid myself.

The relevant links:
* https://wiki.archlinux.org/index.php/Systemd#Running_DEs_under_systemd
* http://unix.stackexchange.com/a/35626/15296

Still looks pretty dirty, and there's some duplication
with a hook in features.in/slinux as well.

This was requested by aris@ for live-gnome.iso but is so far
reasonable enough to do by default: the case of a LiveCD
including X and a display manager but willing to get on
with startx by default is rather nonexistant by now.

*Of course* the "weird" [ ... ] || ... construct meant to avoid
the non-zero exit status of the whole thing wasn't employed
where it actually does make the difference!

Thanks ildar@ for hitting and reporting this, as in

  + verbose '/usr/lib64/propagator exists'
  + '[' -n '' ']'
  mki-scripts: .../stage1/scripts.d/80-make-initfs: unable to run script.
  make[3]: *** [run-scripts] Error 1

It's not fun to boot into a livecd just to find that
there's no lspci around!

This is thanks to the fact that alterator-based install2 needs
alterator-browser-qt which needs X11 which needs working device drivers
-- and at least AMD C60 APU would only yield a nice dotted white screen
without that firmware.

Roughly the same for X11 bearing LiveCD images.

The issue that appeared pretty hard to diagnose occured
to be the enhancement made in make-initrd-propagator=0.8.1-alt1.2
(that didn't hit Sisyphus until merged into 0.10-alt1) which
drops propagator dependency.

And that was optimized out in m-p, of course.

The added pdir check was a hillarious(tm) overlooked bug indeed:
I tried to put .../initfs/initfs instead of .../initfs as the result.

Duly spotted by torabora@, thanks a lot.

Still the kmod+propagator+kernel-image combo needed some tweaking too,
see #27640

A tiny bit less cut-n-paste. :)

The culprit would be that $RELNAME isn't really set there
($GLOBAL_RELNAME is), and sh -u will treat that as error.

It's pretty ugly but dropping the current way
means losing the dependency tracking which is
critical to get the required alterator module
into install2.

Thanks mithraen@ for spotting, boyarsh@ for explaining,
and legion@ for hearty support :)

The problem would manifest itself like this:

  /.host/script.sh: line 20: /usr/lib64/propagator/initfs: \
  No such file or directory
  mki-scripts: .../stage1/scripts.d/80-make-initfs: unable to run script.

Thanks Serg Markov for bringing my attention to this:
http://www.opennet.ru/openforum/vsluhforumID3/86552.html#61

While the official distros might skip some filesystems for
support reasons there's no reason for community distros to
do so either.

Let's try that with icewm.iso...

NB: installer has a misfeature of dropping jfs/reiserfs
    support in runtime unless "expertmode" magic word
    is on the kernel bootargs string (#27763, #17368).

Its immediate purpose was influencing the GRUB boot menu
*but* the implemented mechanism is actually a part of the
long planned text branding and might be further merged
into branding when hierarchical features finally chime in.

So let's get the naming straight before it breeds.

File contents should be correct.

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.

3.5.2-std-def-alt2 brings boot problems which were absent
with 3.4.x-std-def and are absent with 3.5.x-un-def;
seems like it's better to stay with known good variant
at the moment instead of having to fall back to it.

The missing "; @:" at the end of the otherwise recipeless rule
resulted in target graph being broken; I should have checked this
when introducing these aliases (the intent was to reduce noise).

It appears that chkconfig wasn't getting pulled in
by now if not told so explicitly.  Still in need.

There's no use of a rescue image when it has no firmware
for the controller in the system being worked on...
so added some.

Thanks both drool@ for his mild frustration with the current
documentation as well as Greg Kroah-Hartman, Heikki Orsila
and Neil Brown for http://lwn.net/Articles/504814/ -- the docs
should really emphasize *why* something is done, not *how*,
as the "how" part is better documented with the code itself
(that doesn't mean that "the big picture" isn't needed).

That sub/stage2/install2 was somewhat clumsy actually as it looked
like a hierarchical thing while being a substitution thing:
generic stage2 would get put in place renamed as install2.

This could only get worse with hierarchical features which have
already been both requested and considered for quite a time,
and "stage2 at install2" reads much more naturally.

Finishes what 3dd02033
has essentially done... the path seems to be elsewhere.

There were heaps of "if type -t git" there already;
it wasn't an unintentional mishap but rather a moderate
copy-paste to get the use cases, and now these seem to
have essentially settled.

So time to scrap some dups.

NB: the scripts in the generated profile can't rely on
the contents of the metaprofile (these need to be able
to work in standalone case either), so a bit of crap
still lurks there.

There's no (convenient) "eject" at times, so it's better to provide
extra ways of booting right away.

Found myself pretty silly while sittin' at the rescue console
and bein' unable to leave the cool server room for a way
more comfortable armchair and a laptop's keyboard...

(yes, it was that disk array needing GPT tools)

This trots along the TODO item on text branding
and hopefully helps Michael Radyuk (torabora)
with his feature request to tweak the installer's
"Install ALT Linux" label; as an example, Simply
will now offer to "Install Simply Linux".

This one was suggested by enp@ for industrial use where
some extra protection for the boot process might be quite
desirable.

If no syslinux ui was specified (the stock configuration paths
ensure there is one) or if it was set to "none" explicitly,
then there's no boot: prompt (let alone any menu).

If there's a need to ensure that the boot process is not
interruptable by Ctrl/Shift/Caps Lock/Scroll Lock.

It wasn't obvious at all what BRANDING variable is for
(at least until the source code and existing configurarion
has been examined).

Also pulled the pkglist/kmodule part out of distro/server-mini's
recipe and started off a standalone feature based on it.

NB: el-smp kernel now contains aufs as a module but propagator
doesn't try to modprobe it.

TDE distros don't really need kdm4 which was proposed as
a replacement by zerg@ (for all the valid reasons but kdm3
wasn't maintained at that point, this has changed since).

The reason is that package lists and individual packages
are processed in different dependency resolution "transactions"
by mkimage; thus if packages (the more precise form of specifying
the contents) come first they can't override the lists appearing
later, and that's wrong: we should be able to specify the more
generic things and then pinpoint the specifics.

This became apparent while authoring [[Mkimage/Profiles/m-p/howto]]
asked for by drool@.

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.

su wasn't making it into the image breaking ~/.git setup,
and there's no reason for a full default boot timeout either.

There was some extra duplication, just clean it up.

It's not DHCP we're configuring but rather eth0.
(no need for trailing space either)