This kernel module needed for bootloading on dbm2 (Baical-M)

See-also: https://bugzilla.altlinux.org/37598
          https://bugzilla.altlinux.org/37636

This list kernel modules for loading on single board computers.

Add more usb kernel modules

This has manifested on e2k for me -- still using older
make-initrd lacking R: file -- so let's get this kludge
back for a while, or until any reasonable make-initrd
around has *everything* it needs to create images
listed in its runtime requirements.

Fixes: 2b3455c2

sin@ was kind enough to just stick mount.cifs into initrd
regardless of its presence in the chroot in question;
let's look first and only add what's found.

This started as a stopgap fix after make-initrd 2.2.0
which happened to collide with cifs-related m-p commits
in a somewhat unfortunate manner...

af_packet rather belongs to networking stack
than to common module library indeed.
Suggested-by: Alexey Gladkov <legion@altlinux.org>

This has been made a bit messy with commit
9f72780d,
just split the "involved" and straightforward
checks into two.

This reverts commit 4a4da37d
as Sisyphus has got GRUB 2.02 in the mean time:
http://git.altlinux.org/tasks/archive/done/_179/183896/

We use grub2 2.00, it's not compatible with new mke2fs
options (namely "64bit" one); disable it for now.

See-also: https://bugzilla.altlinux.org/show_bug.cgi?id=33489#c6

Reported-by: Sergey Bolshakov <sbolshakov@altlinux.org>

eMMC installation support has a few bugs:

https://bugzilla.altlinux.org/30239
https://bugzilla.altlinux.org/30269
https://bugzilla.altlinux.org/32171

Handle the latest one.

If aufs not available/broken we could try to use overlayfs.
NB: changes below doesn't work without modified make-initrd-propagator!

This has no users in master but out-of-tree branches might need
a trivial update.

The rationale is that it's actually for *any* stage2 and not related
to specifically "install" at all (otherwise it should have been moved
to install2 feature altogether).

Note that there's no reason to add nfs-utils similarly as make-initrd
requires kinit-utils which includes its own nfsmount.

This is sort of laying the ground for the future dismantling
of 10-stage2 (which was sub.in/stage1/modules just recently);
things look like tagged lists might become due some day, e.g.
"net+usb" or "scsi+raid" -- time will tell.

These were produced off the single sub.in/stage1/modules
file using this scriptlet to prefix/annotate the names:

  grep '\.ko$' modules \
  | grep -v / \
  | while read m; do \
  	echo "$(find /lib/modules/$(uname -r)/kernel/{drivers,fs} \
		-name "$m" -printf %P $m $(modinfo -d "${m%.ko}" 2>&1)"; \
    done

...with subsequent sorting and manual separation.

This is meant to be the second stage in monolithic modules
file split, so the lists themselves are largely unmolested
otherwise.  The plan is to further split those into prefix-
and module-specific ones.

Add a note clarifying 10-stage2's status, by the way.

What was a static sub.in/stage1/modules (and the only one)
is now features.in/stage2/stage1/modules.d/10-stage2
(basically a compatibility file that might go some day).

It will be auto-picked as its name corresponds to the
NN-SUFFIX pattern specified in stage1 subprofile now
with $(FEATURES) going into default STAGE1_MODLISTS.

stage1's got prepare-modules target collecting
modules file snippets all over stage1/modules.d/
subdirectories within individual features.

stage2 now adds names of all the features going into
a particular image as snippet file suffix list so that
individual features don't have to register themselves
twice (as a feature and as a propagator modules.d
snippet carrier).

This is going to allow both "uncommon" modules getting
included with no problem (sin@ has wanted cifs ones
for quite some time, for example, and some want e.g.
infiniband modules) *and* to reduce the actual list
below the common mark as well (which is the case with
live-privacy image, for one).

And stage1 memory consumption does matter in some cases
as it's highly critical with no chance to use swap yet.

stage2 has been thinking it's synonymous with propagator
and used to usurp kernel's belongings either; carefully
tear scripts apart so that kernel feature makes sure
initrd gets generated, and stage2 (which is still all
about propagator) cares for its bits.

The newly-introduced STAGE1_KCONFIG variable serves
to keep those kernel configuration options that are
required to be present in the kernel to boot.

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.

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

It was removing autodetection setting completely
thus implicitly setting it to the default "all"
with make-initrd-0.8.1+; just set it to be empty.

Thanks legion@ and boyarsh@; see also #28578.

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.

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.

*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

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

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.

An initial draft of it was done half a year ago but several tricky
thingies had kept the code from showing up as it was rather brittle
and incomplete.

This implementation involves quite a few changes all over the place
but finally works good enough for live and installer images.

Please pay attention to the versions of these packages:
- installer-feature-setup-plymouth (0.3.2-alt1+)
- branding-altlinux-sisyphus (20110706-alt2+ if used)
- plymouth (0.8.3-alt20.git20110406+)

See also:
- http://www.altlinux.org/Branding
- http://www.altlinux.org/Plymouth

legion@ implemented skipping depmod call, and that's several more
seconds for most of the images; let's shave these off if possible.

Looks like the 128k default block size is pretty well chosen:
it saves ~6% of image size compared to 64k, and subsequent
differences are ~3% per doubling the block size up to 1M
(thanks led@ for carrying out the tests).

So we'll stick with 256k for "normal" xz compression (inodes
uncompressed) and get 512k back for "tight" one (compressed).
The runtime performance issues are to be examined yet when
bootchart or the like is deployed, nothing drastic though.

With "fast" (gzip/lzo) squash compression inodes go unmolested.

For the record, tight live-webkiosk builds as 95M image in 3:40,
and tight live-flightgear.iso builds as 669M image in 6:34.  Nice.

There's no much sense going for 1M block size: e.g. live-webkiosk
would drop to 93M (3:46) but its load time would increase up to
2:07 as compared to 1:48 for -b 524288 and 1:42 for -b 262144 -noI
on a Duron 500/512M system given the very same DVD+RW media.

The existing implementation would handle kernel differences
just fine but a bit too automatically: if it sees xz support,
that's what will end up being used (and if there's -Xbcj binary
compression filter available for the target platform, it will
be applied unequivocally either).

It's perfectly suitabe for getting fine-tuned release images
but is also a bit too resource-consuming while developing the
image configuration which has no business with its compression.

The one and only knob is SQUASHFS (see doc/variables.txt);
to give an idea of the differences, here are some numbers
for a mostly-binary (43% as per 99-elf-stats) webkiosk livecd
and a rather less so (18%) flightgear one on a dual quad-core
X5570 node (each mksquashfs run used up all the cores):

SQUASHFS | live-webkiosk.iso | live-flightgear.iso
---------+-------------------+---------------------
fast     | 3:30 / 130M       | 5:11 / 852M
normal * | 3:37 / 100M       | 5:35 / 688M
tight    | 3:50 / 98M        | 6:47 / 683M

Thus if the knob isn't fiddled with, the defaults will allow
for a reasonably fast build of a pretty slim image; if one is
building a release or if a particular image is very sensitive
being close to the media capacity then just add SQUASHFS=tight
and see it a percent or two down on size.

Please note that lzo/gzip-compressed images are also quicker
to uncompress thus further helping with test iterations.

Thanks to led@ and glebfm@ for helpful hints and questions.