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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
use/live/install stopped to provide a desktop icon; the nuance is
that zdg-user-dirs-install.sh script in livecd-install package
expects ~/.config/user-dirs.dirs to actually do that.
This script hook used to lurk in live feature but was deemed needed
in cubox images too; thus it's time to move it into a standalone
feature (maybe a configurable one, even).
Thanks glebfm@ for initial shot and sem@ for discussion.
Hardly belonged there in the first place and became a culprit
during armh branch development since it had to be forked in
an ugly manner; move to rootfs hooks and be done with it.
VM images will be able to benefit either *but* installed systems
might have some trouble when this is implemented:
http://lists.altlinux.org/pipermail/devel/2013-May/197447.html
Split off use/live/x11 as a common free/proprietary ground either
(this refactoring had to be performed in parallel with x11 feature
being revamped, diffs quickly became intertangled unfortunately).
This has had several goals:
- a target suitable for x86 and armh providing a rather
minimal set of base xorg packages and generic drivers;
- task-oriented targets for graphics use cases:
+ "desktop" means rather 2D focus with 3D being welcome
or even essential but not performance critical, thus
"a slower driver is fine as long as it does work";
+ "3d" means specific 3D performance being critical,
that is "no 3D means no use at all".
Regarding the free and proprietary 3D-capable drivers:
the previous idea was to split out some common ground
and then add the contenders on top of that; the current
approach is based on the observation that the live images
requiring proprietary NVIDIA/AMD drivers *by default*
are usually of not much use with hardware that lacks
proper 3D acceleration (like Tseng cards) or the driver
support for that (like Matrox these days).
Intel videodriver makes for a special case though:
it is both free and top-notch performer.
Thanks sem@ and boyarsh@ for discussion.
PS: xorg-drv-{keyboard,mouse,void} dropped;
those who need these can usually help themselves.
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.
Another service that's not very useful on a LiveCD;
maybe should be enabled by default upon installation,
this also requires a proper framework in place.
This reverts commit ae44169139
as libglx has been fixed already; see #27340 and #28782 for
the details, huge thanks go to Alexey Borisenkov for his
thorough investigation and patches as well as to shrek@
and sin@ for their cooperation to get this fixed in Sisyphus.
This is to cope with #28782 while the culprit is being found out;
not much of a loss while #27340 is open (thus no 3D with vboxdrv
anyways).
I chose to avoid pulling the service related machinery into
vmguest (and haven't got around to factoring it out from live
feature's scripts into a standalone form) so had to tweak these
as well.
The expected behaviour is to have online repositories enabled
when the livecd is running; the trouble with runtime detection
relates to the asynchronous nature of network configuration,
connection might get probed just before it is brought up
(thus failing the test).
Systems having been installed-from-live don't misbehave this way
so left unmolested.
Runtime detection is still available via use/live/repo/online
but is definitely not the default mechanism.
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*.
Please see the bug for explanations; too bad I chose to limit this
workaround to experimental gnustep image yesterday when aen@ suggested
to apply it universally...
It'd be better for this commit to appear before 0.9.7
(and clobber the original one) but at least the added
functionality has been tested; time to generalize it.
The issue has shown up in regular-*-20130207: /etc/resolv.conf
would suddenly be empty upon successful bootup in virtualbox
with a single DHCP configurable ethernet.
dmesg has some trouble signs:
aufs au_lkup_neg:267:kworker/0:2[998]:
I/O Error, resolv.conf should be negative on b0
sem@ tells something like that has been seen before in a different
configuration (multiple aufs overlays with /etc/ and /var sitting
in different ones resulting in broken hardlinks); rescue boot with
a test "echo > /etc/resolv.conf" yields an I/O error either.
The patch is loosely based upon livecd-net-eth and
m-p-d::profiles/live/image-scripts.d/init3-{network,resolve}.
See also #28484 for the (still ongoing) discussion.
Once upon a time the first and only ethernet interface
on a Linux system used to be known under the name of eth0;
but years passed and the systemd shadow has drawn closer
even to the seemingly remote areas like interface names.
In short, it might get named e.g. enp0s3 (a more human
friendly name of course) and the exact name is to be
figured out in runtime as well.
Sigh.
Currently done for 40-autologin script only but might be
more widely useful: when describing an action to be done
while forming the LiveCD image, also prepare the one that
undoes the effect so that an installed LiveCD doesn't
(mis)behave as if it were young again.
NB: livecd-install provides 50-{gdm,kdm}-autologin-off.sh
hooks which can collide with ours, so let's override those
until things are sorted out properly at both sides.
PS: some half-year old nodm hacks are still in place for t6/branch
(and #27451 should be re-examined when dropping those).
This was requested by aris@ for live-gnome.iso but is so far
reasonable enough to do by default: the case of a LiveCD
including X and a display manager but willing to get on
with startx by default is rather nonexistant by now.
This is thanks to the fact that alterator-based install2 needs
alterator-browser-qt which needs X11 which needs working device drivers
-- and at least AMD C60 APU would only yield a nice dotted white screen
without that firmware.
Roughly the same for X11 bearing LiveCD images.
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.
The reason is that package lists and individual packages
are processed in different dependency resolution "transactions"
by mkimage; thus if packages (the more precise form of specifying
the contents) come first they can't override the lists appearing
later, and that's wrong: we should be able to specify the more
generic things and then pinpoint the specifics.
This became apparent while authoring [[Mkimage/Profiles/m-p/howto]]
asked for by drool@.
Setup network settings:
1. Init /etc/hosts with "127.0.0.1 localhost"
2. Set hostname, domainname
3. Set defaults for NetworkManager or
attempt to autoconfigure eth0 by etcnet.
Based on init3-network script from m-p-d.
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).
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.
