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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
While this argument can only have one "EFI" value.
Thus, the problem of building an image for Raspberry Pi on armh,
where there is no grub-efi, was solved.
The entry in /etc/fstab about the mount parameters of the root
partition needs to be done not only for builds with u-boot.
But, if the record already exists, then it will not be added.
The file system type is set by the variable VM_FSTYPE.
Since packet sorting is enabled by default, then
the order in KFLAVORS has ceased to matter.
Kernels are always installed in alphabetical order.
Therefore, it makes no sense to sort by buildtime.
See-also: https://bugzilla.altlinux.org/show_bug.cgi?id=30806
Also fixed my typo. When creating a symlink, the variable
$kver was used, i.e. the entire list of kernels, not the
last value $KVER of the list.
Not used by systemd and looks obsolete generally
as sysvinit-based disk images aren't really targeting
low-resource systems these days _by default_ but rather
_can_ target those as well; feel free to reconstruct
these "RAM saving" bits as a part of e.g. lowmem patch.
The problem at hand is that different kernels can have
varying module sets, and it makes sense to put four of
those at once sometimes; so avoid silly build breakage.
recovery.tar needed for tavolga (mipsel).
This commit is the result of transferring the required functionality
from build-mr (mipsel rootfs).
This change uses external tool to build Tavolga-compatible
recovery.tar. This simplifies the logic and avoids having
recovery workdir in the profile.
After this change, m-p will require tavolga-image-tools >= 3.0.
build-vm ceases to be a target for building only virtual machine images.
Now it can be used to build tarballs designed for installation on real
machines.
This commit is the result of transferring the required functionality from
build-mr (mipsel rootfs) by Ivan Melnikov <iv@altlinux.org>.
NB: mike@ strongly objected to this dilution but gave up eventually;
the whole kernel/build-vm/tar2fs/pack mess should be split into
distinct layers busy with their own responsibilities:
1) a tarball with kernel is done without tar2fs at all
(and no build-vm bits should be needed either, maybe
it's worth splitting and renaming as "vm" meaning
disk image for some armh board is grossly misleading);
2) a tarball with kernel can be further (multi-)packed
as, well, (compressed) tarball and a disk image
(only the latter one should employ build-vm/tar2fs);
3) compression should be done in pack feature style,
preferably described once and not duplicated all over
the profile for every single new kind of its output.
In the mean time, running into this and moving no further
starts to hurt more than it could help.
The original commit broke system tar2fs use by accidentally
moving TOPDIR definition into a separate shell execution;
thanks iv@ for spotting and fixing it promptly.
Co-authored-by: Ivan A. Melnikov" <iv@altlinux.org>
tar2fs comes from m-p, not from mkimage. Also, we should
use $TOPDIR from shell, not $(TOPDIR) from make, when
calling it.
Note: this is a security fix for environments relying
on packaged mkimage-profiles with sudo enabled for the
builder user.
Fixes: f293239d5b
BASE_PACKAGES_REGEXP and THE_PACKAGES_REGEXP,
to be exact; the lack of handling these appears
to have been the culprit of firefox missing in
vm images which use/browser/firefox.
No need to deduce kernel version again,
just save it in a temporary file.
The main reason to change what worked is
that e2k kernel-image package has Linux bits
named as image-$kver and not vmlinuz-$kver;
the guessing logic taking all of this into
account resulted in non-aesthetic patch.
NB: there's a duplicating script within
kernel feature; it wasn't easy to avoid
this and it might differ when handling
multiple kernels, I didn't think much
about this now as vm images tend to ship
with the sole one.
In this case it's rather worth it to examine build.log
than read documentation again (as vm.txt should have been
read or at least skimmed through to get sudo setup ready,
and the problem might be either an environment one or a bug).
It's at least removing the very obvious user->root
attack through (maliciously) modifying bin/tar2fs
and waiting for it to be run; if mkimage-profiles
is installed system-wide as a package, the script
from /usr/share/mkimage-profiles will be tried so
those willing to allow vm/* build to themselves
can provide for a passwordless sudo (as described
in doc/vm.txt) to run a root-only writable script,
not user-writable.
Still not perfect but a step away from the abyss.
This change is done to reduce ambiguity in some cases;
the previous intention has been to ease navigation when
staying in a particular directory, now it's been changed
in favour of convenient toplevel `git grep' in fact.
Both variants have their pros and cons, I just find myself
leaning to this one by now hence the commit. Feel free to
provide constructive criticism :)
Some path-related bitrot has also been fixed while at that.
Overview of the changes:
- ARM support: separate ext2 /boot, no LILO
- avoid race condition with devmapper
- trap ERR so that -e in shebang doesn't result in extra cleanup hassle
- configurable root filesystem type (ext4 by default)
- jumps through parted hoops
Details:
1. LILO is x86-specific while the rest of the script can be used
to prepare e.g. Marvell ArmadaXP or CuBox images; we can generally
count on uboot supporting ext2 for relatively sane platforms but
not ext4 that would be a better root filesystem performance-wise.
2. Apparently /dev/mapper/loopXpY can be still missing at the time
when kpartx returns and pop up a bit later... sit there, wait
and check for it.
3. If something went wrong with any command of the script it would bail out
due to -e in shebang; it is now better to clean up the loopback device
and its mappings in this situation either.
4. One size doesn't fit all, really.
5. The parted sizing was sloppy as in broken, now it's just half insane.
Someone's decision to stick units and auto-alignment knobs into
a single one was apparently hilarious...
http://www.gnu.org/software/parted/manual/parted.html#unit
Manual loop/dm cleanup is described in documentation just in case.
/boot size meter is suboptimal in terms of additional I/O incurred,
will be most likely rewritten to make use of advance "du -s".
The feature officially introduces the "engineering passwords"
including empty ones which have been around since forever but
weren't properly managed (and still are not, at least until
there are no stray passwd/chpasswd/usermod calls in both the
profile, installer-features and all the other related parts).
It is based on an m-p-d init3-users script by stanv@ but was
cleaned up and restructured in a pretty severe manner; thanks
glebfm@ for additional discussion.
This also cleans up the kludge previously stuck into build-vm.
Note that vm/icewm sports graphical autologin now as well as
the default root password (which can be overridden by passing
ROOTPW=... to make but it is a change from the previous state
of affairs indeed).
Classic VEs don't carry any kernel since these are running
under a single OpenVZ (or potentially LXC) kernel image;
ARM Multiboot (TWRP in this particular case) allows to boot
off a chroot via kexec, and we need a kernel in it for that,
obviously.
No bootloader required inside such VE though.
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.
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.
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.
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).
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.
