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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Kernels >= 5.8 have added new fields to the dmi/id/modalias file in the
middle of the modalias (instead of adding them at the end).
Specifically new ":br<value>:" and (optional) ":efr<value>:" fields have
been added between the ":bd<value>:" and ":svn<value>:" fields.
Note the 5.13.0 and 5.14.0 kernels also added a new ":sku<value>:" field
between the ":pvr<value>:" and ":rvn<value>:" fields, this has been fixed
in later 5.13.y and 5.14.y releases, by moving the sku field to the end:
https://lore.kernel.org/lkml/20210831130508.14511-1-hdegoede@redhat.com/
Unfortunately the same cannot be done for the new br and efr fields since
those have been added more then a year ago and hwdb even already has some
newer entries relying on the new br field being there (and thus not working
with older kernels).
Fix the issue with the br and efr fields through the following changes:
1. Replace any matches on ":br<value>" from newer entries with an '*'
2. Replace "bd<value>:svn<value>" matches with: "bd<value>:*svn<value>"
inserting an '*' where newer kernels will have the new br + efr fields
This makes these matches working with old as well as new kernels.
Link: https://github.com/systemd/systemd/issues/20550
Link: https://github.com/systemd/systemd/pull/20562
It's not "const", it can change any time if people change the fs, and we
don#t send out notifications for it. Hence don't claim it was const.
(Otherwise clients might cache it, but they should not)
Prompted-by: #20792
According to the various man pages of "resolvconf" the -u switch is for:
"-u Just run the update scripts (if updating is enabled)."
"-u Force resolvconf to update all its subscribers. resolvconf does not
update the subscribers when adding a resolv.conf that matches what
it already has for that interface."
We have no "subscribers", we ourselves are the only "subscriber" we
support. Hence it's probably better to ignore such a request and make it
a NOP, then to fail.
Fixes: #20748
Previously, SNTP option is ignored when it appears after NTP option(s),
but merged later NTP options when it appears first.
This makes split the NTP and SNTP addresses, and use SNTP addresses only
when no NTP option is provided.