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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Minor tweaks to toplevel docs as well as some doc/*.txt,
doc/variables.txt renamed to doc/params.txt, and a brand new
doc/pkglists.txt is added (thanks manowar@ for his considerations).
This one was requested by Andrew Churashev; please note
that the image in use must contain recent flash plugin
so that at least the already known vulnerabilities are
more or less plugged in it... and Sun Java plugin isn't
going to get secure either.
A virtual machine isn't very useful if there are no means
to access it; let's bring up the basic networking and provide
root SSH access via pre-existing public key.
As the remote access with known default credentials is roughly
equivalent to just lending one's VMs to anyone with network
access to it, the fallback root password is now exterminated;
you have to provide one (or a long enough random string
if you plan to use keys only, see e.g. apg utility).
There's no need to repeat the typical openssh-* triade
all over the place; those who need server and client
are better off pulling in "openssh" pkglist, and those
needing a particular package should specify it.
It appears that reusing installer-feature-*-stage3 packages
is perfectly fine with VM images; these just need to be removed
after the package scripts they carry have worked out.
Raw disk images are convenient and universal
but there are custom formats like Qemu's qcow2
providing additional features, e.g. copy-on-write
or space savings. All of this ultimately belongs
to mkimage but in the mean time has been implemented
here as well.
Yes, mkimage-profiles is now able to build VM disk images.
So far the support is pretty basic:
- a single hard drive image with a single partition/FS
- only stock root password is configurable
- LILO is hardwired as a bootloader
The resulting images tend to boot under qemu/kvm though.
Please see doc/vm.txt for the warning regarding additional
privileges and setup required. This was started back in
February but I still hoped to avoid sudo/privileged helper
(and libguestfs is almost as undistributable as can be)...
Thanks:
- http://blog.quinthar.com/2008/07/building-1gb-bootable-qemu-image-using.html
- Alexey Morarash who reworked that as https://github.com/tuxofil/linsygen
- led@, legion@, vitty@, aen@ for providing advice and inspiration
autologin won't register a consolekit session, and gnomes
are too greedy regarding sessions to let us go unmolested...
This particular image isn't production ready when built on
current Sisyphus yet due to unresolved NM/dbus problems
but I decided to at least archive the reached state.
This one is contributed by Max Kosmach and somewhat
streamlined/tweaked by me; a part of it rather belongs to
nodm and xinitrc packages but is not exactly trivial to get it
there due to the looming systemd-logind/consolekit disaster;
see also #27449.
Several hacks to make NetworkManager usable in a LiveCD environment
are there too (but it resists so far).
Why would anyone try to remove apt when it's needed
for package dependency tracking for the installation,
it only takes a less cursory look at the build.log
to figure out it didn't actually happen anyways...
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
It somehow managed to evade me that $(TMP) might be uninitialized;
definitely should be checked before stuffing into sed substitution
command.
NB: this could be done in pure make but my take was less readable.
Thanks shadowsbrother/gmail for hitting and reporting this.
It might be spottable but not immediately obvious that a feature
lives entirely in features.in/FEATURE and every target it provides
is described in the corresponding config.mk; thanks dkr@ for asking.
Just like livecd-install, graphical installer KMS support
looks better as an optional part of install2 feature.
Of course it's optional only if the release manager is fine
with VESA drivers and not KMS-requiring intel/radeon/nouveau;
thanks led@ for a confirmation just in case.
After having added metadata dependency livecd-install
started to look more like a feature than like an intermediate
distribution target; so things were shuffled a bit that way.
This further refines the modular build by making
metadata being a clearly separated feature rather
than having to rely on runtime tests, and also by
moving the code which cares for kernel bits of base
installation (.base list) in a feature of its own.
There's more to it but let's get the ball rolling first.
The initial work covered live images but missed an installer bit
(thus notes and slideshow were missing in install2) while forgetting
to put branding packages into base list (thus kindly making these
available for *manual* installation sometime after, ouch).
It's hard to tell a successful build from a failed one
if downstream hides the exit code; it's useless to continue
a `for' loop if a pipe shoves that to a subshell; well it seems
that a bashism is worth a thousand quirks with extra fds here.
Minor regexp enhancements are also due.
reports.mk made a bit more resilient/prudent either.
NB: for the feature to work properly the chosen branding
package set should have proper Provides: and Conflicts:,
specifically it must explicitly conflict with the most
lexicographically cool package set around (these days
it's sisyphus-server-light).
As duly noted by glebfm@, branding issues need more attention
by now since only stage1/install2 got some of it so far in this
regard. Hence the dedicated feature comes to the rescue
(well no, it doesn't actually mess with rescue!).
Following m-p-d, a more involved default output directory
structure is feasible now:
~/out/name/date/name-date-arch.type
instead of plain
~/out/name-date-arch.type
This particular behaviour can be achieved by passing
SORTDIR='$(IMAGE_NAME)/$(DATE)'; note the single quotes.
Reports are also saved in this resulting structure
albeit the place is still highly debatable.
use/slinux-live: in p6 slinux had install-dvd version too
lists/slinux/misc-dvd: user 3d-proprietary comes from use/x11/3d-proprietary
lists/slinux/misc-dvd:restore compiz
slinux: use/syslinux/localboot.cfg
Sometimes it's desirable to provide the kernel supporting
maximal amount of RAM on the system; bad news is that x86
has a kludge named PAE, good news is that x86_64 doesn't
need it at all; but now we must be able to choose between
those.
BIGRAM will hold the flavour needed.
This script specifies the (excessive) lists of services
to be enabled and disabled explicitly; these are mostly based
on profiles/live/image-scripts.d/init3-services from m-p-d.
There might be systemd related pecularities though...
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's no real reason to keep bcmwl and ndiswrapper
around exclusively as the currently available support
vastly takes over the early attempts at the task.
(it's not about bare firmware though, and some day
something like use/hardware/wireless should get in)
Initial SPICE support has been added for kvm/libvirt installation
and boot-up using qxl and spice by default as proposed by shaba@.
VirtualBox part is shifted a level deeper correspondingly
but otherwise stays the same.
It is actually an effort by glebfm@ to create an experimental
systemd-based Simply Linux LiveCD; I merely reviewed the original
diff, moved kernel related bits to firmware (see preceding commits)
and introduced a dedicated pkglist namespace by creating a directory.
THE_PACKAGES_REGEXP is in place, let's rebase firmware packages
so these would be available in LiveCDs either.
The news for systems being installed is that MAIN_* is optional
while THE_* is included in base system; firmware packages tend
to be pretty tiny and harmless.
kernel-wifi pkglist has absolutely no sense by now, hence purged;
firmware-rt* and firmware-i2400m are merged into firmware-linux.
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.
A pretty common issue breaking the image build is inter-package
file conflict resulting in hsh-install failure down there.
Let's bring that back to attention conveniently.
glebfm@ asked what to do with new package lists: whether these
belong to features, or to distributions themselves. This question
is actually open and up for discussion but there are guidelines
that can and should be written down already; and so they were.
Added pkgdups utility reference as well.
Multiple ARCHES won't just magically work without
the ability to figure out the correct apt.conf;
fortunately there's just the right example handy
in profiles.mk.sample already.
Thanks glebfm@ for feedback.
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.
APM enabled notebooks would usually hibernate to
a partition of special type and special format;
thus to make use of this APM BIOS feature folks
might need a corresponding formatter.
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 is at least one known deficiency for mkimage-profiles:
build.log will be truncated if verbose mode is enabled and
hasher version is lower than 1.3.22.
The check is done here since it's where the logging is arranged,
and doing it in image.in/Makefile would result in the warning
about log-truncating software being truncated by the said software.
Thanks Max Kosmach for reporting this inobviousity.
The output was still somewhat ragged in 80x24 terminal window
with fmt(1) which wasn't anticipating the word length difference
subsequent column(1) would have to cope with later on.
Thanks Loic Cattani for his shell columnizer implementation:
https://github.com/Arko/Columnize
Thanks snejok@ for spotting the missing, I didn't get around
to tests with headphones...
Also fixed nouveau getting in after target shuffling,
and tweaked firefox homepage to be useful in this context.
- incompatible change (to fix the rather broken early style):
use/syslinux/ui-% is now use/syslinux/ui/%;
- default timeout changed to 9 seconds (long enough and keeps
the countdown in a single figure);
- added totaltimeout of 300 seconds;
- provided live kiosk images with almost-instant boot by default;
...and some other assorted tweaks here and there, sorry.
Thanks to a reviewer who came with useful feedback and a goal:
http://www.opennet.ru/openforum/vsluhforumID3/83728.html#136
the live-webkiosk image got forked into a separate one:
- dropped DRI, virtualbox GA, mc & co, docs, rpmdb;
- added Russian keyboard layout (ctrl+shift to toggle);
- rebased live-webkiosk onto live-webkiosk-mini ;-)
Maybe vbox guest additions will get back but rpmdb is a bit
impractical on a kiosk squashfs image, even in presence of
aufs rw overlay.
Now is the time for all fonts to be pulled in when needed and not
along with the X server and hardware drivers; tablet support is
moved to a (preexisting) specific target either.
There's no need now to arch-discriminate a few older drivers too.
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.
This one should help (erm... hope not the other way around!)
testing both 3D setup and FlightGear packages I happen to
maintain in a known clean environment.
The previous configuration would result in intel-only
3D being available since nouveau and radeon kernel modules
are packaged separately with most kernel-images; getting
NVIDIA/AMD drivers in is more tricky due to availability
of both proprietary and free implementations with the choice
being rather a tradeoff in each case (somewhat less so with
ATI/AMD drivers).
So this is a first shot at the problem: FlightGear would
freeze on me with today's nouveau.
As was noted by Alexey Shabalin in libosinfo context,
current ALT Linux images tend to lack ISO9660 metadata
-- which they did have back in the day of Master 2.4.
Please note that the data collection occurs this way
due to mkimage's config.mk resetting the values to be
empty; this was worked around by using another config
file, $(BUILDDIR)lib/iso.mk, and including it later
but that would require a separate target with per-target
CONFIG variable which isn't elegant at all given the need
to actually build up the metadata set.
So the variables were changed (to be more readable anyways)
and then proxied back to BOOT_*. This might be cleaned up
some day after the inclusion order is tweaked or mkimage
defaults get set-if-unset-yet (?=).
openssh-server is in need indeed on almost any server instance;
thanks Aleksey Cheusov for reporting the shortage.
This might be amended in the future but is reasonable right now.
As noted in doc/assumptions.txt, the SHELL based target tracing
only works for rules with recipes, even empty but present ones.
The simplest thing to do is hooking "; @:" onto the rule's tail
(one-liner with a non-printing shell builting "true" command).
The purpose is being able to examine particular target interdependency
graph for a given image having been configured to avoid convoluted
dependencies (loops in particular).
The implementation is based on SHELL hook hint by John Graham-Cumming:
http://cmcrossroads.com/ask-mr-make/6535-tracing-rule-execution-in-gnu-make
It looks like the intermediate targets aren't all equal:
some define a finished feature while some create a common
lower level piece of configuration.
Let's do shortcuts for the former so that a distro line can be
more terse and descriptive; help targets in features.in/ tweaked
accordingly.
There are pseudo-distro targets that are useful to combine
the needed bits and pieces for a few more different end-user
images but that are useless themselves (e.g. desktop-base
wouldn't even start X session before someone would have
installed a window manager).
Let's just hide these under the hood so that `make help',
`make everything' and potential frontends don't bother.
The package list taken from mkimage-profiles-desktop
and trimmed down due to current TDE packaging difference
as well as extras being defined elsewhere.
ltsp-icewm used to be the only ALTSP (testbed) distro over here
but now its terminal server part works good enough to seperate
it from the UI part.
A few additions to facilitate testing, tweaking and benchmarking:
iftop, openssh-server, mplayer
If we have a supported display manager, we should rather autoconfigure
that one for autologin instead of configuring autologin package:
those tend to play better with "modern" session management in terms
of runlevel control etc.
xdm doesn't really differ though.
TODO: maybe skip autologin *package* configuration if any dm found
in the live image-script?
From what I've read so far, most of the code should run on 3.80;
there seem to have been some bits that are dependent on 3.81
features, but there is not a bit that depends on 3.82+ features
so far.
It's preferred for Razor-qt's logout app to be able to turn
the system off or reboot it; xdm lacks consolekit support.
Thanks Alexander Sokoloff for the hint.
If there's an ethernet interface, a DHCP client, and these
can result in connectivity out-of-box, then it's rather
a feature for almost any LiveCD.
Thus the configuration script is moved from dev feature
to live one with the addition of dhcpcd/dhclient test.
This is asking for some more neat solution though...
As it happens, I've stumbled upon a successfully built image
with alterator-grub in BASE and lilo in install2's installer-steps.
Of course the installer bailed out after dealing with packages :-/
Thanks Leo-sp50 for pointing out the (hopefully) right direction.
There's still an annoying problem (a race?) manifesting itself
as installer bailing out between packages installation and lilo
setup with X segfault in logs; while the culprit is not known yet,
let's avoid that for most images by moving the bootloader request
from the former "leaf" target (which noe became a "node") into an
experimental server-systemd one.
Thanks Leo-sp50 for bringing that to my attention again; see also
http://forum.russ2.com/index.php?showtopic=3310&pid=31364&st=0&#entry31364
As was duly noted by Leo-sp50, both server.mk and desktop.mk
duplicate a few bits layered over bare distro/installer which
happened to be both a dependency (thus should reduce redundancy)
and a "real distro" target (well, it doesn't just work yet, need
to provide networking and sources.list in install2 by hand).
Fixed by moving a "node" to distro/.installer along with typical
additions and leaving a bare installer as is by now; there's a
need to get it working at least for DHCP/ftp.altlinux.org case.
From now on, non-empty SAVE_PROFILE variable will indicate
the need to carry the particular generated profile inside
the image built from it.
Thanks gns@ for this feature in liveflash.eeepc.
So far the tagged scripts concept is too fragile,
and these were used unconditionally anyways.
features.in/Makefile is broken regarding copying
tagged scripts right now...
This one starts up a Firefox session in kiosk mode
(there are several extensions, I find hsv@'s one
preferable) and tries to browse /image/index.html
which corresponds to index.html in the image root
(could be edited by means of e.g. isomaster).
It's rather unexpected that someone would do an X11 LiveCD
without user autologin -- but even if that's the case,
then this waypoint is just not used for it.
Courtesy of prividen@, there's actual x86_64 client support in ALTSP.
Although led@ tells that it's i586 optimization that hurts on i686+
and should be replaced with either i486 or i686 for that matter...
A larger block size was recommended by led@;
gns@ seems to concur as the 512k value was borrowed
from liveflash.eeepc profile (along with -noI).
The other issue is with binary specific compressors:
x86 was clearly assumed while the data for an educated
guess are pretty handy. Please note that using filters
incurs additional compression attempts for the utility
to choose the best result.
There was a somewhat subtle Makefile->main.mk rename leftover
lurking in "everything" target: the default Makefile got used,
not the supposed main.mk -- which resulted in an attempt to
get way too much job done (the number of builds per target
became $ARCH squared, not just $ARCH).
Huge thanks to led@ for being an inspiring pedantic!
A minimal chroot supporting extension via apt-get;
vitals if built on Sisyphus as of Jan 16, 2012:
i586: 13M tar.xz, 58M chroot (33M w/o /usr/share/{doc,locale,man})
x86_64: 14M tar.xz, 60M chroot (35M w/o /usr/share/{doc,locale,man})
Trivial fixups (extra checks) added to two script hooks.
As was found out by Vladimir Karpinsky (thanks for patience!),
the autochosen directory might still have too restrictive mount
options -- nodev and/or noexec. Hopefully the diags are a bit
better and faster by now.
It happens that if the host environment isn't particularly
tuned up for package builds already then bin/mktmpdir might
come up with a directory outside hasher-allowed prefix list;
now that's a shame and not a Christmas gift, clearly.
Thanks Vladimir Karpinsky for pointing this problem out too.
It was briefly mentioned in QUICKSTART but somehow managed
to evade the commandlines provided. And while at it, let's
make errors like this more explicit to avoid extra lookups.
Oh, and fix QUICKSTART so that readers miss the hassle. :)
Thanks Vladimir Karpinsky for pointing this problem out.
doc/variables.txt was missing the already-existing BUILDLOG
variable description, and ARCHES got added during multi-target
toplevel rewrite. Other minor fixes come as appropriate.
The fallback case of building in a brother directory moved
from the last line of code to the first one becoming more
explicit along the way.
Support for slash-containing argument (being a tmpdir name
template prefix) has been added.
The former toplevel Makefile is now toplevel main.mk;
this change allows for multi-target, multi-arch processing
in the current toplevel Makefile.
As the "build" symlink semantics change quite considerably
when one is doing bulk builds (several pruned builddirs might
be useful for comparison), BUILDDIR is now much more likely
to be recreated: the cases when it will persist are when it's
either a single-image build or when the prefix hasn't changed.
There are some more or less subtle bugfixes and enhancements
all over the map as well.
Done within 20111230..20120102 timeframe, actually...
First, let's not do rsync --delete on an unverified target dir
again: the lesson was learned during a subway hacking session
and I must say that SSDs are frightening fast (even if it was
more than a second to realize what happens and terminate the
extermination before it got /home, thanks xterm).
Second, let's use a variable for common name and make's own
realpath function instead of external binary.
Initial openSUSE package base taming effort has shown that
relatively few things should be fixed; subst has been generalized
as -i option to sed(1) since its introduction, so let's just fix it.
*_PACKAGES and *_LISTS shouldn't inflict copypasted blocks;
we can iterate over these just fine.
NB: dump-*, not dump_*, due to namespace pollution hurting
debug target if done the latter way (in case someone misses
the morning tea as wel).
As current devmapper doesn't allow for simultaneous
mounts of virtually the same device by different names
(signalled by "Device or resource busy" when trying to
e.g. mount /dev/sda2 but with /dev/evms/sda2 being just
fine), EVMS triggering such behaviour but rarely needed
should be avoided altogether until a hook to disable it
is in place.
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.
Some parts of *image* configuration started slipping down
into the *feature* configuration, and that was wrong; fixed.
Also introduced proper use/live/x11 (via use/x11/xorg with added
wacom support for the sake of #26723/#26724) and rebased the
pre-existing descendants onto it.
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.
- parameter order fixed to "simple first, then those with args"
and documented as the preferred one (might be debatable, okay)
- added "lowmem" to live so it avoids a ramdisk but works off media
(it's a knob for propagator)
- added "fastboot" everywhere (but failsafe install) to make use
of Linux 2.6.29+ async controller initialization
- every snippet got a trailing newline so that isolinux.cfg is readable
And a fancy makefile to check for shortcut dups!
Some more filesystem related utilities inspired by PLD rescue
are due indeed; but ntfsprogs are obsoleted by ntfs-3g, in fact.
iotop and iperf were suggested by stalker@.
Here we go with postprocessing priorities along the way
as ISO hybridization has to occur before implanting
final MD5 sum (which must happen earlier than e.g. some
external MD5SUM file generation).
Unfortunately proper dependencies aren't applicable here
(though I'd like to be proved wrong on this one).
Please note that this needs propagator > 20101130-alt9
for automatic mode to work (has also been worked around
in gfxboot case with design-bootloader-source-6.0-alt1).
Thanks rom_as@ for asking about the hybrid image status
and helping out with testing.
This one used to use LIVE_MAIN_GROUPS which seems to be
overlooked substitution artifact from walking over
GLOBAL_PKG_GROUPS and GLOBAL_LIVE_PKG_GROUPS of m-p-d...
(not that LIVE_GROUPS are defined anywhere yet)
Actually there's an added duplication in the form of the
test that was previously missing in pkg.in/lists/Makefile
-- that has to be done properly when it's clear how.
This fully omits pkg/lists/.base generation in environments
that won't make use of it.
The outmost shell loop got replaced with a (hidden) bunch
of targets -- it's somewhat controversial as the inner loops
are still there (but at least don't wrap around my SXGA+).
Full targetization might be beneficial in terms of parallelism
achievable *but* that would ruin git history being generated,
and building a distro configuration takes a few seconds at most.
(upon reading http://stackoverflow.com/questions/5414418/)
The idea is to check:
- the reachability of every target
used to build the image in question;
- the availability of all the package lists
and subsequently packages for that image;
- the lack of "dangling" intermediate targets,
features, pkglists, hooks etc.
So far only the first step is implemented --
it's easy and somewhat helpful already for
make CHECK=1 all
The bin/pkgdups.sh script comes from m-p-d in considerably optimized
form and is to be used with the pkglist files of interest passed
as its arguments to produce a "hall of duplicates" among those.
The tagged lists received some updates along the rescue image lines,
most of those are actually inspired by http://rescuecd.pld-linux.org/
and to lesser extent a few articles on rescue/recovery/forensics
software -- so some newcomers are even employed already.
New stuff:
* distro/live-icewm -- basic icewm livecd with autologin;
* distro/live-rescue -- yet another gparted^Wrescue CD.
A better part of base+rescue tagged pkglist split off into
extra+rescue where the content belongs.
Thanks ruslandh@ for proposing to do a graphical rescue with some
particular tools (albeit qt4-fsarchiver clearly needs more work).
use/live/autologin target tries hard to configure any available
autologin means, including a dedicated package and a few DMs.
Thanks gns@ as liveflash.eeepc got robbed somewhat.
distro/live-builder target used to employ a few duplicated
packages that might make it to a list but as the list would
have only a single user so far these were moved to a target-
specific variable (hm, weird but "private" modifier broke).
Actually this is the proper rewrite that was looming ever since
tgz support was introduced: there are multiple archive formats
supported by mkimage, and there are multiple compression methods
available as well.
So the bullet got bitten yet again along with the "goal parser"
which should be more straightforward by now.
Thanks dkr@ and mithraen@ for the inspiration of this evening.
Partially reverts "Makefile: presume a distro by default" commit:
plain `make' should better help the user to decide the target
rather than rush to build them all upon her.
distro/.base target used to pull in localboot syslinux config
snippet which might be too early for some of the further distros;
it's a quite fragile equilibrium which was shifted a bit by imz@
(see #26606). Feel free to reopen the discussion though, things
might be tweaked so that localboot might be desirable on almost
every image even if with lower priority...
As noted by imz@ in #26608, a LiveCD is the more preferred
boot target to a local drive usually (just as was discussed
and implemented for ALT Linux 4.0 IIRC).
It was actually trivial given that the script was already
maintained as a package by enp@ and msp@; its usage requires
one to manually partition the target disk and optionally
mkswap in advance.
When ve/ support was introduced, a simple "make icewm.iso"
had to turn into the more elaborate "make distro/icewm.iso".
This latter one involves several keystrokes more, which is
not even (environ)mentally friendly.
This was supposed to get fixed somewhere down the road with
a fallback but the elegance of IMAGE_* setup waterfall barred
me from tweaking IMAGE_TARGET at once (and the downstream fixup
would imply re-tweaking the consequent variables as well which
is blatantly anti-mkimage-profilic being a brute fork).
OTOH testing for a "directory" part of the goal is going to
either deadlock on IMAGE_CLASS or duplicate its assignment.
So now when I've had enough typing an extra "distro/",
I'm going to just bite the bullet and tweak IMAGE_TARGET
with a test duplicating IMAGE_CLASS assignment indeed
(testing for e.g. "/" results in a different test,
which would be worse yet).
Please suggest a more elegant solution if you invent one!
As was (quite reasonably) asked by someone and me too,
why should a successful build yield a *red* line
(a grep's default)?
So now it's new and improved, 25% free and so forth:
with a successful build you get a green line, while
errors from a broke one result in red ones.
Clinically tested in both b/w and w/b colour schemes;
in case you're not satisfied, please return original
ANSI_OK and ANSI_FAIL values to the colour dealer
and pass your favourite ones instead.
It's now possible to:
- make distro/server-ovz.iso;
- make distro/server-ovz-netinst.iso;
- publish the former image's contents on ftp.linux.kiev.ua;
- boot the latter (~17M) image and enjoy the netinstall ;-)
The catch is that the stage2 (altinst file) location has to be
hardwired into syslinux config snippet for things to happen
automatically -- even if it can be specified manually in case
of failure.
The other catch is that currently a netinstall image is somewhat
tied to the particular image it installs since stage1 kernel and
stage2 modules must correspond strictly (the typical symptoms of
the glitch would be missing mouse driver and weird "permission
denied" errors during an attempt to partition the hard drives).
It might be desirable to provide multi-distro netinstall image...
The features might get copy-pasted (or even copied-and-pruned)
when initialized; there's an unneccessary duplication of the
function name in the line adding it to FEATURES list, thus
prone to being forgotten and causing some havoc later on.
It was wrong in the first place but tackling this with some
double-colon rules ran into terminality issues, and further
tortures were considered unneccessary.
The current solution isn't perfect (no completely transparent
function name registration upon corresponding target being called)
but at least it is an improvement...
It appears that features.in/Makefile functioned a bit
differently by now than was described back then: after
loops and pushds got rearranged for robustness, it stopped
to pick up a cleanup feature tagged script.
That particular script is now better de-tagged and simply
placed as a script to be merged into install2 subprofile.
The tagged scripts still require a bit more comprehension
to understand the use cases (e.g., do we need per-subprofile
tagged script subdirs or just a toplevel one should be looked
at, with script names telling where to put them).
README used to mix up subprofiles and features; fixed.
We've got some parts of it in build-distro feature,
and some went to dev feature for no real reason.
But a bare installer might go without package base,
and LiveCDs other than live-builder might find local
repository useful given aufs2 root overlay.
Now the overall scheme is more straightforward:
- a distro:
+ asks that a package repo be included
+ cares to further add the packages to it
- a repo feature:
+ pulls in sub/main for it to happen
+ provides genbasedir script to create repo metadata
+ supplements live feature with repo configuration
This is a base for "media check" to become available:
using this feature will implant a checksum into the image
so that it can be verified during install.
Also added a test/demo distro/live-isomd5sum target.
For real distros an alterator module is probably due.
This might be needed to install onto an SD card in a "native"
(non-USB-mediated) SD/MMC cardreader; thanks Vladimir Karpinsky
and gns@ for going over it for liveflash.eeepc case.
This feature was handling powersave already, so the name
should be changed already. Thanks sem@ for cpufreq-simple,
there's now a compelling reason for that rename.
Tweaked a few distro recipes accordingly.
There's a recommended version (0.2.0+ currently) and also
the minimal version, 0.1.7, which received the important fixes.
It was proposed by nice antique@ folks IIRC.
Unfortunately the "suboptimal version" warning is pretty modest,
and "minimal version" error will be apparent with DEBUG enabled;
still the latter will terminate the downstream build and leave
a clear message in build.log at any rate.
2011-11-08 00:07:38 +02:00
282 changed files with 3694 additions and 857 deletions
# NB: sshd might be needed for some particular cases
DISABLE="
anacron
bridge
clamd
crond
dhcpd
dnsmasq
mdadm
netfs
openvpn
rawdevices
slapd
smartd
sshd
update_wms
xinetd
"
for i in $ENABLE; do chkconfig $i on 2>/dev/null; done
for i in $DISABLE; do chkconfig $i off 2>/dev/null; done
:
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
