The initial revision was brilliantly buggy: it is *so* apparent
that cdrom will never be actually used for rw slice that this
has evaded my attention rather completely.

- ahci kludge (see #29705) :(

This change tries to force loading the storage driver
for cases when SecureBoot is "helping" the chainloader
to fail, see #29705 for details collected so far.

Of course ahci.ko only does AHCI but that's every storage
controller I've seen on UEFI/SecureBoot systems so far.

This reverts commit d160d610:
GNUstep reportedly works on x86_64 now.

Conflicts:
	conf.d/regular.mk

- rescue tweaks

Let's put osec tools into installable packages at least
(aiming to shift these into default install probably);
these are worthwile addition to sysadmin's toolbox.

Thanks dobr@ for bringing this up.

It turns out that regular-rescue.iso lacks sshfs,
which is unfortunate (even if it could be installed
with apt in this particular case); three more FUSE
based filesystems have been added just in case.

Thanks mithraen@ for suggesting davfs2.

I'm fed up with graphical software occasionally making it
into regular-rescue.iso and bloating it for no good reason
given that window managers or xinitrc aren't included.

This has been spotted and solved manually several times already,
and that's just boring so let's add the ability to state that
X11-based software is not accepted into a particular rescue image.

Not that I would hate X but things like that belong to a carefully
crafted image which includes either X server or reasonable means
to ensure that GUI software can actually be used.

NB: this is a somewhat new entity: test/rescue/no-x11 knob
for an image-script intended to make it blow up the build
when libX11 is found within the chroot that makes up
the rescue image's filesystem.

The interface is not documented intentionally: it will take
some time to find out whether it sticks or is bad enough.
Please do remind/ask if interested in using that.

It's a pretty hefty addition which isn't strictly required
in a basic rescue image even if it's welcome as an extra.

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.

Rescue images definitely don't need alterator pulled in.

- support for CIFS installation method (sin@)
- glibc-locales for regular images (closes: #29693)

At least regular images should include locale support,
various software and users might malfunction otherwise;
thanks manowar@ for spotting and reporting this (#29693):

http://lists.altlinux.org/pipermail/sisyphus/2014-January/361929.html

It's a tad pointless to be able to create a filesystem
but not to be able to fsck it at boot.

- regular fixes

Dank Bagryantsev asked if it could be added to available packages
at least; well it is there now but not in default install
as aptitude is currently unsupported.

At least lspci was sorely missing in non-rescue images
(as well as in mini rescue part of server image);
thanks Dank Bagryantsev for pointing this out:
http://lists.altlinux.org/pipermail/community/2013-December/681223.html

Thanks ksa at Russia-2 forum:
http://forum.russ2.com/index.php?showtopic=3784&st=0&p=37927&#entry37927

This is pretty valuable addition and doesn't take that much space
(roughly +100M).

I don't think we're gonna like plymouth over rescue image
anytime soon, especially when it hides the moment when shell
pops up somewhere under it without startup-rescue caring to
remove the splash.

So let's put that $(INSTALL2_BRANDING) into proper stage2
flavours only and avoid choking on missing plymouth as well.

led@ has different kernel-modules-* package set,
some of those "standard" names are provided but
vbox* is not the case.

As our macros and helpers will grok this just fine,
let's add both variants so what's present gets in.

Another fork place: live branch used to depend on +vmguest,
installable one omitted that for some reason.

Suddenly got lots of extra space to wa^H^Hfill due to led-ws
thus a few more FRs by Speccyfighter can go in ;-)

This kernel can help save almost 50 megabytes of image size
and shave off several megs of RAM consumption as well which
is important after the installation has been through.

Adding rescue image was requested by Speccyfighter (in Russian):

http://lists.altlinux.org/pipermail/community/2013-December/681045.html

...and it seems hard but doable if one doesn't mind barebone rescue;
still efi-shell shouldn't spoil x86_64 build as that one won't fit CD-R
and doesn't have to anyways.

In these tough times there are no extra resources to waste
for wars or some extra rescue; so it is imperative to provide
some lean and mean help, you know.

IOW a common base has been split out and a more tight rescue
image configuration has been added on top of that so as to
try and fit altlinux-p7-sysv-tde.iso for i586 into CD-R.

Argh, so alterator-auth was hiding under a name it provides too
-- now *that* is the cause for those last-step failures as the
rest of the environment hasn't been getting set up apparently.

Just drop it, there's a proper domain-client pkglist for that.
This is what 63293ff2 should
have done too.

...so that it hits regular-sysv-tde (and other installers) too.

un-def got unsuitable due to initial ramdisk migrating from
initramfs to tmpfs by default in newer kernels, and propagator
was using pretty kludgy way to determine that /dev has been
mounted already; led-ws (and supposedly lks-wks) have stumbled
upon this earlier.

20130822 version has been fixed regarding that.

I've noted that this bit of code should be fixed up
before pushing but managed to overlook that in the end :(

mkimage version bump is due to the somewhat changed layout
of EFI packages and binaries within those (linked message in Russian):
http://lists.altlinux.org/pipermail/devel-distro/2013-December/001283.html

- efi updates

...instead of installer-distro-desktop which pulls in
alterator-auth which breaks things big time for sysv-tde
installer image due to avahi-daemon lazy to run.

Of course it's the last step of installation that has to fail.

And I've been considering this for several months already anyways.

I wondered how regular-e18 lacked econnman but it only
took a closer look to understand that it's just not told
to go in, plain and simple!

There are no e18-extra-modules (at least so far),
confine that to desktop+e17.