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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
According to Jonathan's suggestion, should fix the code from
ostree repo.
With this patch:
- kargs input like "init_on_alloc=1 init_on_free=1", will be
parsed as 2 seperated args `init_on_alloc=1` and `init_on_free=1`,
instead of whole;
- According to https://www.kernel.org/doc/html/v4.14/admin-guide/kernel-parameters.html,
need to keep spaces in double-quotes, like `param="spaces in here"`
will be parsed as whole instead of 3.
Fixes https://github.com/coreos/rpm-ostree/issues/4821
I think it's about time we flipped this on by default;
like the bootprefix I was a bit too chicken. We still have
a `bootloader-naming-1` that can be flipped on in case of
some regression.
Closes: https://github.com/ostreedev/ostree/issues/2961
This builds on top of fa9924e4fe
(But in a very hacky way because we don't currently link to a JSON library)
Basically, bootupd supports injecting static configs, and this
is the currently least hacky way for us to detect this and understand
that we shouldn't try to run `grub2-mkconfig`.
A further patch I'd like to do here is also change the probing
logic to gracefully no-op if `grub2-mkconfig` doesn't exist,
but that has a bit more risk and involvement.
Now that we're using `otcore_load_config` from the deploy
path we end up printing to stdout even for API callers (e.g.
our own CLI tools, and rpm-ostree/bootc/etc) which is wrong.
We don't need this print, so just drop it.
In order to do a runtime feature check, `ostree --version` can be piped
to `grep` or similar. However, if the read end of the pipe doesn't read
all of the output, `ostree` will receive `SIGPIPE` when trying to write
output. Ignore it so that `ostree` still exits successfully in that
case.
As this is only used by internal code, just drop the `_OSTREE_PUBLIC`
marker for now. If we have a reason to export it we can do that
later.
Closes: https://github.com/ostreedev/ostree/issues/3182
Be more explicit in the comment, and use gboolean over bool. Less header
inclusions when we use gboolean. Although bool is used in some places.
Write a separate _ostree_sysroot_parse_bootlink_aboot function for
aboot. Make is_aboot optional. Handle invalid androidboot karg and no
ostree and androidboot kargs differently.
Co-authored-by: Jonathan Lebon <jonathan@jlebon.com>
Signed-off-by: Eric Curtin <ecurtin@redhat.com>
As mentioned in https://github.com/ostreedev/ostree/issues/3187, we
can't allow a hotfix overlay of /usr when using signed composefs
images as that would allow an attacker to persist something used
across boots.
In Android Boot environment we do not parse ostree= karg to determine
what directory to boot into, alternatively we do this based on the
androidboot.slot_suffix= karg. But we do set ostree=true karg to denote
that we are indeed booting an ostree environment (required for some
systemd unit files). This change accounts for this approach in the
systemd generator. In this case androidboot.slot_suffix= points you to
/ostree/root.[a|b] and then that points you to the directory to boot
into in /ostree/deploy... Here is what a cmdline may look like in this
type of environment:
androidboot.slot_suffix=_a androidboot.bootdevice=*.ufshc root=PARTLABEL=system_a root=UUID=76a22bf4-f153-4541-b6c7-0332c0dfaeac rw ostree=true loglevel=4 acpi=off console=ttyAMA0 systemd.show_status=auto libahci.ignore_sss=1 slub_debug=FPZ fsck.mode=skip rcupdate.rcu_normal_after_boot=0 rcupdate.rcu_expedited=1
Signed-off-by: Eric Curtin <ecurtin@redhat.com>
When we load the configuration during deploy we don't need to actually
use the keys, so avoid loading them. This fixes an issue we had where
this broke the initial deploy becasue of a failure to load the key. In
our case it fails because the code looks for the config file in the
deploy dir, but then for the binding key in the real root.
However, even if it were to look for the key in the deploy dir I don't
think it necessarily has to be in the rootfs, it could be only in the
initrd.
This fixes https://github.com/ostreedev/ostree/issues/3188
This avoids false negatives from `ostree --version | grep -q ...`
exiting with failure under `set -o pipefail` because `grep -q` can exit
as soon as it sees the desired string, leaving `ostree --version` to be
terminated by `SIGPIPE` next time it writes to stdout.
Signed-off-by: Simon McVittie <smcv@collabora.com>
RHIVOS is a derivative of CentOS Automotive Stream Distribution that
uses OSTree, it's closest Fedora derivative is Fedora IoT although it
was created as it's own distribution.
Signed-off-by: Eric Curtin <ecurtin@redhat.com>
Short key IDs are not secure, and may be rejected by OpenPGP
implementations. See https://evil32.com/
Signed-off-by: Justus Winter <justus@sequoia-pgp.org>
This mimics the GitHub Pages environment so that you can build and serve
the site locally for testing. It requires webrick these days.
Signed-off-by: Eric Curtin <ecurtin@redhat.com>
Short key IDs are not secure, and may be rejected by OpenPGP
implementations. See https://evil32.com/
Signed-off-by: Justus Winter <justus@sequoia-pgp.org>
