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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
I hit an "assert(j->installed)" failure in transaction_apply(). Looking
into the backtrace I saw what happened:
1. The system was booting. var.mount/start was an installed job.
2. I pressed Ctrl+Alt+Del.
3. reboot.target was going to be isolated.
4. transaction_apply() proceeded to install a var.mount/stop job.
5. job_install() canceled the conflicting start job.
6. Depending jobs ended recursively with JOB_DEPENDENCY, among them was
local-fs.target/start.
7. Its OnFailure action triggered - emergency.target was now going to be
isolated.
8. We recursed back into transaction_apply() where the half-installed
var.mount/stop job confused us.
Recursing from job installation back into the transaction code cannot be
a good idea. Avoid the problem by canceling the conflicting job
non-recursively in job_install(). I don't think we'll miss anything by
not recursing here. After all, we are called from transaction_apply().
We will not be installing just this one job, but all jobs from a
transaction. All requirement dependencies will be included in it and
will be installed separately. Every transaction job will get a chance
to cancel its own conflicting installed job.
Mostly useful for testing purposes. Setting Age to 1s works just as
well, but it is surprising that using 0s (or just 0) does not work.
Also clarify this in the documentation.
HP iLO fw versions below 1.50 incorrectly report that HP iLO virtual
Kbd/Mouse supports remote wakeup. With the rules change in commit
3bfc7a97b1, the HP iLO was listed for
power control.
In iLO fw versions less than 1.50, the iLO Kbd/Mouse become unresponsive
once they are suspended. HP iLO fw versions 1.50+ correctly report that
they don't support remote wakeup, which makes the rules moot in any case.
If you enter unit_add_exec_dependencies with m->where = NULL, you'll
very likely end up aborting somewhere under socket_needs_mount.
(When systemd goes to check to see if the journald socket requires your
mount, it'll do path_startswith(path, m->where)... *kaboom*)
This patch should ensure that:
a) both branches in mount_add_one() set m->where, and
b) mount_add_extras() calls unit_add_exec_dependencies() *after*
setting m->where.
Resolves the TODO, and also uses compgen's -S flag to append the
trailing equals, rather than relying on an array-wide parameter
expansion.
Suggested-by: Ran Benita <ran234@gmail.com>
If 'systemctl enable' (and friends) is run inside chroot it always
exits with a bad return code. unit_file_enable() returns the number of
symlink rules that were supposed to be created. So resetting r to 0 and
exiting gracefully should be the correct way.
