The initial approach required some quite involved postprocessing
as described in http://www.altlinux.org/UEFI#HOWTO; after having
ironed out the kinks so that initial EFI support could be merged
into mkimage proper we're better off just using it, eh?

The previous part was fixed and discussed in commit
c30490e2;
so much for a deduplication effort...

This would result in almost immediate

  make[1]: *** [profile/populate] Error 2

as well.

An example for sam9x25-ek:

make \
 PACK_UBI_MIN_IO_SIZE=2KiB \
 PACK_UBIFS_OPTS="-e 124KiB -c 1984" \
 PACK_UBI_OPTS="-p 128KiB -s 2048" \
 PACK_UBI_VOL_TYPE=dynamic \
 PACK_UBI_VOL_NAME=rootfs \
 PACK_UBI_VOL_FLAGS=autoresize \
 HSH_EXCLUDE_DOCS=1 ARCH=arm APTCONF=apt.conf.sisyphus.arm ve/generic.ubifs

https://bugzilla.altlinux.org/show_bug.cgi?id=27994#c0

Based on timonbl4@'s advice; might need some bleeding edge
packages right now, feel free to ask (everything should be
in place by p7/branch though).

propagator-20121109-alt1 obsoleted initfs (and dropped
mkinitfs script altogether); that was taken into account
in both make-initrd-propagator and mkimage-profiles-desktop
but not in mkimage proper, see also discussion in #27976.

Tagged scripts got heavily postponed
for the lack of practicability
so far.

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.