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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
When `linux-headers` is installed on Arch Linux, it stores the module
source tree in the kernel module directory, which is then picked up by
`find` and we get a lot of harmless but annoying errors:
```
...
modprobe: FATAL: Module Kconfig.iosched not found in directory /lib/modules/5.13.7-arch1-1
modprobe: FATAL: Module Kconfig not found in directory /lib/modules/5.13.7-arch1-1
modprobe: FATAL: Module Kconfig not found in directory /lib/modules/5.13.7-arch1-1
modprobe: FATAL: Module dm-mpath.h not found in directory /lib/modules/5.13.7-arch1-1
modprobe: FATAL: Module dm-bio-prison-v2.h not found in directory /lib/modules/5.13.7-arch1-1
modprobe: FATAL: Module raid0.h not found in directory /lib/modules/5.13.7-arch1-1
...
```
Let's fix this by trying to install only kernel modules (*.ko files with
an optional compression).
The configuration ROM of Acoustic Reality eAR Master One, Eroica, Figaro,
and Ciaccona has OUI for TerraTec Electronic GmbH in its vendor ID field.
As a result, modalias for the unit is the same as Terratec Electronic
Aureon 7.1 FireWire.
Linux FireWire subsystem adds the same modalias for units of the models.
ALSA bebob driver had duplicated entries for them and was changed at
Linux kernel v5.14 to remove the duplicated entries.
It's better to improve corresponding entries in systemd hwdb, while
it's impossible to distinguish the models by modalias and force to use
the same entry for them. As last resort, this commit selects more
popular model, Aureon 7.1 FireWire for ID_VENDOR_FROM_DATABASE and
ID_MODEL_FROM_DATABASE.
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a07ebc7e050ccdfec508449b2ef8f2b2aa90927b
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
I had misunderstanding that BridgeCo ASIC would be used for extension
option for Mackie d.2 and OXFW971 would be used for Mackie d.2 Pro like
Mackie d.4 Pro. However, it's clear that the latter is model with
pre-installed option.
This commit fixes commit to entry for Mackie d.2. I note that the modalias
of unit of Mackie d.4 Pro is still unidentified.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Some Mackie Onyx-i models are known to have two revisions at least, which
use different ASICS; Oxford Semiconductor FW971 and TC Applied
Technologies TCD2210. I misunderstand that Onyx 1640i had not such
revisions.
This commit fixes comment to entry for the model.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Some of Phonic Firefly series and Helix Board series have the same
combination of vendor ID, model ID, specifier ID, and software
version in their configuration ROM. On the other hand, the other models
have unique combination.
ALSA bebob driver in Linux kernel v5.14 was changed in its modalias table
for the models.
This commit fixes systemd hwdb for the models.
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1586d461f641b60040438275e14c7dbcec5907d6
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
We would update 'found' using bit operations, but studiously ignore the actual
value and treat it as boolean. So just use a boolean variable instead. Because
there is a double loop, we would break the inner loop, but repeat the outer
loop, even though the boolean was already set. Add '&& !found' in the loop
conditions to break iteration immediately.
We had 'msghdr' and 'mh' in various places. Now 'const struct msghdr msghdr' is
used consistently. With structured init the variable is only used in the call
to sendmsg(), so let's make it a bit more descriptive.
Normally, these services are killed because we run isolate. But I booted into
emergency mode (because of a futher bug with us timing out improperly on the
luks password prompt), and then continuted to the host system by running
'systemctl start systemd-switch-root.service'. My error, but the results are
confusing and bad: systemd in the host sees 'systemd-tmpfiles-setup.service'
as started successfully, and doesn't restart it, so the setup for /tmp/.X11 is
not done and gdm.service fails. So while we wouldn't encounter this during
normal successful boot, I think it's good to make this more robust.
The dep is added to systemd-tmpfiles-{setup,clean}, because /tmp is not
propagated over switch-root. /dev is, so I didn't touch
systemd-tmpfiles-setup-dev.service.
The unit queues are not serialized/deserialized (they are recreated
after reexec/reload instead). The destroyed units are not removed from
the cgroup_oom_queue. That means the queue may contain possibly invalid
pointers to released units.
Fix this by removing the units from cgroup_oom_queue as we do for
others. When at it, sync assert checks with currently existing queues
and put them in order in the manager cleanup code.
While reexec/reload, we drop the inotify watch on cgroup file(s), so
we need to re-check them in case they changed and we missed the event.
Fixes: #20198
The current pattern '#' triggers on the openSUSE kernel version that is
printed early during boot when no actual prompt is ready
> [ 0.000000] Linux version 5.12.10-1-default (geeko@buildhost) (gcc (SUSE Linux) 11.1.1 20210510 [revision 23855a176609fe8dda6abaf2b21846b4517966eb], GNU ld (GNU Binutils; openSUSE Tumbleweed) 2.36.1.20210326-4) #1 SMP Fri Jun 11 05:05:06 UTC 2021 (b92eaf7)
Instead wait for pattern that: a) should have fewer false positives, b)
still be with working on distro shells:
openSUSE (red color)
^[[1m^[[31mimage:~ #^[[m^O
arch
[root@image ~]#
debian
root@image:~#
ubuntu
root@image:~#
fedora
[root@image ~]#
The current boot test relies on terminal login, therefore network setup
inside image is unnecessary. This opens up possibility to test images
that don't support the network setup via veth devices.
These have ignored the return value forever. Two are public APIs so
we can't really change what they return anyway, and the other one is
a cleanup path and the existing error code is more important.
CID#1461274
CID#1461275
CID#1461276
In general we almost never hit those asserts in production code, so users see
them very rarely, if ever. But either way, we just need something that users
can pass to the developers.
We have quite a few of those asserts, and some have fairly nice messages, but
many are like "WTF?" or "???" or "unexpected something". The error that is
printed includes the file location, and function name. In almost all functions
there's at most one assert, so the function name alone is enough to identify
the failure for a developer. So we don't get much extra from the message, and
we might just as well drop them.
Dropping them makes our code a tiny bit smaller, and most importantly, improves
development experience by making it easy to insert such an assert in the code
without thinking how to phrase the argument.
