IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
At the moment, the ability to select the kernel with which to boot is
implemented only for grub (grub-pc, grub-efi, ieee1275boot).
note that renamed STAGE1_KFLAVOUR to STAGE1_KFLAVOURS, as multiple
kernels can now be added.
The drm feature solves the problem of creating a common entry
point for adding kernel drm modules for different package lists.
The need for allocation into a separate feature arose from one
parties to the need to make a switch between free and proprietary
NVIDIA driver, on the other, because of the need to add only drm
modules kernels for purposes such as use/stage2/kms and use/plymouth.
Also no more switch needed for RADEON, as only the free video driver
remains.
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: 2b3455c29a
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...
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.
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 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
c30490e2e884f8655a2704fa6a84e60b13876874;
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
