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 ordering of the includes apparently matters...and I didn't
actually check that the previous change enables composefs on c9s.
But I did now. For reals.
While we have the patient open, I switched to `AC_LANG_PROGRAM`
because I originally thought the bug had something to do with that.
As far as I understand, more cleanly separating the includes
from the injected body text is a useful thing in `AC_LANG_PROGRAM`.
I've verified that this fixes compatibility with GRUB, which
parses the filename:
https://github.com/ostreedev/ostree/issues/2961
However, out of a large degree of conservatism I've made this
an opt-in behavior for now.
My plan is to test it out in the FCOS development streams first.
Add long overdue unit testing coverage for this, which
at least slightly closes out the android boot CI gap.
Actually, this *copies* the karg parsing code into otcore because
it now uses glib, which we're not yet using in the static
prepare-root. It's pretty tempting to drop support for the
static prepare root entirely. But for now we'll live with some
code duplication.
Sometimes android bootloaders boot in a nonab way:
https://source.android.com/docs/core/ota/nonab
In this case, "androidboot." kargs are present but not
"androidboot.slot_suffix" specifically.
In this case, rather than getting stuck in a partially booted
environment, boot system slot a.
And update the doc text to talk about having a timeout at all
by default being a mistake.
Timeouts are really best handled at a higher level; if two processes
are contending for the ostree lock and one is actually frozen,
resolving this is something an admin may want to handle and introspect/debug
instead of having the waiter error out.
Most people using ostree are doing it in a way in which they have
higher level timeouts (e.g. on a container pod).
We saw a bare
`Txn Rebase on <osname> failed: Failed to find kernel in /usr/lib/modules, /usr/lib/ostree-boot or /boot`
which isn't bad, but it'd be better to be a bit more specific.
