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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
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.
