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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
It might benefit the existing users to be able to configure the
build node persistently across reboots; though the need for something
like NFS overlay or repo settings piggybacked over DHCP is still there
(just ask ildar@).
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.
Thanks to Baurzhan Muftakhidinov's efforts along with help
from cas@ and zerg@, regular images should now support Kazakh
fairly well at least in terms of translation; this commit amends
these images with Ukrainian too and adds an experimental razorqt
based distribution that boots in kk_KZ by default.
There's no NetworkManager or connman in this lightweight image
so let's put at least the lightweight connection specific GUIs
like this one; proposed on the forum by Speccyfighter and
acked by squire as useful for traffic-metered plans:
http://forum.altlinux.org/index.php/topic,28619.msg201159.html#msg201159
Suggested by YYY; the initial plan was to include CUPS
in all the regular images but that turned out to be
impractical (too much bits added with too few actual
usage per bit expected).
So let's take s-c-p along with cups.
A syslogd is required by interactivesystem and we definitely
don't want any extra systemd on a sysvinit image.
Thanks Speccyfighter on the forum for the observation.
The former helps totem a lot regarding actual video reproduction,
suggested for gnome3-default metapackage; the latter helps aris@
to actually get any sound out, so is supposed to land there too.
A duplicate has formed while factoring out bare target;
as currently only the rescue image uses it in a special way
and that one benefits from additional crypto packages as well,
let's put LUKS related packages into bare for the time being.
The persistent storage is a nice addition to LiveCD images;
it doesn't come for free though in terms of performance
(especially for the first boot), so it should stay optional.
Note that use/live/rw belongs to base and not bare since
otherwise rescue becomes rescue+live which is superfluous;
hence the special use/rescue/rw.
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 original mkisofs would only care for the proper ISO9660 image
but we've switched to xorriso which is able to perform the hack
to yield UEFI hybrid images; thus no need for the postprocessing.
Requires mkimage >= 0.2.5 and xorriso (obviously).
Added sysklogd and udev-rule-generator-net there too; if someone
needs to inherit a systemd based image from distro/.desktop-network
don't break the existing behaviour please.
Rebased tde flavours to .desktop-network as these were the actual
target to fix.
There's some peculiarity causing Sisyphus' initrd
(namely led-ws and make-initrd{,-propagator} of today
to die with this message while booting the resulting ISO:
initrd: Running /scripts/pre/prepare/000-propagator
FATAL ERROR IN INIT: mkdir
I can't recover from this,please reboot manually and send bugreport.
It's required by make-initrd-propagator in "rw slice" mode
when the remainder of an USB Flash drive is prepared and used
for persistent storage; fdisk is also immensely useful in general.
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...
Whoops, and I was mildly wondering where are alterator modules...
thanks Speccyfighter again for bringing attention to the issue
which has turned out to be ultimately caused by an overlooked bit
being missing.
The real issue was that regular-tde.iso was discovered to
lack FAT support in alterator-vm (known as #28470); as the
filesystem specific packages are pulled in via rescue lists
let's add it here along with dosfstools.
Thanks Speccyfighter at forum.altlinux.org for spotting this.
As zerg@ noted there's synaptic-kde already; I managed to overlook
that synaptic-usermode still gets into kde4 image as it's put into
base+regular pkglist. Thanks aen@ for spotting.
Quite a few filesystem specific tools and utilities went into extra,
some of them pulled back from fs since the proper categorization will
clearly require even more effort.
Added utilities for: f2fs, nilfs, logfs, reiser4fs, clicfs, cloop,
ocfs2, exofs, zfs, cifs.
This one was just asking to be built for quite a long time;
http://sourceforge.net/apps/trac/smartmontools/wiki/LiveCDs
specifically accenting use of smartmontools 6.0 has finally
persuaded me to roll out yet another rescue livecd, that is
on the regular basis.
The reason is to contain the implementation details
within this feature while adding the ability to include
everything it can provide (e.g., for rescue images).
This includes an updated version of 50-fontconfig script
which actually works (the preliminary one attached to #28612
didn't); thanks zerg@ and cow@ for providing the incentive
to introduce it.
Based on m-p-d and installer-feature-kdesktop-fontconfig.
Forum feedback has shown that it's a bit surprising
given the lack of other multimedia applications in
baseline package set; aen@ suggested to leave it out
and hardware support testing requires much more than
that anyways.
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 metapackage was fine, the "only one" additional package
was more or less okay, but there came a dozen more so it's
now reasonable to stash these into a separate pkglist.
...and refactored its use in cinnamon image too;
this isn't a permanent solution though,
slated to move into fonts feature.
Thanks gns@ for suggestion.
There isn't much sense to keep an entirely separate flavour
as deepsolver starts being actually useful and icewm is
a somewhat special flavour for those who know their ways
around Linux plumbing.
It's possible that use/efi/signed target has fired already
at the time when use/efi/shell is invoked; shouldn't clobber
the signed shell with unsigned one.
The various *8168 and friends among kernel modules
have finally been pushed into a designated target
so that RM doesn't have to care which particular
additional ethernet modules are available in this
particular branch and kernel.
Tweak distros as appropriate.
NB: *maybe* this is required by distro/.base either.
acpi_call is used far too often when dealing with the newer
portable x86 hardware, we're better off including it when
it's available.
regular.mk adjusted appropriately.
Richard and Theo would probably roll their eyes at this point
but the unfortunate reality is that wireless hardware is very
much dependent on firmware being explicitly provided; so here
it is.
rtl8192 kernel module added since it's present in t6/branch
at least.
This change mostly concerns with making icewm flavour
the lean one again.
The goal is to widen the dynamic range of regular image features:
icewm is not a desktop thus can bear withouth systemd-logind
even if a bunch of network-managing-media-mounting crap has been
rigged to depend on it, and ALT domain client should be included
in most builds for convenient testing in SMB environments but can
stay out of this minimal and "different" image.
It also receives the "un-def" kernel flavour (3.8.0 as of today)
which might benefit from the more available testing facility too.
Its branding is also simplified, plain syslinux menu is fine;
in similar vein, refind feature is flipped from icewm-only to
all-but-icewm set of images with its state being good enough
as of refind 0.6.7 and mkimage 0.2.7.
mate-default pulls in mate-minimal and both of them
require packages which are also specified in this
pkglist; thus the pkglist should be pruned to avoid
double work and splits like "mate-vfs is dropped
from 1.5 package set, mate-default is adjusted but
the pkglist references the now-missing package".
It happens when there are no separate arch/noarch subrepositories
but everything is dumped into a single directory like in installer
or live-builder environment (at least as of today).
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.
Added use/live/net-eth so that autoconfigured images
still work in predictable manner.
May those breaking trivial cases walk with zillion of
cdrom, modem, ethernet etc device nodes all around them!
The inobvious issue is that while lxde-settings
is required by lxde-common and provided by both
lxde-settings-{altlinux,upstream}, we can't just
add the needed one via PACKAGES since the LISTS'
deps are expanded already with -upstream taking
lexicographical precedence.
This might become more serious if/when there are
several useful packages, -upstream isn't AFAIK
(thanks gns@ for explanation).
Citing the initial comment: "lxterminal is reportedly
sub-par (gns@) but official (aen@)"; the functionality
PoV finally won.
Terminus fonts added to account for presets.
See also #28567.
Added fvwm flavour specially for perestoronin from da LOR.
As if it wasn't enough,
- added UEFI support to desktop/,live-desktop intermediate target;
- added live installation capability to desktop/.livecd-install;
- added "net-eth" subfeature to get good ol' eth0 insteal of enp0s3;
- dropped use/x11/autologin as live subprofile sets up
a supported DM for automatic login anyways.
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.
enp0s3 is quite inferior to eth0 in terms of usability
even if it might be more convenient for the machine{,ry}.
Let's stick with what works here in ALT Linux (see #28484).
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.
The issue is that gfxboot's gettext support works on "label"
strings but doesn't work properly on "menu label" ones as of 4.04
(the "menu label" translations pop up in the "Loading ..." window
but menu items themselves are unaffected thus untranslated).
NB: debian wheezy's syslinux-4.05 package patchset contains
somewhat related 07-gfxboot-menu-label.patch; might be worth
attention given that debian folks participate in upstream.
Now this is ugly: instead of commoditizing the repetitive code
the result ended up working differently by creating several
repositories for the target subdirs instead of the single one
for the generated subprofile as a whole.
This results in .disk/profile.tgz being basically useless
in every image since c4311108ea.
The same "regular-gtk" based set of images received common
desktop background provided; note that kde4 won't like it
(branding package didn't really anticipate kde4 and is to
be updated appropriately as well as extended for mate/fvwm).
This one is also used for lightdm/gtk.
"regular-gtk" based images moved from the (unsupported) gdm2.20
to the (supported) lightdm with gtk greeter; while a couple of
gdm2 forks have emerged it's still unclear whether mate or mint
one will be actually alive, even short/mid-term.
The issue is that it's suddenly broken in current Sisyphus,
looks like the peculiar set of assumptions in fedora-tweaked
systemd+plymouth+gdm3 relies on tty1 being the X session tty
and it's different here.
It appears that manually specified IMAGEDIR, e.g. by adding
IMAGEDIR = ~/out/$(shell date +%Y%m%d)
to ~/.mkimage/profiles.mk, might be problematic due to
missing globbing. Let's make sure the paths are globbed
and directories are created -- since make's wildcard()
returns an empty string when there's nothing there [yet].
It appeared that plymouthd.conf wasn't set up properly
thus "service plymouth stop" didn't result in anything
meaningful; thanks boyarsh@ for his help figuring this
out again.
Folks have been wondering already whether e.g. t6 breakage
qualifies as a bug; it does indeed unless the "broken" part
depends on the features not available with that branch yet,
e.g. EFI support.
Its support was dropped in mkimage some time ago
since xorriso semantics changed quite considerably
and the tweak that was done here is now performed
out-of-box thus no longer needed.
It's aimed at providing UEFI shell implementation which is very
useful for repairs and debug; if the "signed" mode is requested
then the signed variant is used either.
Please note that there are two distinct uses:
- a shell lying around on a filesystem to be copied by hand;
- a shell available in EFI part of boot media to be launched
by firmware's or standalone boot manager (e.g. refind).
Let's provide the official terminal emulator as the reference one,
and those preferring others are welcome to include these either.
(to some extent this commit is biased towards regular.mk though)
The reason is that the most interesting live images by now are
installable ones, and while configurable boot order is not there yet
the "classic" livecd images will require manual choice to boot.
Thanks sem@ for reminding of that FR (which is still open).
It would be great to have #28289 fixed either so that aris@
could approve the image as usable (I totally agree that it's
a major piece of real world functionality currently missing)
looks like there's sense to prepare a starter iso for tests.
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).
- added destination homeros-nano.iso yields minimal
speaking image;
- added "homeros" feature contain scripts appropriate
for general Homeros functions but need further development.
The current refind support implementation doesn't boot
with either USB Flash or CD-ROM for me (due to the different
actual volumes, FAT vs El Torito, accordingly).
And when it does, a host with Secure Boot present and not
disabled yet would turn the unsigned kernel down unlike ELILO
(due to rEFInd using "natural" calls to boot it).
Both issues are reported upstream; in the meanwhile let's
migrate a single test image but build the rest with elilo.
It's not e17-default alone right now, gnome-icon-theme package
appears requisite at the moment so that menus and IBar aren't
half-empty regarding graphics.
Thanks aris@ for the advice and lots of patience with me.
UEFI support is pretty requisite by now;
and el-smp hasn't seen updates for almost
half a year by now so an actively maintained
one is clearly preferred.
See http://www.altlinux.org/Регулярные_сборки_образов
for the idea behind this set of images; in short, it's
*not* a bunch of polished end-user distros in a moment
but rather to facilitate Sisyphus package base testing
in as-is state during branch pre-release time.
It's a separate installation step to set the LUKS password;
see also #28200 for (terse) discussion and instructions on
getting this actually working for a distro.
These are out there in Sisyphus and should be used
instead of copious lines in a package list.
Thanks sem@ for proposing gnome-icon-theme to supplement
the lack of icons in the default theme; note that tango
set doesn't quite cut it, even with extras.
Thunar -> thunar; xfcalendar -> orage
There's use/x11/kde already but that serves somewhat different
purpose as of today; the naming issue (kde vs kde4) was tersely
discussed with sin@ at the time of the merge of his KDE4 image
related bits and it's still not that clear.
Let's try this way and see if existing images would be ported
to use/x11/kde4.
The whole live-rescue needs a massive facelift regarding
applications included and user experience achieved (remember
that folks are going to be stressed enough already with data
lost or system(s) not booting, and probably offline as well);
but at least it's UEFI bootable now.
The (funny but somewhat confusing) problem manifests itself as
E: Couldn't find package Binary
during a build run in the profile where a tagged packagelist
referenced by a specific target being built is open with vim
(which results in .FILE.sw? temporary file lying aside).
There's a possibility to run into IA32 EFI but that's rather
uninteresting hardware (ancient Xeon servers and <s>outdated</s>
early Intel Mac laptops). Just drop it on the floor.
As x86_64 UEFI support would result in "2D hybrid(r)(tm)" image
which boots with all combinations of BIOS/UEFI by CD|DVD/Flash
(or at least should boot), some downgrace seems due: use/efi will
turn use/isohybrid on non-x86_64 -- which will require further
tweaks on PPC/ARM some day.
Intermediate one: build-propagator *is* run off stage1,
no mkimage changes for that matter so far. This means
that m-p still duplicates mki-pack-boot to some extent
but the way to dedup this is still not clear enough...
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?
As was proposed by Alexey Varakin in community@,
whdd was built for ALT Linux by drool@ and pauli@
with some help by torabora@ and mithraen@; looks like
it's a worthy addition to the rescue kit.
The problem manifests itself when the naive parser ignores
any conditions that might have been set in the makefiles
included with subsequent attempt to run a target which has
its actual rule defined within e.g. "ifdef DEBUG" clause
(as is the case for conf.d/test.mk); that will fail with
no proper diagnostics currently.
Maybe this would be of some use (but then again maybe not):
http://stackoverflow.com/questions/3063507/list-goals-targets-in-gnu-make
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.
That is, p6/t6 continue to use 3.81 (while providing 3.82
alongside with it), and Sisyphus has moved to 3.82 before
p7/t7. We support both versions by now.
While ildar@ has some reason for the slimmer image
the somewhat standalone one is documented in examples
for offline use, ruining it in-place is not an option.
Let's just do a split (and lose a target-specific variable
example in favour of a commodity pkglist by the way; oh well).
a live-builder appliance is (or may be) usually used for building software
with many dependencies, hence needing access to external resources,
e.g. apt repos with lib${NAME}-devel packages.
This commit cuts RPM packages from the live-builder LiveCD.
The issue (#28002) resulting in vm image build error reading
Syntax error at or above line 5 in file '/etc/lilo-loop.conf'
was caused by fdisk-2.22 changing its "-l" option output format
to drop the very mention of the long irrelevant crap named "CHS".
The problem is, however, that we still need that crap to piggyback
a loop device's fake geometry to lilo while installing it there.
Reported by icesik@.
Somewhat kludgy unfortunately and might need even more tweaking,
I have only armv7l board handy at the moment to verify that
the transformation is going to work.
QEMU is bailing out here and now ("Exec format error").
Example sources.list.sisyphus.armh of the season:
rpm http://ftp.altlinux.ru/pub/people/asdus/sisyphus armh classic
rpm http://ftp.altlinux.ru/pub/people/asdus/sisyphus noarch classic
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.
Both do require postprocessing (see http://www.altlinux.org/UEFI)
until mkimage receives xorriso support and efiboot.img is passed
down there somehow, but it's beta than nothin' so far.
EFI/UEFI is mostly about partitioning and bootloader setup,
at least from a distribution's point of view; so the
appropriate tools should be handy and firmware interface
module should not be exterminated from installer images
but get autoloaded instead.
Please note that while there exists 32-bit x86 EFI
we don't bother with it at the time being: it's relevant
to some irrelevant Xeon systems as well as for the older
Intel Macs (<2008) that are long out of fashion anyways.
That is, initially we deal with x86_64 EFI only.
Introduced distro/.live-desktop-ru as a shortcut for
distro/.live-desktop use/live/ru which occurs several times
already (and the counter will increase right now).
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.
Thanks go to ildar@ for spotting this: my ~/.mkimage/profiles.mk
routinely contains DEBUG = 1 line which effectively masked this
regression in commit 307fb51f15.
Wouldn't be a big deal but syslinux.iso is recommended in
tutorial docs being slim and fast-building, and it's also
what's buildable locally in live-builder.iso environment.
ildar@ noted that the test involving whitespace is too
quirky for some quirky enough cases like
rpm-dir file:/var/cache/apt/archives . x86_64
-- let's introduce word boundaries there.
*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 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 initial sketch did work but was somewhat redundant
while lacking the knob conveniently change output directory
as well as means to get it cleaned up.
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.
The rationale for the former is that the image gets slightly
more compact (although the current sisyphus build is way larger
than the t6/branch build of the optimization time, need to look
into that...); and for the latter it's to provide yet another
installer with a different enough kernel so that there's one more
chance in a weird situation.
Actually just a split of livecd-webkiosk into the kiosk related
part and generic livecd firefox setup (turning off queries that
are pretty useless in that environment).
This is a mild generalization of what has been done by hand
to figure out a problem with make-initrd-propagator-0.10-alt1:
stripping anything intrinsically volatile off the build.log.
The filter set isn't perfect, and the proper logging will
involve mkimage tweaks as well (e.g., one generally isn't
interested in instrumental chroots' population that much,
so it should only be verbose at the higher debug levels).
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
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.
It's pretty ugly but dropping the current way
means losing the dependency tracking which is
critical to get the required alterator module
into install2.
Thanks mithraen@ for spotting, boyarsh@ for explaining,
and legion@ for hearty support :)
The problem would manifest itself like this:
/.host/script.sh: line 20: /usr/lib64/propagator/initfs: \
No such file or directory
mki-scripts: .../stage1/scripts.d/80-make-initfs: unable to run script.
Thanks Serg Markov for bringing my attention to this:
http://www.opennet.ru/openforum/vsluhforumID3/86552.html#61
While the official distros might skip some filesystems for
support reasons there's no reason for community distros to
do so either.
Let's try that with icewm.iso...
NB: installer has a misfeature of dropping jfs/reiserfs
support in runtime unless "expertmode" magic word
is on the kernel bootargs string (#27763, #17368).
Its immediate purpose was influencing the GRUB boot menu
*but* the implemented mechanism is actually a part of the
long planned text branding and might be further merged
into branding when hierarchical features finally chime in.
So let's get the naming straight before it breeds.
See http://www.opennet.ru/openforum/vsluhforumID3/86239.html#1
for a query that has led to this one; in particular,
- xdm dropped (won't log in root and there are no users yet);
- network is brought up and configured via DHCP by default;
- apt-get works out-of-box;
- default image size is twice the chroot size.
3.5.2-std-def-alt2 brings boot problems which were absent
with 3.4.x-std-def and are absent with 3.5.x-un-def;
seems like it's better to stay with known good variant
at the moment instead of having to fall back to it.
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).
The missing "; @:" at the end of the otherwise recipeless rule
resulted in target graph being broken; I should have checked this
when introducing these aliases (the intent was to reduce noise).
Not even alpha quality yet but at least debuggable:
- X session doesn't autostart but service dm start works;
- keyboard layout indicator is missing until started by hand.
There's a bunch of additions to the MATE package list:
thanks viy@ for pulling extras into autoimports,
several more tweaks done due to hints by dek@,
and openssh packages added for debugging convenience.
The kernel's been changed for the latest one (un-def).
This isn't ready for general consumption (just as centos one)
but the notion of REPO is floating around along with apt-conf
thoughts, and it might still be useful to someone poking around
conf.d/test.mk.
Request hasher-pkg-init.spec from mike@ or led@ if interested;
the experiments were carried out using openSUSE 11.4 repository
and slightly patched hasher (cpio blacklist for devices).
This part of docs was pleading to put it into a small shell
script; it was done to facilitate kas@' debugging efforts
so that qemu-system-ppc might eventually get fixed, thus
livecd-qemu-arch package now "obsoletes" this file.
Thanks both drool@ for his mild frustration with the current
documentation as well as Greg Kroah-Hartman, Heikki Orsila
and Neil Brown for http://lwn.net/Articles/504814/ -- the docs
should really emphasize *why* something is done, not *how*,
as the "how" part is better documented with the code itself
(that doesn't mean that "the big picture" isn't needed).
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.
Found myself pretty silly while sittin' at the rescue console
and bein' unable to leave the cool server room for a way
more comfortable armchair and a laptop's keyboard...
(yes, it was that disk array needing GPT tools)
Another feature suggested by Michael Radyuk (torabora):
some images are known alpha/beta quality, it's more handy
to just state this at the build time than to rename by hand.
This trots along the TODO item on text branding
and hopefully helps Michael Radyuk (torabora)
with his feature request to tweak the installer's
"Install ALT Linux" label; as an example, Simply
will now offer to "Install Simply Linux".
The package actually passed the test and just got uploaded
to Sisyphus proper; its aim is to help set up the cross-arch
QEMU build environment.
NB: there are known issues with PPC32-on-x86_64 (which were
the cause for this package and commit to be created in the
first place).
Some images were unbuildable (at least without special setup,
like ve/centos), unusable or just not useful in any meaningful way
(like distro/live-isomd5sum); as these tend to get any attention
during experiments, I decided to put them together in a separate
configuration file that would be effectively skipped if DEBUG
is not requested.
This one was suggested by enp@ for industrial use where
some extra protection for the boot process might be quite
desirable.
If no syslinux ui was specified (the stock configuration paths
ensure there is one) or if it was set to "none" explicitly,
then there's no boot: prompt (let alone any menu).
If there's a need to ensure that the boot process is not
interruptable by Ctrl/Shift/Caps Lock/Scroll Lock.
The prerequisites for a cleanup after a successful build
were somewhat weird at this point; now the rules are:
- if DEBUG level is more than 1 or CHECK is set, don't do it;
- otherwise if at least one of the following conditions is true:
+ there's more than one target being built in a row;
+ the build was run by e.g. alterator-mkimage;
+ metaprofile directory is read only
...then do a distclean.
If these are still weird or feel unsuitable for profile hacking,
drop me a note (or a patch).
Essentially all the relevant server images got cpufreq setup
and a power button handler; feel free to ask for revert if
this causes any harm in any situation.
`help' used to be the default target described at the very top
of the toplevel makefile but that got broken with g2f307ff;
spotted while discussing m-p with enp@.
Also pulled the pkglist/kmodule part out of distro/server-mini's
recipe and started off a standalone feature based on it.
NB: el-smp kernel now contains aufs as a module but propagator
doesn't try to modprobe it.
Actually the templates pretending to be usable missed the whole
interactivesystem (sysvinit would get pulled in by services as well).
Fixed somewhat but time and practice will tell.
TDE distros don't really need kdm4 which was proposed as
a replacement by zerg@ (for all the valid reasons but kdm3
wasn't maintained at that point, this has changed since).
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@.
The problem was spotted by Alexander Bandura:
bin/tar2vm wasn't present in the generated profile.
I considered extending features.in/Makefile to include
bin/ alongside lib/ but that would make the helper's location
unpredictable (unless BUILDDIR is specified explicitly) so
restricting sudoers would be harder; worse yet, the copied file
would come with write access for the user building an image.
The implications in restricted case are complex enough anyways
so the recommended implementation would only include a fixed
readonly location like /usr/share/mkimage-profiles/bin/tar2vm
as laid out in doc/vm.txt, and that means it's in the metaprofile
not a generated profile.
As it happens, adding another architecture required almost no changes;
native 32-bit ppc build took only ARCH and a repo, qemu-ppc one still
has problems (/.host/entry hangs while unpacking setup for fakedata).
Proof of concept on a QS22:
$ make ve/bare.tar.gz
** ARCH: ppc
/bin/sh: rpmvercmp: command not found
21:41:01 cleaning up
21:41:03 initializing BUILDDIR: build/
21:41:03 preparing distro config
21:41:05 starting image build (coffee time)
21:42:48 done (1:42)
** image: $TMP/out/bare-20120716-ppc.tar.gz [21M]
mkimage and hasher can make use of qemu to run
non-native binaries while working on the chroots;
thanks kas@, manowar@ and sbolshakov@ for implementing
this functionality as well as providing nice examples
through mkimage-profiles-arm and mkimage-profile-armrootfs.
This required the architecture check to be added since baking
a tarball with "arm" as its specified arch and x86_64 inside
isn't particularly good thing to let slip through; however
the implementation is quite fragile, bugreports and patches
are seriously welcome.
NB: APTCONF evaluation order between lazy make and nimble shell
turned out to be quite a delicate issue in this particular case.
The only thing to be fixed was setarch(8) symlinks assumption
that is correct for x86 but not for ARM.
There's also some hasher(7) setup to be done:
mkdir -p ~/.hasher
echo >> ~/.hasher/config <<-EOF
def_target=arm
#cache_dir=$HOME/tmp # depends on RAM/storage configuration
EOF
...and of course apt(8) should be properly set up too.
An example PoC build on a CM-A510 board (tmpfs):
$ make BRANDING=altlinux-centaurus ve/bare.tar.gz
** ARCH: arm
18:10:45 initializing BUILDDIR: build/
18:10:45 preparing distro config: build/distcfg.mk
18:10:46 starting image build: tail -f build/build.log
18:14:49 done (4:02)
** image: $TMP/out/bare-20120706-arm.tar.gz [23M]
The very basic bitmap fonts that were left in back a year ago
aren't particularly modern (even if they are somewhat elegant
and resource sparing which was the goal at that time).
So let's allow for something slightly prettier,
like Croscore Arimo kindly prepared by Steve Matteson,
provided by Google, packaged by Fedora and imported by
Igor Vlasenko.
Here's the news item behind this commit:
http://lwn.net/Articles/502371/
As they say there's nothing more permanent
than a temporary... params.txt and pkglists.txt
were known as vars-build.txt and vars-conf.mk
in the midst of reworking, and part of that
tried to stick.
mkimage implementation requires that the variables
to be passed to the scripts are to be prefixed with
GLOBAL_ or INFO_ tags as appropriate; in this case
the upstream makefile didn't care to.
It's better to rather just move the raw image instead
of specifically converting it into the same, and there's
no need for qemu-img altogether then.
Let's drop the intermediate raw image after successful
conversion as well.
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.
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?
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.