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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
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.
Looks like it's been dumped in along with the rest but not
actually used in {make-initrd-,}propagator; the problem with it
is that snd-dummy.ko matches and pulls a bunch of unrelated
modules where these don't belong (grep -w wouldn't match
snd_dummy.ko though).
These can be found in (semi-)supported branches still:
- loop.ko:
+ 3.0.101-std-def-alt0.M60P.1
+ 3.4.96-led-ws-alt0.M70P.1
- aufs.ko:
+ 2.6.32-el-smp-alt31
+ 3.4.96-led-ws-alt0.M70P.1
ehci_marvell.ko isn't found in contemporary sisyphus/armh
kernels but let's purge it later during archdep rewrite.
NB: libusual.ko has been renamed to usb-libusual.ko as of p6
(not to be found in p7 anymore), and nls_base.ko was in
2.6.32 kernels as of p6 but not there in p7; purge these
somewhere down the road.
This file has been floating around for quite some time,
and some of its contents are pure bit rot by now...
Drop the modules that don't exist as of 3.19.2-un-def-alt1
upon manual diff examination.
This has been missing for *so* long somehow, and adding some 200k
of modules for fast hardware that's widely available by now
looks like a deal.
Added USB Attached SCSI module just in case (or rather for weak
crc_t10dif symbols?).
The former install2-only "bloated binary" purge script
happened to hit stage2 (which is a lot more than just
install2); a kind of safety net has been stuck into it
to guard installable LiveCDs against this particular
cleanup but seems it was not enought for ildar@ who
reported this problem almost three years after it was
introduced.
This change re-places the script back into install2
section; the binaries in question amount for ca. 8 Mb
(except openssl ildar@ asked about); if these are deemed
unneccessary within any other stage2-based subprofiles,
please step up with details.
This function's got its argument order chosen for "aesthetical"
reason of $(2) following $(1) in the macros but the logical order
is exactly the opposite: we care for kernel flavour much more than
for module set (which is dependent upon it).
So while silent dropout of kernel-image if KFLAVOURS is set
but KMODULES is empty could be fixed by testing for $(2) only,
it looks like a good time to fix this discrepancy altogether.
It's been a given that any stage2 is propagator-based
but that's not neccessarily so; the "run X as PID 1"
sort of contest has sparkled interest in some others.
It should state clearly both the positive and negative examples
of rootfs concept use (its name is not consiceenough unfortunately,
and I haven't come up with a better one yet).
There's not much sense in overduplication of documentation
(tends to get stale faster then), still it's not good to
just refer to the code as the PDF/HTML book is less useful
then; maybe drifting towards "recommended" bits with more
"advanced" things being impleentation-defined is better.
It conflicts with r8169.ko inobviously.
The whole mess looks like this:
- r8169.ko doesn't work for all of Realtek 8111/8168/8169 mutations
- r8168.ko works with some of the chips r8169.ko doesn't
- r8168.ko also works with many chips r8169.ko works with
- r8169.ko is provided by kernel-image package (thus default)
- r8168.ko is provided by kernel-modules-r8168 package (optional)
- kernel-modules-r8168 package requires r8168-blacklist package
- r8168-blacklist package is a one-liner that blacklists r8169.ko
- STAGE1_KMODULES wouldn't include r8168 (std-def) or rtl8168 (led-ws)
- sub.in/stage1/modules would mention r8168.ko (m-p-d: r8169.ko)
So a LiveCD built with use/kernel/net might work with RTL8111/8110
just fine when booted live but fail to automatically load the module
when installed onto hard drive; manual modprobe r8169 would work though.
NB: some of the chips (those available to me) would work just fine
both ways -- this has contributed to fixing this *that* late.
Bottom line:
do not install backup/kludge drivers overriding main ones by default!
Thanks sem@ for providing the crucial hint.
This change is done to reduce ambiguity in some cases;
the previous intention has been to ease navigation when
staying in a particular directory, now it's been changed
in favour of convenient toplevel `git grep' in fact.
Both variants have their pros and cons, I just find myself
leaning to this one by now hence the commit. Feel free to
provide constructive criticism :)
Some path-related bitrot has also been fixed while at that.
Its name might still change through 1.1.x series
("userfs"?) but things like this should be mentioned
at least -- or superfluous references to neighbouring
entities should be removed.
Minor fix: /boot directory is not cleaned for livecd if there are
homeros-install or luwrain-install files (in addition to live-install
and livecd-install being already checked).
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.
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 issue is that r8169 is rather broken nowadays while
r8168 tends to work on the same hardware; see also #28473.
Thanks zerg@ for having hinted that it's stage1 modules,
not the root squashfs.
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 newer kernels have versioned NFS support code moved
into a few separate modules with nice self-explanatory
messages reading "Protocol not supported" if one has
managed to overlook this; thanks boyarsh@ for heads-up
(based on f545923271f9d1938d1887632ab4697c4c009039 m-p-d).
The issue actually hit image.in/Makefile: "metadata" target
in features.in/metadata/lib/50-metadata.mk wasn't reached
even if features.in/build-distro/lib/90-build-distro.mk
would ACK that the "whatever" actions included "metadata";
thus Metadata/pkg-groups.tar wasn't created and the installer
silently failed to install the .base system.
Let's armour the rest of the cases where the order of inclusion
might be important as well.
hsh-initroot leaves the chroot's root directory permissions
as 1775 while these should really be 755 at most; let's fix it
(important for both VE and VM images, useful for rescue/livecd
ones as well -- especially those with an installer onboard).
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.
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.
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
The early version considered ISO and KOI encoding families
as obsolete; the current one is a bit more wise and knows
these are just /rare/. Thanks glebfm@ for #27168 research
and cinnamon by slava@ for ISO-related noises at startup.
There were STAGE1_PACKAGES_REGEXP and MAIN_PACKAGES_REGEXP
but adding more of those was postponed to avoid bloat and
bitrot; THE_PACKAGES_REGEXP is needed for use/firmware now
and looks like BASE_PACKAGES_REGEXP and LIVE_PACKAGES_REGEXP
will be useful before too long either.
Docs updated to include stage-specific package related vatiables.
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.
This kind of test was proposed by led@ to gather statistics
on chroot's contents going to become squashfs (the script
optimizations lowering added overhead from ~10 sec down
to a subsecond range were also proposed by him).
Intentionally not documented in doc/variables.txt due to
the rather lowlevel nature of the probe (at least so far).
The knobs involved are SQUASHFS (the additional effort kicks
in only for "tight" case) and GLOBAL_SQUASHFS_SORT (must be
non-empty for this extra overhead to occur).
Additional experimentation is needed to find out whether
the difference in squashfs size and performance is worth
the trouble (seems the impact is non-zero but pretty minor).
There's much reason for reuse instead of duplication
among the different stage2-based subprofiles.
In particular, the rather monolithic driver cleanup script
of the ancient is better done in several clear pieces with
the final depmod run.
Scripts dropping apt/rpm databases will dump pkglist first.
A script purging /boot/* will honour live-install if present.
Minor inno^Wfixups all over the map too.
Fixed up the remnants of the early style mix
to correspond to the proposed doc/style.txt;
the rationale being that
if [ ... ]; then
...
...
fi
is the more readable construct among itself,
if test ...; then
...
...
fi
and
[ ... ] && {
...
...
}
due to the condition being more distinguishable
when bracketed and the body more apparent as the
one inside "if" and not any other block; the less
obvious difference is that the final construct of
the latter form is prone to the whole script exit
status being non-zero if the condition isn't met.
As too many things started duplicating between distros proper
and (e.g. corresponding) LiveCDs, it became apparent that a class
of entities which end up working for THE_USER (not a sysadmin,
and not a developer, just a Linux user) is in need.
So THE_KMODULES will power installed basesystem and live image,
while THE_PACKAGES, THE_LISTS and THE_GROUPS will participate
in building those.
