live-webkiosk.iso regressed into trying to boot off the local disk
immediately, the exact cause is not yet discovered but this one
has popped in build trace (distcfg.mk) already.

Desktop images are still likely to depend on it though.

The problem with hardwired "[alt]" was that it's not going
to match "[p7]", for example.

Brown paper bag bug.

Aimed at live images at first but should cover installers as well.

This has been brewing for quite some time and while the proper
implementation is considerably more complex (and hard to do)
looks like there's demand for the particular important use case,
namely LiveCDs for Russian users, so this code has been shared
with a few people before merge.

It looks *ugly* on-screen, at least within regular builds,
even if the screen is 166dpi.

Based on a quick experiment this morning I'd suggest using
fonts-otf-adobe-source-{code,sans}-pro instead -- and it's
available as use/fonts/otf/adobe now, incidentally.

The documentation is still built with it though as a2x/fop look
unhappy otherwise (as in replacing Cyrillic glyphs with "#"s).

This reverts commit e48fe6c4:
livecd-evms has been updated to cope with systemd-214.

Looks like sysvinit-only services like this pose a major problem
for systemd-214 causing dependency cycles.

fonts-ttf-droid have been superseded by fonts-ttf-google-droid-sans
in Sisyphus which might be lacking; I've considered replacing it
with Fira anyways, so let's just do that.

Firefox was the very reasonable default for initial livecd
implementation but now that at least initial browser chooser
infrastructure is in place it's time to un-hardwire its use.

It's _the_ default but switchable now so that images providing
a comprehensive browser can avoid feature duplication.

dm service is set up to autostart when installed anyways,
and explicit `chkconfig dm on' results in it being turned on
at runlevels 2, 3 and 4 too which is really not needed.

Thanks led@ for spotting and reporting this.

It appears that live feature has been buggy regarding user
groups: its 30-users script would create a predefined account
with fixed supplementry groups list, and even if deflogin feature
got used too it would fail to add any groups to already existing
account since its useradd(8) call would fail.

Let's drop this duplication which has been long overdue anyways.

Thanks dd@ for both reporting the problem and carrying out
initial investigation.

We don't really want to disable NFS portmapper completely
but having some extra root code listening to the world is
really unneccessary unless explicitly required.

Applying "control rpcbind local", thanks ldv@ for advice.

50-setup-network was a hasty hack (surprise!) that used to do
what net and net-eth features have been created to do since;
just drop the duplicated crufty code.

Unconditional resolver setup isn't done now: those with static
setup are better off doing it explicitly, and those with DHCP
should be fine already.

NB: /etc/hosts *is* fine within setup package *but* hasher will
    overwrite it with a copy of host's one; let's reset contents
    to initial at least until hasher gets fixed and the fix is
    rather deployed in the wild.

03-services was a hasty hack that has been long done properly
elsewhere, namely in a specialized feature; finally got around
to deduplicate it out.

"cdrom" is rather obsolete (currently unused), and "xgrp"
is useful (and actually required to use bumblebee package).

use/live/textinstall target is a base for those images whose
target audience tends to be somewhat more experienced; these
might prefer to just boot off the image instead of having to
perform any extra action like pressing down arrow and enter.

This is also to help msp@'s homeros-*.iso boot immediately.

It's hardwired at 1/10 of the default /etc/net value
since 3 seconds are enough for properly functioning
DHCP servers in properly maintained networks (those
improper ones tend to have problems with 30 seconds
anyways), and waiting for too long makes users feel
bad for a reason.

Thanks msp@ for bringing attention to this.

use/live/sound target is dropped on the floor,
there were no more in-profile users of it.

use/live/install stopped to provide a desktop icon; the nuance is
that zdg-user-dirs-install.sh script in livecd-install package
expects ~/.config/user-dirs.dirs to actually do that.

This script hook used to lurk in live feature but was deemed needed
in cubox images too; thus it's time to move it into a standalone
feature (maybe a configurable one, even).

Thanks glebfm@ for initial shot and sem@ for discussion.

A service a day makes the boot a long wait!

Hardly belonged there in the first place and became a culprit
during armh branch development since it had to be forked in
an ugly manner; move to rootfs hooks and be done with it.

VM images will be able to benefit either *but* installed systems
might have some trouble when this is implemented:
http://lists.altlinux.org/pipermail/devel/2013-May/197447.html

Split off use/live/x11 as a common free/proprietary ground either
(this refactoring had to be performed in parallel with x11 feature
being revamped, diffs quickly became intertangled unfortunately).

This has had several goals:
- a target suitable for x86 and armh providing a rather
  minimal set of base xorg packages and generic drivers;
- task-oriented targets for graphics use cases:
  + "desktop" means rather 2D focus with 3D being welcome
    or even essential but not performance critical, thus
    "a slower driver is fine as long as it does work";
  + "3d" means specific 3D performance being critical,
    that is "no 3D means no use at all".

Regarding the free and proprietary 3D-capable drivers:
the previous idea was to split out some common ground
and then add the contenders on top of that; the current
approach is based on the observation that the live images
requiring proprietary NVIDIA/AMD drivers *by default*
are usually of not much use with hardware that lacks
proper 3D acceleration (like Tseng cards) or the driver
support for that (like Matrox these days).

Intel videodriver makes for a special case though:
it is both free and top-notch performer.

Thanks sem@ and boyarsh@ for discussion.

PS: xorg-drv-{keyboard,mouse,void} dropped;
those who need these can usually help themselves.

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.

...so that they can run mtr, iftop and other goodies out-of-box;
thanks folks at forum.altlinux.org for a regular-icewm.iso
related feature request.

shaba@ says it's improper yet as prefdm is used (#28973).

Another service that's not very useful on a LiveCD;
maybe should be enabled by default upon installation,
this also requires a proper framework in place.

This reverts commit ae441691
as libglx has been fixed already; see #27340 and #28782 for
the details, huge thanks go to Alexey Borisenkov for his
thorough investigation and patches as well as to shrek@
and sin@ for their cooperation to get this fixed in Sisyphus.

This is to cope with #28782 while the culprit is being found out;
not much of a loss while #27340 is open (thus no 3D with vboxdrv
anyways).

I chose to avoid pulling the service related machinery into
vmguest (and haven't got around to factoring it out from live
feature's scripts into a standalone form) so had to tweak these
as well.

The newcomers have crept in with rescue+extra;
maybe it's not worth taking that one into every
regular image, after all...

The expected behaviour is to have online repositories enabled
when the livecd is running; the trouble with runtime detection
relates to the asynchronous nature of network configuration,
connection might get probed just before it is brought up
(thus failing the test).

Systems having been installed-from-live don't misbehave this way
so left unmolested.

Runtime detection is still available via use/live/repo/online
but is definitely not the default mechanism.

It's a worthwhile addition to virtually any LiveCD
thus usually included (but can be left disabled).

This reverts commit 9c766cd9
since vboxdrv is already fixed by sin@ (thanks a lot, great timing!).

There's a need for a separate boot target since
persistent storage is way slower than tmpfs indeed;
usbflash has a tendency for huge performance drops
given simultaneous writes in addition to reads which
are the bottleneck already.

make-initrd-propagator 0.18 introduced ext4 rw slice,
so the corresponding kernel module needs to be included
into stage1; see also #28289.

NB: not available on x86_64-efi (or hybrid GPT to be strict)
due to fragility of the hack being made: parted(8) panics
upon seeing that, and good ol' fdisk is unable to treat it.

NB: use/live/rw use/rescue/rx use/syslinux/ui/gfxboot
are unlikely to play very nice together due to the latter's
magic l10n: "session" label is taken by live_rw config snippet
and *is* translated in design-bootloader-source;
OTOH "rescue_session" is *not*.

The setup has to be livecd-only thus made as a service, not a hook.

Please see the bug for explanations; too bad I chose to limit this
workaround to experimental gnustep image yesterday when aen@ suggested
to apply it universally...

It would be better to put it into stage2 in the first place
but this somehow went over my head; rescue made a reminder.

Its support is quite mature and practically useful by now.
Let's also add a convenient alias.

It was bailing out due to the grossly unneeded -e;
thanks dans@ for bringing my attention to this
right at LVEE 2013 Winter.

It'd be better for this commit to appear before 0.9.7
(and clobber the original one) but at least the added
functionality has been tested; time to generalize it.

The issue has shown up in regular-*-20130207: /etc/resolv.conf
would suddenly be empty upon successful bootup in virtualbox
with a single DHCP configurable ethernet.

dmesg has some trouble signs:

  aufs au_lkup_neg:267:kworker/0:2[998]:
  I/O Error, resolv.conf should be negative on b0

sem@ tells something like that has been seen before in a different
configuration (multiple aufs overlays with /etc/ and /var sitting
in different ones resulting in broken hardlinks); rescue boot with
a test "echo > /etc/resolv.conf" yields an I/O error either.

The patch is loosely based upon livecd-net-eth and
m-p-d::profiles/live/image-scripts.d/init3-{network,resolve}.

See also #28484 for the (still ongoing) discussion.