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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
The idea is to not embed grub.cfg in the efi image, in order to determine the
installed grub in EFI/BOOT/boot*.efi by grub.cfg.
In the case of x86_64, the prebuilt uefi image is always used.
There's a race condition (TOCTOU) between losetup --find
and applying the obtained path after additional dd in between;
twice awful as *at least* running both losetups closely would
reduce the window significantly, and reading the manpage
properly back then would eliminate this.
Reported-by: Anton Midyukov <antohami@altlinux.org>
Suggested-by: Gleb F-Malinovskiy <glebfm@altlinux.org>
The missing glob resulted in disk images properly
partitioned only for e2kv3 ("e2k" for historical
reasons in ALT), and v4+ ones only got a single
ext4 partition that wouldn't work with current
MCST's Boot code.
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.
If build is performed on a system with EFI Secure Boot enabled,
then grub will not boot even on EFI without Secure Boot.
This problem is caused by the use of the --removable option, which
is not compatible with option --uefi-secure-boot the current grub.
Option --uefi-secure-boot is enabled automatically if the system is
booted in EFI Secure Boot mode.
This commit fixes duplication of root device entry in /etc/fstab
and changes LABEL=ROOT entry with the proper one if found.
Apparently this didn't hurt qemu images much though...
Changing ROOTFS owner causes a problem:
created image's root directory is owned
by user executing make instead of root.
Changing WORKDIR owner is unnecessary
because it will be removed anyways.
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>
This one supports multiple kernels (and tweaks boot
labels aiming to simplify target kernel selection
for the CPU at hand) instead of an earlier attempt
to fill in a template.
No need for the template so just drop it.
The current state made vm images belong to root group,
no reason to not change those to the primary group of
the user building an image.
kpartx -d -s could fail in some circumstances,
make a safety cleanup call more verbose.
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.
Yet another age old bug: `sfdisk -l' is mimicking what
a person does by hand but the script is rather interested
in what `sfdisk -g' provides, that is, geometry.
And it's stupid enough to only grok C locale.
Looks like there's a race condition somewhere: this script
will fail to clean up after itself when considerable background
load is inflicted upon the host it's running on (e.g. LA ~16
on a 8-core, single-disk system).
Note that this commit is NOT enough to win that race
but just a step in the right direction...