proxmox-mirrors/systemd
1
0
Fork 0
mirror of https://git.proxmox.com/git/systemd synced 2025-08-14 02:41:13 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

New upstream version 245

Browse Source
This commit is contained in:
Balint Reczey 2020-03-06 17:59:20 +01:00
parent f9efe742a5
commit 46cdbd4966
944 changed files with 67075 additions and 10427 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
.github/FUNDING.yml vendored
View File

@ -1 +1 @@
custom: ['https://spi-inc.org/projects/systemd/', 'https://www.paypal.com/donate/?token=fBGzXDOyIGobZH3oEhYQlYlA61OMRXVnF9XXQqNNehRs-nliAU5XxozIh9z-hlmE-xXC-m']
custom: ['https://spi-inc.org/projects/systemd/']

2
.github/ISSUE_TEMPLATE/Bug_report.md vendored
View File

@ -8,7 +8,7 @@ about: A report of an error in a recent systemd version
> ...
<!-- **NOTE:** Do not submit bug reports about anything but the two most recently released systemd versions upstream! -->
<!-- For older version please use distribution trackers (see https://github.com/systemd/systemd/blob/master/docs/CONTRIBUTING.md#filing-issues). -->
<!-- For older version please use distribution trackers (see https://systemd.io/CONTRIBUTING#filing-issues). -->
**Used distribution**
> …

13
.lgtm.yml
View File

@ -1,13 +1,14 @@
---
# vi: ts=2 sw=2 et:
extraction:
cpp:
prepare:
packages:
- python3-pip
- python3-setuptools
- python3-wheel
after_prepare:
- pip3 install meson
- export PATH="$HOME/.local/bin/:$PATH"
- libpwquality-dev
- libfdisk-dev
- libp11-kit-dev
- libssl-dev
python:
python_setup:
version: 3

2
.mailmap
View File

@ -30,6 +30,7 @@ Daniel Machon <Danielmachon@live.dk>
Daniel Rusek <mail@asciiwolf.com>
Daniel Stekloff <dsteklof@us.ibm.com>
Daniel Șerbănescu <dasj19@users.noreply.github.com>
Dann Frazier <dann.frazier@canonical.com>
Dave Reisner <dreisner@archlinux.org> <d@falconindy.com>
David Zeuthen <david@fubar.dk>
David Zeuthen <david@fubar.dk> <davidz@redhat.com>
@ -164,6 +165,7 @@ Stefan Schweter <stefan@schweter.it>
Stuart McLaren <stuart.mclaren@hp.com>
Susant Sahani <ssahani@gmail.com> <145210+ssahani@users.noreply.github.com>
Susant Sahani <ssahani@gmail.com> <susant@redhat.com>
Sylvain Plantefeve <sylvain.plantefeve@gmail.com>
Sébastien Bacher <seb128@ubuntu.com>
Tanu Kaskinen <TanuKaskinen@web>
Ted Ts'o <tytso@mit.edu>

17
.mkosi/mkosi.fedora
View File

@ -8,9 +8,8 @@ Distribution=fedora
Release=31
[Output]
Format=raw_btrfs
Format=gpt_ext4
Bootable=yes
KernelCommandLine=printk.devkmsg=on
[Partitions]
RootSize=3G
@ -27,6 +26,7 @@ BuildPackages=
gcc
gettext
git
glibc-minimal-langpack
gnu-efi
gnu-efi-devel
gnutls-devel
@ -38,19 +38,22 @@ BuildPackages=
libblkid-devel
libcap-devel
libcurl-devel
libfdisk-devel
libgcrypt-devel
libidn2-devel
libmicrohttpd-devel
libmount-devel
libpwquality-devel
libseccomp-devel
libselinux-devel
libtool
libxkbcommon-devel
libxslt
lz4
lz4-devel
m4
meson
openssl-devel
p11-kit-devel
pam-devel
pcre2-devel
pkgconfig
@ -58,10 +61,18 @@ BuildPackages=
python3-lxml
qrencode-devel
tree
valgrind-devel
xz-devel
Packages=
coreutils
cryptsetup-libs
kmod-libs
e2fsprogs
libidn2
libseccomp
procps-ng
util-linux
BuildDirectory=mkosi.builddir
Cache=mkosi.cache

357
NEWS
View File

@ -1,5 +1,314 @@
systemd System and Service Manager
CHANGES WITH 245:
* A new tool "systemd-repart" has been added, that operates as an
idempotent declarative repartitioner for GPT partition tables.
Specifically, a set of partitions that must or may exist can be
configured via drop-in files, and during every boot the partition
table on disk is compared with these files, creating missing
partitions or growing existing ones based on configurable relative
and absolute size constraints. The tool is strictly incremental,
i.e. does not delete, shrink or move partitions, but only adds and
grows them. The primary use-case is OS images that ship in minimized
form, that on first boot are grown to the size of the underlying
block device or augmented with additional partitions. For example,
the root partition could be extended to cover the whole disk, or a
swap or /home partitions could be added on first boot. It can also be
used for systems that use an A/B update scheme but ship images with
just the A partition, with B added on first boot. The tool is
primarily intended to be run in the initrd, shortly before
transitioning into the host OS, but can also be run after the
transition took place. It automatically discovers the disk backing
the root file system, and should hence not require any additional
configuration besides the partition definition drop-ins. If no
configuration drop-ins are present, no action is taken.
* A new component "userdb" has been added, along with a small daemon
"systemd-userdb.service" and a client tool "userdbctl". The framework
allows defining rich user and group records in a JSON format,
extending on the classic "struct passwd" and "struct group"
structures. Various components in systemd have been updated to
process records in this format, including systemd-logind and
pam-systemd. The user records are intended to be extensible, and
allow setting various resource management, security and runtime
parameters that shall be applied to processes and sessions of the
user as they log in. This facility is intended to allow associating
such metadata directly with user/group records so that they can be
produced, extended and consumed in unified form. We hope that
eventually frameworks such as sssd will generate records this way, so
that for the first time resource management and various other
per-user settings can be configured in LDAP directories and then
provided to systemd (specifically to systemd-logind and pam-system)
to apply on login. For further details see:
https://systemd.io/USER_RECORD
https://systemd.io/GROUP_RECORD
https://systemd.io/USER_GROUP_API
* A small new service systemd-homed.service has been added, that may be
used to securely manage home directories with built-in encryption.
The complete user record data is unified with the home directory,
thus making home directories naturally migratable. Its primary
back-end is based on LUKS volumes, but fscrypt, plain directories,
and other storage schemes are also supported. This solves a couple of
problems we saw with traditional ways to manage home directories, in
particular when it comes to encryption. For further discussion of
this, see the video of Lennart's talk at AllSystemsGo! 2019:
https://media.ccc.de/v/ASG2019-164-reinventing-home-directories
For further details about the format and expectations on home
directories this new daemon makes, see:
https://systemd.io/HOME_DIRECTORY
* systemd-journald is now multi-instantiable. In addition to the main
instance systemd-journald.service there's now a template unit
systemd-journald@.service, with each instance defining a new named
log 'namespace' (whose name is specified via the instance part of the
unit name). A new unit file setting LogNamespace= has been added,
taking such a namespace name, that assigns services to the specified
log namespaces. As each log namespace is serviced by its own
independent journal daemon, this functionality may be used to improve
performance and increase isolation of applications, at the price of
losing global message ordering. Each instance of journald has a
separate set of configuration files, with possibly different disk
usage limitations and other settings.
journalctl now takes a new option --namespace= to show logs from a
specific log namespace. The sd-journal.h API gained
sd_journal_open_namespace() for opening the log stream of a specific
log namespace. systemd-journald also gained the ability to exit on
idle, which is useful in the context of log namespaces, as this means
log daemons for log namespaces can be activated automatically on
demand and will stop automatically when no longer used, minimizing
resource usage.
* When systemd-tmpfiles copies a file tree using the 'C' line type it
will now label every copied file according to the SELinux database.
* When systemd/PID 1 detects it is used in the initrd it will now boot
into initrd.target rather than default.target by default. This should
make it simpler to build initrds with systemd as for many cases the
only difference between a host OS image and an initrd image now is
the presence of the /etc/initrd-release file.
* A new kernel command line option systemd.cpu_affinity= is now
understood. It's equivalent to the CPUAffinity= option in
/etc/systemd/system.conf and allows setting the CPU mask for PID 1
itself and the default for all other processes.
* When systemd/PID 1 is reloaded (with systemctl daemon-reload or
equivalent), the SELinux database is now reloaded, ensuring that
sockets and other file system objects are generated taking the new
database into account.
* systemd/PID 1 accepts a new "systemd.show-status=error" setting, and
"quiet" has been changed to imply that instead of
"systemd.show-status=auto". In this mode, only messages about errors
and significant delays in boot are shown on the console.
* The sd-event.h API gained native support for the new Linux "pidfd"
concept. This permits watching processes using file descriptors
instead of PID numbers, which fixes a number of races and makes
process supervision more robust and efficient. All of systemd's
components will now use pidfds if the kernel supports it for process
watching, with the exception of PID 1 itself, unfortunately. We hope
to move PID 1 to exclusively using pidfds too eventually, but this
requires some more kernel work first. (Background: PID 1 watches
processes using waitid() with the P_ALL flag, and that does not play
together nicely with pidfds yet.)
* Closely related to this, the sd-event.h API gained two new calls
sd_event_source_send_child_signal() (for sending a signal to a
watched process) and sd_event_source_get_child_process_own() (for
marking a process so that it is killed automatically whenever the
event source watching it is freed).
* systemd-networkd gained support for configuring Token Bucket Filter
(TBF) parameters in its qdisc configuration support. Similarly,
support for Stochastic Fairness Queuing (SFQ), Controlled-Delay
Active Queue Management (CoDel), and Fair Queue (FQ) has been added.
* systemd-networkd gained support for Intermediate Functional Block
(IFB) network devices.
* systemd-networkd gained support for configuring multi-path IP routes,
using the new MultiPathRoute= setting in the [Route] section.
* systemd-networkd's DHCPv4 client has been updated to support a new
SendDecline= option. If enabled, duplicate address detection is done
after a DHCP offer is received from the server. If a conflict is
detected, the address is declined. The DHCPv4 client also gained
support for a new RouteMTUBytes= setting that allows to configure the
MTU size to be used for routes generated from DHCPv4 leases.
* The PrefixRoute= setting in systemd-networkd's [Address] section of
.network files has been deprecated, and replaced by AddPrefixRoute=,
with its sense inverted.
* The Gateway= setting of [Route] sections of .network files gained
support for a special new value "_dhcp". If set, the configured
static route uses the gateway host configured via DHCP.
* New User= and SuppressPrefixLength= settings have been implemented
for the [RoutingPolicyRule] section of .network files to configure
source routing based on UID ranges and prefix length, respectively.
* sd-bus gained a new API call sd_bus_message_sensitive() that marks a
D-Bus message object as "sensitive". Those objects are erased from
memory when they are freed. This concept is intended to be used for
messages that contain security sensitive data. A new flag
SD_BUS_VTABLE_SENSITIVE has been introduced as well to mark methods
in sd-bus vtables, causing any incoming and outgoing messages of
those methods to be implicitly marked as "sensitive".
* sd-bus gained a new API call sd_bus_message_dump() for dumping the
contents of a message (or parts thereof) to standard output for
debugging purposes.
* systemd-sysusers gained support for creating users with the primary
group named differently than the user.
* systemd-resolved's DNS-over-TLS support gained SNI validation.
* systemd-growfs (i.e. the x-systemd.growfs mount option in /etc/fstab)
gained support for growing XFS partitions. Previously it supported
only ext4 and btrfs partitions.
* The support for /etc/crypttab gained a new x-initrd.attach option. If
set, the specified encrypted volume is unlocked already in the
initrd. This concept corresponds to the x-initrd.mount option in
/etc/fstab.
* systemd-cryptsetup gained native support for unlocking encrypted
volumes utilizing PKCS#11 smartcards, i.e. for example to bind
encryption of volumes to YubiKeys. This is exposed in the new
pkcs11-uri= option in /etc/crypttab.
* The /etc/fstab support in systemd now supports two new mount options
x-systemd.{required,wanted}-by=, for explicitly configuring the units
that the specified mount shall be pulled in by, in place of
the usual local-fs.target/remote-fs.target.
* The https://systemd.io/ web site has been relaunched, directly
populated with most of the documentation included in the systemd
repository. systemd also acquired a new logo, thanks to Tobias
Bernard.
* systemd-udevd gained support for managing "alternative" network
interface names, as supported by new Linux kernels. For the first
time this permits assigning multiple (and longer!) names to a network
interface. systemd-udevd will now by default assign the names
generated via all supported naming schemes to each interface. This
may be further tweaked with .link files and the AlternativeName= and
AlternativeNamesPolicy= settings. Other components of systemd have
been updated to support the new alternative names wherever
appropriate. For example, systemd-nspawn will now generate
alternative interface names for the host-facing side of container
veth links based on the full container name without truncation.
* systemd-nspawn interface naming logic has been updated in another way
too: if the main interface name (i.e. as opposed to new-style
"alternative" names) based on the container name is truncated, a
simple hashing scheme is used to give different interface names to
multiple containers whose names all begin with the same prefix. Since
this changes the primary interface names pointing to containers if
truncation happens, the old scheme may still be requested by
selecting an older naming scheme, via the net.naming-scheme= kernel
command line option.
* PrivateUsers= in service files now works in services run by the
systemd --user per-user instance of the service manager.
* A new per-service sandboxing option ProtectClock= has been added that
locks down write access to the system clock. It takes away device
node access to /dev/rtc as well as the system calls that set the
system clock and the CAP_SYS_TIME and CAP_WAKE_ALARM capabilities.
Note that this option does not affect access to auxiliary services
that allow changing the clock, for example access to
systemd-timedated.
* The systemd-id128 tool gained a new "show" verb for listing or
resolving a number of well-known UUIDs/128bit IDs, currently mostly
GPT partition table types.
* The Discoverable Partitions Specification has been updated to support
/var and /var/tmp partition discovery. Support for this has been
added to systemd-gpt-auto-generator. For details see:
https://systemd.io/DISCOVERABLE_PARTITIONS
* "systemctl list-unit-files" has been updated to show a new column
with the suggested enablement state based on the vendor preset files
for the respective units.
* "systemctl" gained a new option "--with-dependencies". If specified
commands such as "systemctl status" or "systemctl cat" will now show
all specified units along with all units they depend on.
* networkctl gained support for showing per-interface logs in its
"status" output.
* systemd-networkd-wait-online gained support for specifying the maximum
operational state to wait for, and to wait for interfaces to
disappear.
* The [Match] section of .link and .network files now supports a new
option PermanentMACAddress= which may be used to check against the
permanent MAC address of a network device even if a randomized MAC
address is used.
* The [TrafficControlQueueingDiscipline] section in .network files has
been renamed to [NetworkEmulator] with the "NetworkEmulator" prefix
dropped from the individual setting names.
* Any .link and .network files that have an empty [Match] section (this
also includes empty and commented-out files) will now be
rejected. systemd-udev and systemd-networkd started warning about
such files in version 243.
* systemd-logind will now validate access to the operation of changing
the virtual terminal via a PolicyKit action. By default, only users
with at least one session on a local VT are granted permission.
* When systemd sets up PAM sessions that invoked service processes
shall run in, the pam_setcred() API is now invoked, thus permitting
PAM modules to set additional credentials for the processes.
* portablectl attach/detach verbs now accept --now and --enable options
to combine attachment with enablement and invocation, or detachment
with stopping and disablement.
Contributions from: AJ Bagwell, Alin Popa, Andreas Rammhold, Anita
Zhang, Ansgar Burchardt, Antonio Russo, Arian van Putten, Ashley Davis,
Balint Reczey, Bart Willems, Bastien Nocera, Benjamin Dahlhoff, Charles
(Chas) Williams, cheese1, Chris Down, Chris Murphy, Christian Ehrhardt,
Christian Göttsche, cvoinf, Daan De Meyer, Daniele Medri, Daniel Rusek,
Daniel Shahaf, Dann Frazier, Dan Streetman, Dariusz Gadomski, David
Michael, Dimitri John Ledkov, Emmanuel Bourg, Evgeny Vereshchagin,
ezst036, Felipe Sateler, Filipe Brandenburger, Florian Klink, Franck
Bui, Fran Dieguez, Frantisek Sumsal, Greg "GothAck" Miell, Guilhem
Lettron, Guillaume Douézan-Grard, Hans de Goede, HATAYAMA Daisuke, Iain
Lane, James Buren, Jan Alexander Steffens (heftig), Jérémy Rosen, Jin
Park, Jun'ichi Nomura, Kai Krakow, Kevin Kuehler, Kevin P. Fleming,
Lennart Poettering, Leonid Bloch, Leonid Evdokimov, lothrond, Luca
Boccassi, Lukas K, Lynn Kirby, Mario Limonciello, Mark Deneen, Matthew
Leeds, Michael Biebl, Michal Koutný, Michal Sekletár, Mike Auty, Mike
Gilbert, mtron, nabijaczleweli, Naïm Favier, Nate Jones, Norbert Lange,
Oliver Giles, Paul Davey, Paul Menzel, Peter Hutterer, Piotr Drąg, Rafa
Couto, Raphael, rhn, Robert Scheck, Rocka, Romain Naour, Ryan Attard,
Sascha Dewald, Shengjing Zhu, Slava Kardakov, Spencer Michaels, Sylvain
Plantefeve, Stanislav Angelovič, Susant Sahani, Thomas Haller, Thomas
Schmitt, Timo Schlüßler, Timo Wilken, Tobias Bernard, Tobias Klauser,
Tobias Stoeckmann, Topi Miettinen, tsia, WataruMatsuoka, Wieland
Hoffmann, Wilhelm Schuster, Will Fleming, xduugu, Yong Cong Sin, Yuri
Chornoivan, Yu Watanabe, Zach Smith, Zbigniew Jędrzejewski-Szmek, Zeyu
DONG
– Warsaw, 2020-03-06
CHANGES WITH 244:
* Support for the cpuset cgroups v2 controller has been added.
@ -675,32 +984,33 @@ CHANGES WITH 243:
Contributions from: Aaron Barany, Adrian Bunk, Alan Jenkins, Albrecht
Lohofener, Andrej Valek, Anita Zhang, Arian van Putten, Balint Reczey,
Bastien Nocera, Ben Boeckel, Benjamin Robin, camoz, Chen Qi, Chris
Chiu, Chris Down, Christian Kellner, Clinton Roy, Connor Reeder, Daniel
Black, Daniele Medri, Dan Streetman, Dave Reisner, Dave Ross, David
Art, David Tardon, Debarshi Ray, Dimitri John Ledkov, Dominick Grift,
Donald Buczek, Douglas Christman, Eric DeVolder, EtherGraf, Evgeny
Vereshchagin, Feldwor, Felix Riemann, Florian Dollinger, Francesco
Pennica, Franck Bui, Frantisek Sumsal, Franz Pletz, frederik, Hans
de Goede, Iago López Galeiras, Insun Pyo, Ivan Shapovalov, Iwan Timmer,
Jack, Jakob Unterwurzacher, Jan Chren, Jan Klötzke, Jan Losinski, Jan
Pokorný, Jan Synacek, Jan-Michael Brummer, Jeka Pats, Jeremy Soller,
Jérémy Rosen, Jiri Pirko, Joe Lin, Joerg Behrmann, Joe Richey, Jóhann
B. Guðmundsson, Johannes Christ, Johannes Schmitz, Jonathan Rouleau,
Jorge Niedbalski, Kai Krakow, Kai Lüke, Karel Zak, Kashyap Chamarthy,
Chiu, Chris Down, Christian Göttsche, Christian Kellner, Clinton Roy,
Connor Reeder, Daniel Black, Daniel Lublin, Daniele Medri, Dan
Streetman, Dave Reisner, Dave Ross, David Art, David Tardon, Debarshi
Ray, Dimitri John Ledkov, Dominick Grift, Donald Buczek, Douglas
Christman, Eric DeVolder, EtherGraf, Evgeny Vereshchagin, Feldwor,
Felix Riemann, Florian Dollinger, Francesco Pennica, Franck Bui,
Frantisek Sumsal, Franz Pletz, frederik, Hans de Goede, Iago López
Galeiras, Insun Pyo, Ivan Shapovalov, Iwan Timmer, Jack, Jakob
Unterwurzacher, Jan Chren, Jan Klötzke, Jan Losinski, Jan Pokorný, Jan
Synacek, Jan-Michael Brummer, Jeka Pats, Jeremy Soller, Jérémy Rosen,
Jiri Pirko, Joe Lin, Joerg Behrmann, Joe Richey, Jóhann B. Guðmundsson,
Johannes Christ, Johannes Schmitz, Jonathan Rouleau, Jorge Niedbalski,
Jörg Thalheim, Kai Krakow, Kai Lüke, Karel Zak, Kashyap Chamarthy,
Krayushkin Konstantin, Lennart Poettering, Lubomir Rintel, Luca
Boccassi, Luís Ferreira, Marc-André Lureau, Markus Felten, Martin Pitt,
Matthew Leeds, Mattias Jernberg, Michael Biebl, Michael Olbrich,
Michael Prokop, Michael Stapelberg, Michael Zhivich, Michal Koutný,
Michal Sekletar, Mike Gilbert, Milan Broz, Miroslav Lichvar, mpe85,
Mr-Foo, Network Silence, Oliver Harley, pan93412, Paul Menzel, pEJipE,
Peter A. Bigot, Philip Withnall, Piotr Drąg, Rafael Fontenelle, Roberto
Santalla, Ronan Pigott, root, RussianNeuroMancer, Sebastian Jennen,
shinygold, Shreyas Behera, Simon Schricker, Susant Sahani, Thadeu Lima
de Souza Cascardo, Theo Ouzhinski, Thiebaud Weksteen, Thomas Haller,
Thomas Weißschuh, Tomas Mraz, Tommi Rantala, Topi Miettinen, VD-Lycos,
ven, Wieland Hoffmann, William A. Kennington III, William Wold, Xi
Ruoyao, Yuri Chornoivan, Yu Watanabe, Zach Smith, Zbigniew
Jędrzejewski-Szmek, Zhang Xianwei
Peter A. Bigot, Philip Withnall, Piotr Drąg, Rafael Fontenelle, Robert
Scheck, Roberto Santalla, Ronan Pigott, root, RussianNeuroMancer,
Sebastian Jennen, shinygold, Shreyas Behera, Simon Schricker, Susant
Sahani, Thadeu Lima de Souza Cascardo, Theo Ouzhinski, Thiebaud
Weksteen, Thomas Haller, Thomas Weißschuh, Tomas Mraz, Tommi Rantala,
Topi Miettinen, VD-Lycos, ven, Vladimir Yerilov, Wieland Hoffmann,
William A. Kennington III, William Wold, Xi Ruoyao, Yuri Chornoivan,
Yu Watanabe, Zach Smith, Zbigniew Jędrzejewski-Szmek, Zhang Xianwei
– Camerino, 2019-09-03
@ -6914,10 +7224,9 @@ CHANGES WITH 213:
* A new fsck.repair= kernel option has been added to control
how fsck shall deal with unclean file systems at boot.
* The (.ini) configuration file parser will now silently
ignore sections whose name begins with "X-". This may be
used to maintain application-specific extension sections in unit
files.
* The (.ini) configuration file parser will now silently ignore
sections whose names begin with "X-". This may be used to maintain
application-specific extension sections in unit files.
* machined gained a new API to query the IP addresses of
registered containers. "machinectl status" has been updated

4
README.md
View File

@ -1,6 +1,6 @@
![systemd logo](http://brand.systemd.io/assets/page-logo.png)
![Systemd](http://brand.systemd.io/assets/page-logo.png)
# systemd - System and Service Manager
System and Service Manager
<a href="https://in.waw.pl/systemd-github-state/systemd-systemd-issues.svg"><img align="right" src="https://in.waw.pl/systemd-github-state/systemd-systemd-issues-small.svg" alt="Count of open issues over time"></a>
<a href="https://in.waw.pl/systemd-github-state/systemd-systemd-pull-requests.svg"><img align="right" src="https://in.waw.pl/systemd-github-state/systemd-systemd-pull-requests-small.svg" alt="Count of open pull requests over time"></a>

200
TODO
View File

@ -17,18 +17,111 @@ Janitorial Clean-ups:
* rework mount.c and swap.c to follow proper state enumeration/deserialization
semantics, like we do for device.c now
Before v244:
* revisit SystemdOptions EFI variable. Find a better, systematic name and use
it for the env var, the bootctl verb and the EFI variable itself, clear up
semantics.
Features:
* cryptsetup/homed: also support FIDO2 HMAC password logic for unlocking
devices. (see: https://github.com/mjec/fido2-hmac-secret)
* systemd-gpt-auto should probably set x-systemd.growfs on the mounts it
creates
* homed/userdb: distuingish passwords and recovery keys in the records, since
we probably want to use different PBKDF algorithms/settings for them:
passwords have low entropy but recovery keys should have good entropy key
hence we can make them quicker to work.
* bootctl:
- teach it to prepare an ESP wholesale, i.e. with mkfs.vfat invocation
- teach it to copy in unified kernel images and maybe type #1 boot loader spec entries from host
- make it operate on loopback files, dissecting enough to find ESP to operate on
* by default, in systemd --user service bump the OOMAdjust to 100, as privs
allow so that systemd survives
* honour specifiers in unit files that resolve to some very basic
/etc/os-release data, such as ID, VERSION_ID, BUILD_ID, VARIANT_ID.
* cryptsetup: allow encoding key directly in /etc/crypttab, maybe with a
"base64:" prefix. Useful in particular for pkcs11 mode.
* cryptsetup: reimplement the mkswap/mke2fs in cryptsetup-generator to use
systemd-makefs.service instead.
* socket units: allow creating a udev monitor socket with ListenDevices= or so,
with matches, then actviate app thorugh that passing socket oveer
* move discoverable partitions spec into markdown and our tree
* unify on openssl:
- port sd_id128_get_machine_app_specific() over from khash
- port resolved over from libgcrypt (DNSSEC code)
- port journald + fsprg over from libgcrypt
- port importd over from libgcrypt
- when that's done: kill khash.c
- when that's done: kill gnutls support in resolved
* kill zenata, all hail weblate?
* when we resize disks (homed?) always round up to 4K sectors, not 512K
* add growvol and makevol options for /etc/crypttab, similar to
x-systemd.growfs and x-systemd-makefs.
* hook up the TPM to /etc/crypttab, with a new option that is similar to the
new PKCS#11 option in crypttab, and allows unlocking a LUKS volume via a key
unsealed from the TPM. Optionally, if TPM is not available fall back to
TPM-less mode, and set up linear DM mapping instead (inspired by kpartx), so
that the device paths stay the same, regardless if crypto is used or not.
* systemd-repart: by default generate minimized partition tables (i.e. tables
that only covere the space actually used, excluding any free space at the
end), in order to maximize dd'ability. Requires libfdisk work, see
https://github.com/karelzak/util-linux/issues/907
* systemd-repart: optionally, allow specifiying a path to initialize new
partitions from, i.e. an fs image file or a source device node. This would
then turn systemd-repart into a simple installer: with a few .repart files
you could replicate the host system on another device. a full installer would
then be: "systemd-repart /dev/sda && bootctl install /dev/sda &&
systemd-firstboot --image= …"
* systemd-repart: MBR partition table support. Care needs to be taken regarding
Type=, so that partition definitions can sanely apply to both the GPT and the
MBR case. Idea: accept syntax "Type=gpt:home mbr:0x83" for setting the types
for the two partition types explicitly. And provide an internal mapping so
that "Type=linux-generic" maps to the right types for both partition tables
automatically.
* systemd-repart: allow sizing partitions as factor of available RAM, so that
we can reasonably size swap partitions for hibernation.
* systemd-repart: allow running mkfs before making partitions pop up +
encryption via LUKS to allow booting into an empty root with only /usr mounted in
* systemd-repart: allow managing the gpt read-only partition flag + auto-mount flag
* systemd-repart: allow disabling growing of specific partitions, or making
them (think ESP: we don't ever want to grow it, since we cannot resize vfat)
* systemd-repart: add specifier expansion, add especifier that refers to root
device node of current system, /usr device node, and matching verity, so that
an installer can be made a "copy" installer of the booted OS
* systemd-repart: make it a static checker during early boot for existence and
absence of other partitions for trusted boot environments
* systemd-repart: when no configuration is found, exit early do not check
partition table, so that it is safe to run in the initrd on any system
* systemd-repart: allow config of partition uuid
* userdb: allow username prefix searches in varlink API
* userdb: allow existence checks
* pid: activation by journal search expression
* when switching root from initrd to host, set the machine_id env var so that
if the host has no machine ID set yet we continue to use the random one the
initrd had set.
* sd-event: add native support for P_ALL waitid() watching, then move PID 1 to
it fo reaping assigned but unknown children. This needs to some special care
@ -41,8 +134,6 @@ Features:
waitid() only on the children with the highest priority until one is waitable
and ignore all lower-prio ones from that point on
* sd-event: drop stack allocated epoll_event buffer in sd_event_wait()
* maybe introduce xattrs that can be set on the root dir of the root fs
partition that declare the volatility mode to use the image in. Previously I
thought marking this via GPT partition flags but that's not ideal since
@ -50,8 +141,6 @@ Features:
shouldn't operate in a volatile mode unless we got told so from a trusted
source.
* look for /var/tmp automatically via gpt auto discovery
* figure out automatic partition discovery when combining writable root dir
with immutable /usr
@ -84,10 +173,6 @@ Features:
right) become genuine first class citizens, and we gain automatic, sane JSON
output for them.
* dissector: invoke fsck on the file systems we encounter, after all ext4 is
still pretty popular (and we mount the ESP too with it after all, which is
fat)
* systemd-firstboot: teach it dissector magic, so that you can point it to some
disk image and it will just set everything in it all behind the scenes.
@ -110,6 +195,38 @@ Features:
user@.service, which returns the XDG_RUNTIME_DIR value, and make this
behaviour selectable via pam module option.
* homed:
- when user tries to log into record signed by unrecognized key, automatically add key to our chain after polkit auth
- hook up machined/nspawn users with a varlink user query interface
- rollback when resize fails mid-operation
- GNOME's side for forget key on suspend (requires rework so that lock screen runs outside of uid)
- resize on login?
- fstrim on logout?
- shrink fs on logout?
- update LUKS password on login if we find there's a password that unlocks the JSON record but not the LUKS device.
- create on activate?
- properties: icon url?, preferred session type?, administrator bool (which translates to 'wheel' membership)?, address?, telephone?, vcard?, samba stuff?, parental controls?
- communicate clearly when usb stick is safe to remove. probably involves
beefing up logind to make pam session close hook synchronous and wait until
systemd --user is shut down.
- logind: maybe keep a "busy fd" as long as there's a non-released session around or the user@.service
- maybe make automatic, read-only, time-based reflink-copies of LUKS disk images (think: time machine)
- distuingish destroy / remove (i.e. currently we can unregister a user, unregister+remove their home directory, but not just remove their home directory)
- in systemd's PAMName= logic: query passwords with ssh-askpassword, so that we can make "loginctl set-linger" mode work
- fingerprint authentication, pattern authentication, …
- make sure "classic" user records can also be managed by homed
- description field for groups
- make size of $XDG_RUNTIME_DIR configurable in user record
- reuse pwquality magic in firstboot
- query password from kernel keyring first
- update even if record is "absent"
- add a "access mode" + "fstype" field to the "status" section of json identity records reflecting the actually used access mode and fstype, even on non-luks backends
- move acct mgmt stuff from pam_systemd_home to pam_systemd?
- when "homectl --pkcs11-token-uri=" is used, synthesize ssh-authorized-keys records for all keys we have private keys on the stick for
- make slice for users configurable (requires logind rework)
- logind: populate auto-login list bus property from PKCS#11 token
- when determining state of a LUKS home directory, check DM suspended sysfs file
* introduce a new per-process uuid, similar to the boot id, the machine id, the
invocation id, that is derived from process creds, specifically a hashed
combination of AT_RANDOM + getpid() + the starttime from
@ -180,13 +297,6 @@ Features:
* introduce per-unit (i.e. per-slice, per-service) journal log size limits.
* optionally, if a per-partition GPT flag is set for the root/home/… partitions
format the partition on next boot and unset the flag, in order to implement
factory reset. also, add a second flag that simply indicates whether such a
scheme is supported. then, add a tool (or maybe beef up systemd-dissect) to
show state of these flags, and optionally trigger such a factory reset on
next boot by setting the flag.
* sd-boot: automatically load EFI modules from some drop-in dir, so that people
can add in file system drivers and such
@ -238,7 +348,7 @@ Features:
1. add resume_offset support to the resume code (i.e. support swap files
properly)
2. check if swap is on weird storage and refuse if so
3. add autodetection of hibernation images
3. add auto-detection of hibernation images
* cgroups: use inotify to get notified when somebody else modifies cgroups
owned by us, then log a friendly warning.
@ -382,8 +492,6 @@ Features:
* show whether a service has out-of-date configuration in "systemctl status" by
using mtime data of ConfigurationDirectory=.
* replace all remaining uses of fgets() + LINE_MAX by read_line()
* Add AddUser= setting to unit files, similar to DynamicUser=1 which however
creates a static, persistent user rather than a dynamic, transient user. We
can leverage code from sysusers.d for this.
@ -402,10 +510,6 @@ Features:
yogas can be recognized as "convertible" too, even if they predate the DMI
"convertible" form factor
* Maybe add a small tool invoked early at boot, that adds in or resizes
partitions automatically, to be used when the media used is actually larger
than the image written onto it is.
* Maybe add PrivatePIDs= as new unit setting, and do minimal PID namespacing
after all. Be strict however, only support the equivalent of nspawn's
--as-pid2 switch, and sanely proxy sd_notify() messages dropping stuff such
@ -424,24 +528,6 @@ Features:
"systemd-gdb" for attaching to the start-up of any system service in its
natural habitat.
* maybe introduce gpt auto discovery for /var/tmp?
* maybe add gpt-partition-based user management: each user gets his own
LUKS-encrypted GPT partition with a new GPT type. A small nss module
enumerates users via udev partition enumeration. UIDs are assigned in a fixed
way: the partition index is added as offset to some fixed base uid. User name
is stored in GPT partition name. A PAM module authenticates the user via the
LUKS partition password. Benefits: strong per-user security, compatibility
with stateless/read-only/verity-enabled root. (other idea: do this based on
loopback files in /home, without GPT involvement)
* gpt-auto logic: introduce support for discovering /var matching an image. For
that, use a partition type UUID that is hashed from the OS name (as encoded
in /etc/os-release), the architecture, and 4 new bits from the gpt flags
field of the root partition. This way can easily support multiple OS
installations on the same GPT partition table, without problems with
unmatched /var partitions.
* gpt-auto logic: related to the above, maybe support a "secondary" root
partition, that is mounted to / and is writable, and where the actual root's
/usr is mounted into.
@ -464,8 +550,6 @@ Features:
* define gpt header bits to select volatility mode
* ProtectKernelLogs= (drops CAP_SYSLOG, add seccomp for syslog() syscall, and DeviceAllow to /dev/kmsg) in service files
* ProtectClock= (drops CAP_SYS_TIMES, adds seecomp filters for settimeofday, adjtimex), sets DeviceAllow o /dev/rtc
* ProtectTracing= (drops CAP_SYS_PTRACE, blocks ptrace syscall, makes /sys/kernel/tracing go away)
@ -523,7 +607,7 @@ Features:
* when we detect that there are waiting jobs but no running jobs, do something
* push CPUAffinity= also into the "cpuset" cgroup controller (only after the cpuset controller got ported to the unified hierarchy)
* push CPUAffinity= also into the "cpuset" cgroup controller
* PID 1 should send out sd_notify("WATCHDOG=1") messages (for usage in the --user mode, and when run via nspawn)
@ -566,8 +650,6 @@ Features:
* as soon as we have sender timestamps, revisit coalescing multiple parallel daemon reloads:
http://lists.freedesktop.org/archives/systemd-devel/2014-December/025862.html
* in systemctl list-unit-files: show the install value the presets would suggest for a service in a third column
* figure out when we can use the coarse timers
* add "systemctl start -v foobar.service" that shows logs of a service
@ -584,8 +666,6 @@ Features:
* what to do about udev db binary stability for apps? (raw access is not an option)
* man: maybe use the word "inspect" rather than "introspect"?
* systemctl: if some operation fails, show log output?
* systemctl edit: use equivalent of cat() to insert existing config as a comment, prepended with #.
@ -597,9 +677,6 @@ Features:
* merge ~/.local/share and ~/.local/lib into one similar /usr/lib and /usr/share....
* systemd.show_status= should probably have a mode where only failed
units are shown.
* add systemd.abort_on_kill or some other such flag to send SIGABRT instead of SIGKILL
(throughout the codebase, not only PID1)
@ -705,7 +782,6 @@ Features:
- allow multiple signal handlers per signal?
- document chaining of signal handler for SIGCHLD and child handlers
- define more intervals where we will shift wakeup intervals around in, 1h, 6h, 24h, ...
- generate a failure of a default event loop is executed out-of-thread
* investigate endianness issues of UUID vs. GUID
@ -818,11 +894,6 @@ Features:
- journald: when we drop syslog messages because the syslog socket is
full, make sure to write how many messages are lost as first thing
to syslog when it works again.
- change systemd-journal-flush into a service that stays around during
boot, and causes the journal to be moved back to /run on shutdown,
so that we do not keep /var busy. This needs to happen synchronously,
hence doing this via signals is not going to work.
- optionally support running journald from the command line for testing purposes in external projects
- journald: allow per-priority and per-service retention times when rotating/vacuuming
- journald: make use of uid-range.h to managed uid ranges to split
journals in.
@ -1044,8 +1115,6 @@ Features:
- allow Type=simple with PIDFile=
https://bugzilla.redhat.com/show_bug.cgi?id=723942
- allow writing multiple conditions in unit files on one line
- load-fragment: when loading a unit file via a chain of symlinks
verify that it is not masked via any of the names traversed.
- introduce Type=pid-file
- introduce mix of BindTo and Requisite
- add a concept of RemainAfterExit= to scope units
@ -1154,4 +1223,3 @@ Regularly:
* link up selected blog stories from man pages and unit files Documentation= fields
String is not UTF-8 clean, ignoring assignment
timedatex.service: Consumed 26ms CPU time.

3
configure vendored
View File

@ -1,4 +1,5 @@
#!/bin/bash -e
#!/usr/bin/env bash
set -e
cflags=CFLAGS="$CFLAGS"
cxxflags=CXXFLAGS="$CXXFLAGS"

1
docs/.gitignore vendored Normal file
View File

@ -0,0 +1 @@
_site

8
docs/AUTOMATIC_BOOT_ASSESSMENT.md
View File

@ -1,5 +1,7 @@
---
title: Automatic Boot Assessment
category: Booting
layout: default
---
# Automatic Boot Assessment
@ -54,7 +56,7 @@ components:
script can optionally create boot loader entries that carry an initial boot
counter (the initial counter is configurable in `/etc/kernel/tries`).
# Details
## Details
The boot counting data `systemd-boot` and `systemd-bless-boot.service`
manage is stored in the name of the boot loader entries. If a boot loader entry
@ -147,7 +149,7 @@ scenario the first 4 steps are the same as above:
12. On the following boot (and all subsequent boots after that) the entry is
now seen with boot counting turned off, no further renaming takes place.
# How to adapt this scheme to other setups
## How to adapt this scheme to other setups
Of the stack described above many components may be replaced or augmented. Here
are a couple of recommendations.
@ -178,7 +180,7 @@ are a couple of recommendations.
wrap them in a unit and order them after `boot-complete.target`, pulling it
in.
# FAQ
## FAQ
1. *Why do you use file renames to store the counter? Why not a regular file?*
— Mainly two reasons: it's relatively likely that renames can be implemented

2
docs/BLOCK_DEVICE_LOCKING.md
View File

@ -1,5 +1,7 @@
---
title: Locking Block Device Access
category: Interfaces
layout: default
---
# Locking Block Device Access

12
docs/BOOT_LOADER_INTERFACE.md
View File

@ -1,5 +1,7 @@
---
title: The Boot Loader Interface
title: Boot Loader Interface
category: Booting
layout: default
---
# The Boot Loader Interface
@ -140,3 +142,11 @@ names for them in UIs.
6. If a boot menu entry encapsulates a reboot into EFI firmware setup feature,
it should use the identifier `reboot-to-firmware-setup` (or
`auto-reboot-to-firmware-setup` in case it is automatically discovered).
## Links
[Boot Loader Specification](https://systemd.io/BOOT_LOADER_INTERFACE)<br>
[Discoverable Partitions Specification](https://systemd.io/DISCOVERABLE_PARTITIONS)<br>
[systemd-boot(7)](https://www.freedesktop.org/software/systemd/man/systemd-boot.html)<br>
[bootctl(1)](https://www.freedesktop.org/software/systemd/man/bootctl.html)<br>
[systemd-gpt-auto-generator(8)](https://www.freedesktop.org/software/systemd/man/systemd-gpt-auto-generator.html)

40
docs/BOOT_LOADER_SPECIFICATION.md
View File

@ -1,5 +1,7 @@
---
title: The Boot Loader Specification
title: Boot Loader Specification
category: Booting
layout: default
---
# The Boot Loader Specification
@ -53,14 +55,14 @@ functionality. Here's why we think that it is not enough for our uses:
Everything described below is located on a placeholder file system `$BOOT`. The installer program should pick `$BOOT` according to the following rules:
* On disks with MBR disk labels
* If the OS is installed on a disk with MBR disk label, and a partition with the MBR type id of 0xEA already exists it should be used as `$BOOT`.
* Otherwise, if the OS is installed on a disk with MBR disk label, a new partition with MBR type id of 0xEA shall be created, of a suitable size (let's say 500MB), and it should be used as `$BOOT`.
* On disks with GPT disk labels
* If the OS is installed on a disk with GPT disk label, and a partition with the GPT type GUID of `bc13c2ff-59e6-4262-a352-b275fd6f7172` already exists, it should be used as `$BOOT`.
* Otherwise, if the OS is installed on a disk with GPT disk label, and an ESP partition (i.e. with the GPT type UID of `c12a7328-f81f-11d2-ba4b-00a0c93ec93b`) already exists and is large enough (let's say 250MB`) and otherwise qualifies, it should be used as `$BOOT`.
* Otherwise, if the OS is installed on a disk with GPT disk label, and if the ESP partition already exists but is too small, a new suitably sized (let's say 500MB) partition with GPT type GUID of `bc13c2ff-59e6-4262-a352-b275fd6f7172` shall be created and it should be used as `$BOOT`.
* Otherwise, if the OS is installed on a disk with GPT disk label, and no ESP partition exists yet, a new suitably sized (let's say 500MB) ESP should be created and should be used as `$BOOT`.
* On disks with an MBR partition table:
* If the OS is installed on a disk with an MBR partition table, and a partition with the type id of 0xEA already exists it should be used as `$BOOT`.
* Otherwise, if the OS is installed on a disk with an MBR partition table, a new partition with type id of 0xEA shall be created, of a suitable size (let's say 500MB), and it should be used as `$BOOT`.
* On disks with GPT (GUID Partition Table)
* If the OS is installed on a disk with GPT, and an Extended Boot Loader Partition or XBOOTLDR partition for short, i.e. a partition with GPT type GUID of `bc13c2ff-59e6-4262-a352-b275fd6f7172`, already exists, it should be used as `$BOOT`.
* Otherwise, if the OS is installed on a disk with GPT, and an EFI System Partition or ESP for short, i.e. a partition with GPT type UID of `c12a7328-f81f-11d2-ba4b-00a0c93ec93b`) already exists and is large enough (let's say 250MB) and otherwise qualifies, it should be used as `$BOOT`.
* Otherwise, if the OS is installed on a disk with GPT, and if the ESP partition already exists but is too small, a new suitably sized (let's say 500MB) XBOOTLDR partition shall be created and used as `$BOOT`.
* Otherwise, if the OS is installed on a disk with GPT, and no ESP partition exists yet, a new suitably sized (let's say 500MB) ESP should be created and used as `$BOOT`.
This placeholder file system shall be determined during _installation time_, and an fstab entry may be created. It should be mounted to either `/boot/` or `/efi/`. Additional locations like `/boot/efi/`, with `/boot/` being a separate file system, might be supported by implementations. This is not recommended because the mounting of `$BOOT` is then dependent on and requires the mounting of the intermediate file system.
@ -89,6 +91,20 @@ from the user. Only entries matching the feature set of boot loader and system
shall be considered and displayed. This allows image builders to put together
images that transparently support multiple different architectures.
Note that the `$BOOT` partition is not supposed to be exclusive territory of
this specification. This specification only defines semantics of the `/loader/`
directory inside the file system (see below), but it doesn't intend to define
ownership of the whole file system exclusively. Boot loaders, firmware, and
other software implementating this specification may choose to place other
files and directories in the same file system. For example, boot loaders that
implement this specification might install their own boot code into the `$BOOT`
partition. On systems where `$BOOT` is the ESP this is a particularly common
setup. Implementations of this specification must be able to operate correctly
if files or directories other than `/loader/` are found in the top level
directory. Implementations that add their own files or directories to the file
systems should use well-named directories, to make name collisions between
multiple users of the file system unlikely.
### Type #1 Boot Loader Specification Entries
We define two directories below `$BOOT`:
@ -218,5 +234,9 @@ There are a couple of items that are out of focus for this specification:
## Links
[GUID Partition Table](https://en.wikipedia.org/wiki/GUID_Partition_Table)<br>
[Boot Loader Interface](https://systemd.io/BOOT_LOADER_INTERFACE)<br>
[Discoverable Partitions Specification](https://systemd.io/DISCOVERABLE_PARTITIONS)<br>
[systemd-boot(7)](https://www.freedesktop.org/software/systemd/man/systemd-boot.html)<br>
[bootctl(1)](https://www.freedesktop.org/software/systemd/man/bootctl.html)
[bootctl(1)](https://www.freedesktop.org/software/systemd/man/bootctl.html)<br>
[systemd-gpt-auto-generator(8)](https://www.freedesktop.org/software/systemd/man/systemd-gpt-auto-generator.html)

10
docs/CGROUP_DELEGATION.md
View File

@ -1,5 +1,7 @@
---
title: Control Group APIs and Delegation
category: Interfaces
layout: default
---
# Control Group APIs and Delegation
@ -19,10 +21,10 @@ comprehensive up-to-date information about all this, particular in light of the
poor implementations of the components interfacing with systemd of current
container managers.
Before you read on, please make sure you read the low-level [kernel
documentation about
cgroup v2](https://www.kernel.org/doc/Documentation/cgroup-v2.txt). This
documentation then adds in the higher-level view from systemd.
Before you read on, please make sure you read the low-level kernel
documentation about the
[unified cgroup hierarchy](https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html).
This document then adds in the higher-level view from systemd.
This document augments the existing documentation we already have:

4
docs/CODE_OF_CONDUCT.md
View File

@ -1,5 +1,7 @@
---
title: The systemd Community Conduct Guidelines
title: systemd Community Conduct Guidelines
category: Contributing
layout: default
---
# The systemd Community Conduct Guidelines

2
docs/CODE_QUALITY.md
View File

@ -1,5 +1,7 @@
---
title: Code Quality Tools
category: Contributing
layout: default
---
# Code Quality Tools

4
docs/CODING_STYLE.md
View File

@ -1,5 +1,7 @@
---
title: Coding Style
category: Contributing
layout: default
---
# Coding Style
@ -541,7 +543,7 @@ title: Coding Style
time you need that please immediately undefine `basename()`, and add a
comment about it, so that no code ever ends up using the POSIX version!
# Committing to git
## Committing to git
- Commit message subject lines should be prefixed with an appropriate component
name of some kind. For example "journal: ", "nspawn: " and so on.

290
docs/CONTAINER_INTERFACE.md Normal file
View File

@ -0,0 +1,290 @@
---
title: Container Interface
category: Interfaces
layout: default
---
# The Container Interface
Also consult [Writing Virtual Machine or Container
Managers](http://www.freedesktop.org/wiki/Software/systemd/writing-vm-managers).
systemd has a number of interfaces for interacting with container managers,
when systemd is used inside of an OS container. If you work on a container
manager, please consider supporting the following interfaces.
## Execution Environment
1. If the container manager wants to control the hostname for a container
running systemd it may just set it before invoking systemd, and systemd will
leave it unmodified when there is no hostname configured in `/etc/hostname`
(that file overrides whatever is pre-initialized by the container manager).
2. Make sure to pre-mount `/proc/`, `/sys/`, and `/sys/fs/selinux/` before
invoking systemd, and mount `/proc/sys/`, `/sys/`, and `/sys/fs/selinux/`
read-only in order to prevent the container from altering the host kernel's
configuration settings. (As a special exception, if your container has
network namespaces enabled, feel free to make `/proc/sys/net/` writable).
systemd and various other subsystems (such as the SELinux userspace) have
been modified to behave accordingly when these file systems are read-only.
(It's OK to mount `/sys/` as `tmpfs` btw, and only mount a subset of its
sub-trees from the real `sysfs` to hide `/sys/firmware/`, `/sys/kernel/` and
so on. If you do that, make sure to mark `/sys/` read-only, as that
condition is what systemd looks for, and is what is considered to be the API
in this context.)
3. Pre-mount `/dev/` as (container private) `tmpfs` for the container and bind
mount some suitable TTY to `/dev/console`. Also, make sure to create device
nodes for `/dev/null`, `/dev/zero`, `/dev/full`, `/dev/random`,
`/dev/urandom`, `/dev/tty`, `/dev/ptmx` in `/dev/`. It is not necessary to
create `/dev/fd` or `/dev/stdout`, as systemd will do that on its own. Make
sure to set up a `BPF_PROG_TYPE_CGROUP_DEVICE` BPF program — on cgroupv2 —
or the `devices` cgroup controller — on cgroupv1 — so that no other devices
but these may be created in the container. Note that many systemd services
use `PrivateDevices=`, which means that systemd will set up a private
`/dev/` for them for which it needs to be able to create these device nodes.
Dropping `CAP_MKNOD` for containers is hence generally not advisable, but
see below.
4. `systemd-udevd` is not available in containers (and refuses to start), and
hence device dependencies are unavailable. The `systemd-udevd` unit files
will check for `/sys/` being read-only, as an indication whether device
management can work. Therefore make sure to mount `/sys/` read-only in the
container (see above). Various clients of `systemd-udevd` also check the
read-only state of `/sys/`, including PID 1 itself and `systemd-networkd`.
5. If systemd detects it is run in a container it will spawn a single shell on
`/dev/console`, and not care about VTs or multiple gettys on VTs. (But see
`$container_ttys` below.)
6. Either pre-mount all cgroup hierarchies in full into the container, or leave
that to systemd which will do so if they are missing. Note that it is
explicitly *not* OK to just mount a sub-hierarchy into the container as that
is incompatible with `/proc/$PID/cgroup` (which lists full paths). Also the
root-level cgroup directories tend to be quite different from inner
directories, and that distinction matters. It is OK however, to mount the
"upper" parts read-only of the hierarchies, and only allow write-access to
the cgroup sub-tree the container runs in. It's also a good idea to mount
all controller hierarchies with exception of `name=systemd` fully read-only
(this only applies to cgroupv1, of course), to protect the controllers from
alteration from inside the containers. Or to turn this around: only the
cgroup sub-tree of the container itself (on cgroupv2 in the unified
hierarchy, and on cgroupv1 in the `name=systemd` hierarchy) may be writable
to the container.
7. Create the control group root of your container by either running your
container as a service (in case you have one container manager instance per
container instance) or creating one scope unit for each container instance
via systemd's transient unit API (in case you have one container manager
that manages all instances. Either way, make sure to set `Delegate=yes` in
it. This ensures that that the unit you created will be part of all cgroup
controllers (or at least the ones systemd understands). The latter may also
be done via `systemd-machined`'s `CreateMachine()` API. Make sure to use the
cgroup path systemd put your process in for all operations of the container.
Do not add new cgroup directories to the top of the tree. This will not only
confuse systemd and the admin, but also prevent your implementation from
being "stackable".
## Environment Variables
1. To allow systemd (and other programs) to identify that it is executed within
a container, please set the `$container` environment variable for PID 1 in
the container to a short lowercase string identifying your
implementation. With this in place the `ConditionVirtualization=` setting in
unit files will work properly. Example: `container=lxc-libvirt`
2. systemd has special support for allowing container managers to initialize
the UUID for `/etc/machine-id` to some manager supplied value. This is only
enabled if `/etc/machine-id` is empty (i.e. not yet set) at boot time of the
container. The container manager should set `$container_uuid` as environment
variable for the container's PID 1 to the container UUID. (This is similar
to the effect of `qemu`'s `-uuid` switch). Note that you should pass only a
UUID here that is actually unique (i.e. only one running container should
have a specific UUID), and gets changed when a container gets duplicated.
Also note that systemd will try to persistently store the UUID in
`/etc/machine-id` (if writable) when this option is used, hence you should
always pass the same UUID here. Keeping the externally used UUID for a
container and the internal one in sync is hopefully useful to minimize
surprise for the administrator.
3. systemd can automatically spawn login gettys on additional ptys. A container
manager can set the `$container_ttys` environment variable for the
container's PID 1 to tell it on which ptys to spawn gettys. The variable
should take a space separated list of pty names, without the leading `/dev/`
prefix, but with the `pts/` prefix included. Note that despite the
variable's name you may only specify ptys, and not other types of ttys. Also
you need to specify the pty itself, a symlink will not suffice. This is
implemented in
[systemd-getty-generator(8)](https://www.freedesktop.org/software/systemd/man/systemd-getty-generator.html).
Note that this variable should not include the pty that `/dev/console` maps
to if it maps to one (see below). Example: if the container receives
`container_ttys=pts/7 pts/8 pts/14` it will spawn three additional login
gettys on ptys 7, 8, and 14.
## Advanced Integration
1. Consider syncing `/etc/localtime` from the host file system into the
container. Make it a relative symlink to the containers's zoneinfo dir, as
usual. Tools rely on being able to determine the timezone setting from the
symlink value, and making it relative looks nice even if people list the
container's `/etc/` from the host.
2. Make the container journal available in the host, by automatically
symlinking the container journal directory into the host journal directory.
More precisely, link `/var/log/journal/<container-machine-id>` of the
container into the same dir of the host. Administrators can then
automatically browse all container journals (correctly interleaved) by
issuing `journalctl -m`. The container machine ID can be determined from
`/etc/machine-id` in the container.
3. If the container manager wants to cleanly shutdown the container, it might
be a good idea to send `SIGRTMIN+3` to its init process. systemd will then
do a clean shutdown. Note however, that since only systemd understands
`SIGRTMIN+3` like this, this might confuse other init systems.
4. To support [Socket Activated
Containers](http://0pointer.de/blog/projects/socket-activated-containers.html)
the container manager should be capable of being run as a systemd
service. It will then receive the sockets starting with FD 3, the number of
passed FDs in `$LISTEN_FDS` and its PID as `$LISTEN_PID`. It should take
these and pass them on to the container's init process, also setting
$LISTEN_FDS and `$LISTEN_PID` (basically, it can just leave the FDs and
`$LISTEN_FDS` untouched, but it needs to adjust `$LISTEN_PID` to the
container init process). That's all that's necessary to make socket
activation work. The protocol to hand sockets from systemd to services is
hence the same as from the container manager to the container systemd. For
further details see the explanations of
[sd_listen_fds(1)](http://0pointer.de/public/systemd-man/sd_listen_fds.html)
and the [blog story for service
developers](http://0pointer.de/blog/projects/socket-activation.html).
5. Container managers should stay away from the cgroup hierarchy outside of the
unit they created for their container. That's private property of systemd,
and no other code should modify it.
## Networking
1. Inside of a container, if a `veth` link is named `host0`, `systemd-networkd`
running inside of the container will by default run DHCPv4, DHCPv6, and
IPv4LL clients on it. It is thus recommended that container managers that
add a `veth` link to a container name it `host0`, to get an automatically
configured network, with no manual setup.
2. Outside of a container, if a `veth` link is prefixed "ve-", `systemd-networkd`
will by default run DHCPv4 and DHCPv6 servers on it, as well as IPv4LL. It
is thus recommended that container managers that add a `veth` link to a
container name the external side `ve-` + the container name.
3. It is recommended to configure stable MAC addresses for container `veth`
devices, for example hashed out of the container names. That way it is more
likely that DHCP and IPv4LL will acquire stable addresses.
## What You Shouldn't Do
1. Do not drop `CAP_MKNOD` from the container. `PrivateDevices=` is a commonly
used service setting that provides a service with its own, private, minimal
version of `/dev/`. To set this up systemd in the container needs this
capability. If you take away the capability than all services that set this
flag will cease to work. Use `BPF_PROG_TYPE_CGROUP_DEVICE` BPF programs — on
cgroupv2 — or the `devices` controller — on cgroupv1 — to restrict what
device nodes the container can create instead of taking away the capability
wholesale. (Also see the section about fully unprivileged containers below.)
2. Do not drop `CAP_SYS_ADMIN` from the container. A number of the most
commonly used file system namespacing related settings, such as
`PrivateDevices=`, `ProtectHome=`, `ProtectSystem=`, `MountFlags=`,
`PrivateTmp=`, `ReadWriteDirectories=`, `ReadOnlyDirectories=`,
`InaccessibleDirectories=`, and `MountFlags=` need to be able to open new
mount namespaces and the mount certain file systems into them. You break all
services that make use of these options if you drop the capability. Also
note that logind mounts `XDG_RUNTIME_DIR` as `tmpfs` for all logged in users
and that won't work either if you take away the capability. (Also see
section about fully unprivileged containers below.)
3. Do not cross-link `/dev/kmsg` with `/dev/console`. They are different things,
you cannot link them to each other.
4. Do not pretend that the real VTs are available in the container. The VT
subsystem consists of all the devices `/dev/tty*`, `/dev/vcs*`, `/dev/vcsa*`
plus their `sysfs` counterparts. They speak specific `ioctl()`s and
understand specific escape sequences, that other ptys don't understand.
Hence, it is explicitly not OK to mount a pty to `/dev/tty1`, `/dev/tty2`,
`/dev/tty3`. This is explicitly not supported.
5. Don't pretend that passing arbitrary devices to containers could really work
well. For example, do not pass device nodes for block devices to the
container. Device access (with the exception of network devices) is not
virtualized on Linux. Enumeration and probing of meta information from
`/sys/` and elsewhere is not possible to do correctly in a container. Simply
adding a specific device node to a container's `/dev/` is *not* *enough* to
do the job, as `systemd-udevd` and suchlike are not available at all, and no
devices will appear available or enumerable, inside the container.
6. Don't mount only a sub-tree of the `cgroupfs` into the container. This will not
work as `/proc/$PID/cgroup` lists full paths and cannot be matched up with
the actual `cgroupfs` tree visible, then. (You may "prune" some branches
though, see above.)
7. Do not make `/sys/` writable in the container. If you do,
`systemd-udevd.service` is started to manage your devices — inside the
container, but that will cause conflicts and errors given that the Linux
device model is not virtualized for containers on Linux and thus the
containers and the host would try to manage the same devices, fighting for
ownership. Multiple other subsystems of systemd similarly test for `/sys/`
being writable to decide whether to use `systemd-udevd` or assume that
device management is properly available on the instance. Among them
`systemd-networkd` and `systemd-logind`. The conditionalization on the
read-only state of `/sys/` enables a nice automatism: as soon as `/sys/` and
the Linux device model are changed to be virtualized properly the container
payload can make use of that, simply by marking `/sys/` writable. (Note that
as special exception, the devices in `/sys/class/net/` are virtualized
already, if network namespacing is used. Thus it is OK to mount the relevant
sub-directories of `/sys/` writable, but make sure to leave the root of
`/sys/` read-only.)
## Fully Unprivileged Container Payload
First things first, to make this clear: Linux containers are not a security
technology right now. There are more holes in the model than in swiss cheese.
For example: if you do not use user namespacing, and share root and other users
between container and host, the `struct user` structures will be shared between
host and container, and hence `RLIMIT_NPROC` and so of the container users
affect the host and other containers, and vice versa. This is a major security
hole, and actually is a real-life problem: since Avahi sets `RLIMIT_NPROC` of
its user to 2 (to effectively disallow `fork()`ing) you cannot run more than
one Avahi instance on the entire system...
People have been asking to be able to run systemd without `CAP_SYS_ADMIN` and
`CAP_SYS_MKNOD` in the container. This is now supported to some level in
systemd, but we recommend against it (see above). If `CAP_SYS_ADMIN` and
`CAP_SYS_MKNOD` are missing from the container systemd will now gracefully turn
off `PrivateTmp=`, `PrivateNetwork=`, `ProtectHome=`, `ProtectSystem=` and
others, because those capabilities are required to implement these options. The
services using these settings (which include many of systemd's own) will hence
run in a different, less secure environment when the capabilities are missing
than with them around.
With user namespacing in place things get much better. With user namespaces the
`struct user` issue described above goes away, and containers can keep
`CAP_SYS_ADMIN` safely for the user namespace, as capabilities are virtualized
and having capabilities inside a container doesn't mean one also has them
outside.
## Final Words
If you write software that wants to detect whether it is run in a container,
please check `/proc/1/environ` and look for the `container=` environment
variable. Do not assume the environment variable is inherited down the process
tree. It generally is not. Hence check the environment block of PID 1, not your
own. Note though that that file is only accessible to root. systemd hence early
on also copies the value into `/run/systemd/container`, which is readable for
everybody. However, that's a systemd-specific interface and other init systems
are unlikely to do the same.
Note that it is our intention to make systemd systems work flawlessly and
out-of-the-box in containers. In fact we are interested to ensure that the same
OS image can be booted on a bare system, in a VM and in a container, and behave
correctly each time. If you notice that some component in systemd does not work
in a container as it should, even though the container manager implements
everything documented above, please contact us.

2
docs/CONTRIBUTING.md
View File

@ -1,5 +1,7 @@
---
title: Contributing
category: Contributing
layout: default
---
# Contributing

216
docs/DISCOVERABLE_PARTITIONS.md Normal file
View File

@ -0,0 +1,216 @@
---
title: Discoverable Partitions Specification
category: Concepts
layout: default
---
# The Discoverable Partitions Specification
_TL;DR: Let's automatically discover, mount and enable the root partition,
`/home/`, `/srv/`, `/var/` and `/var/tmp/` and the swap partitions based on
GUID Partition Tables (GPT)!_
The GUID Partition Table (GPT) is mandatory on EFI systems. It allows
identification of partition types with UUIDs. So far Linux has made little use
of this, and mostly just defined one UUID for file system/data partitions and
another one for swap partitions. With this specification, we introduce
additional partition types to enable automatic discovery of partitions and
their intended mountpoint. This has many benefits:
* OS installers can automatically discover and make sense of partitions of
existing Linux installations.
* The OS can discover and mount the necessary file systems with a non-existing
or incomplete `/etc/fstab` file and without the `root=` kernel command line
option.
* Container managers (such as nspawn and libvirt-lxc) can decode and set up
file systems contained in GPT disk images automatically and mount them to the
right places, thus allowing booting the same, identical images on bare-metal
and in Linux containers. This enables true, natural portability of disk
images between physical machines and Linux containers.
* As a help to administrators and users partition manager tools can show more
descriptive information about partitions tables.
Note that the OS side of this specification is currently implemented in
[systemd](http://systemd.io/) 211 and newer in the
[systemd-auto-gpt-generator(8)](http://www.freedesktop.org/software/systemd/man/systemd-gpt-auto-generator.html)
generator tool. Note that automatic discovery of the root only works if the
boot loader communicates this information to the OS, by implementing the [Boot
Loader
Interface](https://systemd.io/BOOT_LOADER_INTERFACE).
## Defined Partition Type UUIDs
| Partition Type UUID | Name | Allowed File Systems | Explanation |
|---------------------|------|----------------------|-------------|
| `44479540-f297-41b2-9af7-d131d5f0458a` | _Root Partition (x86)_ | Any native, optionally in LUKS | On systems with matching architecture, the first partition with this type UUID on the disk containing the active EFI ESP is automatically mounted to the root directory <tt>/</tt>. If the partition is encrypted with LUKS or has dm-verity integrity data (see below), the device mapper file will be named `/dev/mapper/root`. |
| `4f68bce3-e8cd-4db1-96e7-fbcaf984b709` | _Root Partition (x86-64)_ | ditto | ditto |
| `69dad710-2ce4-4e3c-b16c-21a1d49abed3` | _Root Partition (32-bit ARM)_ | ditto | ditto |
| `b921b045-1df0-41c3-af44-4c6f280d3fae` | _Root Partition (64-bit ARM/AArch64)_ | ditto | ditto |
| `993d8d3d-f80e-4225-855a-9daf8ed7ea97` | _Root Partition (Itanium/IA-64)_ | ditto | ditto |
| `d13c5d3b-b5d1-422a-b29f-9454fdc89d76` | _Root Verity Partition (x86)_ | A dm-verity superblock followed by hash data | On systems with matching architecture, contains dm-verity integrity hash data for the matching root partition. If this feature is used the partition UUID of the root partition should be the first 128bit of the root hash of the dm-verity hash data, and the partition UUID of this dm-verity partition should be the final 128bit of it, so that the root partition and its verity partition can be discovered easily, simply by specifying the root hash. |
| `2c7357ed-ebd2-46d9-aec1-23d437ec2bf5` | _Root Verity Partition (x86-64)_ | ditto | ditto |
| `7386cdf2-203c-47a9-a498-f2ecce45a2d6` | _Root Verity Partition (32-bit ARM)_ | ditto | ditto |
| `df3300ce-d69f-4c92-978c-9bfb0f38d820` | _Root Verity Partition (64-bit ARM/AArch64)_ | ditto | ditto |
| `86ed10d5-b607-45bb-8957-d350f23d0571` | _Root Verity Partition (Itanium/IA-64)_ | ditto | ditto |
| `933ac7e1-2eb4-4f13-b844-0e14e2aef915` | _Home Partition_ | Any native, optionally in LUKS | The first partition with this type UUID on the disk containing the root partition is automatically mounted to `/home/`. If the partition is encrypted with LUKS, the device mapper file will be named `/dev/mapper/home`. |
| `3b8f8425-20e0-4f3b-907f-1a25a76f98e8` | _Server Data Partition_ | Any native, optionally in LUKS | The first partition with this type UUID on the disk containing the root partition is automatically mounted to `/srv/`. If the partition is encrypted with LUKS, the device mapper file will be named `/dev/mapper/srv`. |
| `4d21b016-b534-45c2-a9fb-5c16e091fd2d` | _Variable Data Partition_ | Any native, optionally in LUKS | The first partition with this type UUID on the disk containing the root partition is automatically mounted to `/var/` — under the condition that its partition UUID matches the first 128 bit of `HMAC-SHA256(machine-id, 0x4d21b016b53445c2a9fb5c16e091fd2d)` (i.e. the SHA256 HMAC hash of the binary type UUID keyed by the machine ID as read from [`/etc/machine-id`](https://www.freedesktop.org/software/systemd/man/machine-id.html). This special requirement is made because `/var/` (unlike the other partition types listed here) is inherently private to a specific installation and cannot possibly be shared between multiple OS installations on the same disk, and thus should be bound to a specific instance of the OS, identified by its machine ID. If the partition is encrypted with LUKS, the device mapper file will be named `/dev/mapper/var`. |
| `7ec6f557-3bc5-4aca-b293-16ef5df639d1` | _Temporary Data Partition_ | Any native, optionally in LUKS | The first partition with this type UUID on the disk containing the root partition is automatically mounted to `/var/tmp/`. If the partition is encrypted with LUKS, the device mapper file will be named `/dev/mapper/tmp`. Note that the intended mount point is indeed `/var/tmp/`, not `/tmp/`. The latter is typically maintained in memory via <tt>tmpfs</tt> and does not require a partition on disk. In some cases it might be desirable to make `/tmp/` persistent too, in which case it is recommended to make it a symlink or bind mount to `/var/tmp/`, thus not requiring its own partition type UUID. |
| `0657fd6d-a4ab-43c4-84e5-0933c84b4f4f` | _Swap_ | Swap | All swap partitions on the disk containing the root partition are automatically enabled. |
| `c12a7328-f81f-11d2-ba4b-00a0c93ec93b` | _EFI System Partition_ | VFAT | The ESP used for the current boot is automatically mounted to `/efi/` (or `/boot/` as fallback), unless a different partition is mounted there (possibly via `/etc/fstab`, or because the Extended Boot Loader Partition — see below — exists) or the directory is non-empty on the root disk. This partition type is defined by the [UEFI Specification](http://www.uefi.org/specifications). |
| `bc13c2ff-59e6-4262-a352-b275fd6f7172` | _Extended Boot Loader Partition_ | Typically VFAT | The Extended Boot Loader Partition (XBOOTLDR) used for the current boot is automatically mounted to <tt>/boot/</tt>, unless a different partition is mounted there (possibly via <tt>/etc/fstab</tt>) or the directory is non-empty on the root disk. This partition type is defined by the [Boot Loader Specification](https://systemd.io/BOOT_LOADER_SPECIFICATION). |
| `0fc63daf-8483-4772-8e79-3d69d8477de4` | _Other Data Partitions_ | Any native, optionally in LUKS | No automatic mounting takes place for other Linux data partitions. This partition type should be used for all partitions that carry Linux file systems. The installer needs to mount them explicitly via entries in <tt>/etc/fstab</tt>. Optionally, these partitions may be encrypted with LUKS. |
Other GPT type IDs might be used on Linux, for example to mark software RAID or
LVM partitions. The definitions of those GPT types is outside of the scope of
this specification.
[systemd-id128(1)](http://www.freedesktop.org/software/systemd/man/systemd-i128.html)
may be used to list those UUIDs.
## Partition Names
For partitions of the types listed above it is recommended to use
human-friendly, descriptive partition names in the GPT partition table, for
example "*Home*", "*Server* *Data*", "*Fedora* *Root*" and similar, possibly
localized.
## Partition Flags
For the root, server data, home, variable data, temporary data and swap
partitions, the partition flag bit 63 ("*no-auto*") may be used to turn off
auto-discovery for the specific partition. If set, the partition will not be
automatically mounted or enabled.
For the root, server data, home, variable data and temporary data partitions,
the partition flag bit 60 ("*read-only*") may be used to mark a partition for
read-only mounts only. If set, the partition will be mounted read-only instead
of read-write. Note that the variable data partition and the temporary data
partition will generally not be able to serve their purpose if marked
read-only, since by their very definition they are supposed to be mutable. (The
home and server data partitions are generally assumed to be mutable as well,
but the requirement for them is not equally strong.) Because of that, while the
read-only flag is defined and supported, it's almost never a good idea to
actually use it for these partitions.
Note that these two flag definitions happen to map nicely to the ones used by
Microsoft Basic Data Partitions.
## Suggested Mode of Operation
An *installer* that repartitions the hard disk _should_ use the above UUID
partition types for appropriate partitions it creates.
An *installer* which supports a "manual partitioning" interface _may_ choose to
pre-populate the interface with swap, `/home/`, `/srv/`, `/var/tmp/` partitions
of pre-existing Linux installations, identified with the GPT type UUIDs
above. The installer should not pre-populate such an interface with any
identified root or `/var/` partition unless the intention is to overwrite an
existing operating system that might be installed.
An *installer* _may_ omit creating entries in `/etc/fstab` for root, `/home/`,
`/srv/`, `/var/`, `/var/tmp` and for the swap partitions if they use these UUID
partition types, and are the first partitions on the disk of each type. If the
ESP shall be mounted to `/efi/` (or `/boot/`), it may additionally omit
creating the entry for it in `/etc/fstab`. If an extended boot partition is
used, or if the EFI partition shall not be mounted to `/efi/` or `/boot/`, it
_must_ create `/etc/fstab` entries for them. If other partitions are used (for
example for `/usr/` or `/var/lib/mysql/`), the installer _must_ register these
in `/etc/fstab`. The `root=` parameter passed to the kernel by the boot loader
may be omitted if the root partition is the first one on the disk of its type.
If the root partition is not the first one on the disk, the `root=` parameter
_must_ be passed to the kernel by the boot loader. An installer that mounts a
root, `/home/`, `/srv/`, `/var/`, or `/var/tmp/` file system with the partition
types defined as above which contains a LUKS header _must_ call the device
mapper device "root", "home", "srv", "var" or "tmp", respectively. This is
necessary to ensure that the automatic discovery will never result in different
device mapper names than any static configuration by the installer, thus
eliminating possible naming conflicts and ambiguities.
An *operating* *system* _should_ automatically discover and mount the first
root partition that does not have the no-auto flag set (as described above) by
scanning the disk containing the currently used EFI ESP. It _should_
automatically discover and mount the first `/home/`, `/srv/`, `/var/`,
`/var/tmp/` and swap partitions that do not have the no-auto flag set by
scanning the disk containing the discovered root partition. It should
automatically discover and mount the partition containing the currently used
EFI ESP to `/efi/` (or `/boot/` as fallback). It should automatically discover
and mount the partition containing the currently used Extended Boot Loader
Partition to `/boot/`. It _should not_ discover or automatically mount
partitions with other UUID partition types, or partitions located on other
disks, or partitions with the no-auto flag set. User configuration shall
always override automatic discovery and mounting. If a root, `/home/`,
`/srv/`, `/boot/`, `/var/`, `/var/tmp/`, `/efi/`, `/boot/` or swap partition is
listed in `/etc/fstab` or with `root=` on the kernel command line, it _must_
take precedence over automatically discovered partitions. If a `/home/`,
`/srv/`, `/boot/`, `/var/`, `/var/tmp/`, `/efi/` or `/boot/` directory is found
to be populated already in the root partition, the automatic discovery _must
not_ mount any discovered file system over it.
A *container* *manager* should automatically discover and mount the root,
`/home/`, `/srv/`, `/var/`, `/var/tmp/` partitions inside a container disk
image. It may choose to mount any discovered ESP and/or XBOOOTLDR partition to
`/efi/` or `/boot/`. It should ignore any swap should they be included in a
container disk image.
If a btrfs file system is automatically discovered and mounted by the operating
system/container manager it will be mounted with its *default* subvolume. The
installer should make sure to set the default subvolume correctly using "btrfs
subvolume set-default".
## Sharing of File Systems between Installations
If two Linux-based operating systems are installed on the same disk, the scheme
above suggests that they may share the swap, `/home/`, `/srv/`, `/var/tmp/`,
ESP, XBOOTLDR. However, they should each have their own root and `/var/`
partition.
## Frequently Asked Questions
### Why are you taking my `/etc/fstab` away?
We are not. `/etc/fstab` always overrides automatic discovery and is indeed
mentioned in the specifications. We are simply trying to make the boot and
installation processes of Linux a bit more robust and self-descriptive.
### Why did you only define the root partition for x86, x86-64, ARM, ARM64, ia64?
The automatic discovery of the root partition is defined to operate on the disk
containing the current EFI System Partition (ESP). Since EFI only exists on
x86, x86-64, ia64, and ARM so far, we only defined root partition UUIDs for
these architectures. Should EFI become more common on other architectures, we
can define additional UUIDs for them.
### Why define distinct root partition UUIDs for the various architectures?
This allows disk images that may be booted on multiple architectures to use
discovery of the appropriate root partition on each architecture.
### Doesn't this break multi-boot scenarios?
No, it doesn't. The specification says that installers may not stop creating
`/etc/fstab` or stop including `root=` on the kernel command line, unless the used
partitions are the first ones of their type on the disk. Additionally,
`/etc/fstab` and `root=` both override automatic discovery. Multi-boot is hence
well supported, since it doesn't change anything for anything but the first
installation.
That all said, it's not expected that generic installers generally stop setting
`root=` and creating `/etc/fstab` anyway. The option to drop these configuration
bits is primarily something for appliance-like devices. However, generic
installers should *still* set the right GPT partition types for the partitions
they create so that container managers, partition tools and administrators can
benefit. Phrased differently, this specification introduces A) the
*recommendation* to use the newly defined partition types to tag things
properly and B) the *option* to then drop `root=` and `/etc/fstab`. While we
advertise A) to *all* installers, we only propose B) for simpler,
appliance-like installations.
### What partitioning tools will create a DPS-compliant partition table?
As of util-linux 2.25.2, the fdisk tool provides type codes to create the root,
home, and swap partitions that the DPS expects, but the gdisk tool (version
0.8.10) and its variants do not support creation of a root file system with a
matching type code. By default, fdisk will create an old-style MBR, not a GPT,
so typing 'l' to list partition types will not show the choices that the root
partition with the correct UUID. You must first create an empty GPT and then
type 'l' in order for the DPS-compliant type codes to be available.

2
docs/DISTRO_PORTING.md
View File

@ -1,5 +1,7 @@
---
title: Porting systemd To New Distributions
category: Concepts
layout: default
---
# Porting systemd To New Distributions

9
docs/ENVIRONMENT.md
View File

@ -1,5 +1,7 @@
---
title: Known Environment Variables
category: Interfaces
layout: default
---
# Known Environment Variables
@ -71,6 +73,13 @@ All tools:
appropriate path under /run. This variable is also set by the manager when
RuntimeDirectory= is used, see systemd.exec(5).
* `$SYSTEMD_CRYPT_PREFIX` — if set configures the hash method prefix to use for
UNIX crypt() when generating passwords. By default the system's "preferred
method" is used, but this can be overridden with this environment
variable. Takes a prefix such as `$6$` or `$y$`. (Note that this is only
honoured on systems built with libxcrypt and is ignored on systems using
glibc's original, internal crypt() implementation.)
systemctl:
* `$SYSTEMCTL_FORCE_BUS=1` — if set, do not connect to PID1's private D-Bus

158
docs/GROUP_RECORD.md Normal file
View File

@ -0,0 +1,158 @@
---
title: JSON Group Records
category: Interfaces
layout: default
---
# JSON Group Records
Long story short: JSON Group Records are to `struct group` what [JSON User
Records](https://systemd.io/USER_RECORD.md) are to `struct passwd`.
Conceptually, much of what applies to JSON user records also applies to JSON
group records. They also consist of seven sections, with similar properties and
they carry some identical (or at least very similar) fields.
## Fields in the `regular` section
`groupName` → A string with the UNIX group name. Matches the `gr_name` field of
UNIX/glibc NSS `struct group`, or the shadow structure `struct sgrp`'s
`sg_namp` field.
`realm` → The "realm" the group belongs to, conceptually identical to the same
field of user records. A string in DNS domain name syntax.
`disposition` → The disposition of the group, conceptually identical to the
same field of user records. A string.
`service` → A string, an identifier for the service managing this group record
(this field is typically in reverse domain name syntax.)
`lastChangeUSec` → An unsigned 64bit integer, a timestamp (in µs since the UNIX
epoch 1970) of the last time the group record has been modified. (Covers only
the `regular`, `perMachine` and `privileged` sections).
`gid` → An unsigned integer in the range 0…4294967295: the numeric UNIX group
ID (GID) to use for the group. This corresponds to the `gr_gid` field of
`struct group`.
`members` → An array of strings, listing user names that are members of this
group. Note that JSON user records also contain a `memberOf` field, or in other
words a group membership can either be denoted in the JSON user record or in
the JSON group record, or in both. The list of memberships should be determined
as the combination of both lists (plus optionally others). If a user is listed
as member of a group and doesn't exist it should be ignored. This field
corresponds to the `gr_mem` field of `struct group` and the `sg_mem` field of
`struct sgrp`.
`administrators` → Similarly, an array of strings, listing user names that
shall be considered "administrators" of this group. This field corresponds to
the `sg_adm` field of `struct sgrp`.
`privileged`/`perMachine`/`binding`/`status`/`signature`/`secret` → The
objects/arrays for the other six group record sections. These are organized the
same way as for the JSON user records, and have the same semantics.
## Fields in the `privileged` section
The following fields are defined:
`hashedPassword` → An array of strings with UNIX hashed passwords; see the
matching field for user records for details. This field corresponds to the
`sg_passwd` field of `struct sgrp` (and `gr_passwd` of `struct group` in a
way).
## Fields in the `perMachine` section
`matchMachineId`/`matchHostname` → Strings, match expressions similar as for
user records, see the user record documentation for details.
The following fields are defined for the `perMachine` section and are defined
equivalent to the fields of the same name in the `regular` section, and
override those:
`gid`, `members`, `administrators`
## Fields in the `binding` section
The following fields are defined for the `binding` section, and are equivalent
to the fields of the same name in the `regular` and `perMachine` sections:
`gid`
## Fields in the `status` section
The following fields are defined in the `status` section, and are mostly
equivalent to the fields of the same name in the `regular` section, though with
slightly different conceptual semantics, see the same fields in the user record
documentation:
`service`
## Fields in the `signature` section
The fields in this section are defined identically to those in the matching
section in the user record.
## Fields in the `secret` section
Currently no fields are defined in this section for group records.
## Mapping to `struct group` and `struct sgrp`
When mapping classic UNIX group records (i.e. `struct group` and `struct sgrp`)
to JSON group records the following mappings should be applied:
| Structure | Field | Section | Field | Condition |
|----------------|-------------|--------------|------------------|----------------------------|
| `struct group` | `gr_name` | `regular` | `groupName` | |
| `struct group` | `gr_passwd` | `privileged` | `password` | (See notes below) |
| `struct group` | `gr_gid` | `regular` | `gid` | |
| `struct group` | `gr_mem` | `regular` | `members` | |
| `struct sgrp` | `sg_namp` | `regular` | `groupName` | |
| `struct sgrp` | `sg_passwd` | `privileged` | `password` | (See notes below) |
| `struct sgrp` | `sg_adm` | `regular` | `administrators` | |
| `struct sgrp` | `sg_mem` | `regular` | `members` | |
At this time almost all Linux machines employ shadow passwords, thus the
`gr_passwd` field in `struct group` is set to `"x"`, and the actual password
is stored in the shadow entry `struct sgrp`'s field `sg_passwd`.
## Extending These Records
The same logic and recommendations apply as for JSON user records.
## Examples
A reasonable group record for a system group might look like this:
```json
{
"groupName" : "systemd-resolve",
"gid" : 193,
"status" : {
"6b18704270e94aa896b003b4340978f1" : {
"service" : "io.systemd.NameServiceSwitch"
}
}
}
```
And here's a more complete one for a regular group:
```json
{
"groupName" : "grobie",
"binding" : {
"6b18704270e94aa896b003b4340978f1" : {
"gid" : 60232
}
},
"disposition" : "regular",
"status" : {
"6b18704270e94aa896b003b4340978f1" : {
"service" : "io.systemd.Home"
}
}
}
```

8
docs/HACKING.md
View File

@ -1,5 +1,7 @@
---
title: Hacking on systemd
category: Contributing
layout: default
---
# Hacking on systemd
@ -125,7 +127,5 @@ guidance in [CONTRIBUTING.md](CONTRIBUTING.md) on how to report a security vulne
For more details on building fuzzers and integrating with OSS-Fuzz, visit:
- https://github.com/google/oss-fuzz/blob/master/docs/new_project_guide.md
- https://llvm.org/docs/LibFuzzer.html
- https://github.com/google/fuzzer-test-suite/blob/master/tutorial/libFuzzerTutorial.md
- https://chromium.googlesource.com/chromium/src/testing/libfuzzer/+/HEAD/efficient_fuzzer.md
- [Setting up a new project - OSS-Fuzz](https://google.github.io/oss-fuzz/getting-started/new-project-guide/)
- [Tutorials - OSS-Fuzz](https://google.github.io/oss-fuzz/reference/useful-links/#tutorials)

173
docs/HOME_DIRECTORY.md Normal file
View File

@ -0,0 +1,173 @@
---
title: Home Directories
category: Concepts
layout: default
---
# Home Directories
[`systemd-homed.service(8)`](https://www.freedesktop.org/software/systemd/man/systemd-homed.service.html)
manages home directories of regular ("human") users. Each directory it manages
encapsulates both the data store and the user record of the user so that it
comprehensively describes the user account, and is thus naturally portable
between systems without any further, external metadata. This document describes
the format used by these home directories, in context of the storage mechanism
used.
## General Structure
Inside of the home directory a file `~/.identity` contains the JSON formatted
user record of the user. It follows the format defined in [`JSON User
Records`](https://systemd.io/USER_RECORD). It is recommended to bring the
record into 'normalized' form (i.e. all objects should contain their fields
sorted alphabetically by their key) before storing it there, though this is not
required nor enforced. Since the user record is cryptographically signed the
user cannot make modifications to the file on their own (at least not without
corrupting it, or knowing the private key used for signing the record). Note
that user records are stored here without their `binding`, `status` and
`secret` sections, i.e. only with the sections included in the signature plus
the signature section itself.
## Storage Mechanism: Plain Directory/`btrfs` Subvolume
If the plain directory or `btrfs` subvolume storage mechanism of
`systemd-homed` is used (i.e. `--storage=directory` or `--storage=subvolume` on
the
[`homectl(1)`](https://www.freedesktop.org/software/systemd/man/homectl.html)
command line) the home directory requires no special set-up besides including
the user record in the `~/.identity` file.
It is recommended to name home directories managed this way by
`systemd-homed.service` by the user name, suffixed with `.homedir` (example:
`lennart.homedir` for a user `lennart`) but this is not enforced. When the user
is logged in the directory is generally mounted to `/home/$USER` (in our
example: `/home/lennart`), thus dropping the suffix while the home directory is
active. `systemd-homed` will automatically discover home directories named this
way in `/home/*.homedir` and synthesize NSS user records for them as they show
up.
## Storage Mechanism: `fscrypt` Directories
This storage mechanism is mostly identical to the plain directory storage
mechanism, except that the home directory is encrypted using `fscrypt`. (Use
`--storage=fscrypt` on the `homectl` command line.) Key management is
implemented via extended attributes on the directory itself: for each password
an extended attribute `trusted.fscrypt_slot0`, `trusted.fscrypt_slot1`,
`trusted.fscrypt_slot2`, … is maintained. It's value contains a colon-separated
pair of Base64 encoded data fields. The first field contains a salt value, the
second field the encrypted volume key. The latter is encrypted using AES256 in
counter mode, using a key derived from the password via PBKDF2-HMAC-SHA512
together with the salt value. The construction is similar to what LUKS does for
`dm-crypt` encrypted volumes. Note that extended attributes are not encrypted
by `fscrypt` and hence are suitable for carry the key slots. Moreover, by using
extended attributes the slots are directly attached to the directory and an
independent sidecar key database is not required.
## Storage Mechanism: `cifs` Home Directories
In this storage mechanism the home directory is mounted from a CIFS server and
service at login, configured inside the user record. (Use `--storage=cifs` on
the `homectl` command line.) The local password of the user is used to log into
the CIFS service. The directory share needs to contain the user record in
`~/.identity` as well. Note that this means that the user record needs to be
registered locally before it can be mounted for the first time, since CIFS
domain and server information needs to be known *before* the mount. Note that
for all other storage mechanisms it is entirely sufficient if the directories
or storage artifacts are placed at the right locations — all information to
activate them can be derived automatically from their mere availability.
## Storage Mechanism: `luks` Home Directories
This is the most advanced and most secure storage mechanism and consists of a
Linux file system inside a LUKS2 volume inside a loopback file (or on removable
media). (Use `--storage=luks` on the `homectl` command line.) Specifically:
* The image contains a GPT partition table. For now it should only contain a
single partition, and that partition must have the type UUID
`773f91ef-66d4-49b5-bd83-d683bf40ad16`. It's partition label must be the
user name.
* This partition must contain a LUKS2 volume, whose label must be the user
name. The LUKS2 volume must contain a LUKS2 token field of type
`systemd-homed`. The JSON data of this token must have a `record` field,
containing a string with base64-encoded data. This data is the JSON user
record, in the same serialization as in `~/.identity`, though encrypted. The
JSON data of this token must also have an `iv` field, which contains a
base64-encoded binary initialization vector for the encryption. The
encryption used is the same as the LUKS2 volume itself uses, unlocked by the
same volume key, but based on its own IV.
* Inside of this LUKS2 volume must be a Linux file system, one of `ext4`,
`btrfs` and `xfs`. The file system label must be the user name.
* This file system should contain a single directory named after the user. This
directory will become the home directory of the user when activated. It
contains a second copy of the user record in the `~/.identity` file, like in
the other storage mechanisms.
The image file should either reside in a directory `/home/` on the system,
named after the user, suffixed with `.home`. When activated the container home
directory is mounted to the same path, though with the `.home` suffix dropped —
unless a different mount point is defined in the user record. (e.g.: the
loopback file `/home/waldo.home` is mounted to `/home/waldo` while activated.)
When the image is stored on removable media (such as a USB stick) the image
file can be directly `dd`'ed onto it, the format is unchanged. The GPT envelope
should ensure the image is properly recognizable as a home directory both when
used in a loopback file and on a removable USB stick. (Note that when mounting
a home directory from an USB stick it too defaults to a directory in `/home/`,
named after the username, with no further suffix.)
Rationale for the GPT partition table envelope: this way the image is nicely
discoverable and recognizable already by partition managers as a home
directory. Moreover, when copied onto a USB stick the GPT envelope makes sure
the stick is properly recognizable as a portable home directory
medium. (Moreover it allows to embed additional partitions later on, for
example for allowing a multi-purpose USB stick that contains both a home
directory and a generic storage volume.)
Rationale for including the encrypted user record in the the LUKS2 header:
Linux kernel file system implementations are generally not robust towards
maliciously formatted file systems; there's a good chance that file system
images can be used as attack vectors, exploiting the kernel. Thus it is
necessary to validate the home directory image *before* mounting it and
establishing a minimal level of trust. Since the user record data is
cryptographically signed and user records not signed with a recognized private
key are not accepted a minimal level of trust between the system and the home
directory image is established.
Rationale for storing the home directory one level below to root directory of
the contained file system: this way special directories such as `lost+found/`
do not show up in the user's home directory.
## Algorithm
Regardless of the storage mechanism used, an activated home directory
necessarily involves a mount point to be established. In case of the
directory-based storage mechanisms (`directory`, `subvolume` and `fscrypt`)
this is a bind mount, in case of `cifs` this is a CIFS network mount, and in
case of the LUKS2 backend a regular block device mount of the file system
contained in the LUKS2 image. By requiring a mount for all cases (even for
those that already are a directory) a clear logic is defined to distuingish
active and inactive home directories, so that the directories become
inaccessible under their regular path the instant they are
deactivated. Moreover, the `nosuid`, `nodev` and `noexec` flags configured in
the user record are applied when the bind mount is established.
During activation, the user records retained on the host, the user record
stored in the LUKS2 header (in case of the LUKS2 storage mechanism) and the
user record stored inside the home directory in `~/.identity` are
compared. Activation is only permitted if they match the same user and are
signed by a recognized key. When the three instances differ in `lastChangeUSec`
field, the newest record wins, and is propagated to the other two locations.
During activation the file system checker (`fsck`) appropriate for the
selected file system is automatically invoked, ensuring the file system is in a
healthy state before it is mounted.
If the UID assigned to a user does not match the owner of the home directory in
the file system, the home directory is automatically and recursively `chown()`ed
to the correct UID.
Depending on the `discard` setting of the user record either the backing
loopback file is `fallocate()`ed during activation, or the mounted file system
is `FITRIM`ed after mounting, to ensure the setting is correctly enforced.

73
docs/INITRD_INTERFACE.md Normal file
View File

@ -0,0 +1,73 @@
---
title: Initrd Interface
category: Interfaces
layout: default
---
# The initrd Interface of systemd
The Linux initrd mechanism (short for "initial RAM disk") refers to a small
file system archive that is unpacked by the kernel and contains the first
userspace code that runs. It typically finds and transitions into the actual
root file system to use. systemd supports both initrd and initrd-less boots. If
an initrd is used it is a good idea to pass a few bits of runtime information
from the initrd to systemd in order to avoid duplicate work and to provide
performance data to the administrator. In this page we attempt to roughly
describe the interfaces that exist between the initrd and systemd. These
interfaces are currently used by dracut and the ArchLinux initrds.
* The initrd should mount `/run/` as a tmpfs and pass it pre-mounted when
jumping into the main system when executing systemd. The mount options should
be `mode=755,nodev,nosuid,strictatime`.
* It's highly recommended that the initrd also mounts `/usr/` (if split off) as
appropriate and passes it pre-mounted to the main system, to avoid the
problems described in [Booting without /usr is
Broken](http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken).
* If the executable `/run/initramfs/shutdown` exists systemd will use it to
jump back into the initrd on shutdown. `/run/initramfs/` should be a usable
initrd environment to which systemd will pivot back and the `shutdown`
executable in it should be able to detach all complex storage that for
example was needed to mount the root file system. It's the job of the initrd
to set up this directory and executable in the right way so that this works
correctly. The shutdown binary is invoked with the shutdown verb as `argv[1]`,
optionally followed (in `argv[2]`, `argv[3]`, … systemd's original command
line options, for example `--log-level=` and similar.
* Storage daemons run from the initrd should follow the the guide on [systemd
and Storage Daemons for the Root File
System](https://systemd.io/ROOT_STORAGE_DAEMONS) to survive properly from the
boot initrd all the way to the point where systemd jumps back into the initrd
for shutdown.
One last clarification: we use the term _initrd_ very generically here
describing any kind of early boot file system, regardless whether that might be
implemented as an actual ramdisk, ramfs or tmpfs. We recommend using _initrd_
in this sense as a term that is unrelated to the actual backing technologies
used.
Oh, and one last question before closing: instead of implementing these
features in your own distro's initrd, may I suggest just using Dracut instead?
It's all already implemented there!
## Using systemd inside an initrd
It is also possible and recommended to implement the initrd itself based on
systemd. Here are a few terse notes:
* Provide `/etc/initrd-release` in the initrd image. The idea is that it follows
the same format as the usual `/etc/os-release` but describes the initial RAM
disk implementation rather than the OS. systemd uses the existence of this
file as a flag whether to run in initial RAM disk mode, or not.
* When run in initrd mode, systemd and its components will read a couple of
additional command line arguments, which are generally prefixed with `rd.`
* To transition into the main system image invoke `systemctl switch-root`.
* The switch-root operation will result in a killing spree of all running
processes. Some processes might need to be excluded from that, see the guide
on [systemd and Storage Daemons for the Root File
System](https://systemd.io/ROOT_STORAGE_DAEMONS).

162
docs/PORTABILITY_AND_STABILITY.md Normal file
View File

@ -0,0 +1,162 @@
---
title: Interface Portability and Stability
category: Interfaces
layout: default
---
# Interface Portability and Stability Promise
systemd provides various interfaces developers and programs might rely on. Starting with version 26 (the first version released with Fedora 15) we promise to keep a number of them stable and compatible for the future.
The stable interfaces are:
* **The unit configuration file format**. Unit files written now will stay compatible with future versions of systemd. Extensions to the file format will happen in a way that existing files remain compatible.
* **The command line interface** of `systemd`, `systemctl`, `loginctl`, `journalctl`, and all other command line utilities installed in `$PATH` and documented in a man page. We will make sure that scripts invoking these commands will continue to work with future versions of systemd. Note however that the output generated by these commands is generally not included in the promise, unless it is documented in the man page. Example: the output of `systemctl status` is not stable, but that of `systemctl show` is, because the former is intended to be human readable and the latter computer readable, and this is documented in the man page.
* **The protocol spoken on the socket referred to by `$NOTIFY_SOCKET`**, as documented in [sd_notify(3)](https://www.freedesktop.org/software/systemd/man/sd_notify.html).
* Some of the **"special" unit names** and their semantics. To be precise the ones that are necessary for normal services, and not those required only for early boot and late shutdown, with very few exceptions. To list them here: `basic.target`, `shutdown.target`, `sockets.target`, `network.target`, `getty.target`, `graphical.target`, `multi-user.target`, `rescue.target`, `emergency.target`, `poweroff.target`, `reboot.target`, `halt.target`, `runlevel[1-5].target`.
* **The D-Bus interfaces of the main service daemon and other daemons**. We try to always preserve backwards compatibility, and intentional breakage is never introduced. Nevertheless, when we find bugs that mean that the existing interface was not useful, or when the implementation did something different than stated by the documentation and the implemented behaviour is not useful, we will fix the implementation and thus introduce a change in behaviour. But the API (parameter counts and types) is never changed, and existing attributes and methods will not be removed.
* For a more comprehensive and authoritative list, consult the chart below.
The following interfaces will not necessarily be kept stable for now, but we will eventually make a stability promise for these interfaces too. In the meantime we will however try to keep breakage of these interfaces at a minimum:
* **The set of states of the various state machines used in systemd**, e.g. the high-level unit states inactive, active, deactivating, and so on, as well (and in particular) the low-level per-unit states.
* **All "special" units that aren't listed above**.
The following interfaces are considered private to systemd, and are not and will not be covered by any stability promise:
* **Undocumented switches** to `systemd`, `systemctl` and otherwise.
* **The internal protocols** used on the various sockets such as the sockets `/run/systemd/shutdown`, `/run/systemd/private`.
One of the main goals of systemd is to unify basic Linux configurations and service behaviors across all distributions. Systemd project does not contain any distribution-specific parts. Distributions are expected to convert over time their individual configurations to the systemd format, or they will need to carry and maintain patches in their package if they still decide to stay different.
What does this mean for you? When developing with systemd, don't use any of the latter interfaces, or we will tell your mom, and she won't love you anymore. You are welcome to use the other interfaces listed here, but if you use any of the second kind (i.e. those where we don't yet make a stability promise), then make sure to subscribe to our mailing list, where we will announce API changes, and be prepared to update your program eventually.
Note that this is a promise, not an eternal guarantee. These are our intentions, but if in the future there are very good reasons to change or get rid of an interface we have listed above as stable, then we might take the liberty to do so, despite this promise. However, if we do this, then we'll do our best to provide a smooth and reasonably long transition phase.
## Interface Portability And Stability Chart
systemd provides a number of APIs to applications. Below you'll find a table detailing which APIs are considered stable and how portable they are.
This list is intended to be useful for distribution and OS developers who are interested in maintaining a certain level of compatibility with the new interfaces systemd introduced, without relying on systemd itself.
In general it is our intention to cooperate through interfaces and not code with other distributions and OSes. That means that the interfaces where this applies are best reimplemented in a compatible fashion on those other operating systems. To make this easy we provide detailed interface documentation where necessary. That said, it's all Open Source, hence you have the option to a) fork our code and maintain portable versions of the parts you are interested in independently for your OS, or b) build systemd for your distro, but leave out all components except the ones you are interested in and run them without the core of systemd involved. We will try not to make this any more difficult than necessary. Patches to allow systemd code to be more portable will be accepted on case-by-case basis (essentially, patches to follow well-established standards instead of e.g. glibc or linux extensions have a very high chance of being accepted, while patches which make the code ugly or exist solely to work around bugs in other projects have a low chance of being accepted).
Many of these interfaces are already being used by applications and 3rd party code. If you are interested in compatibility with these applications, please consider supporting these interfaces in your distribution, where possible.
## General Portability of systemd and its Components
**Portability to OSes:** systemd is not portable to non-Linux systems. It makes use of a large number of Linux-specific interfaces, including many that are used by its very core. We do not consider it feasible to port systemd to other Unixes (let alone non-Unix operating systems) and will not accept patches for systemd core implementing any such portability (but hey, it's git, so it's as easy as it can get to maintain your own fork...). APIs that are supposed to be used as library code are exempted from this: it is important to us that these compile nicely on non-Linux and even non-Unix platforms, even if they might just become NOPs.
**Portability to Architectures:** It is important to us that systemd is portable to little endian as well as big endian systems. We will make sure to provide portability with all important architectures and hardware Linux runs on and are happy to accept patches for this.
**Portability to Distributions:** It is important to us that systemd is portable to all Linux distributions. However, the goal is to unify many of the needless differences between the distributions, and hence will not accept patches for certain distribution-specific work-arounds. Compatibility with the distribution's legacy should be maintained in the distribution's packaging, and not in the systemd source tree.
**Compatibility with Specific Versions of Other packages:** We generally avoid adding compatibility kludges to systemd that work around bugs in certain versions of other software systemd interfaces with. We strongly encourage fixing bugs where they are, and if that's not systemd we rather not try to fix it there. (There are very few exceptions to this rule possible, and you need an exceptionally strong case for it).
## General Portability of systemd's APIs
systemd's APIs are available everywhere where systemd is available. Some of the APIs we have defined are supposed to be generic enough to be implementable independently of systemd, thus allowing compatibility with systems systemd itself is not compatible with, i.e. other OSes, and distributions that are unwilling to fully adopt systemd.
A number of systemd's APIs expose Linux or systemd-specific features that cannot sensibly be implemented elsewhere. Please consult the table below for information about which ones these are.
Note that not all of these interfaces are our invention (but most), we just adopted them in systemd to make them more prominently implemented. For example, we adopted many Debian facilities in systemd to push it into the other distributions as well.
---
And now, here's the list of (hopefully) all APIs that we have introduced with systemd:
| API | Type | Covered by Interface Stability Promise | Fully documented | Known External Consumers | Reimplementable Independently | Known Other Implementations | systemd Implementation portable to other OSes or non-systemd distributions |
| --- | ---- | ----------------------------------------------------------------------------------------- | ---------------- | ------------------------ | ----------------------------- | --------------------------- | -------------------------------------------------------------------------- |
| [hostnamed](https://www.freedesktop.org/wiki/Software/systemd/hostnamed) | D-Bus | yes | yes | GNOME | yes | [Ubuntu](https://launchpad.net/ubuntu/+source/ubuntu-system-service), [Gentoo](http://www.gentoo.org/proj/en/desktop/gnome/openrc-settingsd.xml), [BSD](http://uglyman.kremlin.cc/gitweb/gitweb.cgi?p=systembsd.git;a=summary) | partially |
| [localed](https://www.freedesktop.org/wiki/Software/systemd/localed) | D-Bus | yes | yes | GNOME | yes | [Ubuntu](https://launchpad.net/ubuntu/+source/ubuntu-system-service), [Gentoo](http://www.gentoo.org/proj/en/desktop/gnome/openrc-settingsd.xml), [BSD](http://uglyman.kremlin.cc/gitweb/gitweb.cgi?p=systembsd.git;a=summary) | partially |
| [timedated](https://www.freedesktop.org/wiki/Software/systemd/timedated) | D-Bus | yes | yes | GNOME | yes | [Gentoo](http://www.gentoo.org/proj/en/desktop/gnome/openrc-settingsd.xml), [BSD](http://uglyman.kremlin.cc/gitweb/gitweb.cgi?p=systembsd.git;a=summary) | partially |
| [initrd interface](https://www.freedesktop.org/wiki/Software/systemd/InitrdInterface) | Environment, flag files | yes | yes | dracut, ArchLinux | yes | ArchLinux | no |
| [Container interface](https://systemd.io/CONTAINER_INTERFACE) | Environment, Mounts | yes | yes | libvirt/LXC | yes | - | no |
| [Boot Loader interface](https://systemd.io/BOOT_LOADER_INTERFACE) | EFI variables | yes | yes | gummiboot | yes | - | no |
| [Service bus API](https://www.freedesktop.org/wiki/Software/systemd/dbus) | D-Bus | yes | yes | system-config-services | no | - | no |
| [logind](https://www.freedesktop.org/wiki/Software/systemd/logind) | D-Bus | yes | yes | GNOME | no | - | no |
| [sd-login.h API](https://www.freedesktop.org/software/systemd/man/sd-login.html) | C Library | yes | yes | GNOME, PolicyKit, ... | no | - | no |
| [sd-daemon.h API](https://www.freedesktop.org/software/systemd/man/sd-daemon.html) | C Library or Drop-in | yes | yes | numerous | yes | - | yes |
| [sd-id128.h API](https://www.freedesktop.org/software/systemd/man/sd-id128.html) | C Library | yes | yes | - | yes | - | no |
| [sd-journal.h API](https://www.freedesktop.org/software/systemd/man/sd-journal.html) | C Library | yes | yes | - | maybe | - | no |
| [$XDG_RUNTIME_DIR](https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html) | Environment | yes | yes | glib, GNOME | yes | - | no |
| [$LISTEN_FDS $LISTEN_PID FD Passing](https://www.freedesktop.org/software/systemd/man/sd_listen_fds.html) | Environment | yes | yes | numerous (via sd-daemon.h) | yes | - | no |
| [$NOTIFY_SOCKET Daemon Notifications](https://www.freedesktop.org/software/systemd/man/sd_notify.html) | Environment | yes | yes | a few, including udev | yes | - | no |
| [argv&#91;0&#93;&#91;0&#93;='@' Logic](https://www.freedesktop.org/wiki/Software/systemd/RootStorageDaemons) | `/proc` marking | yes | yes | mdadm | yes | - | no |
| [Unit file format](https://www.freedesktop.org/software/systemd/man/systemd.unit.html) | File format | yes | yes | numerous | no | - | no |
| [Network](https://www.freedesktop.org/software/systemd/man/systemd.network.html) & [Netdev file format](https://www.freedesktop.org/software/systemd/man/systemd.netdev.html) | File format | yes | yes | no | no | - | no |
| [Link file format](https://www.freedesktop.org/software/systemd/man/systemd.link.html) | File format | yes | yes | no | no | - | no |
| [Journal File Format](https://www.freedesktop.org/wiki/Software/systemd/journal-files) | File format | yes | yes | - | maybe | - | no |
| [Journal Export Format](https://www.freedesktop.org/wiki/Software/systemd/export) | File format | yes | yes | - | yes | - | no |
| [Cooperation in cgroup tree](https://www.freedesktop.org/wiki/Software/systemd/PaxControlGroups) | Treaty | yes | yes | libvirt | yes | libvirt | no |
| [Password Agents](https://www.freedesktop.org/wiki/Software/systemd/PasswordAgents) | Socket+Files | yes | yes | - | yes | - | no |
| [udev multi-seat properties](https://www.freedesktop.org/wiki/Software/systemd/multiseat) | udev Property | yes | yes | X11, gdm | no | - | no |
| udev session switch ACL properties | udev Property | no | no | - | no | - | no |
| [CLI of systemctl,...](https://www.freedesktop.org/software/systemd/man/systemctl.html) | CLI | yes | yes | numerous | no | - | no |
| [tmpfiles.d](https://www.freedesktop.org/software/systemd/man/tmpfiles.d.html) | File format | yes | yes | numerous | yes | ArchLinux | partially |
| [sysusers.d](https://www.freedesktop.org/software/systemd/man/sysusers.d.html) | File format | yes | yes | unknown | yes | | partially |
| [/etc/machine-id](https://www.freedesktop.org/software/systemd/man/machine-id.html) | File format | yes | yes | D-Bus | yes | - | no |
| [binfmt.d](https://www.freedesktop.org/software/systemd/man/binfmt.d.html) | File format | yes | yes | numerous | yes | - | partially |
| [/etc/hostname](https://www.freedesktop.org/software/systemd/man/hostname.html) | File format | yes | yes | numerous (it's a Debian thing) | yes | Debian, ArchLinux | no |
| [/etc/locale.conf](https://www.freedesktop.org/software/systemd/man/locale.conf.html) | File format | yes | yes | - | yes | ArchLinux | partially |
| [/etc/machine-info](https://www.freedesktop.org/software/systemd/man/machine-info.html) | File format | yes | yes | - | yes | - | partially |
| [modules-load.d](https://www.freedesktop.org/software/systemd/man/modules-load.d.html) | File format | yes | yes | numerous | yes | - | partially |
| [/usr/lib/os-release](https://www.freedesktop.org/software/systemd/man/os-release.html) | File format | yes | yes | some | yes | Fedora, OpenSUSE, ArchLinux, Angstrom, Frugalware, others... | no |
| [sysctl.d](https://www.freedesktop.org/software/systemd/man/sysctl.d.html) | File format | yes | yes | some (it's a Debian thing) | yes | procps/Debian, ArchLinux | partially |
| [/etc/timezone](https://www.freedesktop.org/software/systemd/man/timezone.html) | File format | yes | yes | numerous (it's a Debian thing) | yes | Debian | partially |
| [/etc/vconsole.conf](https://www.freedesktop.org/software/systemd/man/vconsole.conf.html) | File format | yes | yes | - | yes | ArchLinux | partially |
| `/run` | File hierarchy change | yes | yes | numerous | yes | OpenSUSE, Debian, ArchLinux | no |
| [Generators](https://www.freedesktop.org/software/systemd/man/systemd.generator.html) | Subprocess | yes | yes | - | no | - | no |
| [System Updates](https://www.freedesktop.org/software/systemd/man/systemd.offline-updates.html) | System Mode | yes | yes | - | no | - | no |
| [Presets](https://freedesktop.org/wiki/Software/systemd/Preset) | File format | yes | yes | - | no | - | no |
| Udev rules | File format | yes | yes | numerous | no | no | partially |
### Explanations
Items for which "systemd implementation portable to other OSes" is "partially" means that it is possible to run the respective tools that are included in the systemd tarball outside of systemd. Note however that this is not officially supported, so you are more or less on your own if you do this. If you are opting for this solution simply build systemd as you normally would but drop all files except those which you are interested in.
Of course, it is our intention to eventually document all interfaces we defined. If we haven't documented them for now, this is usually because we want the flexibility to still change things, or don't want 3rd party applications to make use of these interfaces already. That said, our sources are quite readable and open source, so feel free to spelunk around in the sources if you want to know more.
If you decide to reimplement one of the APIs for which "Reimplementable independently" is "no", then we won't stop you, but you are on your own.
This is not an attempt to comprehensively list all users of these APIs. We are just listing the most obvious/prominent ones which come to our mind.
Of course, one last thing I can't make myself not ask you before we finish here, and before you start reimplementing these APIs in your distribution: are you sure it's time well spent if you work on reimplementing all this code instead of just spending it on adopting systemd on your distro as well?
## Independent Operation of systemd Programs
Some programs in the systemd suite are intended to operate independently of the
running init process (or even without an init process, for example when
creating system installation chroots). They can be safely called on systems with
a different init process or for example in package installation scriptlets.
The following programs currently and in the future will support operation
without communicating with the `systemd` process:
`systemd-escape`,
`systemd-id128`,
`systemd-path`,
`systemd-tmpfiles`,
`systemd-sysctl`,
`systemd-sysusers`.
Many other programs support operation without the system manager except when
the specific functionality requires such communication. For example
`journalctl` operates almost independently, but will query the boot id when
`--boot` option is used; it also requires `systemd-journald` (and thus
`systemd`) to be running for options like `--flush` and `--sync`.
`systemd-journal-remote`, `systemd-journal-upload`, `systemd-journal-gatewayd`,
`coredumpctl`, `busctl`, `systemctl --root` also fall into this category of
mostly-independent programs.

4
docs/PORTABLE_SERVICES.md
View File

@ -1,5 +1,7 @@
---
title: Portable Services Introduction
category: Concepts
layout: default
---
# Portable Services Introduction
@ -163,7 +165,7 @@ requirements are made for an image that can be attached/detached with
an image with a partition table understood by the Linux kernel with only a
single partition defined, or alternatively, a GPT partition table with a set
of properly marked partitions following the [Discoverable Partitions
Specification](https://www.freedesktop.org/wiki/Specifications/DiscoverablePartitionsSpec/).
Specification](https://systemd.io/DISCOVERABLE_PARTITIONS).
3. The image must at least contain one matching unit file, with the right name
prefix and suffix (see above). The unit file is searched in the usual paths,

27
docs/PREDICTABLE_INTERFACE_NAMES.md
View File

@ -1,23 +1,24 @@
---
title: Predictable Network Interface Names
category: Concepts
layout: default
---
# Predictable Network Interface Names
Starting with v197 systemd/udev will automatically assign predictable, stable network interface names for all local Ethernet, WLAN and WWAN interfaces. This is a departure from the traditional interface naming scheme ("eth0", "eth1", "wlan0", ...), but should fix real problems.
Starting with v197 systemd/udev will automatically assign predictable, stable network interface names for all local Ethernet, WLAN and WWAN interfaces. This is a departure from the traditional interface naming scheme (`eth0`, `eth1`, `wlan0`, ...), but should fix real problems.
## Why?
The classic naming scheme for network interfaces applied by the kernel is to simply assign names beginning with "eth0", "eth1", ... to all interfaces as they are probed by the drivers. As the driver probing is generally not predictable for modern technology this means that as soon as multiple network interfaces are available the assignment of the names "eth0", "eth1" and so on is generally not fixed anymore and it might very well happen that "eth0" on one boot ends up being "eth1" on the next. This can have serious security implications, for example in firewall rules which are coded for certain naming schemes, and which are hence very sensitive to unpredictable changing names.
The classic naming scheme for network interfaces applied by the kernel is to simply assign names beginning with `eth0`, `eth1`, ... to all interfaces as they are probed by the drivers. As the driver probing is generally not predictable for modern technology this means that as soon as multiple network interfaces are available the assignment of the names `eth0`, `eth1` and so on is generally not fixed anymore and it might very well happen that `eth0` on one boot ends up being `eth1` on the next. This can have serious security implications, for example in firewall rules which are coded for certain naming schemes, and which are hence very sensitive to unpredictable changing names.
To fix this problem multiple solutions have been proposed and implemented. For a longer time udev shipped support for assigning permanent "ethX" names to certain interfaces based on their MAC addresses. This turned out to have a multitude of problems, among them: this required a writable root directory which is generally not available; the statelessness of the system is lost as booting an OS image on a system will result in changed configuration of the image; on many systems MAC addresses are not actually fixed, such as on a lot of embedded hardware and particularly on all kinds of virtualization solutions. The biggest of all however is that the userspace components trying to assign the interface name raced against the kernel assigning new names from the same "ethX" namespace, a race condition with all kinds of weird effects, among them that assignment of names sometimes failed. As a result support for this has been removed from systemd/udev a while back.
To fix this problem multiple solutions have been proposed and implemented. For a longer time udev shipped support for assigning permanent `ethX` names to certain interfaces based on their MAC addresses. This turned out to have a multitude of problems, among them: this required a writable root directory which is generally not available; the statelessness of the system is lost as booting an OS image on a system will result in changed configuration of the image; on many systems MAC addresses are not actually fixed, such as on a lot of embedded hardware and particularly on all kinds of virtualization solutions. The biggest of all however is that the userspace components trying to assign the interface name raced against the kernel assigning new names from the same `ethX` namespace, a race condition with all kinds of weird effects, among them that assignment of names sometimes failed. As a result support for this has been removed from systemd/udev a while back.
Another solution that has been implemented is "biosdevname" which tries to find fixed slot topology information in certain firmware interfaces and uses them to assign fixed names to interfaces which incorporate their physical location on the mainboard. In a way this naming scheme is similar to what is already done natively in udev for various device nodes via /dev/*/by-path/ symlinks. In many cases, biosdevname departs from the low-level kernel device identification schemes that udev generally uses for these symlinks, and instead invents its own enumeration schemes.
Another solution that has been implemented is `biosdevname` which tries to find fixed slot topology information in certain firmware interfaces and uses them to assign fixed names to interfaces which incorporate their physical location on the mainboard. In a way this naming scheme is similar to what is already done natively in udev for various device nodes via `/dev/*/by-path/` symlinks. In many cases, biosdevname departs from the low-level kernel device identification schemes that udev generally uses for these symlinks, and instead invents its own enumeration schemes.
Finally, many distributions support renaming interfaces to user-chosen names (think: "internet0", "dmz0", ...) keyed off their MAC addresses or physical locations as part of their networking scripts. This is a very good choice but does have the problem that it implies that the user is willing and capable of choosing and assigning these names.
Finally, many distributions support renaming interfaces to user-chosen names (think: `internet0`, `dmz0`, ...) keyed off their MAC addresses or physical locations as part of their networking scripts. This is a very good choice but does have the problem that it implies that the user is willing and capable of choosing and assigning these names.
We believe it is a good default choice to generalize the scheme pioneered by "biosdevname". Assigning fixed names based on firmware/topology/location information has the big advantage that the names are fully automatic, fully predictable, that they stay fixed even if hardware is added or removed (i.e. no reenumeration takes place) and that broken hardware can be replaced seamlessly. That said, they admittedly are sometimes harder to read than the "eth0" or "wlan0" everybody is used to. Example: "enp5s0"
We believe it is a good default choice to generalize the scheme pioneered by `biosdevname`. Assigning fixed names based on firmware/topology/location information has the big advantage that the names are fully automatic, fully predictable, that they stay fixed even if hardware is added or removed (i.e. no reenumeration takes place) and that broken hardware can be replaced seamlessly. That said, they admittedly are sometimes harder to read than the `eth0` or `wlan0` everybody is used to. Example: `enp5s0`
## What precisely has changed in v197?
@ -45,14 +46,14 @@ With this new scheme you now get:
* Stable interface names even if you have to replace broken ethernet cards by new ones
* The names are automatically determined without user configuration, they just work
* The interface names are fully predictable, i.e. just by looking at lspci you can figure out what the interface is going to be called
* Fully stateless operation, changing the hardware configuration will not result in changes in /etc
* Fully stateless operation, changing the hardware configuration will not result in changes in `/etc`
* Compatibility with read-only root
* The network interface naming now follows more closely the scheme used for aliasing block device nodes and other device nodes in /dev via symlinks
* The network interface naming now follows more closely the scheme used for aliasing block device nodes and other device nodes in `/dev` via symlinks
* Applicability to both x86 and non-x86 machines
* The same on all distributions that adopted systemd/udev
* It's easy to opt out of the scheme (see below)
Does this have any drawbacks? Yes, it does. Previously it was practically guaranteed that hosts equipped with a single ethernet card only had a single "eth0" interface. With this new scheme in place, an administrator now has to check first what the local interface name is before he can invoke commands on it where previously he had a good chance that "eth0" was the right name.
Does this have any drawbacks? Yes, it does. Previously it was practically guaranteed that hosts equipped with a single ethernet card only had a single `eth0` interface. With this new scheme in place, an administrator now has to check first what the local interface name is before he can invoke commands on it where previously he had a good chance that `eth0` was the right name.
## I don't like this, how do I disable this?
@ -60,9 +61,9 @@ Does this have any drawbacks? Yes, it does. Previously it was practically guaran
You basically have three options:
1. You disable the assignment of fixed names, so that the unpredictable kernel names are used again. For this, simply mask udev's .link file for the default policy: `ln -s /dev/null /etc/systemd/network/99-default.link`
1. You create your own manual naming scheme, for example by naming your interfaces "internet0", "dmz0" or "lan0". For that create your own .link files in /etc/systemd/network/, that choose an explicit name or a better naming scheme for one, some, or all of your interfaces. See [[systemd.link(5)|http://www.freedesktop.org/software/systemd/man/systemd.link.html]] for more information.
1. You pass the net.ifnames=0 on the kernel command line
1. You create your own manual naming scheme, for example by naming your interfaces `internet0`, `dmz0` or `lan0`. For that create your own `.link` files in `/etc/systemd/network/`, that choose an explicit name or a better naming scheme for one, some, or all of your interfaces. See [systemd.link(5)](http://www.freedesktop.org/software/systemd/man/systemd.link.html) for more information.
1. You pass the `net.ifnames=0` on the kernel command line
## How does the new naming scheme look like, precisely?
That's documented in detail in a comment block [[the sources of the net_id built-in|https://github.com/systemd/systemd/blob/master/src/udev/udev-builtin-net_id.c#L20]]. Please refer to this in case you are wondering how to decode the new interface names.
That's documented in detail the [systemd.net-naming-scheme(7)](https://www.freedesktop.org/software/systemd/man/systemd.net-naming-scheme.html) man page. Please refer to this in case you are wondering how to decode the new interface names.

2
docs/RANDOM_SEEDS.md
View File

@ -1,5 +1,7 @@
---
title: Random Seeds
category: Concepts
layout: default
---
# Random Seeds

2
docs/RELEASE.md
View File

@ -1,5 +1,7 @@
---
title: Steps to a Successful Release
category: Contributing
layout: default
---
# Steps to a Successful Release

193
docs/ROOT_STORAGE_DAEMONS.md Normal file
View File

@ -0,0 +1,193 @@
---
title: Storage Daemons for the Root File System
category: Interfaces
layout: default
---
# systemd and Storage Daemons for the Root File System
a.k.a. _Pax Cellae pro Radix Arbor_
(or something like that, my Latin is a bit rusty)
A number of complex storage technologies on Linux (e.g. RAID, volume
management, networked storage) require user space services to run while the
storage is active and mountable. This requirement becomes tricky as soon as the
root file system of the Linux operating system is stored on such storage
technology. Previously no clear path to make this work was available. This text
tries to clear up the resulting confusion, and what is now supported and what
is not.
## A Bit of Background
When complex storage technologies are used as backing for the root file system
this needs to be set up by the initial RAM file system (initrd), i.e. on Fedora
by Dracut. In newer systemd versions tear-down of the root file system backing
is also done by the initrd: after terminating all remaining running processes
and unmounting all file systems it can (which means excluding the root fs)
systemd will jump back into the initrd code allowing it to unmount the final
file systems (and its storage backing) that could not be unmounted as long as
the OS was still running from the main root file system. The initrd' job is to
detach/unmount the root fs, i.e. inverting the exact commands it used to set
them up in the first place. This is not only cleaner, but also allows for the
first time arbitrary complex stacks of storage technology.
Previous attempts to handle root file system setups with complex storage as
backing usually tried to maintain the root storage with program code stored on
the root storage itself, thus creating a number of dependency loops. Safely
detaching such a root file system becomes messy, since the program code on the
storage needs to stay around longer than the storage, which is technically
contradicting.
## What's new?
As a result, we hereby clarify that we do not support storage technology setups
where the storage daemons are being run from the storage it maintains
itself. In other words: a storage daemon backing the root file system cannot be
stored on the root file system itself.
What we do support instead is that these storage daemons are started from the
initrd, stay running all the time during normal operation and are terminated
only after we returned control back to the initrd and by the initrd. As such,
storage daemons involved with maintaining the root file system storage
conceptually are more like kernel threads than like normal system services:
from the perspective of the init system (i.e. systemd) these services have been
started before systemd got initialized and stay around until after systemd is
already gone. These daemons can only be updated by updating the initrd and
rebooting, a takeover from initrd-supplied services to replacements from the
root file system is not supported.
## What does this mean?
Near the end of system shutdown, systemd executes a small tool called
systemd-shutdown, replacing its own process. This tool (which runs as PID 1, as
it entirely replaces the systemd init process) then iterates through the
mounted file systems and running processes (as well as a couple of other
resources) and tries to unmount/read-only mount/detach/kill them. It continues
to do this in a tight loop as long as this results in any effect. From this
killing spree a couple of processes are automatically excluded: PID 1 itself of
course, as well as all kernel threads. After the killing/unmounting spree
control is passed back to the initrd, whose job is then to unmount/detach
whatever might be remaining.
The same killing spree logic (but not the unmount/detach/read-only logic) is
applied during the transition from the initrd to the main system (i.e. the
"`switch_root`" operation), so that no processes from the initrd survive to the
main system.
To implement the supported logic proposed above (i.e. where storage daemons
needed for the root fs which are started by the initrd stay around during
normal operation and are only killed after control is passed back to the
initrd) we need to exclude these daemons from the shutdown/switch_root killing
spree. To accomplish this the following logic is available starting with
systemd 38:
Processes (run by the root user) whose first character of the zeroth command
line argument is `@` are excluded from the killing spree, much the same way as
kernel threads are excluded too. Thus, a daemon which wants to take advantage
of this logic needs to place the following at the top of its `main()` function:
```c
...
argv[0][0] = '@';
...
```
And that's already it. Note that this functionality is only to be used by
programs running from the initrd, and **not** for programs running from the
root file system itself. Programs which use this functionality and are running
from the root file system are considered buggy since they effectively prohibit
clean unmounting/detaching of the root file system and its backing storage.
_Again: if your code is being run from the root file system, then this logic
suggested above is **NOT** for you. Sorry. Talk to us, we can probably help you
to find a different solution to your problem._
The recommended way to distinguish between run-from-initrd and run-from-rootfs
for a daemon is to check for `/etc/initrd-release` (which exists on all modern
initrd implementations, see the [initrd
Interface](http://www.freedesktop.org/wiki/Software/systemd/InitrdInterface)
for details) which when exists results in `argv[0][0]` being set to `@`, and
otherwise doesn't. Something like this:
```c
#include <unistd.h>
int main(int argc, char *argv[]) {
...
if (access("/etc/initrd-release", F_OK) >= 0)
argv[0][0] = '@';
...
}
```
Why `@`? Why `argv[0][0]`? First of all, a technique like this is not without
precedent: traditionally Unix login shells set `argv[0][0]` to `-` to clarify
they are login shells. This logic is also very easy to implement. We have been
looking for other ways to mark processes for exclusion from the killing spree,
but could not find any that was equally simple to implement and quick to read
when traversing through `/proc/`. Also, as a side effect replacing the first
character of `argv[0]` with `@` also visually invalidates the path normally
stored in `argv[0]` (which usually starts with `/`) thus helping the
administrator to understand that your daemon is actually not originating from
the actual root file system, but from a path in a completely different
namespace (i.e. the initrd namespace). Other than that we just think that `@`
is a cool character which looks pretty in the ps output... 😎
Note that your code should only modify `argv[0][0]` and leave the comm name
(i.e. `/proc/self/comm`) of your process untouched.
## To which technologies does this apply?
These recommendations apply to those storage daemons which need to stay around
until after the storage they maintain is unmounted. If your storage daemon is
fine with being shut down before its storage device is unmounted you may ignore
the recommendations above.
This all applies to storage technology only, not to daemons with any other
(non-storage related) purposes.
## What else to keep in mind?
If your daemon implements the logic pointed out above it should work nicely
from initrd environments. In many cases it might be necessary to additionally
support storage daemons to be started from within the actual OS, for example
when complex storage setups are used for auxiliary file systems, i.e. not the
root file system, or created by the administrator during runtime. Here are a
few additional notes for supporting these setups:
* If your storage daemon is run from the main OS (i.e. not the initrd) it will
also be terminated when the OS shuts down (i.e. before we pass control back
to the initrd). Your daemon needs to handle this properly.
* It is not acceptable to spawn off background processes transparently from
user commands or udev rules. Whenever a process is forked off on Unix it
inherits a multitude of process attributes (ranging from the obvious to the
not-so-obvious such as security contexts or audit trails) from its parent
process. It is practically impossible to fully detach a service from the
process context of the spawning process. In particular, systemd tracks which
processes belong to a service or login sessions very closely, and by spawning
off your storage daemon from udev or an administrator command you thus make
it part of its service/login. Effectively this means that whenever udev is
shut down, your storage daemon is killed too, resp. whenever the login
session goes away your storage might be terminated as well. (Also note that
recent udev versions will automatically kill all long running background
processes forked off udev rules now.) So, in summary: double-forking off
processes from user commands or udev rules is **NOT** OK!
* To automatically spawn storage daemons from udev rules or administrator
commands, the recommended technology is socket-based activation as
implemented by systemd. Transparently for your client code connecting to the
socket of your storage daemon will result in the storage to be started. For
that it is simply necessary to inform systemd about the socket you'd like it
to listen on on behalf of your daemon and minimally modify the daemon to
receive the listening socket for its services from systemd instead of
creating it on its own. Such modifications can be minimal, and are easily
written in a way that does not negatively impact usability on non-systemd
systems. For more information on making use of socket activation in your
program consult this blog story: [Socket
Activation](http://0pointer.de/blog/projects/socket-activation.html)
* Consider having a look at the [initrd Interface of systemd](https://systemd.io/INITRD_INTERFACE/).

6
docs/SECURITY.md
View File

@ -1,7 +1,9 @@
---
title: Reporting of security vulnerabilities
title: Reporting of Security Vulnerabilities
category: Contributing
layout: default
---
# Reporting of security vulnerabilities
# Reporting of Security Vulnerabilities
If you discover a security vulnerability, we'd appreciate a non-public disclosure. The [issue tracker](https://github.com/systemd/systemd/issues) and [systemd-devel mailing list](https://lists.freedesktop.org/mailman/listinfo/systemd-devel) are fully public. If you need to reach systemd developers in a non-public way, report the issue to the [systemd-security@redhat.com](mailto:systemd-security@redhat.com) mailing list. The disclosure will be coordinated with distributions.

2
docs/TEMPORARY_DIRECTORIES.md
View File

@ -1,5 +1,7 @@
---
title: Using /tmp/ And /var/tmp/ Safely
category: Interfaces
layout: default
---
# Using `/tmp/` And `/var/tmp/` Safely

6
docs/TESTING_WITH_SANITIZERS.md
View File

@ -1,8 +1,10 @@
---
title: Testing systemd using sanitizers
title: Testing systemd Using Sanitizers
category: Contributing
layout: default
---
# Testing systemd using sanitizers
# Testing systemd Using Sanitizers
To catch the *nastier* kind of bugs, you can run your code with [Address Sanitizer](https://clang.llvm.org/docs/AddressSanitizer.html)
and [Undefined Behavior Sanitizer](https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html).

7
docs/TRANSIENT-SETTINGS.md
View File

@ -1,8 +1,10 @@
---
title: What settings are currently available for transient units?
title: What Settings Are Currently Available For Transient Units?
category: Interfaces
layout: default
---
# What settings are currently available for transient units?
# What Settings Are Currently Available For Transient Units?
Our intention is to make all settings that are available as unit file settings
also available for transient units, through the D-Bus API. At the moment,
@ -190,6 +192,7 @@ All execution-related settings are available for transient units.
✓ PrivateUsers=
✓ ProtectSystem=
✓ ProtectHome=
✓ ProtectClock=
✓ MountFlags=
✓ MountAPIVFS=
✓ Personality=

4
docs/TRANSLATORS.md
View File

@ -1,5 +1,7 @@
---
title: Notes for Translators
category: Contributing
layout: default
---
# Notes for Translators
@ -67,7 +69,7 @@ Once you're done, create a git commit for the update of the `po/*.po` file you
touched. Remember to undo the changes to the other `*.po` files (for instance,
using `git checkout -- po/` after you commit the changes you do want to keep.)
# Recompiling Translations
## Recompiling Translations
You can recompile the `*.po` files using the following command:

21
docs/UIDS-GIDS.md
View File

@ -1,8 +1,10 @@
---
title: Users, Groups, UIDs and GIDs on `systemd` Systems
title: Users, Groups, UIDs and GIDs on systemd Systems
category: Concepts
layout: default
---
# Users, Groups, UIDs and GIDs on `systemd` Systems
# Users, Groups, UIDs and GIDs on systemd Systems
Here's a summary of the requirements `systemd` (and Linux) make on UID/GID
assignments and their ranges.
@ -94,7 +96,15 @@ but downstreams are strongly advised against doing that.)
`systemd` defines a number of special UID ranges:
1. 61184…65519 → UIDs for dynamic users are allocated from this range (see the
1. 60001…60513 → UIDs for home directories managed by
[`systemd-homed.service(8)`](https://www.freedesktop.org/software/systemd/man/systemd-homed.service.html). UIDs
from this range are automatically assigned to any home directory discovered,
and persisted locally on first login. On different systems the same user
might get different UIDs assigned in case of conflict, though it is
attempted to make UID assignments stable, by deriving them from a hash of
the user name.
2. 61184…65519 → UIDs for dynamic users are allocated from this range (see the
`DynamicUser=` documentation in
[`systemd.exec(5)`](https://www.freedesktop.org/software/systemd/man/systemd.exec.html)). This
range has been chosen so that it is below the 16bit boundary (i.e. below
@ -109,7 +119,7 @@ but downstreams are strongly advised against doing that.)
user record resolving works correctly without those users being in
`/etc/passwd`.
2. 524288…1879048191 → UID range for `systemd-nspawn`'s automatic allocation of
3. 524288…1879048191 → UID range for `systemd-nspawn`'s automatic allocation of
per-container UID ranges. When the `--private-users=pick` switch is used (or
`-U`) then it will automatically find a so far unused 16bit subrange of this
range and assign it to the container. The range is picked so that the upper
@ -230,7 +240,8 @@ the artifacts the container manager persistently leaves in the system.
| 5 | `tty` group | `systemd` | `/etc/passwd` |
| 6…999 | System users | Distributions | `/etc/passwd` |
| 1000…60000 | Regular users | Distributions | `/etc/passwd` + LDAP/NIS/… |
| 60001…61183 | Unused | | |
| 60001…60513 | Human Users (homed) | `systemd` | `nss-systemd`
| 60514…61183 | Unused | | |
| 61184…65519 | Dynamic service users | `systemd` | `nss-systemd` |
| 65520…65533 | Unused | | |
| 65534 | `nobody` user | Linux | `/etc/passwd` + `nss-systemd` |

267
docs/USER_GROUP_API.md Normal file
View File

@ -0,0 +1,267 @@
---
title: User/Group Record Lookup API via Varlink
category: Interfaces
layout: default
---
# User/Group Record Lookup API via Varlink
JSON User/Group Records (as described in the [JSON User
Records](https://systemd.io/USER_RECORD) and [JSON Group
Records](https://systemd.io/GROUP_RECORD) documents) that are defined on the
local system may be queried with a [Varlink](https://varlink.org/) API. This
API takes both the role of what
[`getpwnam(3)`](http://man7.org/linux/man-pages/man3/getpwnam.3.html) and
related calls are for `struct passwd`, as well as the interfaces modules
implementing the [glibc Name Service Switch
(NSS)](https://www.gnu.org/software/libc/manual/html_node/Name-Service-Switch.html)
expose. Or in other words, it both allows applications to efficiently query
user/group records from local services, and allows local subsystems to provide
user/group records efficiently to local applications.
This simple API only exposes only three method calls, and requires only a small
subset of the Varlink functionality.
## Why Varlink?
The API described in this document is based on a simple subset of the
mechanisms described by [Varlink](https://varlink.org/). The choice of
preferring Varlink over D-Bus and other IPCs in this context was made for three
reasons:
1. User/Group record resolution should work during early boot and late shutdown
without special handling. This is very hard to do with D-Bus, as the broker
service for D-Bus generally runs as regular system daemon and is hence only
available at the latest boot stage.
2. The JSON user/group records are native JSON data, hence picking an IPC
system that natively operates with JSON data is natural and clean.
3. IPC systems such as D-Bus do not provide flow control and are thus unusable
for streaming data. They are useful to pass around short control messages,
but as soon as potentially many and large objects shall be transferred,
D-Bus is not suitable, as any such streaming of messages would be considered
flooding in D-Bus' logic, and thus possibly result in termination of
communication. Since the APIs defined in this document need to support
enumerating potentially large numbers of users and groups, D-Bus is simply
not an appropriate option.
## Concepts
Each subsystem that needs to define users and groups on the local system is
supposed to implement this API, and offer its interfaces on a Varlink
`AF_UNIX`/`SOCK_STREAM` file system socket bound into the
`/run/systemd/userdb/` directory. When a client wants to look up a user or
group record, it contacts all sockets bound in this directory in parallel, and
enqueues the same query to each. The first positive reply is then returned to
the application, or if all fail the last seen error is returned
instead. (Alternatively a special Varlink service is available,
`io.systemd.Multiplexer` which acts as frontend and will do the parallel
queries on behalf of the client, drastically simplifying client
development. This service is not available during earliest boot and final
shutdown phases.)
Unlike with glibc NSS there's no order or programmatic expression language
defined in which queries are issued to the various services. Instead, all
queries are always enqueued in parallel to all defined services, in order to
make look-ups efficient, and the simple rule of "first successful lookup wins"
is unconditionally followed for user and group look-ups (though not for
membership lookups, see below).
This simple scheme only works safely as long as every service providing
user/group records carefully makes sure not to answer with conflicting
records. This API does not define any mechanisms for dealing with user/group
name/ID collisions during look-up nor during record registration. It assumes
the various subsystems that want to offer user and group records to the rest of
the system have made sufficiently sure in advance that their definitions do not
collide with those of other services. Clients are not expected to merge
multiple definitions for the same user or group, and will also not be able to
detect conflicts and suppress such conflicting records.
It is recommended to name the sockets in the directory in reverse domain name
notation, but this is neither required nor enforced.
## Well-Known Services
Any subsystem that wants to provide user/group records can do so, simply by
binding a socket in the aforementioned directory. By default two
services are listening there, that have special relevance:
1. `io.systemd.NameServiceSwitch` → This service makes the classic UNIX/glibc
NSS user/group records available as JSON User/Group records. Any such
records are automatically converted as needed, and possibly augmented with
information from the shadow databases.
2. `io.systemd.Multiplexer` → This service multiplexes client queries to all
other running services. It's supposed to simplify client development: in
order to look up or enumerate user/group records it's sufficient to talk to
one service instead of all of them in parallel. Note that it is not availabe
during earliest boot and final shutdown phases, hence for programs running
in that context it is preferable to implement the parallel lookup
themselves.
Both these services are implemented by the same daemon
`systemd-userdbd.service`.
Note that these services currently implement a subset of Varlink only. For
example, introspection is not available, and the resolver logic is not used.
## Other Services
The `systemd` project provides two other services implementing this
interface. Specifically:
1. `io.systemd.DynamicUser` → This service is implemented by the service
manager itself, and provides records for the users and groups synthesized
via `DynamicUser=` in unit files.
2. `io.systemd.Home` → This service is implemented by `systemd-homed.service`
and provides records for the users and groups defined by the home
directories it manages.
Other projects are invited to implement these services too. For example it
would make sense for LDAP/ActiveDirectory projects to implement these
interfaces, which would provide them a way to do per-user resource management
enforced by systemd and defined directly in LDAP directories.
## Compatibility with NSS
Two-way compatibility with classic UNIX/glibc NSS user/group records is
provided. When using the Varlink API, lookups into databases provided only via
NSS (and not natively via Varlink) are handled by the
`io.systemd.NameServiceSwitch` service (see above). When using the NSS API
(i.e. `getpwnam()` and friends) the `nss-systemd` module will automatically
synthesize NSS records for users/groups natively defined via a Varlink
API. Special care is taken to avoid recursion between these two compatibility
mechanisms.
Subsystems that shall provide user/group records to the system may choose
between offering them via an NSS module or via a this Varlink API, either way
all records are accessible via both APIs, due to the bidirectional
forwarding. It is also possible to provide the same records via both APIs
directly, but in that case the compatibility logic must be turned off. There
are mechanisms in place for this, please contact the systemd project for
details, as these are currently not documented.
## Caching of User Records
This API defines no concepts for caching records. If caching is desired it
should be implemented in the subsystems that provide the user records, not in
the clients consuming them.
## Method Calls
```
interface io.systemd.UserDatabase
method GetUserRecord(
uid : ?int,
userName : ?string,
service : string
) -> (
record : object,
incomplete : boolean
)
method GetGroupRecord(
gid : ?int,
groupName : ?string,
service : string
) -> (
record : object,
incomplete : boolean
)
method GetMemberships(
userName : ?string,
groupName : ?string,
service : string
) -> (
userName : string,
groupName : string
)
error NoRecordFound()
error BadService()
error ServiceNotAvailable()
error ConflictingRecordFound()
```
The `GetUserRecord` method looks up or enumerates a user record. If the `uid`
parameter is set it specifies the numeric UNIX UID to search for. If the
`userName` parameter is set it specifies the name of the user to search
for. Typically, only one of the two parameters are set, depending whether a
look-up by UID or by name is desired. However, clients may also specify both
parameters, in which case a record matching both will be returned, and if only
one exists that matches one of the two parameters but not the other an error of
`ConflictingRecordFound` is returned. If neither of the two parameters are set
the whole user database is enumerated. In this case the method call needs to be
made with `more` set, so that multiple method call replies may be generated as
effect, each carrying one user record.
The `service` parameter is mandatory and should be set to the service name
being talked to (i.e. to the same name as the `AF_UNIX` socket path, with the
`/run/systemd/userdb/` prefix removed). This is useful to allow implementation
of multiple services on the same socket (which is used by
`systemd-userdbd.service`).
The method call returns one or more user records, depending which type of query is
used (see above). The record is returned in the `record` field. The
`incomplete` field indicates whether the record is complete. Services providing
user record lookup should only pass the `privileged` section of user records to
clients that either match the user the record is about or to sufficiently
privileged clients, for all others the section must be removed so that no
sensitive data is leaked this way. The `incomplete` parameter should indicate
whether the record has been modified like this or not (i.e. it is `true` if a
`privileged` section existed in the user record and was removed, and `false` if
no `privileged` section existed or one existed but hasn't been removed).
If no user record matching the specified UID or name is known the error
`NoRecordFound` is returned (this is also returned if neither UID nor name are
specified, and hence enumeration requested but the subsystem currently has no
users defined).
If a method call with an incorrectly set `service` field is received
(i.e. either not set at all, or not to the service's own name) a `BadService`
error is generated. Finally, `ServiceNotAvailable` should be returned when the
backing subsystem is not operational for some reason and hence no information
about existence or non-existence of a record can be returned nor any user
record at all. (The `service` field is defined in order to allow implementation
of daemons that provide multiple distinct user/group services over the same
`AF_UNIX` socket: in order to correctly determine which service a client wants
to talk to the client needs to provide the name in each request.)
The `GetGroupRecord` method call works analogously but for groups.
The `GetMemberships` method call may be used to inquire about group
memberships. The `userName` and `groupName` arguments take what the name
suggests. If one of the two is specified all matching memberships are returned,
if neither is specified all known memberships of any user and any group are
returned. The return value is a pair of user name and group name, where the
user is a member of the group. If both arguments are specified the specified
membership will be tested for, but no others, and the pair is returned if it is
defined. Unless both arguments are specified the method call needs to be made
with `more` set, so that multiple replies can be returned (since typically
there are are multiple members per group and also multiple groups a user is
member of). As with `GetUserRecord` and `GetGroupRecord` the `service`
parameter needs to contain the name of the service being talked to, in order to
allow implementation of multiple service within the same IPC socket. In case no
matching membership is known `NoRecordFound` is returned. The other two errors
are also generated in the same cases as for `GetUserRecord` and
`GetGroupRecord`.
Unlike with `GetUserRecord` and `GetGroupRecord` the lists of memberships
returned by services are always combined. Thus unlike the other two calls a
membership lookup query has to wait for the last simultaneous query to complete
before the complete list is acquired.
Note that only the `GetMemberships` call is authoritative about memberships of
users in groups. i.e. it should not be considered sufficient to check the
`memberOf` field of user records and the `members` field of group records to
acquire the full list of memberships. The full list can only bet determined by
`GetMemberships`, and as mentioned requires merging of these lists of all local
services. Result of this is that it can be one service that defines a user A,
and another service that defines a group B, and a third service that declares
that A is a member of B.
And that's really all there is to it.

1023
docs/USER_RECORD.md Normal file
View File

File diff suppressed because it is too large Load Diff

10
docs/_config.yml
View File

@ -1 +1,9 @@
theme: jekyll-theme-primer
# Site settings
title: systemd
baseurl: "" # the subpath of your site, e.g. /blog/
url: "http://systemd.io" # the base hostname & protocol for your site
permalink: /:title/
# Build settings
markdown: kramdown

10
docs/_data/extra_pages.json Normal file
View File

@ -0,0 +1,10 @@
[
{ "category": "Project", "title": "Brand", "url": "https://brand.systemd.io/" },
{ "category": "Project", "title": "Releases", "url": "https://github.com/systemd/systemd/releases" },
{ "category": "Project", "title": "GitHub Project Page", "url": "https://github.com/systemd/systemd" },
{ "category": "Project", "title": "Issues", "url": "https://github.com/systemd/systemd/issues" },
{ "category": "Project", "title": "Pull Requests", "url": "https://github.com/systemd/systemd/pulls" },
{ "category": "Project", "title": "Mailing List", "url": "https://lists.freedesktop.org/mailman/listinfo/systemd-devel" },
{ "category": "Manual Pages", "title": "Index", "url": "https://www.freedesktop.org/software/systemd/man/" },
{ "category": "Manual Pages", "title": "Directives", "url": "https://www.freedesktop.org/software/systemd/man/systemd.directives.html" }
]

5
docs/_includes/footer.html Normal file
View File

@ -0,0 +1,5 @@
<footer class="site-footer">
<p>&copy; systemd, 2020</p>
<p><a href="https://github.com/systemd/systemd">Website source</a></p>
</footer>

16
docs/_includes/head.html Normal file
View File

@ -0,0 +1,16 @@
<head>
<meta charset="utf-8">
<meta http-equiv="X-UA-Compatible" content="IE=edge">
<meta name="viewport" content="width=device-width, initial-scale=1">
<meta name="theme-color" content="#0021D8">
<title>{% if page.title %}{{ page.title }}{% else %}{{ site.title }}{% endif %}</title>
<link rel="canonical" href="{{ page.url | replace:'index.html','' | prepend: site.baseurl | prepend: site.url }}">
<link rel="alternate" type="application/rss+xml" title="{{ site.title }}" href="{{ "/feed.xml" | prepend: site.baseurl | prepend: site.url }}" />
<link rel="stylesheet" href="{{ "/style.css" | prepend: site.baseurl }}">
<link rel="icon" type="image/png" href="/favicon.png" />
<link rel="icon" sizes="144x144" href="apple-touch-icon.png">
</head>

11
docs/_includes/header.html Normal file
View File

@ -0,0 +1,11 @@
<header class="site-header">
<div class="wrapper">
<a class="page-logo" href="{{ site.baseurl }}/">
<img src="/assets/page-logo.svg" alt="systemd">
</a>
</div>
</header>

18
docs/_layouts/default.html Normal file
View File

@ -0,0 +1,18 @@
<!DOCTYPE html>
<html>
{% include head.html %}
<body>
{% include header.html %}
<div class="container">
{{ content }}
</div>
{% include footer.html %}
</body>
</html>

6
docs/assets/page-logo.svg Normal file
View File

@ -0,0 +1,6 @@
<svg xmlns="http://www.w3.org/2000/svg" width="202" height="26">
<path overflow="visible" font-weight="400" d="M0 0v26h10v-4H4V4h6V0zm76 0v4h6v18h-6v4h10V0z" style="line-height:normal;font-variant-ligatures:normal;font-variant-position:normal;font-variant-caps:normal;font-variant-numeric:normal;font-variant-alternates:normal;font-feature-settings:normal;text-indent:0;text-align:start;text-decoration-line:none;text-decoration-style:solid;text-decoration-color:#000;text-transform:none;text-orientation:mixed;white-space:normal;shape-padding:0;isolation:auto;mix-blend-mode:normal;solid-color:#000;solid-opacity:1" color="#000" font-family="sans-serif" fill="#201a26"/>
<path word-spacing="0" letter-spacing=".2" font-size="12" font-weight="700" style="line-height:1.25;-inkscape-font-specification:'Heebo Bold';text-align:start" d="M113.498 14.926q-4.5-.96-4.5-3.878 0-1.079.609-1.981.621-.902 1.781-1.441 1.16-.54 2.707-.54 1.63 0 2.848.528 1.219.516 1.875 1.453.656.926.656 2.121h-3.539q0-.762-.457-1.183-.457-.434-1.394-.434-.774 0-1.243.363-.457.364-.457.938 0 .55.516.89.527.34 1.781.575 1.5.28 2.543.738 1.043.445 1.653 1.242.62.797.62 2.027 0 1.114-.667 2.004-.657.88-1.887 1.383-1.219.504-2.836.504-1.711 0-2.965-.621-1.242-.633-1.898-1.617-.645-.985-.645-2.051h3.34q.036.914.656 1.36.621.433 1.594.433.902 0 1.383-.34.492-.351.492-.937 0-.364-.223-.61-.21-.258-.773-.48-.55-.223-1.57-.446zm19.384-7.606l-5.086 14.58q-.293.831-.726 1.523-.434.703-1.266 1.195-.832.504-2.098.504-.457 0-.75-.048-.281-.046-.785-.176v-2.672q.176.02.527.02.95 0 1.418-.293.47-.293.715-.961l.352-.926-4.43-12.738h3.797l2.262 7.687 2.285-7.687zm5.884 7.606q-4.5-.96-4.5-3.878 0-1.079.61-1.981.62-.902 1.781-1.441 1.16-.54 2.707-.54 1.629 0 2.848.528 1.218.516 1.875 1.453.656.926.656 2.121h-3.539q0-.762-.457-1.183-.457-.434-1.395-.434-.773 0-1.242.363-.457.364-.457.938 0 .55.516.89.527.34 1.781.575 1.5.28 2.543.738 1.043.445 1.652 1.242.621.797.621 2.027 0 1.114-.668 2.004-.656.88-1.886 1.383-1.219.504-2.836.504-1.711 0-2.965-.621-1.242-.633-1.899-1.617-.644-.985-.644-2.051h3.34q.036.914.656 1.36.621.433 1.594.433.902 0 1.383-.34.492-.351.492-.937 0-.364-.223-.61-.21-.258-.773-.48-.551-.223-1.57-.446zm13.983 2.403q.574 0 .984-.082v2.66q-.914.328-2.086.328-3.727 0-3.727-3.797V9.899h-1.793V7.321h1.793v-3.14h3.54v3.14h2.132v2.578h-2.133v6.129q0 .75.293 1.031.293.27.997.27zm14.228-2.519h-8.016q.2 1.183.985 1.886.785.691 2.015.691.914 0 1.688-.34.785-.351 1.336-1.042l1.699 1.957q-.668.96-1.957 1.617-1.278.656-3 .656-1.946 0-3.387-.82-1.43-.82-2.203-2.227-.762-1.406-.762-3.105v-.446q0-1.898.715-3.386.715-1.489 2.063-2.32 1.347-.844 3.187-.844 1.793 0 3.059.761 1.265.762 1.922 2.168.656 1.395.656 3.293zm-3.469-2.65q-.024-1.03-.574-1.628-.54-.598-1.617-.598-1.008 0-1.582.668-.563.668-.739 1.84h4.512zm19.923-5.073q1.934 0 2.989 1.148 1.054 1.148 1.054 3.727v8.039h-3.539V11.95q0-.797-.21-1.23-.212-.446-.61-.61-.387-.164-.984-.164-.715 0-1.219.352-.504.34-.797.972.02.082.02.27V20h-3.54v-8.015q0-.797-.21-1.242-.211-.445-.61-.621-.386-.176-.996-.176-.68 0-1.183.304-.492.293-.797.844V20h-3.539V7.32h3.316l.118 1.419q.633-.797 1.547-1.22.926-.433 2.086-.433 1.172 0 2.016.48.855.47 1.312 1.442.633-.926 1.582-1.418.961-.504 2.203-.504zM201.398 2v18h-3.187l-.176-1.359q-1.243 1.594-3.212 1.594-1.535 0-2.66-.82-1.113-.832-1.699-2.285-.574-1.454-.574-3.317v-.246q0-1.934.574-3.398.586-1.465 1.7-2.274 1.124-.808 2.683-.808 1.805 0 3.012 1.37V2.001zm-5.672 15.376q1.488 0 2.133-1.266v-4.898q-.61-1.266-2.11-1.266-1.207 0-1.77.984-.55.985-.55 2.637v.246q0 1.629.54 2.602.55.96 1.757.96z" font-family="Heebo" fill="#201a26"/>
<path d="M45 13L63 3v20z" fill="#30d475"/>
<circle cx="30.001" cy="13.001" r="9" fill="#30d475"/>
</svg>
Side by Side

After

Width:  |  Height:  |  Size: 3.7 KiB

BIN
docs/favicon.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 394 B

10
docs/favicon.svg Normal file
View File

@ -0,0 +1,10 @@
<svg xmlns="http://www.w3.org/2000/svg" width="16" height="16">
<g transform="translate(380 -506.52)">
<rect ry="16.875" rx="16.875" y="2409.281" x="4128.568" height="90" width="90" fill="#201a26" transform="matrix(.17778 0 0 .17778 -1113.968 78.203)" stroke-width="5.625"/>
<g fill="none" stroke="#fff" stroke-width="2">
<path d="M-377 513.02h-1.5v3h1.5M-367 513.02h1.5v3h-1.5" stroke-width="1"/>
</g>
<path d="M-368 516.77v-4.5l-3 1.25-1 1 1 1z" fill="#30d475"/>
<circle cx="-374.25" cy="514.52" r="1.75" fill="#30d475"/>
</g>
</svg>
Side by Side

After

Width:  |  Height:  |  Size: 596 B

BIN
docs/fonts/heebo-bold.woff Normal file
View File

Binary file not shown.

BIN
docs/fonts/heebo-regular.woff Normal file
View File

Binary file not shown.

94
docs/index.md
View File

@ -1,11 +1,95 @@
---
title: systemd Documentation
layout: default
---
# systemd Documentation
systemd is a suite of basic building blocks for a Linux system. It provides a system and service manager that runs as PID 1 and starts the rest of the system.
systemd provides aggressive parallelization capabilities, uses socket and D-Bus activation for starting services, offers on-demand starting of daemons, keeps track of processes using Linux control groups, maintains mount and automount points, and implements an elaborate transactional dependency-based service control logic. systemd supports SysV and LSB init scripts and works as a replacement for sysvinit.
{% for p in site.pages %}
{% if p.url != page.url and p.title %}
* [{{ p.title }}]({{ p.url | relative_url }})
Other parts include a logging daemon, utilities to control basic system configuration like the hostname, date, locale, maintain a list of logged-in users and running containers and virtual machines, system accounts, runtime directories and settings, and daemons to manage simple network configuration, network time synchronization, log forwarding, and name resolution.
---
{% assign by_category = site.pages | group_by:"category" %}
{% assign extra_pages = site.data.extra_pages | group_by:"category" %}
{% assign merged = by_category | concat: extra_pages | sort:"name" %}
{% for pair in merged %}
{% if pair.name != "" %}
## {{ pair.name }}
{% assign sorted = pair.items | sort:"title" %}{% for page in sorted %}
* [{{ page.title }}]({{ page.url | relative_url }}){% endfor %}
{% endif %}
{% endfor %}
## See also
* [Introductory blog story](http://0pointer.de/blog/projects/systemd.html)
* [Three](http://0pointer.de/blog/projects/systemd-update.html) [status](http://0pointer.de/blog/projects/systemd-update-2.html) [updates](http://0pointer.de/blog/projects/systemd-update-3.html)
* The [Wikipedia article](https://en.wikipedia.org/wiki/systemd)
---
<pre style="color:white; background-color:black; font-size:smaller; padding:6pt 8pt">
Welcome to <span style="color:blue">Fedora 20 (Heisenbug)</span>!
[ <span style="color:green">OK</span> ] Reached target Remote File Systems.
[ <span style="color:green">OK</span> ] Listening on Delayed Shutdown Socket.
[ <span style="color:green">OK</span> ] Listening on /dev/initctl Compatibility Named Pipe.
[ <span style="color:green">OK</span> ] Reached target Paths.
[ <span style="color:green">OK</span> ] Reached target Encrypted Volumes.
[ <span style="color:green">OK</span> ] Listening on Journal Socket.
Mounting Huge Pages File System...
Mounting POSIX Message Queue File System...
Mounting Debug File System...
Starting Journal Service...
[ <span style="color:green">OK</span> ] Started Journal Service.
Mounting Configuration File System...
Mounting FUSE Control File System...
[ <span style="color:green">OK</span> ] Created slice Root Slice.
[ <span style="color:green">OK</span> ] Created slice User and Session Slice.
[ <span style="color:green">OK</span> ] Created slice System Slice.
[ <span style="color:green">OK</span> ] Reached target Slices.
[ <span style="color:green">OK</span> ] Reached target Swap.
Mounting Temporary Directory...
[ <span style="color:green">OK</span> ] Reached target Local File Systems (Pre).
Starting Load Random Seed...
Starting Load/Save Random Seed...
[ <span style="color:green">OK</span> ] Mounted Huge Pages File System.
[ <span style="color:green">OK</span> ] Mounted POSIX Message Queue File System.
[ <span style="color:green">OK</span> ] Mounted Debug File System.
[ <span style="color:green">OK</span> ] Mounted Configuration File System.
[ <span style="color:green">OK</span> ] Mounted FUSE Control File System.
[ <span style="color:green">OK</span> ] Mounted Temporary Directory.
[ <span style="color:green">OK</span> ] Started Load Random Seed.
[ <span style="color:green">OK</span> ] Started Load/Save Random Seed.
[ <span style="color:green">OK</span> ] Reached target Local File Systems.
Starting Recreate Volatile Files and Directories...
Starting Trigger Flushing of Journal to Persistent Storage...
[ <span style="color:green">OK</span> ] Started Recreate Volatile Files and Directories.
Starting Update UTMP about System Reboot/Shutdown...
[ <span style="color:green">OK</span> ] Started Trigger Flushing of Journal to Persistent Storage.
[ <span style="color:green">OK</span> ] Started Update UTMP about System Reboot/Shutdown.
[ <span style="color:green">OK</span> ] Reached target System Initialization.
[ <span style="color:green">OK</span> ] Reached target Timers.
[ <span style="color:green">OK</span> ] Listening on D-Bus System Message Bus Socket.
[ <span style="color:green">OK</span> ] Reached target Sockets.
[ <span style="color:green">OK</span> ] Reached target Basic System.
Starting Permit User Sessions...
Starting D-Bus System Message Bus...
[ <span style="color:green">OK</span> ] Started D-Bus System Message Bus.
Starting Login Service...
Starting Cleanup of Temporary Directories...
[ <span style="color:green">OK</span> ] Started Permit User Sessions.
[ <span style="color:green">OK</span> ] Started Cleanup of Temporary Directories.
Starting Console Getty...
[ <span style="color:green">OK</span> ] Started Console Getty.
[ <span style="color:green">OK</span> ] Reached target Login Prompts.
[ <span style="color:green">OK</span> ] Started Login Service.
[ <span style="color:green">OK</span> ] Reached target Multi-User System.
Fedora release 20 (Heisenbug)
Kernel 3.9.2-200.fc18.x86_64 on an x86_64 (console)
fedora login:
</pre>

347
docs/style.css Normal file
View File

@ -0,0 +1,347 @@
@font-face {
font-family: 'Heebo';
src: url('fonts/heebo-regular.woff');
font-weight: 400;
}
@font-face {
font-family: 'Heebo';
src: url('fonts/heebo-bold.woff');
font-weight: 600;
}
/* Typography */
* {
-moz-box-sizing: border-box;
-webkit-box-sizing: border-box;
box-sizing: border-box;
}
html, body {
margin: 0;
padding: 0;
font-size: 16px;
font-family: "Heebo", sans-serif;
font-weight: 400;
line-height: 1.6;
}
body {
color: #241f31;
background-color: #f6f5f4;
}
h1, h2, h3, h4, h5, h6 {
margin: 1rem 0 10px;
font-weight: 600;
line-height: 1.25;
}
h1 {
text-align: center;
font-size: 30px;
font-weight: 100;
font-style: normal;
margin-bottom: 2rem;
}
@media screen and (min-width: 650px) {
h1 {
margin-left: 10%;
margin-right: 10%;
font-size: 38px;
}
}
h2 {
margin-top: 3rem;
font-size: 1.2rem;
}
a {
font-weight: 600;
text-decoration: none;
color: #26b763;
cursor: pointer;
}
a:hover {
text-decoration: underline;
}
b {
font-weight: 600;
}
small {
color: #777;
}
hr {
margin: 3rem auto 4rem;
width: 40%;
opacity: 40%;
}
/* Layout */
.container {
width: 80%;
margin-left: auto;
margin-right: auto;
max-width: 720px;
}
/* Singletons */
.page-logo {
display: block;
padding: 5rem 0 3rem;
}
.page-logo > img {
display: block;
margin: 0 auto;
}
.brand-white {
background-color: #fff;
}
.brand-green {
background-color: #30D475;
}
.brand-black {
background-color: #201A26;
color: white;
}
.page-link::after {
content: " ➜";
}
/* Footer */
footer {
text-align: center;
padding: 3em 0 3em;
font-size: 1em;
margin-top: 4rem;
}
/* Github Code Highlighting */
.highlight table td { padding: 5px; }
.highlight table pre { margin: 0; }
.highlight .cm {
color: #999988;
font-style: italic;
}
.highlight .cp {
color: #999999;
font-weight: bold;
}
.highlight .c1 {
color: #999988;
font-style: italic;
}
.highlight .cs {
color: #999999;
font-weight: bold;
font-style: italic;
}
.highlight .c, .highlight .ch, .highlight .cd, .highlight .cpf {
color: #999988;
font-style: italic;
}
.highlight .err {
color: #a61717;
background-color: #e3d2d2;
}
.highlight .gd {
color: #000000;
background-color: #ffdddd;
}
.highlight .ge {
color: #000000;
font-style: italic;
}
.highlight .gr {
color: #aa0000;
}
.highlight .gh {
color: #999999;
}
.highlight .gi {
color: #000000;
background-color: #ddffdd;
}
.highlight .go {
color: #888888;
}
.highlight .gp {
color: #555555;
}
.highlight .gs {
font-weight: bold;
}
.highlight .gu {
color: #aaaaaa;
}
.highlight .gt {
color: #aa0000;
}
.highlight .kc {
color: #000000;
font-weight: bold;
}
.highlight .kd {
color: #000000;
font-weight: bold;
}
.highlight .kn {
color: #000000;
font-weight: bold;
}
.highlight .kp {
color: #000000;
font-weight: bold;
}
.highlight .kr {
color: #000000;
font-weight: bold;
}
.highlight .kt {
color: #445588;
font-weight: bold;
}
.highlight .k, .highlight .kv {
color: #000000;
font-weight: bold;
}
.highlight .mf {
color: #009999;
}
.highlight .mh {
color: #009999;
}
.highlight .il {
color: #009999;
}
.highlight .mi {
color: #009999;
}
.highlight .mo {
color: #009999;
}
.highlight .m, .highlight .mb, .highlight .mx {
color: #009999;
}
.highlight .sb {
color: #d14;
}
.highlight .sc {
color: #d14;
}
.highlight .sd {
color: #d14;
}
.highlight .s2 {
color: #d14;
}
.highlight .se {
color: #d14;
}
.highlight .sh {
color: #d14;
}
.highlight .si {
color: #d14;
}
.highlight .sx {
color: #d14;
}
.highlight .sr {
color: #009926;
}
.highlight .s1 {
color: #d14;
}
.highlight .ss {
color: #990073;
}
.highlight .s, .highlight .sa, .highlight .dl {
color: #d14;
}
.highlight .na {
color: #008080;
}
.highlight .bp {
color: #999999;
}
.highlight .nb {
color: #0086B3;
}
.highlight .nc {
color: #445588;
font-weight: bold;
}
.highlight .no {
color: #008080;
}
.highlight .nd {
color: #3c5d5d;
font-weight: bold;
}
.highlight .ni {
color: #800080;
}
.highlight .ne {
color: #990000;
font-weight: bold;
}
.highlight .nf, .highlight .fm {
color: #990000;
font-weight: bold;
}
.highlight .nl {
color: #990000;
font-weight: bold;
}
.highlight .nn {
color: #555555;
}
.highlight .nt {
color: #000080;
}
.highlight .vc {
color: #008080;
}
.highlight .vg {
color: #008080;
}
.highlight .vi {
color: #008080;
}
.highlight .nv, .highlight .vm {
color: #008080;
}
.highlight .ow {
color: #000000;
font-weight: bold;
}
.highlight .o {
color: #000000;
font-weight: bold;
}
.highlight .w {
color: #bbbbbb;
}
.highlight {
background-color: #f8f8f8;
}
/* Code Blocks */
.highlighter-rouge {
padding: 2px 1rem;
border-radius: 5px;
background-color: white;
overflow: auto;
}
.highlighter-rouge * {
background-color: white;
}
/* Inline Code */
code.highlighter-rouge {
padding: 2px 6px;
background-color: rgba(0,0,0, 0.07);
}

2
factory/etc/nsswitch.conf
View File

@ -1,7 +1,7 @@
# This file is part of systemd.
passwd: compat mymachines systemd
group: compat mymachines systemd
group: compat [SUCCESS=merge] mymachines [SUCCESS=merge] systemd
shadow: compat
hosts: files mymachines resolve [!UNAVAIL=return] dns myhostname

26
factory/etc/pam.d/system-auth
View File

@ -3,17 +3,21 @@
# You really want to adjust this to your local distribution. If you use this
# unmodified you are not building systems safely and securely.
auth sufficient pam_unix.so nullok try_first_pass
auth required pam_deny.so
auth sufficient pam_unix.so
-auth sufficient pam_systemd_home.so
auth required pam_deny.so
account required pam_nologin.so
account sufficient pam_unix.so
account required pam_permit.so
account required pam_nologin.so
-account sufficient pam_systemd_home.so
account sufficient pam_unix.so
account required pam_permit.so
password sufficient pam_unix.so nullok sha512 shadow try_first_pass try_authtok
password required pam_deny.so
-password sufficient pam_systemd_home.so
password sufficient pam_unix.so sha512 shadow try_first_pass try_authtok
password required pam_deny.so
-session optional pam_keyinit.so revoke
-session optional pam_loginuid.so
-session optional pam_systemd.so
session sufficient pam_unix.so
-session optional pam_keyinit.so revoke
-session optional pam_loginuid.so
-session optional pam_systemd_home.so
-session optional pam_systemd.so
session required pam_unix.so

1
fuzzbuzz.yaml
View File

@ -5,6 +5,7 @@ setup:
- sudo apt-get update -y
- sudo apt-get build-dep -y systemd
- sudo apt-get install -y python3-pip
- sudo apt-get install -y libfdisk-dev libp11-kit-dev libssl-dev libpwquality-dev
- pip3 install meson ninja
- export PATH="$HOME/.local/bin/:$PATH"
- CC=$FUZZ_CC CXX=$FUZZ_CXX meson -Dfuzzbuzz=true -Dfuzzbuzz-engine-dir=$(dirname "$FUZZ_ENGINE") -Dfuzzbuzz-engine=$(cut -d. -f1 <(basename "$FUZZ_ENGINE")) -Db_lundef=false ./build

719
hwdb.d/20-OUI.hwdb
View File

File diff suppressed because it is too large Load Diff

3
hwdb.d/20-acpi-vendor.hwdb
View File

@ -216,6 +216,9 @@ acpi:OVTI*:
acpi:PEGA*:
ID_VENDOR_FROM_DATABASE=Pegatron Corporation
acpi:PHYT*:
ID_VENDOR_FROM_DATABASE=Phytium Technology Co. Ltd.
acpi:QCOM*:
ID_VENDOR_FROM_DATABASE=Qualcomm Inc

98
hwdb.d/20-acpi-vendor.hwdb.patch
View File

@ -1,5 +1,5 @@
--- 20-acpi-vendor.hwdb.base 2020-02-04 18:26:50.552863816 +0100
+++ 20-acpi-vendor.hwdb 2020-02-04 18:26:50.569863967 +0100
--- 20-acpi-vendor.hwdb.base 2020-03-06 12:40:11.417307950 +0100
+++ 20-acpi-vendor.hwdb 2020-03-06 12:40:11.433308177 +0100
@@ -3,6 +3,8 @@
# Data imported from:
# https://uefi.org/uefi-pnp-export
@ -19,7 +19,7 @@
acpi:AMDI*:
ID_VENDOR_FROM_DATABASE=AMD
@@ -283,6 +282,9 @@
@@ -286,6 +285,9 @@
acpi:AAA*:
ID_VENDOR_FROM_DATABASE=Avolites Ltd
@ -29,7 +29,7 @@
acpi:AAE*:
ID_VENDOR_FROM_DATABASE=Anatek Electronics Inc.
@@ -310,6 +312,9 @@
@@ -313,6 +315,9 @@
acpi:ABO*:
ID_VENDOR_FROM_DATABASE=D-Link Systems Inc
@ -39,7 +39,7 @@
acpi:ABS*:
ID_VENDOR_FROM_DATABASE=Abaco Systems, Inc.
@@ -355,7 +360,7 @@
@@ -358,7 +363,7 @@
acpi:ACO*:
ID_VENDOR_FROM_DATABASE=Allion Computer Inc.
@ -48,7 +48,7 @@
ID_VENDOR_FROM_DATABASE=Aspen Tech Inc
acpi:ACR*:
@@ -628,6 +633,9 @@
@@ -631,6 +636,9 @@
acpi:AMT*:
ID_VENDOR_FROM_DATABASE=AMT International Industry
@ -58,7 +58,7 @@
acpi:AMX*:
ID_VENDOR_FROM_DATABASE=AMX LLC
@@ -676,6 +684,9 @@
@@ -679,6 +687,9 @@
acpi:AOA*:
ID_VENDOR_FROM_DATABASE=AOpen Inc.
@ -68,7 +68,7 @@
acpi:AOE*:
ID_VENDOR_FROM_DATABASE=Advanced Optics Electronics, Inc.
@@ -685,6 +696,9 @@
@@ -688,6 +699,9 @@
acpi:AOT*:
ID_VENDOR_FROM_DATABASE=Alcatel
@ -78,7 +78,7 @@
acpi:APC*:
ID_VENDOR_FROM_DATABASE=American Power Conversion
@@ -860,7 +874,7 @@
@@ -863,7 +877,7 @@
ID_VENDOR_FROM_DATABASE=Alps Electric Inc
acpi:AUO*:
@ -87,7 +87,7 @@
acpi:AUR*:
ID_VENDOR_FROM_DATABASE=Aureal Semiconductor
@@ -940,6 +954,9 @@
@@ -943,6 +957,9 @@
acpi:AXE*:
ID_VENDOR_FROM_DATABASE=Axell Corporation
@ -97,7 +97,7 @@
acpi:AXI*:
ID_VENDOR_FROM_DATABASE=American Magnetics
@@ -1090,6 +1107,9 @@
@@ -1093,6 +1110,9 @@
acpi:BML*:
ID_VENDOR_FROM_DATABASE=BIOMED Lab
@ -107,7 +107,7 @@
acpi:BMS*:
ID_VENDOR_FROM_DATABASE=BIOMEDISYS
@@ -1102,6 +1122,9 @@
@@ -1105,6 +1125,9 @@
acpi:BNO*:
ID_VENDOR_FROM_DATABASE=Bang & Olufsen
@ -117,7 +117,7 @@
acpi:BNS*:
ID_VENDOR_FROM_DATABASE=Boulder Nonlinear Systems
@@ -1342,6 +1365,9 @@
@@ -1345,6 +1368,9 @@
acpi:CHA*:
ID_VENDOR_FROM_DATABASE=Chase Research PLC
@ -127,7 +127,7 @@
acpi:CHD*:
ID_VENDOR_FROM_DATABASE=ChangHong Electric Co.,Ltd
@@ -1495,6 +1521,9 @@
@@ -1498,6 +1524,9 @@
acpi:COD*:
ID_VENDOR_FROM_DATABASE=CODAN Pty. Ltd.
@ -137,7 +137,7 @@
acpi:COI*:
ID_VENDOR_FROM_DATABASE=Codec Inc.
@@ -1901,7 +1930,7 @@
@@ -1904,7 +1933,7 @@
ID_VENDOR_FROM_DATABASE=Dragon Information Technology
acpi:DJE*:
@ -146,7 +146,7 @@
acpi:DJP*:
ID_VENDOR_FROM_DATABASE=Maygay Machines, Ltd
@@ -2233,6 +2262,9 @@
@@ -2236,6 +2265,9 @@
acpi:EIN*:
ID_VENDOR_FROM_DATABASE=Elegant Invention
@ -156,7 +156,7 @@
acpi:EKA*:
ID_VENDOR_FROM_DATABASE=MagTek Inc.
@@ -2494,6 +2526,9 @@
@@ -2497,6 +2529,9 @@
acpi:FCG*:
ID_VENDOR_FROM_DATABASE=First International Computer Ltd
@ -166,7 +166,7 @@
acpi:FCS*:
ID_VENDOR_FROM_DATABASE=Focus Enhancements, Inc.
@@ -2867,7 +2902,7 @@
@@ -2870,7 +2905,7 @@
ID_VENDOR_FROM_DATABASE=General Standards Corporation
acpi:GSM*:
@ -175,7 +175,7 @@
acpi:GSN*:
ID_VENDOR_FROM_DATABASE=Grandstream Networks, Inc.
@@ -2968,6 +3003,9 @@
@@ -2971,6 +3006,9 @@
acpi:HEC*:
ID_VENDOR_FROM_DATABASE=Hisense Electric Co., Ltd.
@ -185,7 +185,7 @@
acpi:HEL*:
ID_VENDOR_FROM_DATABASE=Hitachi Micro Systems Europe Ltd
@@ -3097,6 +3135,9 @@
@@ -3100,6 +3138,9 @@
acpi:HSD*:
ID_VENDOR_FROM_DATABASE=HannStar Display Corp
@ -195,7 +195,7 @@
acpi:HSM*:
ID_VENDOR_FROM_DATABASE=AT&T Microelectronics
@@ -3220,6 +3261,9 @@
@@ -3223,6 +3264,9 @@
acpi:ICI*:
ID_VENDOR_FROM_DATABASE=Infotek Communication Inc
@ -205,7 +205,7 @@
acpi:ICM*:
ID_VENDOR_FROM_DATABASE=Intracom SA
@@ -3316,6 +3360,9 @@
@@ -3319,6 +3363,9 @@
acpi:IKE*:
ID_VENDOR_FROM_DATABASE=Ikegami Tsushinki Co. Ltd.
@ -215,7 +215,7 @@
acpi:IKS*:
ID_VENDOR_FROM_DATABASE=Ikos Systems Inc
@@ -3361,6 +3408,9 @@
@@ -3364,6 +3411,9 @@
acpi:IMT*:
ID_VENDOR_FROM_DATABASE=Inmax Technology Corporation
@ -225,7 +225,7 @@
acpi:INA*:
ID_VENDOR_FROM_DATABASE=Inventec Corporation
@@ -3868,6 +3918,9 @@
@@ -3871,6 +3921,9 @@
acpi:LAN*:
ID_VENDOR_FROM_DATABASE=Sodeman Lancom Inc
@ -235,7 +235,7 @@
acpi:LAS*:
ID_VENDOR_FROM_DATABASE=LASAT Comm. A/S
@@ -3913,6 +3966,9 @@
@@ -3916,6 +3969,9 @@
acpi:LED*:
ID_VENDOR_FROM_DATABASE=Long Engineering Design Inc
@ -245,7 +245,7 @@
acpi:LEG*:
ID_VENDOR_FROM_DATABASE=Legerity, Inc
@@ -3928,6 +3984,9 @@
@@ -3931,6 +3987,9 @@
acpi:LGC*:
ID_VENDOR_FROM_DATABASE=Logic Ltd
@ -255,7 +255,7 @@
acpi:LGI*:
ID_VENDOR_FROM_DATABASE=Logitech Inc
@@ -3982,6 +4041,9 @@
@@ -3985,6 +4044,9 @@
acpi:LND*:
ID_VENDOR_FROM_DATABASE=Land Computer Company Ltd
@ -265,7 +265,7 @@
acpi:LNK*:
ID_VENDOR_FROM_DATABASE=Link Tech Inc
@@ -4016,7 +4078,7 @@
@@ -4019,7 +4081,7 @@
ID_VENDOR_FROM_DATABASE=Design Technology
acpi:LPL*:
@ -274,7 +274,7 @@
acpi:LSC*:
ID_VENDOR_FROM_DATABASE=LifeSize Communications
@@ -4192,6 +4254,9 @@
@@ -4195,6 +4257,9 @@
acpi:MCX*:
ID_VENDOR_FROM_DATABASE=Millson Custom Solutions Inc.
@ -284,7 +284,7 @@
acpi:MDA*:
ID_VENDOR_FROM_DATABASE=Media4 Inc
@@ -4429,6 +4494,9 @@
@@ -4432,6 +4497,9 @@
acpi:MOM*:
ID_VENDOR_FROM_DATABASE=Momentum Data Systems
@ -294,7 +294,7 @@
acpi:MOS*:
ID_VENDOR_FROM_DATABASE=Moses Corporation
@@ -4654,6 +4722,9 @@
@@ -4657,6 +4725,9 @@
acpi:NAL*:
ID_VENDOR_FROM_DATABASE=Network Alchemy
@ -304,7 +304,7 @@
acpi:NAT*:
ID_VENDOR_FROM_DATABASE=NaturalPoint Inc.
@@ -5158,6 +5229,9 @@
@@ -5161,6 +5232,9 @@
acpi:PCX*:
ID_VENDOR_FROM_DATABASE=PC Xperten
@ -314,7 +314,7 @@
acpi:PDM*:
ID_VENDOR_FROM_DATABASE=Psion Dacom Plc.
@@ -5221,9 +5295,6 @@
@@ -5224,9 +5298,6 @@
acpi:PHE*:
ID_VENDOR_FROM_DATABASE=Philips Medical Systems Boeblingen GmbH
@ -324,7 +324,7 @@
acpi:PHL*:
ID_VENDOR_FROM_DATABASE=Philips Consumer Electronics Company
@@ -5311,9 +5382,6 @@
@@ -5314,9 +5385,6 @@
acpi:PNL*:
ID_VENDOR_FROM_DATABASE=Panelview, Inc.
@ -334,7 +334,7 @@
acpi:PNR*:
ID_VENDOR_FROM_DATABASE=Planar Systems, Inc.
@@ -5449,15 +5517,9 @@
@@ -5452,15 +5520,9 @@
acpi:PTS*:
ID_VENDOR_FROM_DATABASE=Plain Tree Systems Inc
@ -350,7 +350,7 @@
acpi:PVG*:
ID_VENDOR_FROM_DATABASE=Proview Global Co., Ltd
@@ -5773,9 +5835,6 @@
@@ -5776,9 +5838,6 @@
acpi:RTI*:
ID_VENDOR_FROM_DATABASE=Rancho Tech Inc
@ -360,7 +360,7 @@
acpi:RTL*:
ID_VENDOR_FROM_DATABASE=Realtek Semiconductor Company Ltd
@@ -5941,9 +6000,6 @@
@@ -5944,9 +6003,6 @@
acpi:SEE*:
ID_VENDOR_FROM_DATABASE=SeeColor Corporation
@ -370,7 +370,7 @@
acpi:SEI*:
ID_VENDOR_FROM_DATABASE=Seitz & Associates Inc
@@ -6400,6 +6456,9 @@
@@ -6403,6 +6459,9 @@
acpi:SVD*:
ID_VENDOR_FROM_DATABASE=SVD Computer
@ -380,7 +380,7 @@
acpi:SVI*:
ID_VENDOR_FROM_DATABASE=Sun Microsystems
@@ -6484,6 +6543,9 @@
@@ -6487,6 +6546,9 @@
acpi:SZM*:
ID_VENDOR_FROM_DATABASE=Shenzhen MTC Co., Ltd
@ -390,7 +390,7 @@
acpi:TAA*:
ID_VENDOR_FROM_DATABASE=Tandberg
@@ -6574,6 +6636,9 @@
@@ -6577,6 +6639,9 @@
acpi:TDG*:
ID_VENDOR_FROM_DATABASE=Six15 Technologies
@ -400,7 +400,7 @@
acpi:TDM*:
ID_VENDOR_FROM_DATABASE=Tandem Computer Europe Inc
@@ -6616,6 +6681,9 @@
@@ -6619,6 +6684,9 @@
acpi:TEV*:
ID_VENDOR_FROM_DATABASE=Televés, S.A.
@ -410,7 +410,7 @@
acpi:TEZ*:
ID_VENDOR_FROM_DATABASE=Tech Source Inc.
@@ -6730,9 +6798,6 @@
@@ -6733,9 +6801,6 @@
acpi:TNC*:
ID_VENDOR_FROM_DATABASE=TNC Industrial Company Ltd
@ -420,7 +420,7 @@
acpi:TNM*:
ID_VENDOR_FROM_DATABASE=TECNIMAGEN SA
@@ -7039,14 +7104,14 @@
@@ -7042,14 +7107,14 @@
acpi:UNC*:
ID_VENDOR_FROM_DATABASE=Unisys Corporation
@ -441,7 +441,7 @@
acpi:UNI*:
ID_VENDOR_FROM_DATABASE=Uniform Industry Corp.
@@ -7081,6 +7146,9 @@
@@ -7084,6 +7149,9 @@
acpi:USA*:
ID_VENDOR_FROM_DATABASE=Utimaco Safeware AG
@ -451,7 +451,7 @@
acpi:USD*:
ID_VENDOR_FROM_DATABASE=U.S. Digital Corporation
@@ -7324,9 +7392,6 @@
@@ -7327,9 +7395,6 @@
acpi:WAL*:
ID_VENDOR_FROM_DATABASE=Wave Access
@ -461,7 +461,7 @@
acpi:WAV*:
ID_VENDOR_FROM_DATABASE=Wavephore
@@ -7451,7 +7516,7 @@
@@ -7454,7 +7519,7 @@
ID_VENDOR_FROM_DATABASE=WyreStorm Technologies LLC
acpi:WYS*:
@ -470,7 +470,7 @@
acpi:WYT*:
ID_VENDOR_FROM_DATABASE=Wooyoung Image & Information Co.,Ltd.
@@ -7465,9 +7530,6 @@
@@ -7468,9 +7533,6 @@
acpi:XDM*:
ID_VENDOR_FROM_DATABASE=XDM Ltd.
@ -480,7 +480,7 @@
acpi:XES*:
ID_VENDOR_FROM_DATABASE=Extreme Engineering Solutions, Inc.
@@ -7498,9 +7560,6 @@
@@ -7501,9 +7563,6 @@
acpi:XNT*:
ID_VENDOR_FROM_DATABASE=XN Technologies, Inc.
@ -490,7 +490,7 @@
acpi:XQU*:
ID_VENDOR_FROM_DATABASE=SHANGHAI SVA-DAV ELECTRONICS CO., LTD
@@ -7567,6 +7626,9 @@
@@ -7570,6 +7629,9 @@
acpi:ZBX*:
ID_VENDOR_FROM_DATABASE=Zebax Technologies

344
hwdb.d/20-pci-vendor-model.hwdb
View File

@ -116,6 +116,9 @@ pci:v0000018A*
pci:v0000018Ad00000106*
ID_MODEL_FROM_DATABASE=FPC-0106TX misprogrammed [RTL81xx]
pci:v000001DE*
ID_VENDOR_FROM_DATABASE=Oxide Computer Company
pci:v0000021B*
ID_VENDOR_FROM_DATABASE=Compaq Computer Corporation
@ -1214,6 +1217,12 @@ pci:v00001000d0000005Dsv000017AAsd00001052*
pci:v00001000d0000005Dsv000017AAsd00001053*
ID_MODEL_FROM_DATABASE=MegaRAID SAS-3 3108 [Invader] (ThinkServer RAID 720ix)
pci:v00001000d0000005Dsv00001BD4sd00000014*
ID_MODEL_FROM_DATABASE=MegaRAID SAS-3 3108 [Invader] (12G SAS3108 2G)
pci:v00001000d0000005Dsv00001BD4sd00000015*
ID_MODEL_FROM_DATABASE=MegaRAID SAS-3 3108 [Invader] (12G SAS3108 4G)
pci:v00001000d0000005Dsv00001D49sd00000600*
ID_MODEL_FROM_DATABASE=MegaRAID SAS-3 3108 [Invader] (ThinkSystem RAID 730-8i 1GB Cache PCIe 12Gb Adapter)
@ -1427,6 +1436,21 @@ pci:v00001000d00000072sv00001028sd00001F20*
pci:v00001000d00000072sv00001028sd00001F22*
ID_MODEL_FROM_DATABASE=SAS2008 PCI-Express Fusion-MPT SAS-2 [Falcon] (PERC H200 Internal Tape Adapter)
pci:v00001000d00000072sv00001734sd00001177*
ID_MODEL_FROM_DATABASE=SAS2008 PCI-Express Fusion-MPT SAS-2 [Falcon] (HBA Ctrl SAS 6G 0/1 [D2607])
pci:v00001000d00000072sv00001BD4sd0000000D*
ID_MODEL_FROM_DATABASE=SAS2008 PCI-Express Fusion-MPT SAS-2 [Falcon] (6G SAS2008IT)
pci:v00001000d00000072sv00001BD4sd0000000E*
ID_MODEL_FROM_DATABASE=SAS2008 PCI-Express Fusion-MPT SAS-2 [Falcon] (6G SAS2008IR)
pci:v00001000d00000072sv00001BD4sd0000000F*
ID_MODEL_FROM_DATABASE=SAS2008 PCI-Express Fusion-MPT SAS-2 [Falcon] (6G SAS2008IT SA5248)
pci:v00001000d00000072sv00001BD4sd00000010*
ID_MODEL_FROM_DATABASE=SAS2008 PCI-Express Fusion-MPT SAS-2 [Falcon] (6G SAS2008IR SA5248)
pci:v00001000d00000072sv00008086sd0000350F*
ID_MODEL_FROM_DATABASE=SAS2008 PCI-Express Fusion-MPT SAS-2 [Falcon] (RMS2LL040 RAID Controller)
@ -1751,6 +1775,12 @@ pci:v00001000d00000087sv00001590sd00000042*
pci:v00001000d00000087sv00001590sd00000044*
ID_MODEL_FROM_DATABASE=SAS2308 PCI-Express Fusion-MPT SAS-2 (H220i)
pci:v00001000d00000087sv00001BD4sd00000009*
ID_MODEL_FROM_DATABASE=SAS2308 PCI-Express Fusion-MPT SAS-2 (6G SAS2308IR)
pci:v00001000d00000087sv00001BD4sd0000000A*
ID_MODEL_FROM_DATABASE=SAS2308 PCI-Express Fusion-MPT SAS-2 (6G SAS2308IT)
pci:v00001000d00000087sv00008086sd00003000*
ID_MODEL_FROM_DATABASE=SAS2308 PCI-Express Fusion-MPT SAS-2 (RS25GB008 RAID Controller)
@ -1841,6 +1871,18 @@ pci:v00001000d00000097sv00001BD4sd0000000C*
pci:v00001000d00000097sv00001BD4sd00000011*
ID_MODEL_FROM_DATABASE=SAS3008 PCI-Express Fusion-MPT SAS-3 (Inspur 12Gb 8i-3008 IT SAS HBA)
pci:v00001000d00000097sv00001BD4sd00000012*
ID_MODEL_FROM_DATABASE=SAS3008 PCI-Express Fusion-MPT SAS-3 (12Gb SAS3008IR UDM)
pci:v00001000d00000097sv00001BD4sd00000026*
ID_MODEL_FROM_DATABASE=SAS3008 PCI-Express Fusion-MPT SAS-3 (12G SAS3008IT RACK)
pci:v00001000d00000097sv00001BD4sd00000027*
ID_MODEL_FROM_DATABASE=SAS3008 PCI-Express Fusion-MPT SAS-3 (12G SAS3008IMR RACK)
pci:v00001000d00000097sv00001BD4sd00000028*
ID_MODEL_FROM_DATABASE=SAS3008 PCI-Express Fusion-MPT SAS-3 (12G SAS3008IR RACK)
pci:v00001000d000000AB*
ID_MODEL_FROM_DATABASE=SAS3516 Fusion-MPT Tri-Mode RAID On Chip (ROC)
@ -2480,9 +2522,15 @@ pci:v00001002d00001307*
pci:v00001002d00001308*
ID_MODEL_FROM_DATABASE=Kaveri HDMI/DP Audio Controller
pci:v00001002d00001308sv000017AAsd00003988*
ID_MODEL_FROM_DATABASE=Kaveri HDMI/DP Audio Controller (Z50-75)
pci:v00001002d00001309*
ID_MODEL_FROM_DATABASE=Kaveri [Radeon R6/R7 Graphics]
pci:v00001002d00001309sv000017AAsd00003830*
ID_MODEL_FROM_DATABASE=Kaveri [Radeon R6/R7 Graphics] (Z50-75)
pci:v00001002d0000130A*
ID_MODEL_FROM_DATABASE=Kaveri [Radeon R6 Graphics]
@ -2570,6 +2618,9 @@ pci:v00001002d000015D8*
pci:v00001002d000015D8sv0000103Csd00008615*
ID_MODEL_FROM_DATABASE=Picasso (Pavilion Laptop 15-cw1xxx)
pci:v00001002d000015D8sv000017AAsd00005124*
ID_MODEL_FROM_DATABASE=Picasso (ThinkPad E595)
pci:v00001002d000015DD*
ID_MODEL_FROM_DATABASE=Raven Ridge [Radeon Vega Series / Radeon Vega Mobile Series]
@ -2585,6 +2636,9 @@ pci:v00001002d000015DE*
pci:v00001002d000015DEsv0000103Csd00008615*
ID_MODEL_FROM_DATABASE=Raven/Raven2/Fenghuang HDMI/DP Audio Controller (Pavilion Laptop 15-cw1xxx)
pci:v00001002d000015DEsv000017AAsd00005124*
ID_MODEL_FROM_DATABASE=Raven/Raven2/Fenghuang HDMI/DP Audio Controller (ThinkPad E595)
pci:v00001002d000015DF*
ID_MODEL_FROM_DATABASE=Raven/Raven2/Fenghuang/Renoir Cryptographic Coprocessor
@ -3114,7 +3168,7 @@ pci:v00001002d00004383sv00001019sd00002120*
ID_MODEL_FROM_DATABASE=SBx00 Azalia (Intel HDA) (A785GM-M)
pci:v00001002d00004383sv0000103Csd00001611*
ID_MODEL_FROM_DATABASE=SBx00 Azalia (Intel HDA) (Pavilion DM1Z-3000)
ID_MODEL_FROM_DATABASE=SBx00 Azalia (Intel HDA) (Pavilion dm1z-3000)
pci:v00001002d00004383sv0000103Csd0000280A*
ID_MODEL_FROM_DATABASE=SBx00 Azalia (Intel HDA) (DC5750 Microtower)
@ -5412,22 +5466,25 @@ pci:v00001002d00006610sv00001642sd00003F09*
ID_MODEL_FROM_DATABASE=Oland XT [Radeon HD 8670 / R7 250/350] (Radeon R7 350)
pci:v00001002d00006611*
ID_MODEL_FROM_DATABASE=Oland [Radeon HD 8570 / R7 240/340 OEM]
ID_MODEL_FROM_DATABASE=Oland [Radeon HD 8570 / R7 240/340 / Radeon 520 OEM]
pci:v00001002d00006611sv00001028sd0000210B*
ID_MODEL_FROM_DATABASE=Oland [Radeon HD 8570 / R7 240/340 OEM] (Radeon R5 240 OEM)
ID_MODEL_FROM_DATABASE=Oland [Radeon HD 8570 / R7 240/340 / Radeon 520 OEM] (Radeon R5 240 OEM)
pci:v00001002d00006611sv00001642sd00001869*
ID_MODEL_FROM_DATABASE=Oland [Radeon HD 8570 / R7 240/340 / Radeon 520 OEM] (Radeon 520 OEM)
pci:v00001002d00006611sv0000174Bsd00004248*
ID_MODEL_FROM_DATABASE=Oland [Radeon HD 8570 / R7 240/340 OEM] (Radeon R7 240 OEM)
ID_MODEL_FROM_DATABASE=Oland [Radeon HD 8570 / R7 240/340 / Radeon 520 OEM] (Radeon R7 240 OEM)
pci:v00001002d00006611sv0000174Bsd0000A240*
ID_MODEL_FROM_DATABASE=Oland [Radeon HD 8570 / R7 240/340 OEM] (Radeon R7 240 OEM)
ID_MODEL_FROM_DATABASE=Oland [Radeon HD 8570 / R7 240/340 / Radeon 520 OEM] (Radeon R7 240 OEM)
pci:v00001002d00006611sv0000174Bsd0000D340*
ID_MODEL_FROM_DATABASE=Oland [Radeon HD 8570 / R7 240/340 OEM] (Radeon R7 340 OEM)
ID_MODEL_FROM_DATABASE=Oland [Radeon HD 8570 / R7 240/340 / Radeon 520 OEM] (Radeon R7 340 OEM)
pci:v00001002d00006611sv00001B0Asd000090D3*
ID_MODEL_FROM_DATABASE=Oland [Radeon HD 8570 / R7 240/340 OEM] (Radeon R7 240 OEM)
ID_MODEL_FROM_DATABASE=Oland [Radeon HD 8570 / R7 240/340 / Radeon 520 OEM] (Radeon R7 240 OEM)
pci:v00001002d00006613*
ID_MODEL_FROM_DATABASE=Oland PRO [Radeon R7 240/340]
@ -5604,7 +5661,7 @@ pci:v00001002d00006665*
ID_MODEL_FROM_DATABASE=Jet PRO [Radeon R5 M230 / R7 M260DX / Radeon 520 Mobile]
pci:v00001002d00006665sv000017AAsd00001309*
ID_MODEL_FROM_DATABASE=Jet PRO [Radeon R5 M230 / R7 M260DX / Radeon 520 Mobile] (Radeon R7 M260DX)
ID_MODEL_FROM_DATABASE=Jet PRO [Radeon R5 M230 / R7 M260DX / Radeon 520 Mobile] (Z50-75 Radeon R7 M260DX)
pci:v00001002d00006665sv000017AAsd0000368F*
ID_MODEL_FROM_DATABASE=Jet PRO [Radeon R5 M230 / R7 M260DX / Radeon 520 Mobile] (Radeon R5 A230)
@ -7485,7 +7542,7 @@ pci:v00001002d000067DFsv00001462sd00008A92*
ID_MODEL_FROM_DATABASE=Ellesmere [Radeon RX 470/480/570/570X/580/580X/590] (Radeon RX 580)
pci:v00001002d000067DFsv0000148Csd00002372*
ID_MODEL_FROM_DATABASE=Ellesmere [Radeon RX 470/480/570/570X/580/580X/590] (Radeon RX 480)
ID_MODEL_FROM_DATABASE=Ellesmere [Radeon RX 470/480/570/570X/580/580X/590] (Radeon RX 480 [Red Dragon])
pci:v00001002d000067DFsv0000148Csd00002373*
ID_MODEL_FROM_DATABASE=Ellesmere [Radeon RX 470/480/570/570X/580/580X/590] (Radeon RX 470)
@ -13790,27 +13847,42 @@ pci:v00001022d000015DE*
pci:v00001022d000015DF*
ID_MODEL_FROM_DATABASE=Family 17h (Models 10h-1fh) Platform Security Processor
pci:v00001022d000015DFsv000017AAsd00005124*
ID_MODEL_FROM_DATABASE=Family 17h (Models 10h-1fh) Platform Security Processor (ThinkPad E595)
pci:v00001022d000015E0*
ID_MODEL_FROM_DATABASE=Raven USB 3.1
pci:v00001022d000015E0sv0000103Csd00008615*
ID_MODEL_FROM_DATABASE=Raven USB 3.1 (Pavilion Laptop 15-cw1xxx)
pci:v00001022d000015E0sv000017AAsd00005124*
ID_MODEL_FROM_DATABASE=Raven USB 3.1 (ThinkPad E595)
pci:v00001022d000015E1*
ID_MODEL_FROM_DATABASE=Raven USB 3.1
pci:v00001022d000015E1sv0000103Csd00008615*
ID_MODEL_FROM_DATABASE=Raven USB 3.1 (Pavilion Laptop 15-cw1xxx)
pci:v00001022d000015E1sv000017AAsd00005124*
ID_MODEL_FROM_DATABASE=Raven USB 3.1 (ThinkPad E595)
pci:v00001022d000015E2*
ID_MODEL_FROM_DATABASE=Raven/Raven2/FireFlight/Renoir Audio Processor
pci:v00001022d000015E2sv000017AAsd00005124*
ID_MODEL_FROM_DATABASE=Raven/Raven2/FireFlight/Renoir Audio Processor (ThinkPad E595)
pci:v00001022d000015E3*
ID_MODEL_FROM_DATABASE=Family 17h (Models 10h-1fh) HD Audio Controller
pci:v00001022d000015E3sv0000103Csd00008615*
ID_MODEL_FROM_DATABASE=Family 17h (Models 10h-1fh) HD Audio Controller (Pavilion Laptop 15-cw1xxx)
pci:v00001022d000015E3sv000017AAsd00005124*
ID_MODEL_FROM_DATABASE=Family 17h (Models 10h-1fh) HD Audio Controller (ThinkPad E595)
pci:v00001022d000015E4*
ID_MODEL_FROM_DATABASE=Raven/Raven2/Renoir Sensor Fusion Hub
@ -14435,6 +14507,9 @@ pci:v00001022d00007801sv0000103Csd0000168B*
pci:v00001022d00007801sv0000103Csd0000194E*
ID_MODEL_FROM_DATABASE=FCH SATA Controller [AHCI mode] (ProBook 455 G1 Notebook)
pci:v00001022d00007801sv000017AAsd00003988*
ID_MODEL_FROM_DATABASE=FCH SATA Controller [AHCI mode] (Z50-75)
pci:v00001022d00007801sv00001849sd00007801*
ID_MODEL_FROM_DATABASE=FCH SATA Controller [AHCI mode] (QC5000-ITX/PH)
@ -14465,6 +14540,9 @@ pci:v00001022d00007807sv0000103Csd0000194E*
pci:v00001022d00007807sv0000103Csd00001985*
ID_MODEL_FROM_DATABASE=FCH USB OHCI Controller (Pavilion 17-e163sg Notebook PC)
pci:v00001022d00007807sv000017AAsd00003988*
ID_MODEL_FROM_DATABASE=FCH USB OHCI Controller (Z50-75)
pci:v00001022d00007807sv00001849sd00007807*
ID_MODEL_FROM_DATABASE=FCH USB OHCI Controller (QC5000-ITX/PH)
@ -14477,6 +14555,9 @@ pci:v00001022d00007808sv0000103Csd0000194E*
pci:v00001022d00007808sv0000103Csd00001985*
ID_MODEL_FROM_DATABASE=FCH USB EHCI Controller (Pavilion 17-e163sg Notebook PC)
pci:v00001022d00007808sv000017AAsd00003988*
ID_MODEL_FROM_DATABASE=FCH USB EHCI Controller (Z50-75)
pci:v00001022d00007808sv00001849sd00007808*
ID_MODEL_FROM_DATABASE=FCH USB EHCI Controller (QC5000-ITX/PH)
@ -14486,6 +14567,9 @@ pci:v00001022d00007809*
pci:v00001022d00007809sv0000103Csd0000194E*
ID_MODEL_FROM_DATABASE=FCH USB OHCI Controller (ProBook 455 G1 Notebook)
pci:v00001022d00007809sv000017AAsd00003988*
ID_MODEL_FROM_DATABASE=FCH USB OHCI Controller (Z50-75)
pci:v00001022d0000780A*
ID_MODEL_FROM_DATABASE=Kabini/Mullins SATA Raid/AHCI Mode (DotHill driver)
@ -14498,6 +14582,9 @@ pci:v00001022d0000780Bsv0000103Csd0000194E*
pci:v00001022d0000780Bsv0000103Csd00001985*
ID_MODEL_FROM_DATABASE=FCH SMBus Controller (Pavilion 17-e163sg Notebook PC)
pci:v00001022d0000780Bsv000017AAsd00003988*
ID_MODEL_FROM_DATABASE=FCH SMBus Controller (Z50-75)
pci:v00001022d0000780Bsv00001849sd0000780B*
ID_MODEL_FROM_DATABASE=FCH SMBus Controller (QC5000-ITX/PH)
@ -14516,6 +14603,9 @@ pci:v00001022d0000780Dsv0000103Csd00001985*
pci:v00001022d0000780Dsv00001043sd00008444*
ID_MODEL_FROM_DATABASE=FCH Azalia Controller (F2A85-M Series)
pci:v00001022d0000780Dsv000017AAsd00003988*
ID_MODEL_FROM_DATABASE=FCH Azalia Controller (Z50-75)
pci:v00001022d0000780Dsv00001849sd00008892*
ID_MODEL_FROM_DATABASE=FCH Azalia Controller (QC5000-ITX/PH)
@ -14528,6 +14618,9 @@ pci:v00001022d0000780Esv0000103Csd0000194E*
pci:v00001022d0000780Esv0000103Csd00001985*
ID_MODEL_FROM_DATABASE=FCH LPC Bridge (Pavilion 17-e163sg Notebook PC)
pci:v00001022d0000780Esv000017AAsd00003988*
ID_MODEL_FROM_DATABASE=FCH LPC Bridge (Z50-75)
pci:v00001022d0000780Esv00001849sd0000780E*
ID_MODEL_FROM_DATABASE=FCH LPC Bridge (QC5000-ITX/PH)
@ -14549,6 +14642,9 @@ pci:v00001022d00007814sv0000103Csd0000194E*
pci:v00001022d00007814sv0000103Csd00001985*
ID_MODEL_FROM_DATABASE=FCH USB XHCI Controller (Pavilion 17-e163sg Notebook PC)
pci:v00001022d00007814sv000017AAsd00003988*
ID_MODEL_FROM_DATABASE=FCH USB XHCI Controller (Z50-75)
pci:v00001022d00007814sv00001849sd00007814*
ID_MODEL_FROM_DATABASE=FCH USB XHCI Controller (QC5000-ITX/PH)
@ -14588,6 +14684,9 @@ pci:v00001022d0000790Bsv0000103Csd00008615*
pci:v00001022d0000790Bsv00001462sd00007C37*
ID_MODEL_FROM_DATABASE=FCH SMBus Controller (X570-A PRO motherboard)
pci:v00001022d0000790Bsv000017AAsd00005124*
ID_MODEL_FROM_DATABASE=FCH SMBus Controller (ThinkPad E595)
pci:v00001022d0000790E*
ID_MODEL_FROM_DATABASE=FCH LPC Bridge
@ -14597,6 +14696,9 @@ pci:v00001022d0000790Esv0000103Csd00008615*
pci:v00001022d0000790Esv00001462sd00007C37*
ID_MODEL_FROM_DATABASE=FCH LPC Bridge (X570-A PRO motherboard)
pci:v00001022d0000790Esv000017AAsd00005124*
ID_MODEL_FROM_DATABASE=FCH LPC Bridge (ThinkPad E595)
pci:v00001022d0000790F*
ID_MODEL_FROM_DATABASE=FCH PCI Bridge
@ -19226,6 +19328,9 @@ pci:v00001057d00004803*
pci:v00001057d00004806*
ID_MODEL_FROM_DATABASE=CPX8216
pci:v00001057d0000480B*
ID_MODEL_FROM_DATABASE=MPC7410
pci:v00001057d00004D68*
ID_MODEL_FROM_DATABASE=20268
@ -20513,6 +20618,12 @@ pci:v00001077d00002281sv00001077sd000002EE*
pci:v00001077d00002281sv00001077sd000002F0*
ID_MODEL_FROM_DATABASE=ISP2812-based 64/32G Fibre Channel to PCIe Controller (QLE2770 Single Port 32GFC PCIe Gen4 x8 Adapter)
pci:v00001077d00002281sv00001077sd000002F2*
ID_MODEL_FROM_DATABASE=ISP2812-based 64/32G Fibre Channel to PCIe Controller (QLogic 1x32Gb QLE2770 FC HBA)
pci:v00001077d00002281sv00001077sd000002F3*
ID_MODEL_FROM_DATABASE=ISP2812-based 64/32G Fibre Channel to PCIe Controller (QLogic 2x32Gb QLE2772 FC HBA)
pci:v00001077d00002281sv00001590sd000002D3*
ID_MODEL_FROM_DATABASE=ISP2812-based 64/32G Fibre Channel to PCIe Controller (SN1610Q - 1P Enhanced 32GFC Single Port Fibre Channel Host Bus Adapter)
@ -20747,6 +20858,12 @@ pci:v00001077d00008070sv00001077sd00000056*
pci:v00001077d00008070sv00001077sd00000057*
ID_MODEL_FROM_DATABASE=FastLinQ QL41000 Series 10/25/40/50GbE Controller (2x25GE QL41232HxCU NIC)
pci:v00001077d00008070sv00001077sd00000065*
ID_MODEL_FROM_DATABASE=FastLinQ QL41000 Series 10/25/40/50GbE Controller (QLogic 4x10GE QL41154HQRJ CNA)
pci:v00001077d00008070sv00001077sd00000066*
ID_MODEL_FROM_DATABASE=FastLinQ QL41000 Series 10/25/40/50GbE Controller (QLogic 4x10GE QL41154HQCU CNA)
pci:v00001077d00008070sv00001077sd00000068*
ID_MODEL_FROM_DATABASE=FastLinQ QL41000 Series 10/25/40/50GbE Controller (10GbE 2p SFP+ QL41132HLCU-HC Adapter)
@ -20876,6 +20993,12 @@ pci:v00001077d00008084sv00001077sd0000000E*
pci:v00001077d00008084sv00001077sd0000000F*
ID_MODEL_FROM_DATABASE=FastLinQ QL41000 Series 10/25/40/50GbE Controller (iSCSI) (2x25GE QL41262HMKR CNA)
pci:v00001077d00008084sv00001077sd00000065*
ID_MODEL_FROM_DATABASE=FastLinQ QL41000 Series 10/25/40/50GbE Controller (iSCSI) (QLogic 4x10GE QL41154HQRJ CNA)
pci:v00001077d00008084sv00001077sd00000066*
ID_MODEL_FROM_DATABASE=FastLinQ QL41000 Series 10/25/40/50GbE Controller (iSCSI) (QLogic 4x10GE QL41154HQCU CNA)
pci:v00001077d00008084sv00001590sd0000021A*
ID_MODEL_FROM_DATABASE=FastLinQ QL41000 Series 10/25/40/50GbE Controller (iSCSI) (10GbE 2P QL41162HLRJ-HP Adapter)
@ -20948,6 +21071,12 @@ pci:v00001077d00008090sv00001077sd00000056*
pci:v00001077d00008090sv00001077sd00000057*
ID_MODEL_FROM_DATABASE=FastLinQ QL41000 Series Gigabit Ethernet Controller (SR-IOV VF) (2x25GE QL41232HxCU NIC)
pci:v00001077d00008090sv00001077sd00000065*
ID_MODEL_FROM_DATABASE=FastLinQ QL41000 Series Gigabit Ethernet Controller (SR-IOV VF) (QLogic 4x10GE QL41154HQRJ CNA)
pci:v00001077d00008090sv00001077sd00000066*
ID_MODEL_FROM_DATABASE=FastLinQ QL41000 Series Gigabit Ethernet Controller (SR-IOV VF) (QLogic 4x10GE QL41154HQCU CNA)
pci:v00001077d00008090sv00001590sd0000021A*
ID_MODEL_FROM_DATABASE=FastLinQ QL41000 Series Gigabit Ethernet Controller (SR-IOV VF) (10GbE 2P QL41162HLRJ-HP Adapter)
@ -32426,6 +32555,9 @@ pci:v000010DEd00000FBA*
pci:v000010DEd00000FBB*
ID_MODEL_FROM_DATABASE=GM204 High Definition Audio Controller
pci:v000010DEd00000FBC*
ID_MODEL_FROM_DATABASE=GM107 High Definition Audio Controller [GeForce 940MX]
pci:v000010DEd00000FC0*
ID_MODEL_FROM_DATABASE=GK107 [GeForce GT 640 OEM]
@ -34727,6 +34859,9 @@ pci:v000010DEd00001407*
pci:v000010DEd00001427*
ID_MODEL_FROM_DATABASE=GM206M [GeForce GTX 965M]
pci:v000010DEd00001427sv0000103Csd0000825B*
ID_MODEL_FROM_DATABASE=GM206M [GeForce GTX 965M] (OMEN-17-w001nv)
pci:v000010DEd00001430*
ID_MODEL_FROM_DATABASE=GM206GL [Quadro M2000]
@ -34787,6 +34922,9 @@ pci:v000010DEd00001789*
pci:v000010DEd0000179C*
ID_MODEL_FROM_DATABASE=GM107 [GeForce 940MX]
pci:v000010DEd0000179Csv00001025sd00001094*
ID_MODEL_FROM_DATABASE=GM107 [GeForce 940MX] (Acer Aspire E5-575G)
pci:v000010DEd000017C2*
ID_MODEL_FROM_DATABASE=GM200 [GeForce GTX TITAN X]
@ -35135,6 +35273,12 @@ pci:v000010DEd00001CCC*
pci:v000010DEd00001CCD*
ID_MODEL_FROM_DATABASE=GP107BM [GeForce GTX 1050 Mobile]
pci:v000010DEd00001CFA*
ID_MODEL_FROM_DATABASE=GP107GL [Quadro P2000]
pci:v000010DEd00001CFB*
ID_MODEL_FROM_DATABASE=GP107GL [Quadro P1000]
pci:v000010DEd00001D01*
ID_MODEL_FROM_DATABASE=GP108 [GeForce GT 1030]
@ -35204,6 +35348,12 @@ pci:v000010DEd00001DBA*
pci:v000010DEd00001DBAsv000010DEsd000012EB*
ID_MODEL_FROM_DATABASE=GV100GL [Quadro GV100] (TITAN V CEO Edition)
pci:v000010DEd00001DF0*
ID_MODEL_FROM_DATABASE=GV100GL [Tesla PG500-216]
pci:v000010DEd00001DF2*
ID_MODEL_FROM_DATABASE=GV100GL [Tesla PG503-216]
pci:v000010DEd00001DF5*
ID_MODEL_FROM_DATABASE=GV100GL [Tesla V100 SXM2 16GB]
@ -35237,6 +35387,18 @@ pci:v000010DEd00001E30sv000010DEsd0000129E*
pci:v000010DEd00001E30sv000010DEsd000012BA*
ID_MODEL_FROM_DATABASE=TU102GL [Quadro RTX 6000/8000] (Quadro RTX 6000)
pci:v000010DEd00001E37*
ID_MODEL_FROM_DATABASE=TU102GL [GRID RTX T10-4/T10-8/T10-16]
pci:v000010DEd00001E37sv000010DEsd00001347*
ID_MODEL_FROM_DATABASE=TU102GL [GRID RTX T10-4/T10-8/T10-16] (GRID RTX T10-8)
pci:v000010DEd00001E37sv000010DEsd00001348*
ID_MODEL_FROM_DATABASE=TU102GL [GRID RTX T10-4/T10-8/T10-16] (GRID RTX T10-4)
pci:v000010DEd00001E37sv000010DEsd00001370*
ID_MODEL_FROM_DATABASE=TU102GL [GRID RTX T10-4/T10-8/T10-16] (GRID RTX T10-16)
pci:v000010DEd00001E38*
ID_MODEL_FROM_DATABASE=TU102GL
@ -36041,6 +36203,12 @@ pci:v000010ECd0000522A*
pci:v000010ECd0000522Asv0000103Csd00008079*
ID_MODEL_FROM_DATABASE=RTS522A PCI Express Card Reader (EliteBook 840 G3)
pci:v000010ECd0000522Asv0000103Csd0000825B*
ID_MODEL_FROM_DATABASE=RTS522A PCI Express Card Reader (OMEN-17-w001nv)
pci:v000010ECd0000522Asv000017AAsd00005124*
ID_MODEL_FROM_DATABASE=RTS522A PCI Express Card Reader (ThinkPad E595)
pci:v000010ECd00005249*
ID_MODEL_FROM_DATABASE=RTS5249 PCI Express Card Reader
@ -36074,6 +36242,9 @@ pci:v000010ECd00005286*
pci:v000010ECd00005287*
ID_MODEL_FROM_DATABASE=RTL8411B PCI Express Card Reader
pci:v000010ECd00005287sv00001025sd00001094*
ID_MODEL_FROM_DATABASE=RTL8411B PCI Express Card Reader (Acer Aspire E5-575G)
pci:v000010ECd00005288*
ID_MODEL_FROM_DATABASE=RTS5288 PCI Express Card Reader
@ -36320,6 +36491,9 @@ pci:v000010ECd00008168*
pci:v000010ECd00008168sv00001019sd00008168*
ID_MODEL_FROM_DATABASE=RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (RTL8111/8168 PCI Express Gigabit Ethernet controller)
pci:v000010ECd00008168sv00001025sd00001094*
ID_MODEL_FROM_DATABASE=RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (Acer Aspire E5-575G)
pci:v000010ECd00008168sv00001028sd00000283*
ID_MODEL_FROM_DATABASE=RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (Vostro 220)
@ -36344,6 +36518,9 @@ pci:v000010ECd00008168sv0000103Csd00001950*
pci:v000010ECd00008168sv0000103Csd00002A6F*
ID_MODEL_FROM_DATABASE=RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (Asus IPIBL-LB Motherboard)
pci:v000010ECd00008168sv0000103Csd0000825B*
ID_MODEL_FROM_DATABASE=RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (OMEN-17-w001nv)
pci:v000010ECd00008168sv0000103Csd00008615*
ID_MODEL_FROM_DATABASE=RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (Pavilion Laptop 15-cw1xxx)
@ -36401,6 +36578,12 @@ pci:v000010ECd00008168sv00001462sd00007C37*
pci:v000010ECd00008168sv00001775sd000011CC*
ID_MODEL_FROM_DATABASE=RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (CC11/CL11)
pci:v000010ECd00008168sv000017AAsd00003814*
ID_MODEL_FROM_DATABASE=RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (Z50-75)
pci:v000010ECd00008168sv000017AAsd00005124*
ID_MODEL_FROM_DATABASE=RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (ThinkPad E595)
pci:v000010ECd00008168sv00001849sd00008168*
ID_MODEL_FROM_DATABASE=RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (Motherboard (one of many))
@ -36551,12 +36734,21 @@ pci:v000010ECd0000B723*
pci:v000010ECd0000B723sv000010ECsd00008739*
ID_MODEL_FROM_DATABASE=RTL8723BE PCIe Wireless Network Adapter (Dell Wireless 1801)
pci:v000010ECd0000B723sv000017AAsd0000B736*
ID_MODEL_FROM_DATABASE=RTL8723BE PCIe Wireless Network Adapter (Z50-75)
pci:v000010ECd0000B822*
ID_MODEL_FROM_DATABASE=RTL8822BE 802.11a/b/g/n/ac WiFi adapter
pci:v000010ECd0000B822sv0000103Csd0000831B*
ID_MODEL_FROM_DATABASE=RTL8822BE 802.11a/b/g/n/ac WiFi adapter (Realtek RTL8822BE 802.11ac 2 × 2 Wi-Fi + Bluetooth 4.2 Combo Adapter (MU-MIMO supported))
pci:v000010ECd0000B822sv000017AAsd00005124*
ID_MODEL_FROM_DATABASE=RTL8822BE 802.11a/b/g/n/ac WiFi adapter (ThinkPad E595)
pci:v000010ECd0000B822sv000017AAsd0000B023*
ID_MODEL_FROM_DATABASE=RTL8822BE 802.11a/b/g/n/ac WiFi adapter (ThinkPad E595)
pci:v000010ECd0000C821*
ID_MODEL_FROM_DATABASE=RTL8821CE 802.11ac PCIe Wireless Network Adapter
@ -36996,7 +37188,16 @@ pci:v00001102d00000005sv00001102sd00001003*
ID_MODEL_FROM_DATABASE=EMU20k1 [Sound Blaster X-Fi Series] (X-Fi XtremeMusic)
pci:v00001102d00000006*
ID_MODEL_FROM_DATABASE=EMU10k1X [SB Live! Value/OEM Series]
ID_MODEL_FROM_DATABASE=EMU10k1X / CA0103 [SB Live! OEM / SB 5.1 / Ectiva 5.1]
pci:v00001102d00000006sv00001102sd00001001*
ID_MODEL_FROM_DATABASE=EMU10k1X / CA0103 [SB Live! OEM / SB 5.1 / Ectiva 5.1] (SB0680 Sound Blaster 5.1)
pci:v00001102d00000006sv00001102sd00001003*
ID_MODEL_FROM_DATABASE=EMU10k1X / CA0103 [SB Live! OEM / SB 5.1 / Ectiva 5.1] (SB0203 SB Live! 5.1 (Dell))
pci:v00001102d00000006sv00001102sd00001004*
ID_MODEL_FROM_DATABASE=EMU10k1X / CA0103 [SB Live! OEM / SB 5.1 / Ectiva 5.1] (TP0033 Ectiva Audio 5.1)
pci:v00001102d00000007*
ID_MODEL_FROM_DATABASE=CA0106/CA0111 [SB Live!/Audigy/X-Fi Series]
@ -53561,6 +53762,9 @@ pci:v0000144Dd0000A822sv00001028sd00001FF9*
pci:v0000144Dd0000A822sv00001028sd00001FFA*
ID_MODEL_FROM_DATABASE=NVMe SSD Controller 172Xa/172Xb (Express Flash PM1725b 12.8TB AIC)
pci:v0000144Dd0000A824*
ID_MODEL_FROM_DATABASE=NVMe SSD Controller PM173X
pci:v0000144E*
ID_VENDOR_FROM_DATABASE=OLITEC
@ -58907,6 +59111,9 @@ pci:v000015B3d00004117*
pci:v000015B3d00004117sv00001BD4sd00000039*
ID_MODEL_FROM_DATABASE=MT27712A0-FDCF-AE (SN10XMP2P25)
pci:v000015B3d00004117sv00001BD4sd0000003A*
ID_MODEL_FROM_DATABASE=MT27712A0-FDCF-AE (25G SFP28 SP EO251FM9 Adapter)
pci:v000015B3d00004117sv00001BD4sd0000004D*
ID_MODEL_FROM_DATABASE=MT27712A0-FDCF-AE (SN10XMP2P25,YZPC-01191-101)
@ -60749,6 +60956,9 @@ pci:v0000168Cd00000041*
pci:v0000168Cd00000042*
ID_MODEL_FROM_DATABASE=QCA9377 802.11ac Wireless Network Adapter
pci:v0000168Cd00000042sv000011ADsd000008A6*
ID_MODEL_FROM_DATABASE=QCA9377 802.11ac Wireless Network Adapter (Qualcomm Atheros QCA9377 802.11ac Wireless Network Adapter)
pci:v0000168Cd00000046*
ID_MODEL_FROM_DATABASE=QCA9984 802.11ac Wave 2 Wireless Network Adapter
@ -64781,6 +64991,9 @@ pci:v000019E5d00000200*
pci:v000019E5d00000200sv000019E5sd0000D139*
ID_MODEL_FROM_DATABASE=Hi1822 Family (2*100GE) (Hi1822 SP572 (2*100GE))
pci:v000019E5d00000200sv000019E5sd0000D13D*
ID_MODEL_FROM_DATABASE=Hi1822 Family (2*100GE) (Hi1822 SC371 (2*100GE))
pci:v000019E5d00000202*
ID_MODEL_FROM_DATABASE=Hi1822 Family (2*32G FC)
@ -64811,6 +65024,9 @@ pci:v000019E5d00000206*
pci:v000019E5d00000206sv000019E5sd0000D138*
ID_MODEL_FROM_DATABASE=Hi1822 Family (2*25GE) (Hi1822 SP582 (2*25GE))
pci:v000019E5d00000206sv000019E5sd0000D13A*
ID_MODEL_FROM_DATABASE=Hi1822 Family (2*25GE) (Hi1822 SC381 (2*25GE))
pci:v000019E5d00000210*
ID_MODEL_FROM_DATABASE=Hi1822 Family (4*25GE)
@ -64826,6 +65042,9 @@ pci:v000019E5d00000211sv000019E5sd0000D12F*
pci:v000019E5d00000211sv000019E5sd0000D137*
ID_MODEL_FROM_DATABASE=Hi1822 Family (4*25GE) (Hi1822 SP581 (4*25GE))
pci:v000019E5d00000211sv000019E5sd0000D142*
ID_MODEL_FROM_DATABASE=Hi1822 Family (4*25GE) (Hi1822 SP583 (4*25GE))
pci:v000019E5d00000212*
ID_MODEL_FROM_DATABASE=Hi1822 Family (2*8G FC)
@ -64850,6 +65069,9 @@ pci:v000019E5d00001822sv000019E5sd0000D129*
pci:v000019E5d00001822sv000019E5sd0000D136*
ID_MODEL_FROM_DATABASE=Hi1822 Family (4*25GE) (Hi1822 SP580 (4*25GE))
pci:v000019E5d00001822sv000019E5sd0000D141*
ID_MODEL_FROM_DATABASE=Hi1822 Family (4*25GE) (Hi1822 SP583 (4*25GE))
pci:v000019E5d0000371E*
ID_MODEL_FROM_DATABASE=Hi1822 Family Virtual Bridge
@ -65318,6 +65540,12 @@ pci:v00001AB8d00004006*
pci:v00001AB9*
ID_VENDOR_FROM_DATABASE=Espia Srl
pci:v00001AC1*
ID_VENDOR_FROM_DATABASE=Global Unichip Corp.
pci:v00001AC1d0000089A*
ID_MODEL_FROM_DATABASE=Coral Edge TPU
pci:v00001AC8*
ID_VENDOR_FROM_DATABASE=Aeroflex Gaisler
@ -66380,6 +66608,9 @@ pci:v00001C5Cd00001284*
pci:v00001C5Cd00001285*
ID_MODEL_FROM_DATABASE=PC300 NVMe Solid State Drive 1TB
pci:v00001C5Cd00001327*
ID_MODEL_FROM_DATABASE=BC501 NVMe Solid State Drive 512GB
pci:v00001C5Cd00001504*
ID_MODEL_FROM_DATABASE=SC300 512GB M.2 2280 SATA Solid State Drive
@ -67145,6 +67376,9 @@ pci:v00001DBFd00000401*
pci:v00001DC5*
ID_VENDOR_FROM_DATABASE=FADU Inc.
pci:v00001DCD*
ID_VENDOR_FROM_DATABASE=Liqid Inc.
pci:v00001DD8*
ID_VENDOR_FROM_DATABASE=Pensando Systems Inc
@ -67376,6 +67610,12 @@ pci:v00001E24d00001635*
pci:v00001E26*
ID_VENDOR_FROM_DATABASE=Fujitsu Client Computing Limited
pci:v00001E36*
ID_VENDOR_FROM_DATABASE=Shanghai Enflame Technology Co. Ltd
pci:v00001E36d00000001*
ID_MODEL_FROM_DATABASE=T10 [CloudBlazer]
pci:v00001E38*
ID_VENDOR_FROM_DATABASE=Blaize, Inc
@ -67415,6 +67655,9 @@ pci:v00001E89d00000002*
pci:v00001E89d00000003*
ID_MODEL_FROM_DATABASE=Quantis-PCIe-240M
pci:v00001E94*
ID_VENDOR_FROM_DATABASE=Calian SED
pci:v00001FC0*
ID_VENDOR_FROM_DATABASE=Ascom (Finland) Oy
@ -72596,6 +72839,9 @@ pci:v00008086d0000101Esv00001179sd00000001*
pci:v00008086d0000101Esv00008086sd0000101E*
ID_MODEL_FROM_DATABASE=82540EP Gigabit Ethernet Controller (Mobile) (PRO/1000 MT Mobile Connection)
pci:v00008086d0000101F*
ID_MODEL_FROM_DATABASE=Ethernet Controller V710 for 5GBASE-T
pci:v00008086d00001026*
ID_MODEL_FROM_DATABASE=82545GM Gigabit Ethernet Controller
@ -74822,6 +75068,9 @@ pci:v00008086d00001528sv00001137sd000000BF*
pci:v00008086d00001528sv00001170sd00000052*
ID_MODEL_FROM_DATABASE=Ethernet Controller 10-Gigabit X540-AT2
pci:v00008086d00001528sv000015D9sd00000734*
ID_MODEL_FROM_DATABASE=Ethernet Controller 10-Gigabit X540-AT2 (AOC-STG-I2T)
pci:v00008086d00001528sv000017AAsd00001073*
ID_MODEL_FROM_DATABASE=Ethernet Controller 10-Gigabit X540-AT2 (ThinkServer X540-T2 AnyFabric)
@ -76019,6 +76268,9 @@ pci:v00008086d00001903sv00001028sd000006DC*
pci:v00008086d00001903sv00001028sd000006E4*
ID_MODEL_FROM_DATABASE=Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor Thermal Subsystem (XPS 15 9550)
pci:v00008086d00001903sv0000103Csd0000825B*
ID_MODEL_FROM_DATABASE=Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor Thermal Subsystem (OMEN-17-w001nv)
pci:v00008086d00001903sv000017AAsd0000225D*
ID_MODEL_FROM_DATABASE=Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor Thermal Subsystem (ThinkPad T480)
@ -76064,6 +76316,9 @@ pci:v00008086d00001910*
pci:v00008086d00001910sv00001028sd000006E4*
ID_MODEL_FROM_DATABASE=Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor Host Bridge/DRAM Registers (XPS 15 9550)
pci:v00008086d00001910sv0000103Csd0000825B*
ID_MODEL_FROM_DATABASE=Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor Host Bridge/DRAM Registers (OMEN-17-w001nv)
pci:v00008086d00001911*
ID_MODEL_FROM_DATABASE=Xeon E3-1200 v5/v6 / E3-1500 v5 / 6th/7th/8th Gen Core Processor Gaussian Mixture Model
@ -76103,6 +76358,9 @@ pci:v00008086d0000191B*
pci:v00008086d0000191Bsv00001028sd000006E4*
ID_MODEL_FROM_DATABASE=HD Graphics 530 (XPS 15 9550)
pci:v00008086d0000191Bsv0000103Csd0000825B*
ID_MODEL_FROM_DATABASE=HD Graphics 530 (OMEN-17-w001nv)
pci:v00008086d0000191D*
ID_MODEL_FROM_DATABASE=HD Graphics P530
@ -87827,6 +88085,9 @@ pci:v00008086d00003B42sv00001028sd0000040A*
pci:v00008086d00003B42sv00001028sd0000040B*
ID_MODEL_FROM_DATABASE=5 Series/3400 Series Chipset PCI Express Root Port 1 (Latitude E6510)
pci:v00008086d00003B42sv0000103Csd00001521*
ID_MODEL_FROM_DATABASE=5 Series/3400 Series Chipset PCI Express Root Port 1 (EliteBook 8540p)
pci:v00008086d00003B42sv0000144Dsd0000C06A*
ID_MODEL_FROM_DATABASE=5 Series/3400 Series Chipset PCI Express Root Port 1 (R730 Laptop)
@ -88805,6 +89066,9 @@ pci:v00008086d00005902*
pci:v00008086d00005904*
ID_MODEL_FROM_DATABASE=Xeon E3-1200 v6/7th Gen Core Processor Host Bridge/DRAM Registers
pci:v00008086d00005904sv00001025sd0000115F*
ID_MODEL_FROM_DATABASE=Xeon E3-1200 v6/7th Gen Core Processor Host Bridge/DRAM Registers (Aspire E5-575G)
pci:v00008086d00005904sv000017AAsd00002247*
ID_MODEL_FROM_DATABASE=Xeon E3-1200 v6/7th Gen Core Processor Host Bridge/DRAM Registers (ThinkPad T570)
@ -88844,6 +89108,9 @@ pci:v00008086d00005914sv000017AAsd0000225D*
pci:v00008086d00005916*
ID_MODEL_FROM_DATABASE=HD Graphics 620
pci:v00008086d00005916sv00001025sd00001094*
ID_MODEL_FROM_DATABASE=HD Graphics 620 (Aspire E5-575G)
pci:v00008086d00005916sv000017AAsd00002248*
ID_MODEL_FROM_DATABASE=HD Graphics 620 (ThinkPad T570)
@ -91052,6 +91319,9 @@ pci:v00008086d00009CE6*
pci:v00008086d00009D03*
ID_MODEL_FROM_DATABASE=Sunrise Point-LP SATA Controller [AHCI mode]
pci:v00008086d00009D03sv00001025sd0000115F*
ID_MODEL_FROM_DATABASE=Sunrise Point-LP SATA Controller [AHCI mode] (Acer Aspire E5-575G)
pci:v00008086d00009D03sv00001028sd000006DC*
ID_MODEL_FROM_DATABASE=Sunrise Point-LP SATA Controller [AHCI mode] (Latitude E7470)
@ -91112,6 +91382,9 @@ pci:v00008086d00009D1A*
pci:v00008086d00009D21*
ID_MODEL_FROM_DATABASE=Sunrise Point-LP PMC
pci:v00008086d00009D21sv00001025sd0000115F*
ID_MODEL_FROM_DATABASE=Sunrise Point-LP PMC (Acer Aspire E5-575G)
pci:v00008086d00009D21sv00001028sd000006DC*
ID_MODEL_FROM_DATABASE=Sunrise Point-LP PMC (Latitude E7470)
@ -91133,6 +91406,9 @@ pci:v00008086d00009D21sv000017AAsd0000382A*
pci:v00008086d00009D23*
ID_MODEL_FROM_DATABASE=Sunrise Point-LP SMBus
pci:v00008086d00009D23sv00001025sd0000115F*
ID_MODEL_FROM_DATABASE=Sunrise Point-LP SMBus (Acer Aspire E5-575G)
pci:v00008086d00009D23sv00001028sd000006DC*
ID_MODEL_FROM_DATABASE=Sunrise Point-LP SMBus (Latitude E7470)
@ -91172,6 +91448,9 @@ pci:v00008086d00009D2D*
pci:v00008086d00009D2F*
ID_MODEL_FROM_DATABASE=Sunrise Point-LP USB 3.0 xHCI Controller
pci:v00008086d00009D2Fsv00001025sd0000115F*
ID_MODEL_FROM_DATABASE=Sunrise Point-LP USB 3.0 xHCI Controller (Acer Aspire E5-575G)
pci:v00008086d00009D2Fsv00001028sd000006DC*
ID_MODEL_FROM_DATABASE=Sunrise Point-LP USB 3.0 xHCI Controller (Latitude E7470)
@ -91193,6 +91472,9 @@ pci:v00008086d00009D2Fsv000017AAsd0000382A*
pci:v00008086d00009D31*
ID_MODEL_FROM_DATABASE=Sunrise Point-LP Thermal subsystem
pci:v00008086d00009D31sv00001025sd0000115F*
ID_MODEL_FROM_DATABASE=Sunrise Point-LP Thermal subsystem (Acer Aspire E5-575G)
pci:v00008086d00009D31sv00001028sd000006DC*
ID_MODEL_FROM_DATABASE=Sunrise Point-LP Thermal subsystem (Latitude E7470)
@ -91220,6 +91502,9 @@ pci:v00008086d00009D35*
pci:v00008086d00009D3A*
ID_MODEL_FROM_DATABASE=Sunrise Point-LP CSME HECI #1
pci:v00008086d00009D3Asv00001025sd0000115F*
ID_MODEL_FROM_DATABASE=Sunrise Point-LP CSME HECI #1 (Acer Aspire E5-575G)
pci:v00008086d00009D3Asv00001028sd000006DC*
ID_MODEL_FROM_DATABASE=Sunrise Point-LP CSME HECI #1 (Latitude E7470)
@ -91280,6 +91565,9 @@ pci:v00008086d00009D56*
pci:v00008086d00009D58*
ID_MODEL_FROM_DATABASE=Sunrise Point-LP LPC Controller
pci:v00008086d00009D58sv00001025sd0000115F*
ID_MODEL_FROM_DATABASE=Sunrise Point-LP LPC Controller (Acer Aspire E5-575G)
pci:v00008086d00009D58sv000017AAsd00002247*
ID_MODEL_FROM_DATABASE=Sunrise Point-LP LPC Controller (ThinkPad T570)
@ -91289,6 +91577,9 @@ pci:v00008086d00009D58sv000017AAsd0000224F*
pci:v00008086d00009D60*
ID_MODEL_FROM_DATABASE=Sunrise Point-LP Serial IO I2C Controller #0
pci:v00008086d00009D60sv00001025sd0000115F*
ID_MODEL_FROM_DATABASE=Sunrise Point-LP Serial IO I2C Controller #0 (Acer Aspire E5-575G)
pci:v00008086d00009D60sv00001028sd000006F3*
ID_MODEL_FROM_DATABASE=Sunrise Point-LP Serial IO I2C Controller #0 (Latitude 3570)
@ -91337,6 +91628,9 @@ pci:v00008086d00009D70sv000017AAsd0000382A*
pci:v00008086d00009D71*
ID_MODEL_FROM_DATABASE=Sunrise Point-LP HD Audio
pci:v00008086d00009D71sv00001025sd00001094*
ID_MODEL_FROM_DATABASE=Sunrise Point-LP HD Audio (Acer Aspire E5-575G)
pci:v00008086d00009D71sv000017AAsd0000224F*
ID_MODEL_FROM_DATABASE=Sunrise Point-LP HD Audio (ThinkPad X1 Carbon 5th Gen)
@ -91502,6 +91796,9 @@ pci:v00008086d0000A103*
pci:v00008086d0000A103sv00001028sd000006E4*
ID_MODEL_FROM_DATABASE=HM170/QM170 Chipset SATA Controller [AHCI Mode] (XPS 15 9550)
pci:v00008086d0000A103sv0000103Csd0000825B*
ID_MODEL_FROM_DATABASE=HM170/QM170 Chipset SATA Controller [AHCI Mode] (OMEN-17-w001nv)
pci:v00008086d0000A105*
ID_MODEL_FROM_DATABASE=Sunrise Point-H SATA Controller [RAID mode]
@ -91571,6 +91868,9 @@ pci:v00008086d0000A121*
pci:v00008086d0000A121sv00001028sd000006E4*
ID_MODEL_FROM_DATABASE=100 Series/C230 Series Chipset Family Power Management Controller (XPS 15 9550)
pci:v00008086d0000A121sv0000103Csd0000825B*
ID_MODEL_FROM_DATABASE=100 Series/C230 Series Chipset Family Power Management Controller (OMEN-17-w001nv)
pci:v00008086d0000A122*
ID_MODEL_FROM_DATABASE=Sunrise Point-H cAVS
@ -91580,6 +91880,9 @@ pci:v00008086d0000A123*
pci:v00008086d0000A123sv00001028sd000006E4*
ID_MODEL_FROM_DATABASE=100 Series/C230 Series Chipset Family SMBus (XPS 15 9550)
pci:v00008086d0000A123sv0000103Csd0000825B*
ID_MODEL_FROM_DATABASE=100 Series/C230 Series Chipset Family SMBus (OMEN-17-w001nv)
pci:v00008086d0000A124*
ID_MODEL_FROM_DATABASE=100 Series/C230 Series Chipset Family SPI Controller
@ -91607,6 +91910,9 @@ pci:v00008086d0000A12F*
pci:v00008086d0000A12Fsv00001028sd000006E4*
ID_MODEL_FROM_DATABASE=100 Series/C230 Series Chipset Family USB 3.0 xHCI Controller (XPS 15 9550)
pci:v00008086d0000A12Fsv0000103Csd0000825B*
ID_MODEL_FROM_DATABASE=100 Series/C230 Series Chipset Family USB 3.0 xHCI Controller (OMEN-17-w001nv)
pci:v00008086d0000A130*
ID_MODEL_FROM_DATABASE=100 Series/C230 Series Chipset Family USB Device Controller (OTG)
@ -91616,6 +91922,9 @@ pci:v00008086d0000A131*
pci:v00008086d0000A131sv00001028sd000006E4*
ID_MODEL_FROM_DATABASE=100 Series/C230 Series Chipset Family Thermal Subsystem (XPS 15 9550)
pci:v00008086d0000A131sv0000103Csd0000825B*
ID_MODEL_FROM_DATABASE=100 Series/C230 Series Chipset Family Thermal Subsystem (OMEN-17-w001nv)
pci:v00008086d0000A133*
ID_MODEL_FROM_DATABASE=Sunrise Point-H Northpeak ACPI Function
@ -91628,6 +91937,9 @@ pci:v00008086d0000A13A*
pci:v00008086d0000A13Asv00001028sd000006E4*
ID_MODEL_FROM_DATABASE=100 Series/C230 Series Chipset Family MEI Controller #1 (XPS 15 9550)
pci:v00008086d0000A13Asv0000103Csd0000825B*
ID_MODEL_FROM_DATABASE=100 Series/C230 Series Chipset Family MEI Controller #1 (OMEN-17-w001nv)
pci:v00008086d0000A13B*
ID_MODEL_FROM_DATABASE=100 Series/C230 Series Chipset Family MEI Controller #2
@ -91688,6 +92000,9 @@ pci:v00008086d0000A14E*
pci:v00008086d0000A14Esv00001028sd000006E4*
ID_MODEL_FROM_DATABASE=HM170 Chipset LPC/eSPI Controller (XPS 15 9550)
pci:v00008086d0000A14Esv0000103Csd0000825B*
ID_MODEL_FROM_DATABASE=HM170 Chipset LPC/eSPI Controller (OMEN-17-w001nv)
pci:v00008086d0000A14F*
ID_MODEL_FROM_DATABASE=Sunrise Point-H LPC Controller
@ -91745,6 +92060,9 @@ pci:v00008086d0000A160*
pci:v00008086d0000A160sv00001028sd000006E4*
ID_MODEL_FROM_DATABASE=100 Series/C230 Series Chipset Family Serial IO I2C Controller #0 (XPS 15 9550)
pci:v00008086d0000A160sv0000103Csd0000825B*
ID_MODEL_FROM_DATABASE=100 Series/C230 Series Chipset Family Serial IO I2C Controller #0 (OMEN-17-w001nv)
pci:v00008086d0000A161*
ID_MODEL_FROM_DATABASE=100 Series/C230 Series Chipset Family Serial IO I2C Controller #1
@ -91778,6 +92096,9 @@ pci:v00008086d0000A170*
pci:v00008086d0000A170sv00001028sd000006E4*
ID_MODEL_FROM_DATABASE=100 Series/C230 Series Chipset Family HD Audio Controller (XPS 15 9550)
pci:v00008086d0000A170sv0000103Csd0000825B*
ID_MODEL_FROM_DATABASE=100 Series/C230 Series Chipset Family HD Audio Controller (OMEN-17-w001nv)
pci:v00008086d0000A171*
ID_MODEL_FROM_DATABASE=CM238 HD Audio Controller
@ -92402,6 +92723,9 @@ pci:v00008086d0000F1A5*
pci:v00008086d0000F1A6*
ID_MODEL_FROM_DATABASE=SSD Pro 7600p/760p/E 6100p Series
pci:v00008086d0000F1A6sv00008086sd0000390B*
ID_MODEL_FROM_DATABASE=SSD Pro 7600p/760p/E 6100p Series (Intel Corporation SSD Pro 7600p/760p/E 6100p Series [NVM Express])
pci:v00008086d0000F1A8*
ID_MODEL_FROM_DATABASE=SSD 660P Series

179
hwdb.d/20-usb-vendor-model.hwdb
View File

@ -68,6 +68,9 @@ usb:v0085*
usb:v0085p0600*
ID_MODEL_FROM_DATABASE=eBook Reader
usb:v0102*
ID_VENDOR_FROM_DATABASE=miniSTREAK
usb:v0105*
ID_VENDOR_FROM_DATABASE=Trust International B.V.
@ -458,6 +461,9 @@ usb:v03EBp7800*
usb:v03EBp800C*
ID_MODEL_FROM_DATABASE=Airspy HF+
usb:v03EBpFF01*
ID_MODEL_FROM_DATABASE=WootingOne
usb:v03EBpFF02*
ID_MODEL_FROM_DATABASE=WootingTwo
@ -2048,6 +2054,9 @@ usb:v03F0pC111*
usb:v03F0pC202*
ID_MODEL_FROM_DATABASE=PhotoSmart 8200 series
usb:v03F0pC211*
ID_MODEL_FROM_DATABASE=Deskjet 2540 series
usb:v03F0pC302*
ID_MODEL_FROM_DATABASE=DeskJet D2300
@ -2336,6 +2345,9 @@ usb:v0403p8371*
usb:v0403p8372*
ID_MODEL_FROM_DATABASE=FT8U100AX Serial Port
usb:v0403p8508*
ID_MODEL_FROM_DATABASE=Selectronic SP PRO
usb:v0403p87D0*
ID_MODEL_FROM_DATABASE=Cressi Dive Computer Interface
@ -2378,6 +2390,9 @@ usb:v0403p9136*
usb:v0403p9E90*
ID_MODEL_FROM_DATABASE=Marvell OpenRD Base/Client
usb:v0403p9F08*
ID_MODEL_FROM_DATABASE=CIB-1894 Conclusion SmartLink Box:
usb:v0403p9F80*
ID_MODEL_FROM_DATABASE=Ewert Energy Systems CANdapter
@ -3437,6 +3452,9 @@ usb:v040B*
usb:v040Bp0A68*
ID_MODEL_FROM_DATABASE=Func MS-3 gaming mouse [WT6573F MCU]
usb:v040Bp2000*
ID_MODEL_FROM_DATABASE=wired Keyboard [Dynex DX-WRK1401]
usb:v040Bp2367*
ID_MODEL_FROM_DATABASE=Human Interface Device [HP CalcPad 200 Calculator and Numeric Keypad]
@ -5882,6 +5900,9 @@ usb:v0450*
usb:v0451*
ID_VENDOR_FROM_DATABASE=Texas Instruments, Inc.
usb:v0451p0422*
ID_MODEL_FROM_DATABASE=TUSB422 Port Controller with Power Delivery
usb:v0451p1234*
ID_MODEL_FROM_DATABASE=Bluetooth Device
@ -5891,9 +5912,18 @@ usb:v0451p1428*
usb:v0451p1446*
ID_MODEL_FROM_DATABASE=TUSB2040/2070 Hub
usb:v0451p16A2*
ID_MODEL_FROM_DATABASE=CC Debugger
usb:v0451p16A6*
ID_MODEL_FROM_DATABASE=BM-USBD1 BlueRobin RF heart rate sensor receiver
usb:v0451p16A8*
ID_MODEL_FROM_DATABASE=CC2531 ZigBee
usb:v0451p16AE*
ID_MODEL_FROM_DATABASE=CC2531 Dongle
usb:v0451p2036*
ID_MODEL_FROM_DATABASE=TUSB2036 Hub
@ -5996,6 +6026,9 @@ usb:v0451pE013*
usb:v0451pE01C*
ID_MODEL_FROM_DATABASE=Data Collection Sled [Nspire Lab Cradle, Nspire Datatracker Cradle]
usb:v0451pE01E*
ID_MODEL_FROM_DATABASE=Nspire™ CX Navigator™ Access Point
usb:v0451pE01F*
ID_MODEL_FROM_DATABASE=Python Adapter (firmware install mode)
@ -6092,6 +6125,9 @@ usb:v0458p0003*
usb:v0458p0006*
ID_MODEL_FROM_DATABASE=Easy Mouse+
usb:v0458p0007*
ID_MODEL_FROM_DATABASE=Trackbar Emotion
usb:v0458p000B*
ID_MODEL_FROM_DATABASE=NetMouse Wheel(P+U)
@ -6710,6 +6746,9 @@ usb:v045Ep00CE*
usb:v045Ep00D1*
ID_MODEL_FROM_DATABASE=Optical Mouse with Tilt Wheel
usb:v045Ep00D2*
ID_MODEL_FROM_DATABASE=Notebook Optical Mouse with Tilt Wheel
usb:v045Ep00DA*
ID_MODEL_FROM_DATABASE=eHome Infrared Receiver
@ -7364,6 +7403,9 @@ usb:v045Ep07F8*
usb:v045Ep07FD*
ID_MODEL_FROM_DATABASE=Nano Transceiver 1.1
usb:v045Ep0810*
ID_MODEL_FROM_DATABASE=LifeCam HD-3000
usb:v045Ep0900*
ID_MODEL_FROM_DATABASE=Surface Dock Hub
@ -7595,6 +7637,9 @@ usb:v0461p4D75*
usb:v0461p4D81*
ID_MODEL_FROM_DATABASE=Dell N889 Optical Mouse
usb:v0461p4D8A*
ID_MODEL_FROM_DATABASE=HP Multimedia Keyboard
usb:v0461p4D91*
ID_MODEL_FROM_DATABASE=Laser mouse M-D16DL
@ -7613,6 +7658,9 @@ usb:v0461p4DE7*
usb:v0461p4E04*
ID_MODEL_FROM_DATABASE=Lenovo Keyboard KB1021
usb:v0461p4E6F*
ID_MODEL_FROM_DATABASE=Acer Wired Keyboard Model KBAY211
usb:v0463*
ID_VENDOR_FROM_DATABASE=MGE UPS Systems
@ -7697,6 +7745,9 @@ usb:v046Ap0106*
usb:v046Ap010D*
ID_MODEL_FROM_DATABASE=MX-Board 3.0 Keyboard
usb:v046Ap0180*
ID_MODEL_FROM_DATABASE=Strait 3.0
usb:v046ApB090*
ID_MODEL_FROM_DATABASE=Keyboard
@ -8168,6 +8219,9 @@ usb:v046Dp0A4D*
usb:v046Dp0A5B*
ID_MODEL_FROM_DATABASE=G933 Wireless Headset Dongle
usb:v046Dp0A5D*
ID_MODEL_FROM_DATABASE=G933 Headset Battery Charger
usb:v046Dp0A66*
ID_MODEL_FROM_DATABASE=[G533 Wireless Headset Dongle]
@ -8555,6 +8609,9 @@ usb:v046DpC245*
usb:v046DpC246*
ID_MODEL_FROM_DATABASE=Gaming Mouse G300
usb:v046DpC247*
ID_MODEL_FROM_DATABASE=G100S Optical Gaming Mouse
usb:v046DpC248*
ID_MODEL_FROM_DATABASE=G105 Gaming Keyboard
@ -8699,6 +8756,9 @@ usb:v046DpC326*
usb:v046DpC328*
ID_MODEL_FROM_DATABASE=Corded Keyboard K280e
usb:v046DpC32B*
ID_MODEL_FROM_DATABASE=G910 Orion Spark Mechanical Keyboard
usb:v046DpC332*
ID_MODEL_FROM_DATABASE=G502 Proteus Spectrum Optical Mouse
@ -8822,6 +8882,12 @@ usb:v046DpC532*
usb:v046DpC534*
ID_MODEL_FROM_DATABASE=Unifying Receiver
usb:v046DpC537*
ID_MODEL_FROM_DATABASE=Cordless Mouse Receiver
usb:v046DpC53A*
ID_MODEL_FROM_DATABASE=PowerPlay Wireless Charging System
usb:v046DpC603*
ID_MODEL_FROM_DATABASE=3Dconnexion Spacemouse Plus XT
@ -9683,6 +9749,9 @@ usb:v047F*
usb:v047Fp0101*
ID_MODEL_FROM_DATABASE=Bulk Driver
usb:v047Fp02EE*
ID_MODEL_FROM_DATABASE=BT600
usb:v047Fp0301*
ID_MODEL_FROM_DATABASE=Bulk Driver
@ -9710,6 +9779,9 @@ usb:v047FpC008*
usb:v047FpC00E*
ID_MODEL_FROM_DATABASE=Blackwire C310 headset
usb:v047FpC03B*
ID_MODEL_FROM_DATABASE=HD1
usb:v0480*
ID_VENDOR_FROM_DATABASE=Toshiba America Inc
@ -9737,6 +9809,9 @@ usb:v0480p0820*
usb:v0480p0821*
ID_MODEL_FROM_DATABASE=Canvio Advance 2TB model DTC920
usb:v0480p0900*
ID_MODEL_FROM_DATABASE=MQ04UBF100
usb:v0480pA006*
ID_MODEL_FROM_DATABASE=External Disk 1.5TB
@ -9944,6 +10019,9 @@ usb:v0483p91D1*
usb:v0483pA171*
ID_MODEL_FROM_DATABASE=ThermaData WiFi
usb:v0483pA2E0*
ID_MODEL_FROM_DATABASE=BMeasure instrument
usb:v0483pDF11*
ID_MODEL_FROM_DATABASE=STM Device in DFU Mode
@ -10031,6 +10109,9 @@ usb:v048Dp1165*
usb:v048Dp1172*
ID_MODEL_FROM_DATABASE=Flash Drive
usb:v048Dp1234*
ID_MODEL_FROM_DATABASE=Mass storage
usb:v048Dp1336*
ID_MODEL_FROM_DATABASE=SD/MMC Cardreader
@ -11066,6 +11147,9 @@ usb:v04A9p10CA*
usb:v04A9p10E3*
ID_MODEL_FROM_DATABASE=PIXMA iX6850 Printer
usb:v04A9p12FE*
ID_MODEL_FROM_DATABASE=Printer in service mode
usb:v04A9p1404*
ID_MODEL_FROM_DATABASE=W6400PG
@ -11411,6 +11495,9 @@ usb:v04A9p178D*
usb:v04A9p180B*
ID_MODEL_FROM_DATABASE=PIXMA MG3000 series
usb:v04A9p1856*
ID_MODEL_FROM_DATABASE=PIXMA TS6250
usb:v04A9p1900*
ID_MODEL_FROM_DATABASE=CanoScan LiDE 90
@ -11615,6 +11702,9 @@ usb:v04A9p2634*
usb:v04A9p2635*
ID_MODEL_FROM_DATABASE=MPC190
usb:v04A9p2636*
ID_MODEL_FROM_DATABASE=LBP3200
usb:v04A9p2637*
ID_MODEL_FROM_DATABASE=iR C6800
@ -11657,12 +11747,18 @@ usb:v04A9p2650*
usb:v04A9p2651*
ID_MODEL_FROM_DATABASE=iR 3100C EUR
usb:v04A9p2654*
ID_MODEL_FROM_DATABASE=LBP3600
usb:v04A9p2655*
ID_MODEL_FROM_DATABASE=FP-L170/MF350/L380/L398
usb:v04A9p2656*
ID_MODEL_FROM_DATABASE=iR1510-1670 CAPT Printer
usb:v04A9p2657*
ID_MODEL_FROM_DATABASE=LBP3210
usb:v04A9p2659*
ID_MODEL_FROM_DATABASE=MF8100
@ -11703,7 +11799,7 @@ usb:v04A9p2669*
ID_MODEL_FROM_DATABASE=iR105PLUS
usb:v04A9p266A*
ID_MODEL_FROM_DATABASE=CAPT Device
ID_MODEL_FROM_DATABASE=LBP3000
usb:v04A9p266B*
ID_MODEL_FROM_DATABASE=iR8070
@ -11748,7 +11844,7 @@ usb:v04A9p2678*
ID_MODEL_FROM_DATABASE=iR 2570C EUR
usb:v04A9p2679*
ID_MODEL_FROM_DATABASE=CAPT Device
ID_MODEL_FROM_DATABASE=LBP5000
usb:v04A9p267A*
ID_MODEL_FROM_DATABASE=iR2016
@ -11759,6 +11855,9 @@ usb:v04A9p267B*
usb:v04A9p267D*
ID_MODEL_FROM_DATABASE=MF7100 series
usb:v04A9p267E*
ID_MODEL_FROM_DATABASE=LBP3300
usb:v04A9p2684*
ID_MODEL_FROM_DATABASE=MF3200 series
@ -11777,6 +11876,9 @@ usb:v04A9p2689*
usb:v04A9p268A*
ID_MODEL_FROM_DATABASE=LC310/L390/L408S
usb:v04A9p268B*
ID_MODEL_FROM_DATABASE=LBP3500
usb:v04A9p268C*
ID_MODEL_FROM_DATABASE=iR C6870
@ -11792,9 +11894,15 @@ usb:v04A9p268F*
usb:v04A9p2691*
ID_MODEL_FROM_DATABASE=iR7105
usb:v04A9p26A1*
ID_MODEL_FROM_DATABASE=LBP5300
usb:v04A9p26A3*
ID_MODEL_FROM_DATABASE=MF4100 series
usb:v04A9p26A4*
ID_MODEL_FROM_DATABASE=LBP5100
usb:v04A9p26B0*
ID_MODEL_FROM_DATABASE=MF4600 series
@ -11807,21 +11915,54 @@ usb:v04A9p26B5*
usb:v04A9p26B6*
ID_MODEL_FROM_DATABASE=FAX-L140/L130
usb:v04A9p26B9*
ID_MODEL_FROM_DATABASE=LBP3310
usb:v04A9p26BA*
ID_MODEL_FROM_DATABASE=LBP5050
usb:v04A9p26DA*
ID_MODEL_FROM_DATABASE=LBP3010B printer
ID_MODEL_FROM_DATABASE=LBP3010/LBP3018/LBP3050
usb:v04A9p26DB*
ID_MODEL_FROM_DATABASE=LBP3100/LBP3108/LBP3150
usb:v04A9p26E6*
ID_MODEL_FROM_DATABASE=iR1024
usb:v04A9p26EA*
ID_MODEL_FROM_DATABASE=LBP9100C
usb:v04A9p26EE*
ID_MODEL_FROM_DATABASE=MF4320-4350
usb:v04A9p26F1*
ID_MODEL_FROM_DATABASE=LBP7200C
usb:v04A9p26FF*
ID_MODEL_FROM_DATABASE=LBP6300
usb:v04A9p271A*
ID_MODEL_FROM_DATABASE=LBP6000
usb:v04A9p271B*
ID_MODEL_FROM_DATABASE=LBP6200
usb:v04A9p271C*
ID_MODEL_FROM_DATABASE=LBP7010C/7018C
usb:v04A9p2736*
ID_MODEL_FROM_DATABASE=I-SENSYS MF4550d
usb:v04A9p2737*
ID_MODEL_FROM_DATABASE=MF4410
usb:v04A9p2771*
ID_MODEL_FROM_DATABASE=LBP6020
usb:v04A9p2796*
ID_MODEL_FROM_DATABASE=LBP6230/6240
usb:v04A9p3041*
ID_MODEL_FROM_DATABASE=PowerShot S10
@ -13028,6 +13169,9 @@ usb:v04B0p042A*
usb:v04B0p0430*
ID_MODEL_FROM_DATABASE=D7100
usb:v04B0p0436*
ID_MODEL_FROM_DATABASE=D810
usb:v04B0p043F*
ID_MODEL_FROM_DATABASE=D5600
@ -13211,6 +13355,9 @@ usb:v04B4p4616*
usb:v04B4p4624*
ID_MODEL_FROM_DATABASE=DS-Xtreme Flash Card
usb:v04B4p4717*
ID_MODEL_FROM_DATABASE=West Bridge
usb:v04B4p5201*
ID_MODEL_FROM_DATABASE=Combi Keyboard-Hub (Hub)
@ -35001,7 +35148,7 @@ usb:v09C2*
ID_VENDOR_FROM_DATABASE=Nisca Corp.
usb:v09C3*
ID_VENDOR_FROM_DATABASE=ActivCard, Inc.
ID_VENDOR_FROM_DATABASE=HID Global
usb:v09C3p0007*
ID_MODEL_FROM_DATABASE=Reader V2
@ -35012,6 +35159,24 @@ usb:v09C3p0008*
usb:v09C3p0014*
ID_MODEL_FROM_DATABASE=ActivIdentity ActivKey SIM USB Token
usb:v09C3p0028*
ID_MODEL_FROM_DATABASE=Crescendo Key
usb:v09C3p0029*
ID_MODEL_FROM_DATABASE=Crescendo Key
usb:v09C3p002A*
ID_MODEL_FROM_DATABASE=Crescendo Key
usb:v09C3p002B*
ID_MODEL_FROM_DATABASE=Crescendo Key
usb:v09C3p002C*
ID_MODEL_FROM_DATABASE=Crescendo Key
usb:v09C3p002E*
ID_MODEL_FROM_DATABASE=Crescendo Key
usb:v09C4*
ID_VENDOR_FROM_DATABASE=ACTiSYS Corp.
@ -57887,6 +58052,12 @@ usb:v2548p1001*
usb:v2548p1002*
ID_MODEL_FROM_DATABASE=CEC Adapter
usb:v25B5*
ID_VENDOR_FROM_DATABASE=FlatFrog
usb:v25B5p0002*
ID_MODEL_FROM_DATABASE=Multitouch 3200
usb:v2632*
ID_VENDOR_FROM_DATABASE=TwinMOS

29
hwdb.d/60-keyboard.hwdb
View File

@ -973,16 +973,16 @@ evdev:input:b0003v046Dp00FE*
KEYBOARD_KEY_c1018=media # Media button
# MX5000 keyboard (HID proxy mode and bluetooth matches)
# The 4 buttons below the LCD send codes 0xc100c - 0xc100f. They only send
# these codes when the LCD is displaying text send to it. These codes are
# directly consumed by recent versions of lcdproc when it is driving the LCD,
# so these codes should not be mapped
evdev:input:b0003v046DpB305*
evdev:input:b0005v046DpB305*
KEYBOARD_KEY_c0230=zoomreset # HUT says fullscreen, kbd says 100%
KEYBOARD_KEY_c1004=send # Send and receive / sync button
KEYBOARD_KEY_c1006=coffee # Status (online/away) button
KEYBOARD_KEY_c1007=camera # Webcam button
KEYBOARD_KEY_c100c=kbd_lcd_menu1 # 1st button below the builtin LCD
KEYBOARD_KEY_c100d=kbd_lcd_menu4 # 4th button below the builtin LCD
KEYBOARD_KEY_c100e=kbd_lcd_menu2 # 2nd button below the builtin LCD
KEYBOARD_KEY_c100f=kbd_lcd_menu3 # 3th button below the builtin LCD
KEYBOARD_KEY_c1038=prog1 # Smartkey A → XF86Launch1
KEYBOARD_KEY_c1039=prog2 # Smartkey B → XF86Launch2
KEYBOARD_KEY_c103a=prog3 # Smartkey C → XF86Launch3
@ -1200,6 +1200,19 @@ evdev:name:MSI Laptop hotkeys:dmi:bvn*:bvr*:bd*:svn*:pnM[iI][cC][rR][oO]-S[tT][a
KEYBOARD_KEY_0213=f22
KEYBOARD_KEY_0214=f23
###########################################################
# Olimex
###########################################################
# Teres-I
evdev:input:b0003v15BAp003C*
KEYBOARD_KEY_70066=sleep # Fn+F1
KEYBOARD_KEY_700f6=wlan # Fn+F2
KEYBOARD_KEY_700c7=f21 # Fn+F3 touchpad toggle
KEYBOARD_KEY_7006f=brightnessdown # Fn+F7
KEYBOARD_KEY_70070=brightnessup # Fn+F8
KEYBOARD_KEY_7006e=switchvideomode # Fn+F9
###########################################################
# OLPC
###########################################################
@ -1558,6 +1571,14 @@ evdev:atkbd:dmi:bvn*:bvr*:bd*:svnVIA:pnK8N800:pvr*
evdev:name:SIPODEV USB Composite Device:dmi:bvn*:bvr*:bd*:svnVIOS:pnLTH17:pvr*
KEYBOARD_KEY_70073=f21 # Touchpad toggle
###########################################################
# WeiHeng
###########################################################
# P325J
evdev:atkbd:dmi:bvn*:bvr*:bd*:svnINET:pnP325J:pvr*
KEYBOARD_KEY_76=f21 # Touchpad toggle
###########################################################
# Zepto
###########################################################

20
hwdb.d/60-sensor.hwdb
View File

@ -41,11 +41,15 @@
#
# Allowed properties are:
# ACCEL_MOUNT_MATRIX=<matrix>
# PROXIMITY_NEAR_LEVEL=<value>
#
# where <matrix> is a mount-matrix in the format specified in the IIO
# subsystem[1]. The default, when unset, is equivalent to:
# ACCEL_MOUNT_MATRIX=1, 0, 0; 0, 1, 0; 0, 0, 1
# eg. the identity matrix.
# and <value> is an integer value above which an object is considered
# close by a proximity sensor:
# PROXIMITY_NEAR_LEVEL=100
#
# [1]: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=dfc57732ad38f93ae6232a3b4e64fd077383a0f1
#
@ -209,6 +213,10 @@ sensor:modalias:acpi:KIOX000A*:dmi:*:svnConnect:pnTablet9:*
sensor:modalias:acpi:KIOX000A*:dmi:*:svncube:pni1-TF:*
ACCEL_MOUNT_MATRIX=1, 0, 0; 0, -1, 0; 0, 0, 1
# Cube i7
sensor:modalias:acpi:SMO8500*:dmi:*:svncube:pni7:*
ACCEL_MOUNT_MATRIX=1, 0, 0; 0, -1, 0; 0, 0, 1
# Cube i7 Stylus
sensor:modalias:acpi:KIOX000A*:dmi:*:svnCube:pni7Stylus:*
ACCEL_MOUNT_MATRIX=-1, 0, 0; 0, 1, 0; 0, 0, 1
@ -384,7 +392,7 @@ sensor:modalias:acpi:KIOX000A*:dmi:*svnLAMINA:pnT-1016BNORD*
sensor:modalias:acpi:NCPE0388*:dmi:*:rnLenovoYOGA510-14IKB:*
ACCEL_MOUNT_MATRIX=-1, 0, 0; 0, -1, 0; 0, 0, 1
sensor:modalias:acpi:BOSC0200:BOSC0200:dmi:*ThinkPadYoga11e3rdGen*
sensor:modalias:acpi:BOSC0200*:dmi:*ThinkPadYoga11e3rdGen*
ACCEL_MOUNT_MATRIX=0, 1, 0; -1, 0, 0; 0, 0, 1
# Miix3-1030
@ -431,6 +439,12 @@ sensor:modalias:acpi:KIOX000A*:dmi:*:svnLINX*:pnLINX12*64:*
#########################################
# Medion
#########################################
# Medion Akoya E1239T MD60568
sensor:modalias:acpi:KIOX0009*:dmi:*:svnMEDION:pnE1239TMD60568:*
ACCEL_MOUNT_MATRIX=1, 0, 0; 0, -1, 0; 0, 0, 1
# Medion Akoya E2212T MD99720
sensor:modalias:acpi:SMO8500*:dmi:*:svnMEDION:pnAkoyaE2212TMD99720:*
ACCEL_MOUNT_MATRIX=-1, 0, 0; 0, 1, 0; 0, 0, 1
@ -473,6 +487,10 @@ sensor:modalias:acpi:KIOX000A*:dmi:*:svnTMAX:pnTM800W560L:*
sensor:modalias:acpi:KIOX000A*:dmi:*:svnTMAX:pnTM101W610L:*
ACCEL_MOUNT_MATRIX=0, -1, 0; -1, 0, 0; 0, 0, 1
# Nuvision Encite Split 11. NES11-C432SSA
sensor:modalias:acpi:BOSC0200*:dmi:*:svnNuvision:pnNES11:*
ACCEL_MOUNT_MATRIX=1, 0, 0; 0, -1, 0; 0, 0, 1
#########################################
# Onda
#########################################

1
hwdb.d/acpi_id_registry.html
View File

@ -96,6 +96,7 @@
<tr class="even"><td>Amazon Corporation</td><td>AMZN</td><td>02/06/2019</td> </tr>
<tr class="odd"><td>ASEM S.p.A.</td><td>ASEM</td><td>04/29/2019</td> </tr>
<tr class="even"><td>Fujitsu Limited</td><td>FUJI</td><td>06/18/2019</td> </tr>
<tr class="odd"><td>Phytium Technology Co. Ltd.</td><td>PHYT</td><td>02/14/2020</td> </tr>
</tbody>
</table>
</body>

1410
hwdb.d/ma-large.txt
View File

File diff suppressed because it is too large Load Diff

273
hwdb.d/ma-medium.txt
View File

@ -1133,12 +1133,6 @@ A4-DA-22 (hex) DURATECH Enterprise,LLC
Seoul 08501
KR
A4-DA-22 (hex) Abetechs GmbH
A00000-AFFFFF (base 16) Abetechs GmbH
Niermannsweg 11
Erkrath North Rhine-Westphalia 40699
DE
A4-DA-22 (hex) LORIOT AG
400000-4FFFFF (base 16) LORIOT AG
Zuercherstrasse 68
@ -1241,12 +1235,6 @@ B00000-BFFFFF (base 16) ThirdReality, Inc
SHEN ZHEN GUANGDONG 518000
CN
9C-43-1E (hex) Midas Technology DBA Phoenix Audio Technologies
E00000-EFFFFF (base 16) Midas Technology DBA Phoenix Audio Technologies
16 Goodyear #120
Irvine CA 92618
US
F8-B5-68 (hex) Dongwoo Engineering Co.,Ltd
300000-3FFFFF (base 16) Dongwoo Engineering Co.,Ltd
#311, dREC Techno 9-ro, Yuseong-gu
@ -3686,12 +3674,6 @@ A00000-AFFFFF (base 16) hyBee Inc.
Qingdao Shandong 266000
CN
94-05-BB (hex) LTE-X, Inc
700000-7FFFFF (base 16) LTE-X, Inc
2-2-20 Higashi-Shinagawa
Shinagawa Tokyo 1400002
JP
94-05-BB (hex) BAE Systems
E00000-EFFFFF (base 16) BAE Systems
21 continental boulevard
@ -3710,12 +3692,60 @@ B00000-BFFFFF (base 16) A-dec Inc.
Newberg OR 97132
US
C0-9B-F4 (hex) LTD Delovoy Office
600000-6FFFFF (base 16) LTD Delovoy Office
Block “B”, floor 6, build 4/1, Stroiteley blvd
Krasnogorsk 143401
RU
94-05-BB (hex) LTE-X, Inc
700000-7FFFFF (base 16) LTE-X, Inc
4F Ginza Showa Dori Building 8-14-14 Ginza
Chuo-ku Tokyo 104-0062
JP
F4-90-CB (hex) TEQ SA
700000-7FFFFF (base 16) TEQ SA
Via al Municipio 16
Barbengo Ticino 6917
CH
9C-43-1E (hex) Midas Technology, Inc. dba Stem Audio / Phoenix Au
E00000-EFFFFF (base 16) Midas Technology, Inc. dba Stem Audio / Phoenix Au
2552 White Road, Suite A
Irvine CA 92614
US
E8-B4-70 (hex) YAWATA ELECTRIC INDUSTRIAL CO.,LTD.
400000-4FFFFF (base 16) YAWATA ELECTRIC INDUSTRIAL CO.,LTD.
1-17-1 Ohmorihigashi
Ohta-ku Tokyo 143-0012
JP
A4-DA-22 (hex) Grundig
A00000-AFFFFF (base 16) Grundig
Steinhof 39
Erkrath North Rhine-Westphalia 40699
DE
E8-B4-70 (hex) Tibit Communications
700000-7FFFFF (base 16) Tibit Communications
1 Willowbrook Court, Suite 150
Petaluma CA 94954
US
94-FB-A7 (hex) Shanghai Hyco Genyong Technology Co., Ltd.
900000-9FFFFF (base 16) Shanghai Hyco Genyong Technology Co., Ltd.
Room 105, 1/F, Building B, No.999 of Huaxu Road, Qingpu District, Shanghai, China
Shanghai 201702
CN
94-FB-A7 (hex) Creotech Instruments S.A.
D00000-DFFFFF (base 16) Creotech Instruments S.A.
ul. Gen. L. Okulickiego 7/9
Piaseczno Mazovia 05-500
PL
4C-4B-F9 (hex) Shenzhen dingsheng technology co., LTD
400000-4FFFFF (base 16) Shenzhen dingsheng technology co., LTD
Floor 3, building 5, kaijeda industrial zone, no.97, huaxing road, langkou community, dalang street, longhua district
@ -7175,6 +7205,54 @@ F4-90-CB (hex) Airbeam Wireless Technologies Inc.
Richmond British Columbia V6W 1J8
CA
C0-9B-F4 (hex) Annapurna labs
000000-0FFFFF (base 16) Annapurna labs
Matam Scientific Industries Center, Building 8.2
Mail box 15123 Haifa 3508409
IL
C0-9B-F4 (hex) Alcatraz AI Inc.
900000-9FFFFF (base 16) Alcatraz AI Inc.
1808 El Camino Real
Redwood City CA 94063
US
F4-90-CB (hex) RSAE Labs Inc
E00000-EFFFFF (base 16) RSAE Labs Inc
400 E 16th St
Panama City FL 32405
US
C0-9B-F4 (hex) Big Dutchman International GmbH
700000-7FFFFF (base 16) Big Dutchman International GmbH
Auf der Lage, 2
Vechta Niedersachsen 49377
DE
E8-B4-70 (hex) Anduril Industries
C00000-CFFFFF (base 16) Anduril Industries
2272 Michelson Dr
Irvine CA 92612
US
C0-9B-F4 (hex) Continental Automotive Component Malaysia Sdn.Bhd.
E00000-EFFFFF (base 16) Continental Automotive Component Malaysia Sdn.Bhd.
2455, MK.1, Tingkat Perusahaan 2A,
Prai Industrial Estate, Prai, Penang 13600
MY
E8-B4-70 (hex) Webfleet Solutions B.V.
300000-3FFFFF (base 16) Webfleet Solutions B.V.
De Ruijterkade 154
Amsterdam 1011 AC
NL
E8-B4-70 (hex) Medica Corporation
D00000-DFFFFF (base 16) Medica Corporation
5 Oak Park Drive
Bedford MA 01730
US
20-85-93 (hex) UNILUMIN GROUP CO.,LTD
300000-3FFFFF (base 16) UNILUMIN GROUP CO.,LTD
No.112 Yongfu Rd.,BaoanDistrict,
@ -10676,12 +10754,96 @@ F4-90-CB (hex) Avilution
Madison AL 35758
US
F4-90-CB (hex) Fractyl Labs
900000-9FFFFF (base 16) Fractyl Labs
17 HARTWELL AVE
LEXINGTON MA 02421
US
F4-90-CB (hex) OmniNet
400000-4FFFFF (base 16) OmniNet
6410 Del Rio Rd
Charlotte NC 28277
US
C0-9B-F4 (hex) JSC NPK ATRONIK
400000-4FFFFF (base 16) JSC NPK ATRONIK
VARSHAVSKOE SH, 118-1-P XLII K4 10
Moscow Moscow 117587
RU
C0-9B-F4 (hex) Pinpark Inc.
C00000-CFFFFF (base 16) Pinpark Inc.
9F., No. 101, Sec. 2, Nanjing E. Rd.,, Zhongshan Dist.,
Taipei Taiwan 104
TW
F4-90-CB (hex) Epitel, Inc.
000000-0FFFFF (base 16) Epitel, Inc.
630 S. Stringfellow Ct., Unit #B
Salt Lake City UT 84111
US
C0-9B-F4 (hex) NUCTECH COMPANY LIMITED
B00000-BFFFFF (base 16) NUCTECH COMPANY LIMITED
2/F Block A,Tongfang Building,Shuangqinglu,Haidian District
Beijing Beijing 100084
CN
C0-9B-F4 (hex) Osprey Video, Inc
300000-3FFFFF (base 16) Osprey Video, Inc
1628 Valwood Parkway Suite 200
Carrollton TX 75006
US
C0-9B-F4 (hex) Infiot Inc.
500000-5FFFFF (base 16) Infiot Inc.
75 E. Santa Clara St., Suite 600
San Jose CA 95113
US
E8-B4-70 (hex) plc2 Design GmbH
A00000-AFFFFF (base 16) plc2 Design GmbH
Hugstmattweg 30
Freiburg i. Br. 79112
DE
E8-B4-70 (hex) DEHN SE + Co KG
800000-8FFFFF (base 16) DEHN SE + Co KG
Hans-Dehn-Straße 1
Neumarkt Bavaria 92318
DE
E8-B4-70 (hex) internet domain name system beijing engineering research center ltd
200000-2FFFFF (base 16) internet domain name system beijing engineering research center ltd
4,4TH SOUTH STREET ZHONG GUAN CUN
hai dian qu ,beijing BEIJING 100190
CN
E8-B4-70 (hex) DongGuan Ramaxel Memory Technology
000000-0FFFFF (base 16) DongGuan Ramaxel Memory Technology
No.32, Industrial East Road,Innovation Park, High-tech Industrial Development Zone, Songshan Lake, Dongguan City, Guangdong Province,China
DongGuan Guangdong 523808
CN
E8-B4-70 (hex) Miltek Industries Pte Ltd
900000-9FFFFF (base 16) Miltek Industries Pte Ltd
62 Ubi Road 1 #10-03, Oxley Bizhub 2. Singapore 408734
Singapore 408734
SG
E8-B4-70 (hex) Elcoma
600000-6FFFFF (base 16) Elcoma
Rua Barbosa Lima, 149
Recife Pernambuco 50030-330
BR
E8-B4-70 (hex) Alperia Fiber srl
500000-5FFFFF (base 16) Alperia Fiber srl
Via Dodiciville 8
Bolzano bz 39100
IT
4C-4B-F9 (hex) Shandong Linkotech Electronic Co., Ltd.
600000-6FFFFF (base 16) Shandong Linkotech Electronic Co., Ltd.
22nd Floor, Building 2, Aosheng Building, No.1166 Xinyi Street, High-tech Zone
@ -14228,6 +14390,33 @@ F4-90-CB (hex) Ricker Lyman Robotic
Beacon NY 12508
US
F4-90-CB (hex) Beijing Penslink Co., Ltd.
800000-8FFFFF (base 16) Beijing Penslink Co., Ltd.
502,12rd floor,no.2,Fangheng International Center Beijing, Chaoyang district 100102
Beijing Beijing 100102
CN
F4-90-CB (hex) Private
A00000-AFFFFF (base 16) Private
C0-9B-F4 (hex) The Professional Monitor Company Ltd
D00000-DFFFFF (base 16) The Professional Monitor Company Ltd
Holme Court A1
Biggleswade Bedfordshire SG189ST
GB
C0-9B-F4 (hex) Connected Space Management
100000-1FFFFF (base 16) Connected Space Management
62 boulevard Diderot
Paris 75012
FR
C0-9B-F4 (hex) Inveo
A00000-AFFFFF (base 16) Inveo
Rzemieslnicza 21
Kozy 43-340
PL
20-85-93 (hex) Great Lite International
700000-7FFFFF (base 16) Great Lite International
11F., No.207-2, Sec. 3, Beixin Rd., Xindian Dist.,
@ -17782,3 +17971,51 @@ DC-44-27 (hex) Tesla,Inc.
3500 Deer Creek Road
Palo Alto CA 94304
US
F4-90-CB (hex) ICE Gateway GmbH
200000-2FFFFF (base 16) ICE Gateway GmbH
Am Studio 2
Berlin Berlin 12489
DE
F4-90-CB (hex) DELEM BV
100000-1FFFFF (base 16) DELEM BV
LUCHTHAVEN WEG 42
5657 EB EINDHOVEN
NL
C0-9B-F4 (hex) SHENZHEN WINS ELECTRONIC TECHNOLOGY CO., LTD
800000-8FFFFF (base 16) SHENZHEN WINS ELECTRONIC TECHNOLOGY CO., LTD
Baoan Xixiang Xinbaoji Industry Park,Building A1-2
Shenzhen Guangdong 518026
CN
C0-9B-F4 (hex) Hitachi High-Tech Materials Corporation
200000-2FFFFF (base 16) Hitachi High-Tech Materials Corporation
Toranomon Hills Business Tower, 1-17-1 Toranomon, Minato-ku
Tokyo 105-6413
JP
E8-B4-70 (hex) Autocom Diagnostic Partner AB
100000-1FFFFF (base 16) Autocom Diagnostic Partner AB
Grafitvägen 23B
TROLLHÄTTAN 46138
SE
E8-B4-70 (hex) UNICACCES GROUPE
E00000-EFFFFF (base 16) UNICACCES GROUPE
24 Chemin des Vieilles Vignes
La tour-d'aigues Vaucluse 84240
FR
E8-B4-70 (hex) Digifocus Technology Inc.
B00000-BFFFFF (base 16) Digifocus Technology Inc.
6F, No.89, Xinhu 1st Rd., Neihu Dist.
Taipei City 11494
TW
94-FB-A7 (hex) Silver-I Co.,LTD.
800000-8FFFFF (base 16) Silver-I Co.,LTD.
2-14-4 Shinyokohama,kohoku-ku
Yokohama Kanagawa 222-0033
JP

600
hwdb.d/ma-small.txt
View File

@ -4199,6 +4199,12 @@ EF1000-EF1FFF (base 16) Nanotok LLC
Hong Kong Hong Kong 00000
HK
70-B3-D5 (hex) Technology Link Corporation
B1B000-B1BFFF (base 16) Technology Link Corporation
Shin-Yokohama Kohoku-ku
yokohama kanagawa 222-0033
JP
70-B3-D5 (hex) VANTAGE INTEGRATED SECURITY SOLUTIONS PVT LTD
6BE000-6BEFFF (base 16) VANTAGE INTEGRATED SECURITY SOLUTIONS PVT LTD
B3, Bredon House, 321, Tettenhall Road, Tettenhall
@ -4223,11 +4229,11 @@ F47000-F47FFF (base 16) TXMission Ltd.
Watford Hertfordshire WD25 8HU
GB
70-B3-D5 (hex) Technology Link Corporation
B1B000-B1BFFF (base 16) Technology Link Corporation
Shin-Yokohama Kohoku-ku
yokohama kanagawa 222-0033
JP
70-B3-D5 (hex) sensorway
C52000-C52FFF (base 16) sensorway
A-339 samsong techno valley, 140 tongilro, deockyanggu
goyangsi gyeonggido 10594
KR
70-B3-D5 (hex) Tucsen Photonics Co., Ltd.
8A7000-8A7FFF (base 16) Tucsen Photonics Co., Ltd.
@ -4235,11 +4241,11 @@ B1B000-B1BFFF (base 16) Technology Link Corporation
fuzhou 350000
CN
70-B3-D5 (hex) sensorway
C52000-C52FFF (base 16) sensorway
A-339 samsong techno valley, 140 tongilro, deockyanggu
goyangsi gyeonggido 10594
KR
70-B3-D5 (hex) Beijing Yourong Runda Rechnology Development Co.Ltd.
980000-980FFF (base 16) Beijing Yourong Runda Rechnology Development Co.Ltd.
Changping District Science and Technology Park Advanced Road 37
Beijing 6219650
CN
70-B3-D5 (hex) KDT Corp.
E72000-E72FFF (base 16) KDT Corp.
@ -4247,11 +4253,11 @@ E72000-E72FFF (base 16) KDT Corp.
shaoxing zhejiang 312030
CN
70-B3-D5 (hex) Beijing Yourong Runda Rechnology Development Co.Ltd.
980000-980FFF (base 16) Beijing Yourong Runda Rechnology Development Co.Ltd.
Changping District Science and Technology Park Advanced Road 37
Beijing 6219650
CN
70-B3-D5 (hex) AUTOMATICA Y REGULACION S.A.
EBF000-EBFFFF (base 16) AUTOMATICA Y REGULACION S.A.
Condell 1735, Nunoa
Santiago RM 7770331
CL
70-B3-D5 (hex) R.C. Systems Inc
52F000-52FFFF (base 16) R.C. Systems Inc
@ -4265,18 +4271,18 @@ E72000-E72FFF (base 16) KDT Corp.
Brendola Vicenza 36040
IT
70-B3-D5 (hex) AUTOMATICA Y REGULACION S.A.
EBF000-EBFFFF (base 16) AUTOMATICA Y REGULACION S.A.
Condell 1735, Nunoa
Santiago RM 7770331
CL
70-B3-D5 (hex) Digital Solutions JSC
D9F000-D9FFFF (base 16) Digital Solutions JSC
room 4, office 1, 3rd floor, building 7, house 9a, 2nd Sinichkina Str.
Moscow 111020
RU
70-B3-D5 (hex) DOGA
62A000-62AFFF (base 16) DOGA
11 rue Lavoisier
MAUREPAS 78310
FR
70-B3-D5 (hex) Oculii
B96000-B96FFF (base 16) Oculii
829 Space Dr
@ -4295,12 +4301,78 @@ B96000-B96FFF (base 16) Oculii
Woodside NY 11377
US
70-B3-D5 (hex) DOGA
62A000-62AFFF (base 16) DOGA
11 rue Lavoisier
MAUREPAS 78310
70-B3-D5 (hex) Remote Diagnostic Technologies Ltd
C99000-C99FFF (base 16) Remote Diagnostic Technologies Ltd
Pavilion C2 Ashwood Park, Ashwood Way
Basingstoke Hampshire RG23 8BG
GB
70-B3-D5 (hex) NEUROPHET, Inc.
E31000-E31FFF (base 16) NEUROPHET, Inc.
3rd Floor, 175, Yeoksam-ro, Gangnam-gu, seoul
Seoul Province 06247
KR
70-B3-D5 (hex) Chromateq
944000-944FFF (base 16) Chromateq
191, allée de Lauzard, Bat. B, RDC 1 (Chromateq)
Saint Gély du Fesc 34980
FR
70-B3-D5 (hex) Elk Solutions, LLC
1A7000-1A7FFF (base 16) Elk Solutions, LLC
12708 Misty Grove St
Moorpark CA 93021
US
70-B3-D5 (hex) KAYA Instruments
F3D000-F3DFFF (base 16) KAYA Instruments
20 HaMesila St.
Nesher 3688520
IL
70-B3-D5 (hex) Gogo Business Aviation
3E0000-3E0FFF (base 16) Gogo Business Aviation
105 Edgeview Dr., Suite 300
Broomfield CO 80021
US
70-B3-D5 (hex) Asiga Pty Ltd
53E000-53EFFF (base 16) Asiga Pty Ltd
Unit 2, 19-21 Bourke Road
Alexandria New South Wales 2015
AU
70-B3-D5 (hex) ENABLER LTD.
15A000-15AFFF (base 16) ENABLER LTD.
29F Shiroyama Trust Tower 4-3-1 Toranomon
Minato-ku Tokyo 105-6029
JP
70-B3-D5 (hex) LINEAGE POWER PVT LTD.,
62E000-62EFFF (base 16) LINEAGE POWER PVT LTD.,
30-A1, KIADB, 1ST PHASE INDUSTRIAL ESTATE,KUMBALGODU, BANGALORE-MYSORE ROAD
BANGALORE KARNATAKA 560074
IN
70-B3-D5 (hex) Salupo Sas
898000-898FFF (base 16) Salupo Sas
Via Laganeto n. 129
Rocca di Capri Leone Italia / ME / Sicilia 98070
IT
70-B3-D5 (hex) Nippon Safety co,ltd
872000-872FFF (base 16) Nippon Safety co,ltd
1, suimeicho
Amagasaki Hyogo 660-0082
JP
70-B3-D5 (hex) Grupo Epelsa S.L.
40D000-40DFFF (base 16) Grupo Epelsa S.L.
C/ Punto Net,3
Alcala de Henares Madrid 28805
ES
70-B3-D5 (hex) EVCO SPA
A80000-A80FFF (base 16) EVCO SPA
VIA FELTRE N. 81
@ -8621,24 +8693,30 @@ A7F000-A7FFFF (base 16) AUDIO VISUAL DIGITAL SYSTEMS
Bergisch Gladbach North Rhine-Westphalia 51465
DE
70-B3-D5 (hex) DONG IL VISION Co., Ltd.
038000-038FFF (base 16) DONG IL VISION Co., Ltd.
#9 Ftrek tower, 11-25, Simindaero 327 beongil,Dongan-gu
Anyangi-Si Gyeonggi-Do 14055
KR
70-B3-D5 (hex) Cetitec GmbH
B36000-B36FFF (base 16) Cetitec GmbH
Mannheimer Strasse 17
Pforzheim 75179
DE
70-B3-D5 (hex) DONG IL VISION Co., Ltd.
038000-038FFF (base 16) DONG IL VISION Co., Ltd.
#9 Ftrek tower, 11-25, Simindaero 327 beongil,Dongan-gu
Anyangi-Si Gyeonggi-Do 14055
KR
70-B3-D5 (hex) Kamacho Scale Co., Ltd.
385000-385FFF (base 16) Kamacho Scale Co., Ltd.
2246 Mure
Takamatsu-shi Kagawa-ken 761-0196
JP
70-B3-D5 (hex) Visual Robotics
0F4000-0F4FFF (base 16) Visual Robotics
38 Irving Rd
Eugene OR 97404
US
70-B3-D5 (hex) Vessel Technology Ltd
44D000-44DFFF (base 16) Vessel Technology Ltd
Banchory Business Centre, Burn O'Bennie Road
@ -8651,11 +8729,11 @@ FA8000-FA8FFF (base 16) Munters
Pethch Tikva Israel 4959376
IL
70-B3-D5 (hex) Visual Robotics
0F4000-0F4FFF (base 16) Visual Robotics
38 Irving Rd
Eugene OR 97404
US
70-B3-D5 (hex) TEX COMPUTER SRL
6C2000-6C2FFF (base 16) TEX COMPUTER SRL
VIA MERCADANTE 35
CATTOLICA RIMINI 47841
IT
70-B3-D5 (hex) TangRen C&S CO., Ltd
3FC000-3FCFFF (base 16) TangRen C&S CO., Ltd
@ -8663,12 +8741,6 @@ FA8000-FA8FFF (base 16) Munters
Shenzhen Guangdong 518052
CN
70-B3-D5 (hex) TEX COMPUTER SRL
6C2000-6C2FFF (base 16) TEX COMPUTER SRL
VIA MERCADANTE 35
CATTOLICA RIMINI 47841
IT
70-B3-D5 (hex) LOTES TM OOO
EA5000-EA5FFF (base 16) LOTES TM OOO
Barklaya 22, str.1
@ -8681,6 +8753,72 @@ F28000-F28FFF (base 16) Yi An Electronics Co., Ltd
New Taipei City 22101
TW
70-B3-D5 (hex) Ariston Thermo s.p.a.
3D6000-3D6FFF (base 16) Ariston Thermo s.p.a.
Via Aristide Merloni 45
Fabriano Ancona 60044
IT
70-B3-D5 (hex) MG s.r.l.
130000-130FFF (base 16) MG s.r.l.
via Monte Bianco, 1
Solbiate Olona VA 21058
IT
70-B3-D5 (hex) DORLET SAU
639000-639FFF (base 16) DORLET SAU
Albert Eistein 34
Alava SPAIN 01510
ES
70-B3-D5 (hex) OOO ORION-R
047000-047FFF (base 16) OOO ORION-R
Novoselov str., 40A, room N200
Ryazan 390048
RU
70-B3-D5 (hex) Glory Technology Service Inc.
801000-801FFF (base 16) Glory Technology Service Inc.
3F., No.43-1, Ln. 11, Sec. 6, Minquan E. Rd
Taipei City Neihu Dist 114
TW
70-B3-D5 (hex) Toolplanet Co., Ltd.
4B5000-4B5FFF (base 16) Toolplanet Co., Ltd.
43-2 Himigaike-cho
Gifu-shi Gifu 500-8122
JP
70-B3-D5 (hex) Postmark Incorporated
CBB000-CBBFFF (base 16) Postmark Incorporated
3197 Duncan Lane
San Luis Obispo CA 93401
US
70-B3-D5 (hex) Abbott Diagnostics Technologies AS
53F000-53FFFF (base 16) Abbott Diagnostics Technologies AS
P. O. Box 6863 Rodeløkka
Oslo Oslo 0504
NO
70-B3-D5 (hex) Surion (Pty) Ltd
7FC000-7FCFFF (base 16) Surion (Pty) Ltd
205 Park Corner, 2 Bolton road, Rosebank
JOHANNESBURG NORTH Gauteng 2193
ZA
70-B3-D5 (hex) REO AG
8E7000-8E7FFF (base 16) REO AG
Brühlerstr. 100
Solingen 42657
DE
70-B3-D5 (hex) GIORDANO CONTROLS SPA
95D000-95DFFF (base 16) GIORDANO CONTROLS SPA
VIA PARALLELA 2/4
VILLA BARTOLOMEA IT 37049
IT
70-B3-D5 (hex) System West dba ICS Electronics
E06000-E06FFF (base 16) System West dba ICS Electronics
7034 Commerce Circle Suite A
@ -9002,12 +9140,6 @@ D36000-D36FFF (base 16) Insitu Inc.
Bingen WA 98605
US
70-B3-D5 (hex) Pano0ramic Power
669000-669FFF (base 16) Pano0ramic Power
15 Atir Yeda
Kfar Saba 4464312
IL
00-1B-C5 (hex) Private
0B8000-0B8FFF (base 16) Private
@ -12914,18 +13046,6 @@ F23000-F23FFF (base 16) Lyse AS
Bad Marienberg Rheinland-Pfalz 56470
DE
70-B3-D5 (hex) Walton Hi-Tech Industries Ltd.
E5C000-E5CFFF (base 16) Walton Hi-Tech Industries Ltd.
HOLDING NO. I-65/2, WARD NO-07
CHANDRA, KALIAKOIR, GAZIPUR. 1750
BD
70-B3-D5 (hex) Flextronics International Kft
699000-699FFF (base 16) Flextronics International Kft
38. Zrinyi Str.
Zalaegerszeg Zala 8900
HU
70-B3-D5 (hex) JFA Electronics Industry and Commerce EIRELI
5F7000-5F7FFF (base 16) JFA Electronics Industry and Commerce EIRELI
Rua Flor das Pedras, 175
@ -12938,6 +13058,12 @@ E5C000-E5CFFF (base 16) Walton Hi-Tech Industries Ltd.
Boonton Township NJ 07005
US
70-B3-D5 (hex) Walton Hi-Tech Industries Ltd.
E5C000-E5CFFF (base 16) Walton Hi-Tech Industries Ltd.
HOLDING NO. I-65/2, WARD NO-07
CHANDRA, KALIAKOIR, GAZIPUR. 1750
BD
70-B3-D5 (hex) aquila biolabs GmbH
7DB000-7DBFFF (base 16) aquila biolabs GmbH
Arnold-Sommerfeld-Ring 2
@ -12950,6 +13076,12 @@ C82000-C82FFF (base 16) Sicon srl
Isola Vicentina Vicenza 36033
IT
70-B3-D5 (hex) Flextronics International Kft
699000-699FFF (base 16) Flextronics International Kft
38. Zrinyi Str.
Zalaegerszeg Zala 8900
HU
70-B3-D5 (hex) LGE
DAE000-DAEFFF (base 16) LGE
10, Magokjungang 10-ro, Gangseo-gu
@ -13004,12 +13136,6 @@ F64000-F64FFF (base 16) silicom
Borehamwood Hert WD6 1NA
GB
70-B3-D5 (hex) Kospel S.A.
249000-249FFF (base 16) Kospel S.A.
Olchowa 1
Koszalin 75-136
PL
70-B3-D5 (hex) Microchip Technology Germany II GmbH&Co.KG
77F000-77FFFF (base 16) Microchip Technology Germany II GmbH&Co.KG
Emmy-Noether-Straße 14
@ -13022,17 +13148,11 @@ C98000-C98FFF (base 16) Trust Automation
San Luis Obispo CA 93401
US
70-B3-D5 (hex) ARCLAN'SYSTEM
25C000-25CFFF (base 16) ARCLAN'SYSTEM
1140 rue Ampère - Actimart II - Lot 9
AIX EN PROVENCE 13290
FR
70-B3-D5 (hex) Taejin InfoTech
A75000-A75FFF (base 16) Taejin InfoTech
40, Imi-ro, A-411
Uiwang-si Gyeonggi-do 16006
KR
70-B3-D5 (hex) Kospel S.A.
249000-249FFF (base 16) Kospel S.A.
Olchowa 1
Koszalin 75-136
PL
70-B3-D5 (hex) Coheros Oy
D2E000-D2EFFF (base 16) Coheros Oy
@ -13046,6 +13166,18 @@ E24000-E24FFF (base 16) Gogo Business Aviation
Broomfield CO 80021
US
70-B3-D5 (hex) Taejin InfoTech
A75000-A75FFF (base 16) Taejin InfoTech
40, Imi-ro, A-411
Uiwang-si Gyeonggi-do 16006
KR
70-B3-D5 (hex) ARCLAN'SYSTEM
25C000-25CFFF (base 16) ARCLAN'SYSTEM
1140 rue Ampère - Actimart II - Lot 9
AIX EN PROVENCE 13290
FR
70-B3-D5 (hex) Smart Embedded Systems
A09000-A09FFF (base 16) Smart Embedded Systems
6701 Koll Center Parkway #250
@ -13058,6 +13190,78 @@ F6A000-F6AFFF (base 16) Guan Show Technologe Co., Ltd.
Kaohsiung City 802
TW
70-B3-D5 (hex) LLC Sarov Innovative Technologies (WIZOLUTION)
50F000-50FFFF (base 16) LLC Sarov Innovative Technologies (WIZOLUTION)
RUSSIAN FEDERATION, Nizhny Novgorod region, Varlamovskaya road, 7, build 2
Sarov Nizhny Novgorod 607188
RU
70-B3-D5 (hex) SPX Radiodetection
A77000-A77FFF (base 16) SPX Radiodetection
Western Drive
Bristol Avon BS14 0AF
GB
70-B3-D5 (hex) LM-Instruments Oy
5AC000-5ACFFF (base 16) LM-Instruments Oy
Norrbyn rantatie 8
Parainen 21600
FI
70-B3-D5 (hex) Fuhr GmbH Filtertechnik
DBB000-DBBFFF (base 16) Fuhr GmbH Filtertechnik
Am Weinkastell 14
Klein-Winternheim Rheinland-Pfalz 55270
DE
70-B3-D5 (hex) Sanmina Israel
C18000-C18FFF (base 16) Sanmina Israel
Koren Industrial Zone , POBox 102
Maalot Israel 2101002
IL
70-B3-D5 (hex) INVISSYS
AD4000-AD4FFF (base 16) INVISSYS
25 rue marcel issartier
merignac 33700
FR
70-B3-D5 (hex) Panoramic Power
669000-669FFF (base 16) Panoramic Power
15 Atir Yeda
Kfar Saba 4464312
IL
70-B3-D5 (hex) Panoramic Power
06D000-06DFFF (base 16) Panoramic Power
Atir Yeda 15
Kfar Saba 4464312
IL
70-B3-D5 (hex) Avlinkpro
2C1000-2C1FFF (base 16) Avlinkpro
380 US Highway 46
Totowa NJ 07512
US
70-B3-D5 (hex) DECYBEN
683000-683FFF (base 16) DECYBEN
170 Rue Raymond Losserand
Paris 75014
FR
70-B3-D5 (hex) C4I Systems Ltd
5C6000-5C6FFF (base 16) C4I Systems Ltd
Unit 1Twyford Court
Hereford Herefordshire HR2 6JR
GB
70-B3-D5 (hex) Knowledge Resources GmbH
C36000-C36FFF (base 16) Knowledge Resources GmbH
Ackerstrasse 30
Bsel BS 4057
CH
70-B3-D5 (hex) YUYAMA MFG Co.,Ltd
BBB000-BBBFFF (base 16) YUYAMA MFG Co.,Ltd
3-3-1
@ -17303,24 +17507,30 @@ BE0000-BE0FFF (base 16) Cognosos, Inc.
Taoyuan 330
TW
70-B3-D5 (hex) PolyTech A/S
F4C000-F4CFFF (base 16) PolyTech A/S
HI Park 445
Herning Herning 7400
DK
70-B3-D5 (hex) Zhuhai Lonl electric Co.,Ltd.
EA9000-EA9FFF (base 16) Zhuhai Lonl electric Co.,Ltd.
2nd floor, building B3, nanfang software park, xiangzhou district
Zhuhai Guangdong 519000
CN
70-B3-D5 (hex) PolyTech A/S
F4C000-F4CFFF (base 16) PolyTech A/S
HI Park 445
Herning Herning 7400
DK
70-B3-D5 (hex) Shanghai Tiancheng Communication Technology Corporation
1C3000-1C3FFF (base 16) Shanghai Tiancheng Communication Technology Corporation
No.618,Guangxing Rd.,Songjiang
shanghai 200090
CN
70-B3-D5 (hex) T&M Media Pty Ltd
B41000-B41FFF (base 16) T&M Media Pty Ltd
6, 476 Gardeners Road
Alexandria NSW 2015
AU
70-B3-D5 (hex) SAMBO HITECH
282000-282FFF (base 16) SAMBO HITECH
469,Seokjung-ro,Namdong-Gu
@ -17333,30 +17543,6 @@ F9F000-F9FFFF (base 16) M.A.C. Solutions (UK) Ltd
Redditch Worcestershire B98 8LG
GB
70-B3-D5 (hex) ERA TOYS LIMITED
193000-193FFF (base 16) ERA TOYS LIMITED
Room 505, 5th Floor, Beverley Commercial Centre, 87-105 Chatham Road South
Tsim Sha Tsui Kowloon 0000
HK
70-B3-D5 (hex) T&M Media Pty Ltd
B41000-B41FFF (base 16) T&M Media Pty Ltd
6, 476 Gardeners Road
Alexandria NSW 2015
AU
70-B3-D5 (hex) A&T Corporation
32E000-32EFFF (base 16) A&T Corporation
2023-1
Endo, Fujisawa, Kanagawa 252-0816
JP
70-B3-D5 (hex) Scorpion Precision Industry (HK)CO. Ltd.
02B000-02BFFF (base 16) Scorpion Precision Industry (HK)CO. Ltd.
16th Floor, Excelsior Industrial Building,68-76 Sha Tsui Road,
Tsuen Wan New Territories 999077
HK
70-B3-D5 (hex) Shenzhen CAMERAY ELECTRONIC CO., LTD
1E2000-1E2FFF (base 16) Shenzhen CAMERAY ELECTRONIC CO., LTD
4-5FL, Building 1, Guanghui Science, and Technology Park; Minqing Road, Longhua Town
@ -17369,11 +17555,17 @@ E4D000-E4DFFF (base 16) Vulcan Wireless Inc.
Carlsbad CA 92008
US
70-B3-D5 (hex) MIVO Technology AB
1D5000-1D5FFF (base 16) MIVO Technology AB
Hornsbergsvägen 28
Stockholm 11215
SE
70-B3-D5 (hex) ERA TOYS LIMITED
193000-193FFF (base 16) ERA TOYS LIMITED
Room 505, 5th Floor, Beverley Commercial Centre, 87-105 Chatham Road South
Tsim Sha Tsui Kowloon 0000
HK
70-B3-D5 (hex) Scorpion Precision Industry (HK)CO. Ltd.
02B000-02BFFF (base 16) Scorpion Precision Industry (HK)CO. Ltd.
16th Floor, Excelsior Industrial Building,68-76 Sha Tsui Road,
Tsuen Wan New Territories 999077
HK
70-B3-D5 (hex) Cryptotronix LLC
0DB000-0DBFFF (base 16) Cryptotronix LLC
@ -17381,12 +17573,30 @@ E4D000-E4DFFF (base 16) Vulcan Wireless Inc.
Fort Collins CO 80525
US
70-B3-D5 (hex) MIVO Technology AB
1D5000-1D5FFF (base 16) MIVO Technology AB
Hornsbergsvägen 28
Stockholm 11215
SE
70-B3-D5 (hex) A&T Corporation
32E000-32EFFF (base 16) A&T Corporation
2023-1
Endo, Fujisawa, Kanagawa 252-0816
JP
70-B3-D5 (hex) TOMEI TSUSHIN KOGYO CO,.LTD
FB1000-FB1FFF (base 16) TOMEI TSUSHIN KOGYO CO,.LTD
100-3, Amaike Kodacho
Inazawa Shi Aichi ken 4928274
JP
70-B3-D5 (hex) DogWatch Inc
1E7000-1E7FFF (base 16) DogWatch Inc
10 Michigan Drive
Natick 01760
US
70-B3-D5 (hex) RCH Vietnam Limited Liability Company
C09000-C09FFF (base 16) RCH Vietnam Limited Liability Company
Workshop F.01B-2, Lot No. F.01B Long Hau
@ -17399,24 +17609,6 @@ F69000-F69FFF (base 16) Copper Labs, Inc.
Boulder CO 80301
US
70-B3-D5 (hex) DogWatch Inc
1E7000-1E7FFF (base 16) DogWatch Inc
10 Michigan Drive
Natick 01760
US
70-B3-D5 (hex) Grossenbacher Systeme AG
B75000-B75FFF (base 16) Grossenbacher Systeme AG
Spinnereistrasse 10
St. Gallen 9008
CH
70-B3-D5 (hex) ITsynergy Ltd
D2A000-D2AFFF (base 16) ITsynergy Ltd
9 Bonhill Street
London EC2A 4DJ
GB
70-B3-D5 (hex) SHENZHEN HUINENGYUAN Technology Co., Ltd
A83000-A83FFF (base 16) SHENZHEN HUINENGYUAN Technology Co., Ltd
Room 206, 3 Building, Hongwanchuangke Center, Gushu, Xixiang, Baoan District
@ -17441,30 +17633,96 @@ C94000-C94FFF (base 16) Vars Technology
Blaricum 1261WT
NL
70-B3-D5 (hex) Grossenbacher Systeme AG
B75000-B75FFF (base 16) Grossenbacher Systeme AG
Spinnereistrasse 10
St. Gallen 9008
CH
70-B3-D5 (hex) ITsynergy Ltd
D2A000-D2AFFF (base 16) ITsynergy Ltd
9 Bonhill Street
London EC2A 4DJ
GB
70-B3-D5 (hex) Vaunix Technology Corporation
EE6000-EE6FFF (base 16) Vaunix Technology Corporation
7 New Pasture Rd
Newburyport MA 01950
US
70-B3-D5 (hex) Portrait Displays, Inc.
D77000-D77FFF (base 16) Portrait Displays, Inc.
6663 OWENS DR
PLEASANTON CA 94588
US
70-B3-D5 (hex) chargeBIG
869000-869FFF (base 16) chargeBIG
Pragstraße 26-46
Stuttgart 70376
DE
70-B3-D5 (hex) Portrait Displays, Inc.
D77000-D77FFF (base 16) Portrait Displays, Inc.
6663 OWENS DR
PLEASANTON CA 94588
US
70-B3-D5 (hex) Sprintshield d.o.o.
B03000-B03FFF (base 16) Sprintshield d.o.o.
Marina Getaldi?a 3
Velika Gorica 10410
HR
70-B3-D5 (hex) Tricom Research Inc.
601000-601FFF (base 16) Tricom Research Inc.
17791 Sky Park Circle Suite GHJ
Irvine CA 92614
US
70-B3-D5 (hex) Mictrotrac Retsch GmbH
F09000-F09FFF (base 16) Mictrotrac Retsch GmbH
Retsch-Allee 1-5
Haan NRW 42781
DE
70-B3-D5 (hex) KeyProd
473000-473FFF (base 16) KeyProd
66 avenue des Champs Elysées
Paris 77008
FR
70-B3-D5 (hex) MB connect line GmbH Fernwartungssysteme
6D7000-6D7FFF (base 16) MB connect line GmbH Fernwartungssysteme
Winnettener Straße 6
Dinkelsbuehl Bavaria 91550
DE
70-B3-D5 (hex) EarTex
E01000-E01FFF (base 16) EarTex
41 Corsham Street
London England N1 6DR
GB
70-B3-D5 (hex) AVL DiTEST GmbH
78D000-78DFFF (base 16) AVL DiTEST GmbH
Alte Poststrasse 156
Graz 8020
AT
70-B3-D5 (hex) Scharco Elektronik GmbH
C72000-C72FFF (base 16) Scharco Elektronik GmbH
Tilsiter Strasse 8
Wuppertal NRW 42277
DE
70-B3-D5 (hex) WARECUBE,INC
AD3000-AD3FFF (base 16) WARECUBE,INC
#A-811, 142-10, Saneop-ro, 156beon-gil, Gwonseon-gu
Suwon-si 16648
KR
70-B3-D5 (hex) myUpTech AB
FC3000-FC3FFF (base 16) myUpTech AB
Box 14
Markaryd 28532
SE
70-B3-D5 (hex) DISMUNTEL SAL
92C000-92CFFF (base 16) DISMUNTEL SAL
Pol ind cotes
@ -18971,12 +19229,6 @@ E18000-E18FFF (base 16) Plasmapp Co.,Ltd.
Eckental Bavaria 90542
DE
70-B3-D5 (hex) Pano0ramic Power
53A000-53AFFF (base 16) Pano0ramic Power
15 Atir Yeda
Kfar Saba 4464312
IL
70-B3-D5 (hex) ND METER
68C000-68CFFF (base 16) ND METER
228 BOLTON ROAD
@ -21803,23 +22055,17 @@ A6A000-A6AFFF (base 16) Privafy, Inc
Oslo Oslo 0504
NO
70-B3-D5 (hex) RCH Vietnam Limited Liability Company
6BD000-6BDFFF (base 16) RCH Vietnam Limited Liability Company
Workshop F.01B-2, Lot No. F.01B Long Hau
Ho Chi Minh City Ho Chi Minh 70000
VN
70-B3-D5 (hex) Gamber Johnson-LLC
E34000-E34FFF (base 16) Gamber Johnson-LLC
3001 Borham Ave
Stevens Point WI 54481
US
70-B3-D5 (hex) YUYAMA MFG Co.,Ltd
C2B000-C2BFFF (base 16) YUYAMA MFG Co.,Ltd
3-3-1
TOYONAKASHI OSAKA 561-0841
JP
70-B3-D5 (hex) RCH Vietnam Limited Liability Company
6BD000-6BDFFF (base 16) RCH Vietnam Limited Liability Company
Workshop F.01B-2, Lot No. F.01B Long Hau
Ho Chi Minh City Ho Chi Minh 70000
VN
70-B3-D5 (hex) YUYAMA MFG Co.,Ltd
1F2000-1F2FFF (base 16) YUYAMA MFG Co.,Ltd
@ -21833,6 +22079,12 @@ C2B000-C2BFFF (base 16) YUYAMA MFG Co.,Ltd
Moscow 105484
RU
70-B3-D5 (hex) YUYAMA MFG Co.,Ltd
C2B000-C2BFFF (base 16) YUYAMA MFG Co.,Ltd
3-3-1
TOYONAKASHI OSAKA 561-0841
JP
70-B3-D5 (hex) Adcole Maryland Aerospace
922000-922FFF (base 16) Adcole Maryland Aerospace
669 Forest St
@ -21845,18 +22097,18 @@ C2B000-C2BFFF (base 16) YUYAMA MFG Co.,Ltd
Renens VD 1020
CH
70-B3-D5 (hex) Axnes AS
65F000-65FFFF (base 16) Axnes AS
Terje Løvåsvei 1
Grimstad 4879
NO
70-B3-D5 (hex) Duplomatic MS spa
DE1000-DE1FFF (base 16) Duplomatic MS spa
Via Re Depaolini 24
Parabiago Milan 20015
IT
70-B3-D5 (hex) Axnes AS
65F000-65FFFF (base 16) Axnes AS
Terje Løvåsvei 1
Grimstad 4879
NO
70-B3-D5 (hex) Nanjing Pingguang Electronic Technology Co., Ltd
541000-541FFF (base 16) Nanjing Pingguang Electronic Technology Co., Ltd
B30/B31 4th Floor, Building#11, Shengtai Road, JiangNing District
@ -21868,3 +22120,33 @@ DE1000-DE1FFF (base 16) Duplomatic MS spa
Moosstrasse 7
Lucerne Lucerne 6003
CH
70-B3-D5 (hex) ALVAT s.r.o.
369000-369FFF (base 16) ALVAT s.r.o.
Chodovska 228/3
Praha 4 14100
CZ
70-B3-D5 (hex) PHYZHON Health Inc
744000-744FFF (base 16) PHYZHON Health Inc
180 Blue Ravine Road, suite A
Folsom CA 95630
US
70-B3-D5 (hex) PCB Piezotronics
4CA000-4CAFFF (base 16) PCB Piezotronics
3425 Walden Avenue
Depew NY 14043
US
70-B3-D5 (hex) Panoramic Power
53A000-53AFFF (base 16) Panoramic Power
15 Atir Yeda
Kfar Saba 4464312
IL
70-B3-D5 (hex) STEP sarl
481000-481FFF (base 16) STEP sarl
11, avenue Aristide Berges
LANCEY ISERE 38190
FR

1
hwdb.d/meson.build
View File

@ -13,6 +13,7 @@ hwdb_files = files('''
20-net-ifname.hwdb
20-vmbus-class.hwdb
60-evdev.hwdb
60-input-id.hwdb
60-keyboard.hwdb
60-sensor.hwdb
70-joystick.hwdb

1
hwdb.d/parse_hwdb.py
View File

@ -128,6 +128,7 @@ def property_grammar():
('KEYBOARD_LED_CAPSLOCK', Literal('0')),
('ACCEL_MOUNT_MATRIX', mount_matrix),
('ACCEL_LOCATION', Or(('display', 'base'))),
('PROXIMITY_NEAR_LEVEL', INTEGER),
)
fixed_props = [Literal(name)('NAME') - Suppress('=') - val('VALUE')
for name, val in props]

126
hwdb.d/pci.ids
View File

@ -1,8 +1,8 @@
#
# List of PCI ID's
#
# Version: 2020.01.25
# Date: 2020-01-25 03:15:02
# Version: 2020.03.05
# Date: 2020-03-05 03:15:04
#
# Maintained by Albert Pool, Martin Mares, and other volunteers from
# the PCI ID Project at https://pci-ids.ucw.cz/.
@ -67,6 +67,7 @@
# 018a is not LevelOne but there is a board misprogrammed
018a LevelOne
0106 FPC-0106TX misprogrammed [RTL81xx]
01de Oxide Computer Company
# 021b is not Compaq but there is a board misprogrammed
021b Compaq Computer Corporation
8139 HNE-300 (RealTek RTL8139c) [iPaq Networking]
@ -436,6 +437,8 @@
1028 1fd1 PERC H730P MX
17aa 1052 ThinkServer RAID 720i
17aa 1053 ThinkServer RAID 720ix
1bd4 0014 12G SAS3108 2G
1bd4 0015 12G SAS3108 4G
1d49 0600 ThinkSystem RAID 730-8i 1GB Cache PCIe 12Gb Adapter
1d49 0608 ThinkSystem RAID 730-8i 2GB Flash PCIe 12Gb Adapter
1d49 0609 ThinkSystem RAID 730-8i 4GB Flash PCIe 12Gb Adapter
@ -507,6 +510,12 @@
1028 1f1f PERC H200 Modular
1028 1f20 PERC H200 Embedded
1028 1f22 PERC H200 Internal Tape Adapter
# Fujitsu D2607 SAS2008 HBA controller
1734 1177 HBA Ctrl SAS 6G 0/1 [D2607]
1bd4 000d 6G SAS2008IT
1bd4 000e 6G SAS2008IR
1bd4 000f 6G SAS2008IT SA5248
1bd4 0010 6G SAS2008IR SA5248
8086 350f RMS2LL040 RAID Controller
8086 3700 SSD 910 Series
0073 MegaRAID SAS 2008 [Falcon]
@ -615,6 +624,8 @@
1590 0041 H220i
1590 0042 H221 / 9207-8e
1590 0044 H220i
1bd4 0009 6G SAS2308IR
1bd4 000a 6G SAS2308IT
8086 3000 RS25GB008 RAID Controller
8086 3060 RS25FB044 RAID Controller
8086 3516 RMS25JB080 RAID Controller
@ -646,6 +657,10 @@
1bd4 000b 12G SAS3008IR
1bd4 000c 12G SAS3008IT
1bd4 0011 Inspur 12Gb 8i-3008 IT SAS HBA
1bd4 0012 12Gb SAS3008IR UDM
1bd4 0026 12G SAS3008IT RACK
1bd4 0027 12G SAS3008IMR RACK
1bd4 0028 12G SAS3008IR RACK
00ab SAS3516 Fusion-MPT Tri-Mode RAID On Chip (ROC)
# 8 Internal and 8 External port channel 9400 HBA
1000 3040 HBA 9400-8i8e
@ -881,7 +896,9 @@
1306 Kaveri
1307 Kaveri
1308 Kaveri HDMI/DP Audio Controller
17aa 3988 Z50-75
1309 Kaveri [Radeon R6/R7 Graphics]
17aa 3830 Z50-75
130a Kaveri [Radeon R6 Graphics]
130b Kaveri [Radeon R4 Graphics]
130c Kaveri [Radeon R7 Graphics]
@ -911,11 +928,13 @@
1561 Anubis
15d8 Picasso
103c 8615 Pavilion Laptop 15-cw1xxx
17aa 5124 ThinkPad E595
15dd Raven Ridge [Radeon Vega Series / Radeon Vega Mobile Series]
103c 83c6 Radeon Vega 8 Mobile
1458 d000 Radeon RX Vega 11
15de Raven/Raven2/Fenghuang HDMI/DP Audio Controller
103c 8615 Pavilion Laptop 15-cw1xxx
17aa 5124 ThinkPad E595
15df Raven/Raven2/Fenghuang/Renoir Cryptographic Coprocessor
103c 8615 Pavilion Laptop 15-cw1xxx
15ff Fenghuang [Zhongshan Subor Z+]
@ -1092,7 +1111,7 @@
4382 SB600 AC97 Audio
4383 SBx00 Azalia (Intel HDA)
1019 2120 A785GM-M
103c 1611 Pavilion DM1Z-3000
103c 1611 Pavilion dm1z-3000
103c 280a DC5750 Microtower
1043 8230 M3A78-EH Motherboard
1043 836c M4A785TD Motherboard
@ -1860,8 +1879,9 @@
1642 3c81 Radeon HD 8670
1642 3c91 Radeon HD 8670
1642 3f09 Radeon R7 350
6611 Oland [Radeon HD 8570 / R7 240/340 OEM]
6611 Oland [Radeon HD 8570 / R7 240/340 / Radeon 520 OEM]
1028 210b Radeon R5 240 OEM
1642 1869 Radeon 520 OEM
174b 4248 Radeon R7 240 OEM
174b a240 Radeon R7 240 OEM
174b d340 Radeon R7 340 OEM
@ -1927,7 +1947,7 @@
17aa 3805 Radeon HD 8570M
6664 Jet XT [Radeon R5 M240]
6665 Jet PRO [Radeon R5 M230 / R7 M260DX / Radeon 520 Mobile]
17aa 1309 Radeon R7 M260DX
17aa 1309 Z50-75 Radeon R7 M260DX
17aa 368f Radeon R5 A230
6667 Jet ULT [Radeon R5 M230]
666f Sun LE [Radeon HD 8550M / R5 M230]
@ -2558,7 +2578,7 @@
1462 3418 Radeon RX 580 Armor 4G OC
1462 341e Radeon RX 570 Armor 4G OC
1462 8a92 Radeon RX 580
148c 2372 Radeon RX 480
148c 2372 Radeon RX 480 [Red Dragon]
148c 2373 Radeon RX 470
1682 9470 Radeon RX 470
1682 9480 Radeon RX 480
@ -4675,13 +4695,18 @@
15dc Raven/Raven2 Internal PCIe GPP Bridge 0 to Bus B
15de Raven/Raven2/FireFlight HD Audio Controller
15df Family 17h (Models 10h-1fh) Platform Security Processor
17aa 5124 ThinkPad E595
15e0 Raven USB 3.1
103c 8615 Pavilion Laptop 15-cw1xxx
17aa 5124 ThinkPad E595
15e1 Raven USB 3.1
103c 8615 Pavilion Laptop 15-cw1xxx
17aa 5124 ThinkPad E595
15e2 Raven/Raven2/FireFlight/Renoir Audio Processor
17aa 5124 ThinkPad E595
15e3 Family 17h (Models 10h-1fh) HD Audio Controller
103c 8615 Pavilion Laptop 15-cw1xxx
17aa 5124 ThinkPad E595
15e4 Raven/Raven2/Renoir Sensor Fusion Hub
15e5 Raven2 USB 3.1
15e6 Raven/Raven2/Renoir Non-Sensor Fusion Hub KMDF driver
@ -4890,6 +4915,7 @@
7801 FCH SATA Controller [AHCI mode]
103c 168b ProBook 4535s Notebook
103c 194e ProBook 455 G1 Notebook
17aa 3988 Z50-75
1849 7801 QC5000-ITX/PH
7802 FCH SATA Controller [RAID mode]
7803 FCH SATA Controller [RAID mode]
@ -4900,27 +4926,33 @@
7807 FCH USB OHCI Controller
103c 194e ProBook 455 G1 Notebook
103c 1985 Pavilion 17-e163sg Notebook PC
17aa 3988 Z50-75
1849 7807 QC5000-ITX/PH
7808 FCH USB EHCI Controller
103c 194e ProBook 455 G1 Notebook
103c 1985 Pavilion 17-e163sg Notebook PC
17aa 3988 Z50-75
1849 7808 QC5000-ITX/PH
7809 FCH USB OHCI Controller
103c 194e ProBook 455 G1 Notebook
17aa 3988 Z50-75
780a Kabini/Mullins SATA Raid/AHCI Mode (DotHill driver)
780b FCH SMBus Controller
103c 194e ProBook 455 G1 Notebook
103c 1985 Pavilion 17-e163sg Notebook PC
17aa 3988 Z50-75
1849 780b QC5000-ITX/PH
780c FCH IDE Controller
780d FCH Azalia Controller
103c 194e ProBook 455 G1 Notebook
103c 1985 Pavilion 17-e163sg Notebook PC
1043 8444 F2A85-M Series
17aa 3988 Z50-75
1849 8892 QC5000-ITX/PH
780e FCH LPC Bridge
103c 194e ProBook 455 G1 Notebook
103c 1985 Pavilion 17-e163sg Notebook PC
17aa 3988 Z50-75
1849 780e QC5000-ITX/PH
780f FCH PCI Bridge
7812 FCH USB XHCI Controller
@ -4928,6 +4960,7 @@
7814 FCH USB XHCI Controller
103c 194e ProBook 455 G1 Notebook
103c 1985 Pavilion 17-e163sg Notebook PC
17aa 3988 Z50-75
1849 7814 QC5000-ITX/PH
7900 FCH SATA Controller [IDE mode]
7901 FCH SATA Controller [AHCI mode]
@ -4941,9 +4974,11 @@
790b FCH SMBus Controller
103c 8615 Pavilion Laptop 15-cw1xxx
1462 7c37 X570-A PRO motherboard
17aa 5124 ThinkPad E595
790e FCH LPC Bridge
103c 8615 Pavilion Laptop 15-cw1xxx
1462 7c37 X570-A PRO motherboard
17aa 5124 ThinkPad E595
790f FCH PCI Bridge
7914 FCH USB XHCI Controller
9600 RS780 Host Bridge
@ -6502,6 +6537,8 @@
4802 Falcon
4803 Hawk
4806 CPX8216
# MPC7410 PowerPC microprocessor and PCI host bridge
480b MPC7410
4d68 20268
5600 SM56 PCI Modem
1057 0300 SM56 PCI Speakerphone Modem
@ -6932,6 +6969,8 @@
1077 02e4 QLE2772 Dual Port 32GFC PCIe Gen4 x8 Adapter
1077 02ee QLE2870 Single Port 64GFC PCIe Gen4 x8 Adapter
1077 02f0 QLE2770 Single Port 32GFC PCIe Gen4 x8 Adapter
1077 02f2 QLogic 1x32Gb QLE2770 FC HBA
1077 02f3 QLogic 2x32Gb QLE2772 FC HBA
1590 02d3 SN1610Q - 1P Enhanced 32GFC Single Port Fibre Channel Host Bus Adapter
1590 02d4 SN1610Q – 2P Enhanced 32GFC Dual Port Fibre Channel Host Bus Adapter
2300 QLA2300 64-bit Fibre Channel Adapter
@ -7010,6 +7049,8 @@
1077 0055 QLogic 2x10GE QL41132HQCU NIC
1077 0056 2x10GE QL41132HxRJ NIC
1077 0057 2x25GE QL41232HxCU NIC
1077 0065 QLogic 4x10GE QL41154HQRJ CNA
1077 0066 QLogic 4x10GE QL41154HQCU CNA
1077 0068 10GbE 2p SFP+ QL41132HLCU-HC Adapter
1077 0069 10GbE 2p BASE-T QL41132HQRJ-HC OCP3 Adapter
1077 0070 10GbE 2p BASE-T QL41132HLRJ-HC Adapter
@ -7053,6 +7094,8 @@
1077 000d FastLinQ QL41262H 25GbE iSCSI Adapter
1077 000e FastLinQ QL41162H 10GbE iSCSI Adapter
1077 000f 2x25GE QL41262HMKR CNA
1077 0065 QLogic 4x10GE QL41154HQRJ CNA
1077 0066 QLogic 4x10GE QL41154HQCU CNA
1590 021a 10GbE 2P QL41162HLRJ-HP Adapter
1590 021b 10GbE 2P QL41162HLRJ-HP Adapter
8090 FastLinQ QL41000 Series Gigabit Ethernet Controller (SR-IOV VF)
@ -7077,6 +7120,8 @@
1077 0055 QLogic 2x10GE QL41132HQCU NIC
1077 0056 2x10GE QL41132HxRJ NIC
1077 0057 2x25GE QL41232HxCU NIC
1077 0065 QLogic 4x10GE QL41154HQRJ CNA
1077 0066 QLogic 4x10GE QL41154HQCU CNA
1590 021a 10GbE 2P QL41162HLRJ-HP Adapter
1590 021b 10GbE 2P QL41162HLRJ-HP Adapter
1590 021e 10/25GbE 2P QL41162HMRJ-HP Adapter
@ -10937,6 +10982,7 @@
0fb9 GP107GL High Definition Audio Controller
0fba GM206 High Definition Audio Controller
0fbb GM204 High Definition Audio Controller
0fbc GM107 High Definition Audio Controller [GeForce 940MX]
0fc0 GK107 [GeForce GT 640 OEM]
0fc1 GK107 [GeForce GT 640]
0fc2 GK107 [GeForce GT 630 OEM]
@ -11714,6 +11760,7 @@
1406 GM206 [GeForce GTX 960 OEM]
1407 GM206 [GeForce GTX 750 v2]
1427 GM206M [GeForce GTX 965M]
103c 825b OMEN-17-w001nv
1430 GM206GL [Quadro M2000]
1431 GM206GL [Tesla M4]
1436 GM206GLM [Quadro M2200 Mobile]
@ -11734,6 +11781,7 @@
174e GM108M [GeForce MX110]
1789 GM107GL [GRID M3-3020]
179c GM107 [GeForce 940MX]
1025 1094 Acer Aspire E5-575G
17c2 GM200 [GeForce GTX TITAN X]
17c8 GM200 [GeForce GTX 980 Ti]
17f0 GM200GL [Quadro M6000]
@ -11850,6 +11898,8 @@
1cbd GP107GLM [Quadro P620]
1ccc GP107BM [GeForce GTX 1050 Ti Mobile]
1ccd GP107BM [GeForce GTX 1050 Mobile]
1cfa GP107GL [Quadro P2000]
1cfb GP107GL [Quadro P1000]
1d01 GP108 [GeForce GT 1030]
1d10 GP108M [GeForce MX150]
17aa 225e ThinkPad T480
@ -11873,6 +11923,8 @@
10de 131d Tesla V100-SXM3-32GB-H
1dba GV100GL [Quadro GV100]
10de 12eb TITAN V CEO Edition
1df0 GV100GL [Tesla PG500-216]
1df2 GV100GL [Tesla PG503-216]
1df5 GV100GL [Tesla V100 SXM2 16GB]
1df6 GV100GL [Tesla V100S PCIe 32GB]
1e02 TU102 [TITAN RTX]
@ -11884,6 +11936,10 @@
1e30 TU102GL [Quadro RTX 6000/8000]
10de 129e Quadro RTX 8000
10de 12ba Quadro RTX 6000
1e37 TU102GL [GRID RTX T10-4/T10-8/T10-16]
10de 1347 GRID RTX T10-8
10de 1348 GRID RTX T10-4
10de 1370 GRID RTX T10-16
1e38 TU102GL
1e3c TU102GL
1e3d TU102GL
@ -12154,6 +12210,8 @@
17aa 3832 Yoga 520
522a RTS522A PCI Express Card Reader
103c 8079 EliteBook 840 G3
103c 825b OMEN-17-w001nv
17aa 5124 ThinkPad E595
5249 RTS5249 PCI Express Card Reader
103c 1909 ZBook 15
524a RTS524A PCI Express Card Reader
@ -12165,6 +12223,7 @@
5260 RTS5260 PCI Express Card Reader
5286 RTS5286 PCI Express Card Reader
5287 RTL8411B PCI Express Card Reader
1025 1094 Acer Aspire E5-575G
5288 RTS5288 PCI Express Card Reader
5289 RTL8411 PCI Express Card Reader
1043 1457 K55A Laptop
@ -12247,6 +12306,7 @@
1462 236c 945P Neo3-F motherboard
8168 RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
1019 8168 RTL8111/8168 PCI Express Gigabit Ethernet controller
1025 1094 Acer Aspire E5-575G
1028 0283 Vostro 220
1028 04b2 Vostro 3350
1028 04da Vostro 3750
@ -12255,6 +12315,7 @@
103c 1611 Pavilion DM1Z-3000
103c 1950 ProBook 450/455
103c 2a6f Asus IPIBL-LB Motherboard
103c 825b OMEN-17-w001nv
103c 8615 Pavilion Laptop 15-cw1xxx
1043 11f5 Notebook motherboard (one of many models)
1043 16d5 U6V/U31J laptop
@ -12274,6 +12335,8 @@
1462 7522 X58 Pro-E
1462 7c37 X570-A PRO motherboard
1775 11cc CC11/CL11
17aa 3814 Z50-75
17aa 5124 ThinkPad E595
1849 8168 Motherboard (one of many)
7470 3468 TG-3468 Gigabit PCI Express Network Adapter
8086 2055 NUC Kit DN2820FYKH
@ -12324,8 +12387,11 @@
8821 RTL8821AE 802.11ac PCIe Wireless Network Adapter
b723 RTL8723BE PCIe Wireless Network Adapter
10ec 8739 Dell Wireless 1801
17aa b736 Z50-75
b822 RTL8822BE 802.11a/b/g/n/ac WiFi adapter
103c 831b Realtek RTL8822BE 802.11ac 2 × 2 Wi-Fi + Bluetooth 4.2 Combo Adapter (MU-MIMO supported)
17aa 5124 ThinkPad E595
17aa b023 ThinkPad E595
c821 RTL8821CE 802.11ac PCIe Wireless Network Adapter
c822 RTL8822CE 802.11ac PCIe Wireless Network Adapter
d723 RTL8723DE 802.11b/g/n PCIe Adapter
@ -12476,7 +12542,11 @@
1102 0021 X-Fi Platinum
1102 002c X-Fi XtremeGamer FATAL1TY PRO
1102 1003 X-Fi XtremeMusic
0006 EMU10k1X [SB Live! Value/OEM Series]
# This chip is also known as CA0103 on Sound Blaster 5.1 SB0680 card.
0006 EMU10k1X / CA0103 [SB Live! OEM / SB 5.1 / Ectiva 5.1]
1102 1001 SB0680 Sound Blaster 5.1
1102 1003 SB0203 SB Live! 5.1 (Dell)
1102 1004 TP0033 Ectiva Audio 5.1
0007 CA0106/CA0111 [SB Live!/Audigy/X-Fi Series]
1102 0007 SBLive! 24bit
1102 1001 SB0310 Audigy LS
@ -18067,6 +18137,7 @@
1028 1ff8 Express Flash PM1725b 3.2TB AIC
1028 1ff9 Express Flash PM1725b 6.4TB AIC
1028 1ffa Express Flash PM1725b 12.8TB AIC
a824 NVMe SSD Controller PM173X
144e OLITEC
144f Askey Computer Corp.
1450 Octave Communications Ind.
@ -19873,6 +19944,7 @@
1978 MT42822 Family [BlueField-2 SoC PCIe Bridge]
4117 MT27712A0-FDCF-AE
1bd4 0039 SN10XMP2P25
1bd4 003a 25G SFP28 SP EO251FM9 Adapter
1bd4 004d SN10XMP2P25,YZPC-01191-101
5274 MT21108 InfiniBridge
5a44 MT23108 InfiniHost
@ -20499,6 +20571,7 @@
0040 QCA9980/9990 802.11ac Wireless Network Adapter
0041 QCA6164 802.11ac Wireless Network Adapter
0042 QCA9377 802.11ac Wireless Network Adapter
11ad 08a6 Qualcomm Atheros QCA9377 802.11ac Wireless Network Adapter
0046 QCA9984 802.11ac Wave 2 Wireless Network Adapter
0050 QCA9887 802.11ac Wireless Network Adapter
0207 AR5210 Wireless Network Adapter [AR5000 802.11a]
@ -21892,6 +21965,7 @@
19e5 3036 NVMe SSD ES3600C V3 3200GB HHHL AIC
0200 Hi1822 Family (2*100GE)
19e5 d139 Hi1822 SP572 (2*100GE)
19e5 d13d Hi1822 SC371 (2*100GE)
0202 Hi1822 Family (2*32G FC)
19e5 d302 Hi1822 SP521 (2*32G FC)
19e5 d304 Hi1822 SP526 (2*32G FC)
@ -21902,11 +21976,13 @@
19e5 df27 Hi1822 MZ731 MEZZ (2*100GE)
0206 Hi1822 Family (2*25GE)
19e5 d138 Hi1822 SP582 (2*25GE)
19e5 d13a Hi1822 SC381 (2*25GE)
0210 Hi1822 Family (4*25GE)
19e5 df2e Hi1822 MZ532 MEZZ (4*25GE)
0211 Hi1822 Family (4*25GE)
19e5 d12f Hi1822 SP571 (4*25GE)
19e5 d137 Hi1822 SP581 (4*25GE)
19e5 d142 Hi1822 SP583 (4*25GE)
0212 Hi1822 Family (2*8G FC)
19e5 d303 Hi1822 SP522 (2*8G FC)
19e5 d306 Hi1822 SP523 (2*8G FC)
@ -21915,6 +21991,7 @@
1822 Hi1822 Family (4*25GE)
19e5 d129 Hi1822 SP570 (4*25GE)
19e5 d136 Hi1822 SP580 (4*25GE)
19e5 d141 Hi1822 SP583 (4*25GE)
371e Hi1822 Family Virtual Bridge
375e Hi1822 Family Virtual Function
379e Hi1822 Family Virtual Function
@ -22074,6 +22151,8 @@
4005 Accelerated Virtual Video Adapter
4006 Memory Ballooning Controller
1ab9 Espia Srl
1ac1 Global Unichip Corp.
089a Coral Edge TPU
1ac8 Aeroflex Gaisler
1acc Point of View BV
1ad7 Spectracom Corporation
@ -22465,6 +22544,7 @@
1283 PC300 NVMe Solid State Drive 256GB
1284 PC300 NVMe Solid State Drive 512GB
1285 PC300 NVMe Solid State Drive 1TB
1327 BC501 NVMe Solid State Drive 512GB
1504 SC300 512GB M.2 2280 SATA Solid State Drive
1c5f Beijing Memblaze Technology Co. Ltd.
000d PBlaze5 520/526 AIC
@ -22725,6 +22805,7 @@
1dbf Guizhou Huaxintong Semiconductor Technology Co., Ltd
0401 StarDragon4800 PCI Express Root Port
1dc5 FADU Inc.
1dcd Liqid Inc.
1dd8 Pensando Systems Inc
1000 DSC Capri Upstream Port
1dd8 4000 Naples 100Gb 2-port QSFP28 x16 8GB
@ -22805,6 +22886,8 @@
# JungleCat VU35P Module
1635 JCM35
1e26 Fujitsu Client Computing Limited
1e36 Shanghai Enflame Technology Co. Ltd
0001 T10 [CloudBlazer]
# nee Thinci, Inc
1e38 Blaize, Inc
1e3d Burlywood, Inc
@ -22820,6 +22903,8 @@
1e89 ID Quantique SA
0002 Quantis-PCIe-40M
0003 Quantis-PCIe-240M
# aka SED Systems
1e94 Calian SED
# nee Tumsan Oy
1fc0 Ascom (Finland) Oy
0300 E2200 Dual E1/Rawpipe Card
@ -24697,6 +24782,7 @@
1014 0549 Thinkpad
1179 0001 PRO/1000 MT Mobile Connection
8086 101e PRO/1000 MT Mobile Connection
101f Ethernet Controller V710 for 5GBASE-T
1026 82545GM Gigabit Ethernet Controller
1028 0168 Precision Workstation 670 Mainboard
1028 0169 Precision 470
@ -25440,6 +25526,7 @@
108e 7b15 Sun Dual Port 10 GbE PCIe 2.0 Low Profile Adapter, Base-T
1137 00bf Ethernet Converged Network Adapter X540-T2
1170 0052 Ethernet Controller 10-Gigabit X540-AT2
15d9 0734 AOC-STG-I2T
17aa 1073 ThinkServer X540-T2 AnyFabric
17aa 4006 Ethernet Controller 10-Gigabit X540-AT2
1bd4 001a 10G base-T DP ER102Ti3 Rack Adapter
@ -25847,6 +25934,7 @@
1903 Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor Thermal Subsystem
1028 06dc Latitude E7470
1028 06e4 XPS 15 9550
103c 825b OMEN-17-w001nv
17aa 225d ThinkPad T480
1904 Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor Host Bridge/DRAM Registers
1028 06dc Latitude E7470
@ -25862,6 +25950,7 @@
190f Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor Host Bridge/DRAM Registers
1910 Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor Host Bridge/DRAM Registers
1028 06e4 XPS 15 9550
103c 825b OMEN-17-w001nv
1911 Xeon E3-1200 v5/v6 / E3-1500 v5 / 6th/7th/8th Gen Core Processor Gaussian Mixture Model
17aa 2247 ThinkPad T570
17aa 224f ThinkPad X1 Carbon 5th Gen
@ -25875,6 +25964,7 @@
1919 Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor Imaging Unit
191b HD Graphics 530
1028 06e4 XPS 15 9550
103c 825b OMEN-17-w001nv
191d HD Graphics P530
191e HD Graphics 515
191f Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor Host Bridge/DRAM Registers
@ -29792,6 +29882,7 @@
1028 02da OptiPlex 980
1028 040a Latitude E6410
1028 040b Latitude E6510
103c 1521 EliteBook 8540p
144d c06a R730 Laptop
15d9 060d C7SIM-Q Motherboard
17c0 10d2 Medion Akoya E7214 Notebook PC [MD98410]
@ -30118,6 +30209,7 @@
5901 Xeon E3-1200 v6/7th Gen Core Processor PCIe Controller (x16)
5902 HD Graphics 610
5904 Xeon E3-1200 v6/7th Gen Core Processor Host Bridge/DRAM Registers
1025 115f Aspire E5-575G
17aa 2247 ThinkPad T570
17aa 224f ThinkPad X1 Carbon 5th Gen
5905 Xeon E3-1200 v6/7th Gen Core Processor PCIe Controller (x8)
@ -30131,6 +30223,7 @@
5914 Xeon E3-1200 v6/7th Gen Core Processor Host Bridge/DRAM Registers
17aa 225d ThinkPad T480
5916 HD Graphics 620
1025 1094 Aspire E5-575G
17aa 2248 ThinkPad T570
17aa 224f ThinkPad X1 Carbon 5th Gen
5917 UHD Graphics 620
@ -30867,6 +30960,7 @@
9ce5 Wildcat Point-LP Serial IO GSPI Controller #0
9ce6 Wildcat Point-LP Serial IO GSPI Controller #1
9d03 Sunrise Point-LP SATA Controller [AHCI mode]
1025 115f Acer Aspire E5-575G
1028 06dc Latitude E7470
1028 06f3 Latitude 3570
103c 8079 EliteBook 840 G3
@ -30887,6 +30981,7 @@
9d19 Sunrise Point-LP PCI Express Root Port #10
9d1a Sunrise Point-LP PCI Express Root Port #11
9d21 Sunrise Point-LP PMC
1025 115f Acer Aspire E5-575G
1028 06dc Latitude E7470
1028 06f3 Latitude 3570
103c 8079 EliteBook 840 G3
@ -30894,6 +30989,7 @@
17aa 225d ThinkPad T480
17aa 382a B51-80 Laptop
9d23 Sunrise Point-LP SMBus
1025 115f Acer Aspire E5-575G
1028 06dc Latitude E7470
1028 06f3 Latitude 3570
103c 8079 EliteBook 840 G3
@ -30907,6 +31003,7 @@
9d2a Sunrise Point-LP Serial IO SPI Controller #1
9d2d Sunrise Point-LP Secure Digital IO Controller
9d2f Sunrise Point-LP USB 3.0 xHCI Controller
1025 115f Acer Aspire E5-575G
1028 06dc Latitude E7470
1028 06f3 Latitude 3570
103c 8079 EliteBook 840 G3
@ -30914,6 +31011,7 @@
17aa 225d ThinkPad T480
17aa 382a B51-80 Laptop
9d31 Sunrise Point-LP Thermal subsystem
1025 115f Acer Aspire E5-575G
1028 06dc Latitude E7470
1028 06f3 Latitude 3570
103c 8079 EliteBook 840 G3
@ -30923,6 +31021,7 @@
17aa 382a B51-80 Laptop
9d35 Sunrise Point-LP Integrated Sensor Hub
9d3a Sunrise Point-LP CSME HECI #1
1025 115f Acer Aspire E5-575G
1028 06dc Latitude E7470
1028 06f3 Latitude 3570
103c 8079 EliteBook 840 G3
@ -30943,9 +31042,11 @@
9d50 Sunrise Point LPC Controller
9d56 Sunrise Point-LP LPC Controller
9d58 Sunrise Point-LP LPC Controller
1025 115f Acer Aspire E5-575G
17aa 2247 ThinkPad T570
17aa 224f ThinkPad X1 Carbon 5th Gen
9d60 Sunrise Point-LP Serial IO I2C Controller #0
1025 115f Acer Aspire E5-575G
1028 06f3 Latitude 3570
103c 8079 EliteBook 840 G3
17aa 225d ThinkPad T480
@ -30962,6 +31063,7 @@
103c 8079 EliteBook 840 G3
17aa 382a B51-80 Laptop
9d71 Sunrise Point-LP HD Audio
1025 1094 Acer Aspire E5-575G
17aa 224f ThinkPad X1 Carbon 5th Gen
17aa 225d ThinkPad T480
9d84 Cannon Point-LP LPC Controller
@ -31017,6 +31119,7 @@
a102 Q170/Q150/B150/H170/H110/Z170/CM236 Chipset SATA Controller [AHCI Mode]
a103 HM170/QM170 Chipset SATA Controller [AHCI Mode]
1028 06e4 XPS 15 9550
103c 825b OMEN-17-w001nv
a105 Sunrise Point-H SATA Controller [RAID mode]
a106 Q170/H170/Z170/CM236 Chipset SATA Controller [RAID Mode]
a107 HM170/QM170 Chipset SATA Controller [RAID Mode]
@ -31040,9 +31143,11 @@
a120 100 Series/C230 Series Chipset Family P2SB
a121 100 Series/C230 Series Chipset Family Power Management Controller
1028 06e4 XPS 15 9550
103c 825b OMEN-17-w001nv
a122 Sunrise Point-H cAVS
a123 100 Series/C230 Series Chipset Family SMBus
1028 06e4 XPS 15 9550
103c 825b OMEN-17-w001nv
a124 100 Series/C230 Series Chipset Family SPI Controller
a125 100 Series/C230 Series Chipset Family Gigabit Ethernet Controller
a126 100 Series/C230 Series Chipset Family Trace Hub
@ -31052,13 +31157,16 @@
a12a 100 Series/C230 Series Chipset Family Serial IO GSPI #1
a12f 100 Series/C230 Series Chipset Family USB 3.0 xHCI Controller
1028 06e4 XPS 15 9550
103c 825b OMEN-17-w001nv
a130 100 Series/C230 Series Chipset Family USB Device Controller (OTG)
a131 100 Series/C230 Series Chipset Family Thermal Subsystem
1028 06e4 XPS 15 9550
103c 825b OMEN-17-w001nv
a133 Sunrise Point-H Northpeak ACPI Function
a135 100 Series/C230 Series Chipset Family Integrated Sensor Hub
a13a 100 Series/C230 Series Chipset Family MEI Controller #1
1028 06e4 XPS 15 9550
103c 825b OMEN-17-w001nv
a13b 100 Series/C230 Series Chipset Family MEI Controller #2
a13c 100 Series/C230 Series Chipset Family IDE Redirection
a13d 100 Series/C230 Series Chipset Family KT Redirection
@ -31079,6 +31187,7 @@
a14d QM170 Chipset LPC/eSPI Controller
a14e HM170 Chipset LPC/eSPI Controller
1028 06e4 XPS 15 9550
103c 825b OMEN-17-w001nv
a14f Sunrise Point-H LPC Controller
a150 CM236 Chipset LPC/eSPI Controller
a151 Sunrise Point-H LPC Controller
@ -31098,6 +31207,7 @@
a15f Sunrise Point-H LPC Controller
a160 100 Series/C230 Series Chipset Family Serial IO I2C Controller #0
1028 06e4 XPS 15 9550
103c 825b OMEN-17-w001nv
a161 100 Series/C230 Series Chipset Family Serial IO I2C Controller #1
1028 06e4 XPS 15 9550
a162 100 Series/C230 Series Chipset Family Serial IO I2C Controller #2
@ -31109,6 +31219,7 @@
a16a 100 Series/C230 Series Chipset Family PCI Express Root Port #20
a170 100 Series/C230 Series Chipset Family HD Audio Controller
1028 06e4 XPS 15 9550
103c 825b OMEN-17-w001nv
a171 CM238 HD Audio Controller
a182 C620 Series Chipset Family SATA Controller [AHCI mode]
a186 C620 Series Chipset Family SATA Controller [RAID mode]
@ -31318,6 +31429,7 @@
d158 Core Processor Miscellaneous Registers
f1a5 SSD 600P Series
f1a6 SSD Pro 7600p/760p/E 6100p Series
8086 390b Intel Corporation SSD Pro 7600p/760p/E 6100p Series [NVM Express]
f1a8 SSD 660P Series
8088 Beijing Wangxun Technology Co., Ltd.
0101 WX1860A2 Gigabit Ethernet Controller

69
hwdb.d/usb.ids
View File

@ -9,8 +9,8 @@
# The latest version can be obtained from
# http://www.linux-usb.org/usb.ids
#
# Version: 2020.01.09
# Date: 2020-01-09 20:34:06
# Version: 2020.02.28
# Date: 2020-02-28 20:34:06
#
# Vendors, devices and interfaces. Please keep sorted.
@ -42,6 +42,7 @@
a001 Digitus DA-71114 SATA
0085 Boeye Technology Co., Ltd.
0600 eBook Reader
0102 miniSTREAK
0105 Trust International B.V.
145f NW-3100 802.11b/g 54Mbps Wireless Network Adapter [zd1211]
0127 IBP
@ -172,6 +173,7 @@
7617 AT76C505AS Wireless Adapter
7800 Mini Album
800c Airspy HF+
ff01 WootingOne
ff02 WootingTwo
ff07 Tux Droid fish dongle
03ec Iwatsu America, Inc.
@ -702,6 +704,7 @@
c102 PhotoSmart 8000 series
c111 Deskjet 1510
c202 PhotoSmart 8200 series
c211 Deskjet 2540 series
c302 DeskJet D2300
c402 PhotoSmart D5100 series
c502 PhotoSmart D6100 series
@ -798,6 +801,7 @@
8370 7 Port Hub
8371 PS/2 Keyboard And Mouse
8372 FT8U100AX Serial Port
8508 Selectronic SP PRO
87d0 Cressi Dive Computer Interface
8a28 Rainforest Automation ZigBee Controller
8a98 TIAO Multi-Protocol Adapter
@ -812,6 +816,7 @@
9135 Rotary Pub alarm
9136 Pulsecounter
9e90 Marvell OpenRD Base/Client
9f08 CIB-1894 Conclusion SmartLink Box:
9f80 Ewert Energy Systems CANdapter
a6d0 Texas Instruments XDS100v2 JTAG / BeagleBone A3
a951 HCP HIT GSM/GPRS modem [Cinterion MC55i]
@ -1165,6 +1170,7 @@
602a i900
040b Weltrend Semiconductor
0a68 Func MS-3 gaming mouse [WT6573F MCU]
2000 wired Keyboard [Dynex DX-WRK1401]
2367 Human Interface Device [HP CalcPad 200 Calculator and Numeric Keypad]
6510 Weltrend Bar Code Reader
6520 Xploder Xbox Memory Unit (8MB)
@ -1980,10 +1986,14 @@
b700 Tacticalboard
0450 DFI, Inc.
0451 Texas Instruments, Inc.
0422 TUSB422 Port Controller with Power Delivery
1234 Bluetooth Device
1428 Hub
1446 TUSB2040/2070 Hub
16a2 CC Debugger
16a6 BM-USBD1 BlueRobin RF heart rate sensor receiver
16a8 CC2531 ZigBee
16ae CC2531 Dongle
2036 TUSB2036 Hub
2046 TUSB2046 Hub
2077 TUSB2077 Hub
@ -2018,6 +2028,7 @@
e012 TI-Nspire Calculator
e013 Network Bridge
e01c Data Collection Sled [Nspire Lab Cradle, Nspire Datatracker Cradle]
e01e Nspire™ CX Navigator™ Access Point
e01f Python Adapter (firmware install mode)
e020 Python Adapter
e022 Nspire CX II
@ -2050,6 +2061,7 @@
0002 Genius NetMouse Pro
0003 Genius NetScroll+
0006 Easy Mouse+
0007 Trackbar Emotion
000b NetMouse Wheel(P+U)
000c TACOMA Fingerprint V1.06.01
000e Genius NetScroll Optical
@ -2256,6 +2268,7 @@
00cb Basic Optical Mouse v2.0
00ce Generic PPC Flash device
00d1 Optical Mouse with Tilt Wheel
00d2 Notebook Optical Mouse with Tilt Wheel
00da eHome Infrared Receiver
00db Natural Ergonomic Keyboard 4000 V1.0
00dd Comfort Curve Keyboard 2000 V1.0
@ -2474,6 +2487,7 @@
07cd Surface Keyboard
07f8 Wired Keyboard 600 (model 1576)
07fd Nano Transceiver 1.1
0810 LifeCam HD-3000
0900 Surface Dock Hub
0901 Surface Dock Hub
0902 Surface Dock Hub
@ -2551,12 +2565,14 @@
4d62 HP Laser Mobile Mini Mouse
4d75 Rocketfish RF-FLBTAD Bluetooth Adapter
4d81 Dell N889 Optical Mouse
4d8a HP Multimedia Keyboard
4d91 Laser mouse M-D16DL
4d92 Optical mouse M-D17DR
4db1 Dell Laptop Integrated Webcam 2Mpix
4de3 HP 5-Button Optical Comfort Mouse
4de7 webcam
4e04 Lenovo Keyboard KB1021
4e6f Acer Wired Keyboard Model KBAY211
0463 MGE UPS Systems
0001 UPS
ffff UPS
@ -2585,6 +2601,7 @@
00a1 SmartCard Reader Keyboard KC 1000 SC
0106 R-300 Wireless Mouse Receiver
010d MX-Board 3.0 Keyboard
0180 Strait 3.0
b090 Keyboard
b091 Mouse
046b American Megatrends, Inc.
@ -2742,6 +2759,7 @@
0a45 960 Headset
0a4d G430 Surround Sound Gaming Headset
0a5b G933 Wireless Headset Dongle
0a5d G933 Headset Battery Charger
0a66 [G533 Wireless Headset Dongle]
0b02 C-UV35 [Bluetooth Mini-Receiver] (HID proxy mode)
8801 Video Camera
@ -2871,6 +2889,7 @@
c231 G13 Virtual Mouse
c245 G400 Optical Mouse
c246 Gaming Mouse G300
c247 G100S Optical Gaming Mouse
c248 G105 Gaming Keyboard
c24a G600 Gaming Mouse
c24c G400s Optical Mouse
@ -2919,6 +2938,7 @@
c31f Comfort Keyboard K290
c326 Washable Keyboard K310
c328 Corded Keyboard K280e
c32b G910 Orion Spark Mechanical Keyboard
c332 G502 Proteus Spectrum Optical Mouse
c335 G910 Orion Spectrum Mechanical Keyboard
c33a G413 Gaming Keyboard
@ -2960,6 +2980,8 @@
c531 C-U0007 [Unifying Receiver]
c532 Unifying Receiver
c534 Unifying Receiver
c537 Cordless Mouse Receiver
c53a PowerPlay Wireless Charging System
c603 3Dconnexion Spacemouse Plus XT
c605 3Dconnexion CADman
c606 3Dconnexion Spacemouse Classic
@ -3247,6 +3269,7 @@
f101 Atlas Modem
047f Plantronics, Inc.
0101 Bulk Driver
02ee BT600
0301 Bulk Driver
0411 Savi Office Base Station
0ca1 USB DSP v4 Audio Interface
@ -3256,6 +3279,7 @@
af01 DA80
c008 Audio 655 DSP
c00e Blackwire C310 headset
c03b HD1
0480 Toshiba America Inc
0001 InTouch Module
0004 InTouch Module
@ -3265,6 +3289,7 @@
0200 External Disk
0820 Canvio Advance Disk
0821 Canvio Advance 2TB model DTC920
0900 MQ04UBF100
a006 External Disk 1.5TB
a007 External Disk USB 3.0
a009 Stor.E Basics
@ -3334,6 +3359,7 @@
8259 Probe
91d1 Sensor Hub
a171 ThermaData WiFi
a2e0 BMeasure instrument
df11 STM Device in DFU Mode
ff10 Swann ST56 Modem
0484 Specialix
@ -3363,6 +3389,7 @@
048d Integrated Technology Express, Inc.
1165 IT1165 Flash Controller
1172 Flash Drive
1234 Mass storage
1336 SD/MMC Cardreader
1345 Multi Cardreader
9006 IT9135 BDA Afatech DVB-T HDTV Dongle
@ -3708,6 +3735,7 @@
10c9 PIXMA iP4600 Printer
10ca PIXMA iP3600 Printer
10e3 PIXMA iX6850 Printer
12fe Printer in service mode
1404 W6400PG
1405 W8400PG
150f BIJ2350 PCL
@ -3823,6 +3851,7 @@
178a PIXMA MG3600 Series
178d PIXMA MG6853
180b PIXMA MG3000 series
1856 PIXMA TS6250
1900 CanoScan LiDE 90
1901 CanoScan 8800F
1904 CanoScan LiDE 100
@ -3891,6 +3920,7 @@
2633 LASERCLASS 500
2634 PC-D300/FAX-L400/ICD300
2635 MPC190
2636 LBP3200
2637 iR C6800
2638 iR C3100
263c PIXMA MP360
@ -3905,8 +3935,10 @@
264f MF5650 (FAX)
2650 iR 6800C EUR
2651 iR 3100C EUR
2654 LBP3600
2655 FP-L170/MF350/L380/L398
2656 iR1510-1670 CAPT Printer
2657 LBP3210
2659 MF8100
265b CAPT Printer
265c iR C3220
@ -3920,7 +3952,7 @@
2666 iR C5800
2667 iR85PLUS
2669 iR105PLUS
266a CAPT Device
266a LBP3000
266b iR8070
266c iR9070
266d iR 5800C EUR
@ -3935,31 +3967,46 @@
2676 LBP2900
2677 iR C2570
2678 iR 2570C EUR
2679 CAPT Device
2679 LBP5000
267a iR2016
267b iR2020
267d MF7100 series
267e LBP3300
2684 MF3200 series
2686 MF6500 series
2687 iR4530
2688 LBP3460
2689 FAX-L180/L380S/L398S
268a LC310/L390/L408S
268b LBP3500
268c iR C6870
268d iR 6870C EUR
268e iR C5870
268f iR 5870C EUR
2691 iR7105
26a1 LBP5300
26a3 MF4100 series
26a4 LBP5100
26b0 MF4600 series
26b4 MF4010 series
26b5 MF4200 series
26b6 FAX-L140/L130
26da LBP3010B printer
26b9 LBP3310
26ba LBP5050
26da LBP3010/LBP3018/LBP3050
26db LBP3100/LBP3108/LBP3150
26e6 iR1024
26ea LBP9100C
26ee MF4320-4350
26f1 LBP7200C
26ff LBP6300
271a LBP6000
271b LBP6200
271c LBP7010C/7018C
2736 I-SENSYS MF4550d
2737 MF4410
2771 LBP6020
2796 LBP6230/6240
3041 PowerShot S10
3042 CanoScan FS4000US Film Scanner
3043 PowerShot S20
@ -4362,6 +4409,7 @@
0429 D5100
042a D800 (ptp)
0430 D7100
0436 D810
043f D5600
0f03 PD-10 Wireless Printer Adapter
4000 Coolscan LS 40 ED
@ -4423,6 +4471,7 @@
4611 Storage Adapter FX2 (CY)
4616 Flash Disk (TPP)
4624 DS-Xtreme Flash Card
4717 West Bridge
5201 Combi Keyboard-Hub (Hub)
5202 Combi Keyboard-Hub (Keyboard)
5500 HID->COM RS232 Adapter
@ -11687,10 +11736,16 @@
09c1 Arris Interactive LLC
1337 TOUCHSTONE DEVICE
09c2 Nisca Corp.
09c3 ActivCard, Inc.
09c3 HID Global
0007 Reader V2
0008 ZFG-9800-AC SmartCard Reader
0014 ActivIdentity ActivKey SIM USB Token
0028 Crescendo Key
0029 Crescendo Key
002a Crescendo Key
002b Crescendo Key
002c Crescendo Key
002e Crescendo Key
09c4 ACTiSYS Corp.
0011 ACT-IR2000U IrDA Dongle
09c5 Memory Corp.
@ -19316,6 +19371,8 @@
2548 Pulse-Eight
1001 CEC Adapter
1002 CEC Adapter
25b5 FlatFrog
0002 Multitouch 3200
2632 TwinMOS
3209 7-in-1 Card Reader
2639 Xsens

9
man/busctl.xml
View File

@ -388,6 +388,15 @@
<xi:include href="user-system-options.xml" xpointer="host" />
<xi:include href="user-system-options.xml" xpointer="machine" />
<varlistentry>
<term><option>-l</option></term>
<term><option>--full</option></term>
<listitem>
<para>Do not ellipsize the output in <command>list</command> command.</para>
</listitem>
</varlistentry>
<xi:include href="standard-options.xml" xpointer="no-pager" />
<xi:include href="standard-options.xml" xpointer="no-legend" />
<xi:include href="standard-options.xml" xpointer="help" />

64
man/crypttab.xml
View File

@ -10,7 +10,7 @@
The Red Hat version has been written by Miloslav Trmac <mitr@redhat.com>.
-->
<refentry id="crypttab" conditional='HAVE_LIBCRYPTSETUP'>
<refentry id="crypttab" conditional='HAVE_LIBCRYPTSETUP' xmlns:xi="http://www.w3.org/2001/XInclude">
<refentryinfo>
<title>crypttab</title>
@ -413,9 +413,22 @@
<varlistentry>
<term><option>verify</option></term>
<listitem><para> If the encryption password is read from
console, it has to be entered twice to prevent
typos.</para></listitem>
<listitem><para>If the encryption password is read from console, it has to be entered twice to
prevent typos.</para></listitem>
</varlistentry>
<varlistentry>
<term><option>pkcs11-uri=</option></term>
<listitem><para>Takes a <ulink url="https://tools.ietf.org/html/rfc7512">RFC7512 PKCS#11 URI</ulink>
pointing to a private RSA key which is used to decrypt the key specified in the third column of the
line. This is useful for unlocking encrypted volumes through security tokens or smartcards. See below
for an example how to set up this mechanism for unlocking a LUKS volume with a YubiKey security
token. The specified URI can refer directly to a private RSA key stored on a token or alternatively
just to a slot or token, in which case a search for a suitable private RSA key will be performed. In
this case if multiple suitable objects are found the token is refused. The key configured in the
third column is passed as is to RSA decryption. The resulting decrypted key is then base64 encoded
before it is used to unlock the LUKS volume.</para></listitem>
</varlistentry>
<varlistentry>
@ -431,6 +444,25 @@
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>x-initrd.attach</option></term>
<listitem><para>Setup this encrypted block device in the initramfs, similarly to
<citerefentry><refentrytitle>systemd.mount</refentrytitle><manvolnum>5</manvolnum></citerefentry>
units marked with <option>x-initrd.mount</option>.</para>
<para>Although it's not necessary to mark the mount entry for the root file system with
<option>x-initrd.mount</option>, <option>x-initrd.attach</option> is still recommended with
the encrypted block device containing the root file system as otherwise systemd will
attempt to detach the device during the regular system shutdown while it's still in
use. With this option the device will still be detached but later after the root file
system is unmounted.</para>
<para>All other encrypted block devices that contain file systems mounted in the initramfs
should use this option.</para>
</listitem>
</varlistentry>
</variablelist>
<para>At early boot and when the system manager configuration is
@ -439,7 +471,7 @@
</refsect1>
<refsect1>
<title>Example</title>
<title>Examples</title>
<example>
<title>/etc/crypttab example</title>
<para>Set up four encrypted block devices. One using LUKS for
@ -452,6 +484,28 @@ truecrypt /dev/sda2 /etc/container_password tcrypt
hidden /mnt/tc_hidden /dev/null tcrypt-hidden,tcrypt-keyfile=/etc/keyfile
external /dev/sda3 keyfile:LABEL=keydev keyfile-timeout=10s</programlisting>
</example>
<example>
<title>Yubikey-based Volume Unlocking Example</title>
<para>The PKCS#11 logic allows hooking up any compatible security token that is capable of storing RSA
decryption keys. Here's an example how to set up a Yubikey security token for this purpose, using
<command>ykman</command> from the yubikey-manager project:</para>
<programlisting><xi:include href="yubikey-crypttab.sh" parse="text" /></programlisting>
<para>A few notes on the above:</para>
<itemizedlist>
<listitem><para>We use RSA (and not ECC), since Yubikeys support PKCS#11 Decrypt() only for RSA keys</para></listitem>
<listitem><para>We use RSA2048, which is the longest key size current Yubikeys support</para></listitem>
<listitem><para>LUKS key size must be shorter than 2048bit due to RSA padding, hence we use 128 bytes</para></listitem>
<listitem><para>We use Yubikey key slot 9d, since that's apparently the keyslot to use for decryption purposes,
<ulink url="https://developers.yubico.com/PIV/Introduction/Certificate_slots.html">see
documentation</ulink>.</para></listitem>
</itemizedlist>
</example>
</refsect1>
<refsect1>

35
man/environment.d.xml
View File

@ -36,11 +36,11 @@
<refsect1>
<title>Description</title>
<para>The <filename>environment.d</filename> directories contain a list of "global" environment
variable assignments for the user environment.
<para>The <filename>environment.d</filename> directories contain a list of environment variable
assignments for services started by the systemd user instance.
<citerefentry><refentrytitle>systemd-environment-d-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>
parses them and updates the environment exported by the systemd user instance to the services it
starts.</para>
parses them and updates the environment exported by the systemd user instance. See below for an
discussion of which processes inherit those variables.</para>
<para>It is recommended to use numerical prefixes for file names to simplify ordering.</para>
@ -89,6 +89,33 @@
</refsect2>
</refsect1>
<refsect1>
<title>Applicability</title>
<para>Environment variables exported by the user manager (<command>systemd --user</command> instance
started in the <filename>user@<replaceable>uid</replaceable>.service</filename> system service) apply to
any services started by that manager. In particular, this may include services which run user shells. For
example in the Gnome environment, the graphical terminal emulator runs as the
<filename>gnome-terminal-server.service</filename> user unit, which in turn runs the user shell, so that
shell will inherit environment variables exported by the user manager. For other instances of the shell,
not launched by the user manager, the environment they inherit is defined by the program that starts
them. Hint: in general,
<citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>
units contain programs launched by systemd, and
<citerefentry><refentrytitle>systemd.scope</refentrytitle><manvolnum>5</manvolnum></citerefentry>
units contain programs launched by something else.</para>
<para>Specifically, for ssh logins, the
<citerefentry project='die-net'><refentrytitle>sshd</refentrytitle><manvolnum>8</manvolnum></citerefentry>
service builds an environment that is a combination of variables forwarded from the remote system and
defined by <command>sshd</command>, see the discussion in
<citerefentry project='die-net'><refentrytitle>ssh</refentrytitle><manvolnum>1</manvolnum></citerefentry>.
A graphical display session will have an analogous mechanism to define the environment. Note that some
managers query the systemd user instance for the exported environment and inject this configuration into
programs they start, using <command>systemctl show-environment</command> or the underlying D-Bus call.
</para>
</refsect1>
<refsect1>
<title>See Also</title>
<para>

20
man/halt.xml
View File

@ -41,9 +41,8 @@
<refsect1>
<title>Description</title>
<para><command>halt</command>, <command>poweroff</command>,
<command>reboot</command> may be used to halt, power-off or reboot
the machine.</para>
<para><command>halt</command>, <command>poweroff</command>, <command>reboot</command> may be used to
halt, power-off, or reboot the machine. All three commands take the same options.</para>
</refsect1>
@ -137,12 +136,15 @@
<refsect1>
<title>Notes</title>
<para>These commands are implemented in a way that preserves compatibility with
the original SysV commands.
<citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
verbs <command>halt</command>, <command>poweroff</command>,
<command>reboot</command> provide the same functionality with some additional
features.</para>
<para>These commands are implemented in a way that preserves basic compatibility with the original SysV
commands. <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
verbs <command>halt</command>, <command>poweroff</command>, <command>reboot</command> provide the same
functionality with some additional features.</para>
<para>Note that on many SysV systems <command>halt</command> used to be synonymous to
<command>poweroff</command>, i.e. both commands would equally result in powering the machine off. systemd
is more accurate here, and <command>halt</command> results in halting the machine only (leaving power
on), and <command>poweroff</command> is required to actually power it off.</para>
</refsect1>
<refsect1>

833
man/homectl.xml Normal file
View File

@ -0,0 +1,833 @@
<?xml version='1.0'?>
<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
<!-- SPDX-License-Identifier: LGPL-2.1+ -->
<refentry id="homectl" conditional='ENABLE_HOMED'
xmlns:xi="http://www.w3.org/2001/XInclude">
<refentryinfo>
<title>homectl</title>
<productname>systemd</productname>
</refentryinfo>
<refmeta>
<refentrytitle>homectl</refentrytitle>
<manvolnum>1</manvolnum>
</refmeta>
<refnamediv>
<refname>homectl</refname>
<refpurpose>Create, remove, change or inspect home directories</refpurpose>
</refnamediv>
<refsynopsisdiv>
<cmdsynopsis>
<command>homectl</command>
<arg choice="opt" rep="repeat">OPTIONS</arg>
<arg choice="req">COMMAND</arg>
<arg choice="opt" rep="repeat">NAME</arg>
</cmdsynopsis>
</refsynopsisdiv>
<refsect1>
<title>Description</title>
<para><command>homectl</command> may be used to create, remove, change or inspect a user's home
directory. It's primarily a command interfacing with
<citerefentry><refentrytitle>systemd-homed.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
which manages home directories of users.</para>
<para>Home directories managed by <filename>systemd-homed.service</filename> are self-contained, and thus
include the user's full metadata record in the home's data storage itself, making them easy to migrate
between machines. In particular, a home directory describes a matching user record, and every user record
managed by <filename>systemd-homed.service</filename> also implies existence and encapsulation of a home
directory. The user account and home directory become the same concept.</para>
<para>The following backing storage mechanisms are supported:</para>
<itemizedlist>
<listitem><para>An individual LUKS2 encrypted loopback file for a user, stored in
<filename>/home/*.home</filename>. At login the file system contained in this files is mounted, after
the LUKS2 encrypted volume has been attached. The user's password is identical to the encryption
passphrase of the LUKS2 volume. Access to data without preceeding user authentication is thus not
possible, even for the system administrator. This storage mechanism provides the strongest data
security and is thus recommended.</para></listitem>
<listitem><para>Similar, but the LUKS2 encrypted file system is located on regular block device, such
as an USB storage stick. In this mode home directories and all data they include are nicely migratable
between machines, simply by plugging the USB stick into different systems at different
times.</para></listitem>
<listitem><para>An encrypted directory using <literal>fscrypt</literal> on file systems that support it
(at the moment this is primarily <literal>ext4</literal>), located in
<filename>/home/*.homedir</filename>. This mechanism also provides encryption, but substantially
weaker than LUKS2, as most file system metadata is unprotected. Moreover
it currently does not support changing user passwords once the home directory has been
created.</para></listitem>
<listitem><para>A <literal>btrfs</literal> subvolume for each user, also located in
<filename>/home/*.homedir</filename>. This provides no encryption, but good quota
support.</para></listitem>
<listitem><para>A regular directory for each user, also located in
<filename>/home/*.homedir</filename>. This provides no encryption, but is a suitable fallback
available on all machines, even where LUKS2, <literal>fscrypt</literal> or <literal>btrfs</literal>
support is not available.</para></listitem>
<listitem><para>An individual Windows file share (CIFS) for each user.</para></listitem>
</itemizedlist>
<para>Note that <filename>systemd-homed.service</filename> and <command>homectl</command> will not manage
"classic" UNIX user accounts as created with <citerefentry
project='man-pages'><refentrytitle>useradd</refentrytitle><manvolnum>8</manvolnum></citerefentry> or
similar tools. In particular, this functionality is not suitable for managing system users (i.e. users
with a UID below 1000) but is exclusive to regular ("human") users.</para>
<para>Note that users/home directories managed via <command>systemd-homed.service</command> do not show
up in <filename>/etc/passwd</filename> and similar files, they are synthesized via glibc NSS during
runtime. They are thus resolvable and may be enumerated via the <citerefentry
project='man-pages'><refentrytitle>getent</refentrytitle><manvolnum>1</manvolnum></citerefentry>
tool.</para>
<para>This tool interfaces directly with <filename>systemd-homed.service</filename>, and may execute
specific commands on the home directories it manages. Since every home directory managed that way also
defines a JSON user and group record these home directories may also be inspected and enumerated via
<citerefentry><refentrytitle>userdbctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>.</para>
<para>Home directories managed by <filename>systemd-homed.service</filename> are usually in one of two
states, or in a transition state between them: when <literal>active</literal> they are unlocked and
mounted, and thus accessible to the system and its programs; when <literal>inactive</literal> they are
not mounted and thus not accessible. Activation happens automatically at login of the user and usually
can only complete after a password (or other authentication token) has been supplied. Deactivation
happens after the user fully logged out. A home directory remains active as long as the user is logged in
at least once, i.e. has at least one login session. When the user logs in a second time simultaneously
the home directory remains active. It is deactivated only after the last of the user's sessions
ends.</para>
</refsect1>
<refsect1>
<title>Options</title>
<para>The following general options are understood (further options that control the various properties
of user records managed by <filename>systemd-homed.service</filename> are documented further
down):</para>
<variablelist>
<varlistentry>
<term><option>--identity=</option><replaceable>FILE</replaceable></term>
<listitem><para>Read the user's JSON record from the specified file. If passed as
<literal>-</literal> reads the user record from standard input. The supplied JSON object must follow
the structure documented on <ulink url="https://systemd.io/USER_RECORDS">JSON User
Records</ulink>. This option may be used in conjunction with the <command>create</command> and
<command>update</command> commands (see below), where it allows configuring the user record in JSON
as-is, instead of setting the individual user record properties (see below).</para></listitem>
</varlistentry>
<varlistentry>
<term><option>--json=</option><replaceable>FORMAT</replaceable></term>
<term><option>-J</option></term>
<listitem><para>Controls whether to output the user record in JSON format, if the
<command>inspect</command> command (see below) is used. Takes one of <literal>pretty</literal>,
<literal>short</literal> or <literal>off</literal>. If <literal>pretty</literal> human-friendly
whitespace and newlines are inserted in the output to make the JSON data more readable. If
<literal>short</literal> all superfluous whitespace is suppressed. If <literal>off</literal> (the
default) the user information is not shown in JSON format but in a friendly human readable formatting
instead. The <option>-J</option> option picks <literal>pretty</literal> when run interactively and
<literal>short</literal> otherwise.</para></listitem>
</varlistentry>
<varlistentry>
<term><option>--export-format=</option><replaceable>FORMAT</replaceable></term>
<term><option>-E</option></term>
<term><option>-EE</option></term>
<listitem><para>When used with the <command>inspect</command> verb in JSON mode (see above) may be
used to suppress certain aspects of the JSON user record on output. Specifically, if
<literal>stripped</literal> format is used the binding and runtime fields of the record are
removed. If <literal>minimal</literal> format is used the cryptographic signature is removed too. If
<literal>full</literal> format is used the full JSON record is shown (this is the default). This
option is useful for copying an existing user record to a different system in order to create a
similar user there with the same settings. Specifically: <command>homectl inspect -EE | ssh
root@othersystem homectl create -i-</command> may be used as simple command line for replicating a
user on another host. <option>-E</option> is equivalent to <option>-j --export-format=stripped</option>,
<option>-EE</option> to <option>-j --export-format=minimal</option>. Note that when replicating user
accounts user records acquired in <literal>stripped</literal> mode will retain the original
cryptographic signatures and thus may only be modified when the private key to update them is available
on the destination machine. When replicating users in <literal>minimal</literal> mode, the signature
is removed during the replication and thus the record will be implicitly signed with the key of the destination
machine and may be updated there without any private key replication.</para></listitem>
</varlistentry>
<xi:include href="user-system-options.xml" xpointer="host" />
<xi:include href="user-system-options.xml" xpointer="machine" />
<xi:include href="standard-options.xml" xpointer="no-pager" />
<xi:include href="standard-options.xml" xpointer="no-legend" />
<xi:include href="standard-options.xml" xpointer="no-ask-password" />
<xi:include href="standard-options.xml" xpointer="help" />
<xi:include href="standard-options.xml" xpointer="version" />
</variablelist>
</refsect1>
<refsect1>
<title>User Record Properties</title>
<para>The following options control various properties of the user records/home directories that
<filename>systemd-homed.service</filename> manages. These switches may be used in conjunction with the
<command>create</command> and <command>update</command> commands for configuring various aspects of the
home directory and the user account:</para>
<variablelist>
<varlistentry>
<term><option>--real-name=</option><replaceable>NAME</replaceable></term>
<term><option>-c</option> <replaceable>NAME</replaceable></term>
<listitem><para>The real name for the user. This corresponds with the GECOS field on classic UNIX NSS
records.</para></listitem>
</varlistentry>
<varlistentry>
<term><option>--realm=</option><replaceable>REALM</replaceable></term>
<listitem><para>The realm for the user. The realm associates a user with a specific organization or
installation, and allows distuingishing users of the same name defined in different contexts. The
realm can be any string that also qualifies as valid DNS domain name, and it is recommended to use
the organization's or installation's domain name for this purpose, but this is not enforced nor
required. On each system only a single user of the same name may exist, and if a user with the same
name and realm is seen it is assumed to refer to the same user while a user with the same name but
different realm is considered a different user. Note that this means that two users sharing the same
name but with distinct realms are not allowed on the same system. Assigning a realm to a user is
optional.</para></listitem>
</varlistentry>
<varlistentry>
<term><option>--email-address=</option><replaceable>EMAIL</replaceable></term>
<listitem><para>Takes an electronic mail address to associate with the user. On log-in the
<varname>$EMAIL</varname> environment variable is initialized from this value.</para></listitem>
</varlistentry>
<varlistentry>
<term><option>--location=</option><replaceable>TEXT</replaceable></term>
<listitem><para>Takes location specification for this user. This is free-form text, which might or
might not be usable by geo-location applications. Example: <option>--location="Berlin,
Germany"</option> or <option>--location="Basement, Room 3a"</option></para></listitem>
</varlistentry>
<varlistentry>
<term><option>--icon-name=</option><replaceable>ICON</replaceable></term>
<listitem><para>Takes an icon name to associate with the user, following the scheme defined by the <ulink
url="https://standards.freedesktop.org/icon-naming-spec/icon-naming-spec-latest.html">Icon Naming
Specification</ulink>.</para></listitem>
</varlistentry>
<varlistentry>
<term><option>--home-dir=</option><replaceable>PATH</replaceable></term>
<term><option>-d</option><replaceable>PATH</replaceable></term>
<listitem><para>Takes a path to use as home directory for the user. Note that this is the directory
the user's home directory is mounted to while the user is logged in. This is not where the user's
data is actually stored, see <option>--image-path=</option> for that. If not specified defaults to
<filename>/home/$USER</filename>.</para></listitem>
</varlistentry>
<varlistentry>
<term><option>--uid=</option><replaceable>UID</replaceable></term>
<listitem><para>Takes a preferred numeric UNIX UID to assign this user. If a user is to be created
with the specified UID and it is already taken by a different user on the local system then creation
of the home directory is refused. Note though, if after creating the home directory it is used on a
different system and the configured UID is taken by another user there, then
<command>systemd-homed</command> may assign the user a different UID on that system. The specified
UID must be outside of the system user range. It is recommended to use the 60001…60513 UID range for
this purpose. If not specified the UID is automatically picked. When logging in and the home
directory is found to be owned by a UID not matching the user's assigned one the home directory and
all files and directories inside it will have their ownership changed automatically before login
completes.</para>
<para>Note that users managed by <command>systemd-homed</command> always have a matching group
associated with the same name as well as a GID matching the UID of the user. Thus, configuring the
GID separately is not permitted.</para></listitem>
</varlistentry>
<varlistentry>
<term><option>--member-of=</option><replaceable>GROUP</replaceable></term>
<term><option>-G</option> <replaceable>GROUP</replaceable></term>
<listitem><para>Takes a comma-separated list of auxiliary UNIX groups this user shall belong
to. Example: <option>--member-of=wheel</option> to provide the user with administrator
privileges. Note that <command>systemd-homed</command> does not manage any groups besides a group
matching the user in name and numeric UID/GID. Thus any groups listed here must be registered
independently, for example with <citerefentry
project='man-pages'><refentrytitle>groupadd</refentrytitle><manvolnum>8</manvolnum></citerefentry>. If
non-existant groups that are listed there are ignored. This option may be used more than once, in
which case all specified group lists are combined.</para></listitem>
</varlistentry>
<varlistentry>
<term><option>--skel=</option><replaceable>PATH</replaceable></term>
<listitem><para>Takes a file system path to a directory. Specifies the skeleton directory to
initialize the home directory with. All files and directories in the specified are copied into any
newly create home directory. If not specified defaults to
<filename>/etc/skel/</filename>.</para></listitem>
</varlistentry>
<varlistentry>
<term><option>--shell=</option><replaceable>SHELL</replaceable></term>
<listitem><para>Takes a file system path. Specifies the shell binary to execute on terminal
logins. If not specified defaults to <filename>/bin/bash</filename>.</para></listitem>
</varlistentry>
<varlistentry>
<term><option>--setenv=</option><replaceable>VARIABLE</replaceable>=<replaceable>VALUE</replaceable></term>
<listitem><para>Takes an environment variable assignment to set for all user processes. Note that a
number of other settings also result in environment variables to be set for the user, including
<option>--email=</option>, <option>--timezone=</option> and <option>--language=</option>. May be used
multiple times to set multiple environment variables.</para></listitem>
</varlistentry>
<varlistentry>
<term><option>--timezone=</option><replaceable>TIMEZONE</replaceable></term>
<listitem><para>Takes a timezone specification as string that sets the timezone for the specified
user. Expects a `tzdata` location string. When the user logs in the <varname>$TZ</varname>
environment variable is initialized from this setting. Example:
<option>--timezone=Europe/Amsterdam</option> will result in the environment variable
<literal>TZ=:Europe/Amsterdam</literal>.</para></listitem>
</varlistentry>
<varlistentry>
<term><option>--language=</option><replaceable>LANG</replaceable></term>
<listitem><para>Takes a specifier indicating the preferred language of the user. The
<varname>$LANG</varname> environment variable is initialized from this value on login, and thus a
value suitable for this environment variable is accepted here, for example
<option>--language=de_DE.UTF8</option></para></listitem>
</varlistentry>
<varlistentry>
<term><option>--ssh-authorized-keys=</option><replaceable>KEYS</replaceable></term>
<listitem><para>Either takes a SSH authorized key line to associate with the user record or a
<literal>@</literal> character followed by a path to a file to read one or more such lines from. SSH
keys configured this way are made available to SSH to permit access to this home directory and user
record. This option may be used more than once to configure multiple SSH keys.</para></listitem>
</varlistentry>
<varlistentry>
<term><option>--pkcs11-token-uri=</option><replaceable>URI</replaceable></term>
<listitem><para>Takes an RFC 7512 PKCS#11 URI referencing a security token (e.g. YubiKey or PIV
smartcard) that shall be able to unlock the user account. The security token URI should reference a
security token with exactly one pair of X.509 certificate and private key. A random secret key is
then generated, encrypted with the public key of the X.509 certificate, and stored as part of the
user record. At login time it is decrypted with the PKCS#11 module and then used to unlock the
account and associated resources. See below for an example how to set up authentication with security
token.</para></listitem>
</varlistentry>
<varlistentry>
<term><option>--locked=</option><replaceable>BOOLEAN</replaceable></term>
<listitem><para>Takes a boolean argument. Specifies whether this user account shall be locked. If
true logins into this account are prohibited, if false (the default) they are permitted (of course,
only if authorization otherwise succeeds).</para></listitem>
</varlistentry>
<varlistentry>
<term><option>--not-before=</option><replaceable>TIMESTAMP</replaceable></term>
<term><option>--not-after=</option><replaceable>TIMESTAMP</replaceable></term>
<listitem><para>These options take a timestamp string, in the format documented in
<citerefentry><refentrytitle>systemd.time</refentrytitle><manvolnum>7</manvolnum></citerefentry> and
configures points in time before and after logins into this account are not
permitted.</para></listitem>
</varlistentry>
<varlistentry>
<term><option>--rate-limit-interval=</option><replaceable>SECS</replaceable></term>
<term><option>--rate-limit-burst=</option><replaceable>NUMBER</replaceable></term>
<listitem><para>Configures a rate limit on authentication attempts for this user. If the user
attempts to authenticate more often than the specified number, on a specific system, within the
specified time interval authentication is refused until the time interval passes. Defaults to 10
times per 1min.</para></listitem>
</varlistentry>
<varlistentry>
<term><option>--password-hint=</option><replaceable>TEXT</replaceable></term>
<listitem><para>Takes a password hint to store alongside the user record. This string is stored
accessible only to privileged users and the user itself and may not be queried by other users.
Example: <option>--password-hint="My first pet's name"</option></para></listitem>
</varlistentry>
<varlistentry>
<term><option>--enforce-password-policy=</option><replaceable>BOOL</replaceable></term>
<term><option>-P</option></term>
<listitem><para>Takes a boolean argument. Configures whether to enforce the system's password policy
for this user, regarding quality and strength of selected passwords. Defaults to
on. <option>-P</option> is short for
<option>---enforce-password-policy=no</option>.</para></listitem>
</varlistentry>
<varlistentry>
<term><option>--password-change-now=</option><replaceable>BOOL</replaceable></term>
<listitem><para>Takes a boolean argument. If true the user is asked to change their password on next
login.</para></listitem>
</varlistentry>
<varlistentry>
<term><option>--password-change-min=</option><replaceable>TIME</replaceable></term>
<term><option>--password-change-max=</option><replaceable>TIME</replaceable></term>
<term><option>--password-change-warn=</option><replaceable>TIME</replaceable></term>
<term><option>--password-change-inactive=</option><replaceable>TIME</replaceable></term>
<listitem><para>Each of these options takes a time span specification as argument (in the syntax
documented in
<citerefentry><refentrytitle>systemd.time</refentrytitle><manvolnum>5</manvolnum></citerefentry>) and
configure various aspects of the user's password expiration policy. Specifically,
<option>--password-change-min=</option> configures how much time has to pass after changing the
password of the user until the password may be changed again. If the user tries to change their
password before this time passes the attempt is refused. <option>--password-change-max=</option>
configures how much time has to pass after the the password is changed until the password expires and
needs to be changed again. After this time passes any attempts to log in may only proceed after the
password is changed. <option>--password-change-warn=</option> specifies how much earlier than then
the time configured with <option>--password-change-max=</option> the user is warned at login to
change their password as it will expire soon. Finally <option>--password-change-inactive=</option>
configures the time which has to pass after the password as expired until the user is not permitted
to log in or change the password anymore. Note that these options only apply to password
authentication, and do not apply to other forms of authentication, for example PKCS#11-based security
token authentication.</para></listitem>
</varlistentry>
<varlistentry>
<term><option>--disk-size=</option><replaceable>BYTES</replaceable></term>
<listitem><para>Either takes a size in bytes as argument (possibly using the usual K, M, G, …
suffixes for 1024 base values), or a percentage value and configures the disk space to assign to the
user. If a percentage value is specified (i.e. the argument suffixed with <literal>%</literal>) it is
taken relative to the available disk space of the backing file system. If the LUKS2 backend is used
this configures the size of the loopback file and file system contained therein. For the other
storage backends configures disk quota using the filesystem's native quota logic, if available. If
not specified, defaults to 85% of the available disk space for the LUKS2 backend and to no quota for
the others.</para></listitem>
</varlistentry>
<varlistentry>
<term><option>--access-mode=</option><replaceable>MODE</replaceable></term>
<listitem><para>Takes a UNIX file access mode written in octal. Configures the access mode of the
home directory itself. Note that this is only used when the directory is first created, and the user
may change this any time afterwards. Example:
<option>--access-mode=0700</option></para></listitem>
</varlistentry>
<varlistentry>
<term><option>--umask=</option><replaceable>MASK</replaceable></term>
<listitem><para>Takes the access mode mask (in octal syntax) to apply to newly created files and
directories of the user ("umask"). If set this controls the initial umask set for all login sessions of
the user, possibly overriding the system's defaults.</para></listitem>
</varlistentry>
<varlistentry>
<term><option>--nice=</option><replaceable>NICE</replaceable></term>
<listitem><para>Takes the numeric scheduling priority ("nice level") to apply to the processes of the user at login
time. Takes a numeric value in the range -20 (highest priority) to 19 (lowest priority).</para></listitem>
</varlistentry>
<varlistentry>
<term><option>--rlimit=</option><replaceable>LIMIT</replaceable>=<replaceable>VALUE</replaceable><optional>:<replaceable>VALUE</replaceable></optional></term>
<listitem><para>Allows configuration of resource limits for processes of this user, see <citerefentry
project='man-pages'><refentrytitle>getrlimit</refentrytitle><manvolnum>2</manvolnum></citerefentry>
for details. Takes a resource limit name (e.g. <literal>LIMIT_NOFILE</literal>) followed by an equal
sign, followed by a numeric limit. Optionally, separated by colon a second numeric limit may be
specified. If two are specified this refers to the soft and hard limits, respectively. If only one
limit is specified the setting sets both limits in one.</para></listitem>
</varlistentry>
<varlistentry>
<term><option>--tasks-max=</option><replaceable>TASKS</replaceable></term>
<listitem><para>Takes a non-zero unsigned integer as argument. Configures the maximum numer of tasks
(i.e. processes and threads) the user may have at any given time. This limit applies to all tasks
forked off the user's sessions, even if they change user identity via <citerefentry
project='man-pages'><refentrytitle>su</refentrytitle><manvolnum>1</manvolnum></citerefentry> or a
similar tool. Use <option>--rlimit=LIMIT_NPROC=</option> to place a limit on the tasks actually
running under the UID of the user, thus excluding any child processes that might have changed user
identity. This controls the <varname>TasksMax=</varname> settting of the per-user systemd slice unit
<filename>user-$UID.slice</filename>. See
<citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>
for further details.</para></listitem>
</varlistentry>
<varlistentry>
<term><option>--memory-high=</option><replaceable>BYTES</replaceable></term>
<term><option>--memory-max=</option><replaceable>BYTES</replaceable></term>
<listitem><para>Set a limit on the memory a user may take up on a system at any given time in bytes
(the usual K, M, G, … suffixes are supported, to the base of 1024). This includes all memory used by
the user itself and all processes they forked off that changed user credentials. This controls the
<varname>MemoryHigh=</varname> and <varname>MemoryMax=</varname> settings of the per-user systemd
slice unit <filename>user-$UID.slice</filename>. See
<citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>
for further details.</para></listitem>
</varlistentry>
<varlistentry>
<term><option>--cpu-weight=</option><replaceable>WEIGHT</replaceable></term>
<term><option>--io-weight=</option><replaceable>WEIGHT</replaceable></term>
<listitem><para>Set a CPU and IO scheduling weights of the processes of the user, including those of
processes forked off by the user that changed user credentials. Takes a numeric value in the range
1…10000. This controls the <varname>CPUWeight=</varname> and <varname>IOWeight=</varname> settings of
the per-user systemd slice unit <filename>user-$UID.slice</filename>. See
<citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>
for further details.</para></listitem>
</varlistentry>
<varlistentry>
<term><option>--storage=</option><replaceable>STORAGE</replaceable></term>
<listitem><para>Selects the storage mechanism to use for this home directory. Takes one of
<literal>luks</literal>, <literal>fscrypt</literal>, <literal>directory</literal>,
<literal>subvolume</literal>, <literal>cifs</literal>. For details about these mechanisms, see
above. If a new home directory is created and the storage type is not specifically specified defaults
to <literal>luks</literal> if supported, <literal>subvolume</literal> as first fallback if supported,
and <literal>directory</literal> if not.</para></listitem>
</varlistentry>
<varlistentry>
<term><option>--image-path=</option><replaceable>PATH</replaceable></term>
<listitem><para>Takes a file system path. Configures where to place the user's home directory. When
LUKS2 storage is used refers to the path to the loopback file, otherwise to the path to the home
directory. When unspecified defaults to <filename>/home/$USER.home</filename> when LUKS storage is
used and <filename>/home/$USER.homedir</filename> for the other storage mechanisms. Not defined for
the <literal>cifs</literal> storage mechanism. To use LUKS2 storage on a regular block device (for
example a USB stick) pass the path to the block device here.</para></listitem>
</varlistentry>
<varlistentry>
<term><option>--fs-type=</option><replaceable>TYPE</replaceable></term>
<listitem><para>When LUKS2 storage is used configures the file system type to use inside the home
directory LUKS2 container. One of <literal>ext4</literal>, <literal>xfs</literal>,
<literal>btrfs</literal>. If not specified defaults to <literal>ext4</literal>. Note that
<literal>xfs</literal> is not recommended as its support for file system resizing is too
limited.</para></listitem>
</varlistentry>
<varlistentry>
<term><option>--luks-discard=</option><replaceable>BOOL</replaceable></term>
<listitem><para>When LUKS2 storage is used configures whether to enable the
<literal>discard</literal> feature of the file system. If enabled the file system on top of the LUKS2
volume will report empty block information to LUKS2 and the loopback file below, ensuring that empty
space in the home directory is returned to the backing file system below the LUKS2 volume, resulting
in a "sparse" loopback file. This option mostly defaults to off, since this permits over-committing
home directories which results in I/O errors if the underlying file system runs full while the upper
file system wants to allocate a block. Such I/O errors are generally not handled well by file systems
nor applications. When LUKS2 storage is used on top of regular block devices (instead of on top a
loopback file) the discard logic defaults to on.</para></listitem>
</varlistentry>
<varlistentry>
<term><option>--luks-cipher=</option><replaceable>CIPHER</replaceable></term>
<term><option>--luks-cipher-mode=</option><replaceable>MODE</replaceable></term>
<term><option>--luks-volume-key-size=</option><replaceable>BITS</replaceable></term>
<term><option>--luks-pbkdf-type=</option><replaceable>TYPE</replaceable></term>
<term><option>--luks-pbkdf-hash-algorithm=</option><replaceable>ALGORITHM</replaceable></term>
<term><option>--luks-pbkdf-time-cost=</option><replaceable>SECONDS</replaceable></term>
<term><option>--luks-pbkdf-memory-cost=</option><replaceable>BYTES</replaceable></term>
<term><option>--luks-pbkdf-parallel-threads=</option><replaceable>THREADS</replaceable></term>
<listitem><para>Configures various cryptographic parameters for the LUKS2 storage mechanism. See
<citerefentry
project='man-pages'><refentrytitle>cryptsetup</refentrytitle><manvolnum>8</manvolnum></citerefentry>
for details on the specific attributes.</para></listitem>
</varlistentry>
<varlistentry>
<term><option>--nosuid=</option><replaceable>BOOL</replaceable></term>
<term><option>--nodev=</option><replaceable>BOOL</replaceable></term>
<term><option>--noexec=</option><replaceable>BOOL</replaceable></term>
<listitem><para>Configures the <literal>nosuid</literal>, <literal>nodev</literal> and
<literal>noexec</literal> mount options for the home directories. By default <literal>nodev</literal>
and <literal>nosuid</literal> are on, while <literal>noexec</literal> is off. For details about these
mount options see <citerefentry
project='man-pages'><refentrytitle>mount</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para></listitem>
</varlistentry>
<varlistentry>
<term><option>--cifs-domain=</option><replaceable>DOMAIN</replaceable></term>
<term><option>--cifs-user-name=</option><replaceable>USER</replaceable></term>
<term><option>--cifs-service=</option><replaceable>SERVICE</replaceable></term>
<listitem><para>Configures the Windows File Sharing (CIFS) domain and user to associate with the home
directory/user account, as well as the file share ("service") to mount as directory. The latter is used when
<literal>cifs</literal> storage is selected.</para></listitem>
</varlistentry>
<varlistentry>
<term><option>--stop-delay=</option><replaceable>SECS</replaceable></term>
<listitem><para>Configures the time the per-user service manager shall continue to run after the all
sessions of the user ended. The default is configured in
<citerefentry><refentrytitle>logind.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry> (for
home directories of LUKS2 storage located on removable media this defaults to 0 though). A longer
time makes sure quick, repetitive logins are more efficient as the user's service manager doesn't
have to be started every time.</para></listitem>
</varlistentry>
<varlistentry>
<term><option>--kill-processes=</option><replaceable>BOOL</replaceable></term>
<listitem><para>Configures whether to kill all processes of the user on logout. The default is
configured in
<citerefentry><refentrytitle>logind.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
</varlistentry>
<varlistentry>
<term><option>--auto-login=</option><replaceable>BOOL</replaceable></term>
<listitem><para>Takes a boolean argument. Configures whether the graphical UI of the system should
automatically log this user in if possible. Defaults to off. If less or more than one user is marked
this way automatic login is disabled.</para></listitem>
</varlistentry>
</variablelist>
</refsect1>
<refsect1>
<title>Commands</title>
<para>The following commands are understood:</para>
<variablelist>
<varlistentry>
<term><command>list</command></term>
<listitem><para>List all home directories (along with brief details) currently managed by
<filename>systemd-homed.service</filename>. This command is also executed if none is specified on the
command line. (Note that the list of users shown by this command does not include users managed by
other subsystems, such as system users or any traditional users listed in
<filename>/etc/passwd</filename>.)</para></listitem>
</varlistentry>
<varlistentry>
<term><command>activate</command> <replaceable>USER</replaceable> [<replaceable>USER…</replaceable>]</term>
<listitem><para>Activate one or more home directories. The home directories of each listed user will
be activated and made available under their mount points (typically in
<filename>/home/$USER</filename>). Note that any home activated this way stays active indefinitely,
until it is explicitly deactivated again (with <command>deactivate</command>, see below), or the user
logs in and out again and it thus is deactivated due to the automatic deactivation-on-logout
logic.</para>
<para>Activation of a home directory involves various operations that depend on the selected storage
mechanism. If the LUKS2 mechanism is used, this generally involves: inquiring the user for a
password, setting up a loopback device, validating and activating the LUKS2 volume, checking the file
system, mounting the file system, and potentiatlly changing the ownership of all included files to
the correct UID/GID.</para></listitem>
</varlistentry>
<varlistentry>
<term><command>deactivate</command> <replaceable>USER</replaceable> [<replaceable>USER…</replaceable>]</term>
<listitem><para>Deactivate one or more home directories. This undoes the effect of
<command>activate</command>.</para></listitem>
</varlistentry>
<varlistentry>
<term><command>inspect</command> <replaceable>USER</replaceable> [<replaceable>USER…</replaceable>]</term>
<listitem><para>Show various details about the specified home directories. This shows various
information about the home directory and its user account, including runtime data such as current
state, disk use and similar. Combine with <option>--json=</option> to show the detailed JSON user
record instead, possibly combined with <option>--export-format=</option> to suppress certain aspects
of the output.</para></listitem>
</varlistentry>
<varlistentry>
<term><command>authenticate</command> <replaceable>USER</replaceable> [<replaceable>USER…</replaceable>]</term>
<listitem><para>Validate authentication credentials of a home directory. This queries the caller for
a password (or similar) and checks that it correctly unlocks the home directory. This leaves the home
directory in the state it is in, i.e. it leaves the home directory in inactive state if it was
inactive before, and in active state if it was active before.</para></listitem>
</varlistentry>
<varlistentry>
<term><command>create</command> <replaceable>USER</replaceable></term>
<term><command>create</command> <option>--identity=</option><replaceable>PATH</replaceable> <optional><replaceable>USER</replaceable></optional></term>
<listitem><para>Create a new home directory/user account of the specified name. Use the various
user record property options (as documented above) to control various aspects of the home directory
and its user accounts.</para></listitem>
</varlistentry>
<varlistentry>
<term><command>remove</command> <replaceable>USER</replaceable></term>
<listitem><para>Remove a home directory/user account. This will remove both the home directory's user
record and the home directory itself, and thus delete all files and directories owned by the
user.</para></listitem>
</varlistentry>
<varlistentry>
<term><command>update</command> <replaceable>USER</replaceable></term>
<term><command>update</command> <option>--identity=</option><replaceable>PATH</replaceable> <optional><replaceable>USER</replaceable></optional></term>
<listitem><para>Update a home directory/user account. Use the various user record property options
(as documented above) to make changes to the account, or alternatively provide a full, updated JSON
user record via the <option>--identity=</option> option.</para>
<para>Note that changes to user records not signed by a cryptographic private key available locally
are not permitted, unless <option>--identity=</option> is used with a user record that is already
correctly signed by a recognized private key.</para></listitem>
</varlistentry>
<varlistentry>
<term><command>passwd</command> <replaceable>USER</replaceable></term>
<listitem><para>Change the password of the specified home direcory/user account.</para></listitem>
</varlistentry>
<varlistentry>
<term><command>resize</command> <replaceable>USER</replaceable> <replaceable>BYTES</replaceable></term>
<listitem><para>Change the disk space assigned to the specified home directory. If the LUKS2 storage
mechanism is used this will automatically resize the loopback file and the file system contained
within. Note that if <literal>ext4</literal> is used inside of the LUKS2 volume, it is necessary to
deactivate the home directory before shrinking it (i.e the user has to log out). Growing can be done
while the home directory is active. If <literal>xfs</literal> is used inside of the LUKS2 volume the
home directory may not be shrunk whatsoever. On all three of <literal>ext4</literal>,
<literal>xfs</literal> and <literal>btrfs</literal> the home directory may be grown while the user is
logged in, and on the latter also shrunk while the user is logged in. If the
<literal>subvolume</literal>, <literal>directory</literal>, <literal>fscrypt</literal> storage
mechanisms are used, resizing will change file system quota.</para></listitem>
</varlistentry>
<varlistentry>
<term><command>lock</command> <replaceable>USER</replaceable></term>
<listitem><para>Temporarily suspend access to the user's home directory and remove any associated
cryptographic keys from memory. Any attempts to access the user's home directory will stall until the
home directory is unlocked again (i.e. re-authenticated). This functionality is primarily intended to
be used during system suspend to make sure the user's data cannot be accessed until the user
re-authenticates on resume. This operation is only defined for home directories that use the LUKS2
storage mechanism.</para></listitem>
</varlistentry>
<varlistentry>
<term><command>unlock</command> <replaceable>USER</replaceable></term>
<listitem><para>Resume access to the user's home directory again, undoing the effect of
<command>lock</command> above. This requires authentication of the user, as the cryptographic keys
required for access to the home directory need to be reacquired.</para></listitem>
</varlistentry>
<varlistentry>
<term><command>lock-all</command></term>
<listitem><para>Execute the <command>lock</command> command on all suitable home directories at
once. This operation is generally executed on system suspend (i.e. by <command>systemctl
suspend</command> and related commands), to ensure all active user's cryptographic keys for accessing
their home directories are removed from memory.</para></listitem>
</varlistentry>
<varlistentry>
<term><command>with</command> <replaceable>USER</replaceable> <replaceable>COMMAND…</replaceable></term>
<listitem><para>Activate the specified user's home directory, run the specified command (under the
caller's identity, not the specified user's) and deactivate the home directory afterwards again
(unless the user is logged in otherwise). This command is useful for running privileged backup
scripts and such, but requires authentication with the user's credentials in order to be able to
unlock the user's home directory.</para></listitem>
</varlistentry>
</variablelist>
</refsect1>
<refsect1>
<title>Exit status</title>
<para>On success, 0 is returned, a non-zero failure code otherwise.</para>
</refsect1>
<xi:include href="less-variables.xml" />
<refsect1>
<title>Examples</title>
<example>
<title>Create a user <literal>waldo</literal> in the administrator group <literal>wheel</literal>, and
assign 500 MiB disk space to them.</title>
<programlisting>homectl create waldo --real-name="Waldo McWaldo" -G wheel --disk-size=500M</programlisting>
</example>
<example>
<title>Create a user <literal>wally</literal> on a USB stick, and assign a maximum of 500 concurrent
tasks to them.</title>
<programlisting>homectl create wally --real-name="Wally McWally" --image-path=/dev/disk/by-id/usb-SanDisk_Ultra_Fit_476fff954b2b5c44-0:0 --tasks-max=500</programlisting>
</example>
<example>
<title>Change nice level of user <literal>odlaw</literal> to +5 and make sure the environment variable
<varname>$SOME</varname> is set to the string <literal>THING</literal> for them on login.</title>
<programlisting>homectl update odlaw --nice=5 --setenv=SOME=THING</programlisting>
</example>
<example>
<title>Set up authentication with a YubiKey security token:</title>
<programlisting># Clear the Yubikey from any old keys (careful!)
ykman piv reset
# Generate a new private/public key pair on the device, store the public key in 'pubkey.pem'.
ykman piv generate-key -a RSA2048 9d pubkey.pem
# Create a self-signed certificate from this public key, and store it on the device.
ykman piv generate-certificate --subject "Knobelei" 9d pubkey.pem
# We don't need the publibc key on disk anymore
rm pubkey.pem
# Check if the newly create key on the Yubikey shows up as token in PKCS#11. Have a look at the output, and
# copy the resulting token URI to the clipboard.
p11tool --list-tokens
# Allow the security token referenced by the determined PKCS#11 URI to unlock the account of user
# 'lafcadio'. (Replace the '…' by the URI from the clipboard.)
homectl update lafcadio --pkcs11-token-uri=…</programlisting>
</example>
</refsect1>
<refsect1>
<title>See Also</title>
<para>
<citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
<citerefentry><refentrytitle>systemd-homed.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
<citerefentry><refentrytitle>userdbctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
<citerefentry project='man-pages'><refentrytitle>useradd</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
<citerefentry project='man-pages'><refentrytitle>cryptsetup</refentrytitle><manvolnum>8</manvolnum></citerefentry>
</para>
</refsect1>
</refentry>

22
man/journalctl.xml
View File

@ -597,6 +597,16 @@
priorities.</para></listitem>
</varlistentry>
<varlistentry>
<term><option>--facility=</option></term>
<listitem><para>Filter output by syslog facility. Takes a comma-separated list of numbers or facility
names. The names are the usual syslog facilities as documented in
<citerefentry project='man-pages'><refentrytitle>syslog</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
<option>--facility=help</option> may be used to display a list of known facility names and exit.
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>-g</option></term>
<term><option>--grep=</option></term>
@ -749,6 +759,18 @@
</para></listitem>
</varlistentry>
<varlistentry>
<term><option>--namespace=<replaceable>NAMESPACE</replaceable></option></term>
<listitem><para>Takes a journal namespace identifier string as argument. If not specified the data
collected by the default namespace is shown. If specified shows the log data of the specified
namespace instead. If the namespace is specified as <literal>*</literal> data from all namespaces is
shown, interleaved. If the namespace identifier is prefixed with <literal>+</literal> data from the
specified namespace and the default namespace is shown, interleaved, but no other. For details about
journal namespaces see
<citerefentry><refentrytitle>systemd-journald.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para></listitem>
</varlistentry>
<varlistentry>
<term><option>--header</option></term>

101
man/journald.conf.xml
View File

@ -18,6 +18,7 @@
<refnamediv>
<refname>journald.conf</refname>
<refname>journald.conf.d</refname>
<refname>journald@.conf</refname>
<refpurpose>Journal service configuration files</refpurpose>
</refnamediv>
@ -26,6 +27,7 @@
<para><filename>/etc/systemd/journald.conf.d/*.conf</filename></para>
<para><filename>/run/systemd/journald.conf.d/*.conf</filename></para>
<para><filename>/usr/lib/systemd/journald.conf.d/*.conf</filename></para>
<para><filename>/etc/systemd/journald@<replaceable>NAMESPACE</replaceable>.conf</filename></para>
</refsynopsisdiv>
<refsect1>
@ -37,6 +39,12 @@
<citerefentry><refentrytitle>systemd.syntax</refentrytitle><manvolnum>5</manvolnum></citerefentry>
for a general description of the syntax.</para>
<para>The <command>systemd-journald</command> instance managing the default namespace is configured by
<filename>/etc/systemd/journald.conf</filename> and associated drop-ins. Instances managing other
namespaces read <filename>/etc/systemd/journald@<replaceable>NAMESPACE</replaceable>.conf</filename> with
the namespace identifier filled in. This allows each namespace to carry a distinct configuration. See
<citerefentry><refentrytitle>systemd-journald.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
for details about journal namespaces.</para>
</refsect1>
<xi:include href="standard-conf.xml" xpointer="main-conf" />
@ -52,29 +60,19 @@
<varlistentry>
<term><varname>Storage=</varname></term>
<listitem><para>Controls where to store journal data. One of
<literal>volatile</literal>,
<literal>persistent</literal>,
<literal>auto</literal> and
<literal>none</literal>. If
<literal>volatile</literal>, journal
log data will be stored only in memory, i.e. below the
<filename>/run/log/journal</filename> hierarchy (which is
created if needed). If <literal>persistent</literal>, data
will be stored preferably on disk, i.e. below the
<filename>/var/log/journal</filename> hierarchy (which is
created if needed), with a fallback to
<filename>/run/log/journal</filename> (which is created if
needed), during early boot and if the disk is not writable.
<literal>auto</literal> is similar to
<literal>persistent</literal> but the directory
<filename>/var/log/journal</filename> is not created if
needed, so that its existence controls where log data goes.
<literal>none</literal> turns off all storage, all log data
received will be dropped. Forwarding to other targets, such as
the console, the kernel log buffer, or a syslog socket will
still work however. Defaults to
<literal>auto</literal>.</para></listitem>
<listitem><para>Controls where to store journal data. One of <literal>volatile</literal>,
<literal>persistent</literal>, <literal>auto</literal> and <literal>none</literal>. If
<literal>volatile</literal>, journal log data will be stored only in memory, i.e. below the
<filename>/run/log/journal</filename> hierarchy (which is created if needed). If
<literal>persistent</literal>, data will be stored preferably on disk, i.e. below the
<filename>/var/log/journal</filename> hierarchy (which is created if needed), with a fallback to
<filename>/run/log/journal</filename> (which is created if needed), during early boot and if the disk
is not writable. <literal>auto</literal> is similar to <literal>persistent</literal> but the
directory <filename>/var/log/journal</filename> is not created if needed, so that its existence
controls where log data goes. <literal>none</literal> turns off all storage, all log data received
will be dropped. Forwarding to other targets, such as the console, the kernel log buffer, or a syslog
socket will still work however. Defaults to <literal>auto</literal> in the default journal namespace,
and <literal>persistent</literal> in all others.</para></listitem>
</varlistentry>
<varlistentry>
@ -142,6 +140,51 @@
<literal>us</literal>. To turn off any kind of rate limiting,
set either value to 0.</para>
<para>Note that the effective rate limit is multiplied with a
factor derived from the available free disk space for the journal.
Currently, this factor is calculated using the base 2 logarithm.</para>
<table>
<title>Example <varname>RateLimitBurst=</varname> rate
modifications by the available disk space</title>
<tgroup cols='2'>
<colspec colname='freespace' />
<colspec colname='multiplier' />
<thead>
<row>
<entry>Available Disk Space</entry>
<entry>Burst Multiplier</entry>
</row>
</thead>
<tbody>
<row>
<entry>&lt;= 1MB</entry>
<entry>1</entry>
</row>
<row>
<entry>&lt;= 16MB</entry>
<entry>2</entry>
</row>
<row>
<entry>&lt;= 256MB</entry>
<entry>3</entry>
</row>
<row>
<entry>&lt;= 4GB</entry>
<entry>4</entry>
</row>
<row>
<entry>&lt;= 64GB</entry>
<entry>5</entry>
</row>
<row>
<entry>&lt;= 1TB</entry>
<entry>6</entry>
</row>
</tbody>
</tgroup>
</table>
<para>If a service provides rate limits for itself through
<varname>LogRateLimitIntervalSec=</varname> and/or <varname>LogRateLimitBurst=</varname>
in <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
@ -307,9 +350,9 @@
<varname>TTYPath=</varname>, described below.</para>
<para>When forwarding to the kernel log buffer (kmsg), make sure to select a suitably large size for
the log buffer, and ensure the kernel's rate-limiting applied to userspace processes is turned
off. Specifically, add <literal>log_buf_len=8M</literal> and <literal>printk.devkmsg=on</literal> (or
similar) to the kernel command line.</para></listitem>
the log buffer, for example by adding <literal>log_buf_len=8M</literal> to the kernel command line.
<command>systemd</command> will automatically disable kernel's rate-limiting applied to userspace
processes (equivalent to setting <literal>printk.devkmsg=on</literal>).</para></listitem>
</varlistentry>
<varlistentry>
@ -354,9 +397,9 @@
<varlistentry>
<term><varname>ReadKMsg=</varname></term>
<listitem><para>Takes a boolean value. If enabled (the
default), journal reads <filename>/dev/kmsg</filename>
messages generated by the kernel.</para></listitem>
<listitem><para>Takes a boolean value. If enabled <command>systemd-journal</command> processes
<filename>/dev/kmsg</filename> messages generated by the kernel. In the default journal namespace
this option is enabled by default, it is disabled in all others.</para></listitem>
</varlistentry>
<varlistentry>

13
man/kernel-command-line.xml
View File

@ -107,7 +107,7 @@
<term><varname>systemd.early_core_pattern=</varname></term>
<listitem>
<para>During early boot, the generation of core dump files is disabled until a core dump handler (if any)
takes over. This parameter allows to specifies an absolute path where core dump files should be stored until
takes over. This parameter allows specifying an absolute path where core dump files should be stored until
a handler is installed. The path should be absolute and may contain specifiers, see
<citerefentry><refentrytitle>core</refentrytitle><manvolnum>5</manvolnum></citerefentry> for details.</para>
</listitem>
@ -393,6 +393,17 @@
</listitem>
</varlistentry>
<varlistentry>
<term><varname>systemd.cpu_affinity=</varname></term>
<listitem>
<para>Overrides the CPU affinity mask for the service manager and the default for all child
processes it forks. This takes precedence over <varname>CPUAffinity=</varname>, see
<citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>
for details.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><varname>modules_load=</varname></term>
<term><varname>rd.modules_load=</varname></term>

17
man/machinectl.xml
View File

@ -680,7 +680,8 @@
<term><option>-l</option></term>
<term><option>--full</option></term>
<listitem><para>Do not ellipsize process tree entries.</para>
<listitem><para>Do not ellipsize process tree entries or table. This implies
<option>--max-addresses=full</option>.</para>
</listitem>
</varlistentry>
@ -811,15 +812,11 @@
<varlistentry>
<term><option>--max-addresses=</option></term>
<listitem><para>When used with the <option>list-machines</option>
command, limits the number of ip addresses output for every machine.
Defaults to 1. All addresses can be requested with <literal>all</literal>
as argument to <option>--max-addresses</option> . If the argument to
<option>--max-addresses</option> is less than the actual number
of addresses, <literal>...</literal>follows the last address.
If multiple addresses are to be written for a given machine, every
address except the first one is on a new line and is followed by
<literal>,</literal> if another address will be output afterwards. </para></listitem>
<listitem><para>When used with the <option>list-machines</option> command, limits the number of ip
addresses output for every machine. Defaults to 1. All addresses can be requested with
<literal>all</literal> as argument to <option>--max-addresses=</option>. If the argument to
<option>--max-addresses=</option> is less than the actual number of addresses,
<literal>…</literal>follows the last address.</para></listitem>
</varlistentry>
<varlistentry>

25
man/networkctl.xml
View File

@ -69,6 +69,12 @@
<para>The operational status is one of the following:
<variablelist>
<varlistentry>
<term>missing</term>
<listitem>
<para>the device is missing</para>
</listitem>
</varlistentry>
<varlistentry>
<term>off</term>
<listitem>
@ -311,6 +317,25 @@ s - Service VLAN, m - Two-port MAC Relay (TPMR)
</listitem>
</varlistentry>
<varlistentry>
<term><option>-l</option></term>
<term><option>--full</option></term>
<listitem>
<para>Do not ellipsize the output.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><option>-n</option></term>
<term><option>--lines=</option></term>
<listitem>
<para>When used with <command>status</command>, controls the number of journal lines to show,
counting from the most recent ones. Takes a positive integer argument. Defaults to 10.</para>
</listitem>
</varlistentry>
<xi:include href="standard-options.xml" xpointer="help" />
<xi:include href="standard-options.xml" xpointer="version" />
<xi:include href="standard-options.xml" xpointer="no-legend" />

22
man/nss-systemd.xml
View File

@ -18,7 +18,7 @@
<refnamediv>
<refname>nss-systemd</refname>
<refname>libnss_systemd.so.2</refname>
<refpurpose>Provide UNIX user and group name resolution for dynamic users and groups.</refpurpose>
<refpurpose>Provide UNIX user and group name resolution for user/group lookup via Varlink</refpurpose>
</refnamediv>
<refsynopsisdiv>
@ -28,16 +28,24 @@
<refsect1>
<title>Description</title>
<para><command>nss-systemd</command> is a plug-in module for the GNU Name Service Switch (NSS) functionality of the
GNU C Library (<command>glibc</command>), providing UNIX user and group name resolution for dynamic users and
groups allocated through the <varname>DynamicUser=</varname> option in systemd unit files. See
<citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry> for details on
this option.</para>
<para><command>nss-systemd</command> is a plug-in module for the GNU Name Service Switch (NSS)
functionality of the GNU C Library (<command>glibc</command>), providing UNIX user and group name
resolution for services implementing the <ulink url="https://systemd.io/USER_GROUP_API">User/Group Record
Lookup API via Varlink</ulink>, such as the system and service manager
<citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry> (for its
<varname>DynamicUser=</varname> feature, see
<citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry> for
details) or
<citerefentry><refentrytitle>systemd-homed.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para>
<para>This module also ensures that the root and nobody users and groups (i.e. the users/groups with the UIDs/GIDs
0 and 65534) remain resolvable at all times, even if they aren't listed in <filename>/etc/passwd</filename> or
<filename>/etc/group</filename>, or if these files are missing.</para>
<para>This module preferably utilizes
<citerefentry><refentrytitle>systemd-userdbd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
for resolving users and groups, but also works without the service running.</para>
<para>To activate the NSS module, add <literal>systemd</literal> to the lines starting with
<literal>passwd:</literal> and <literal>group:</literal> in <filename>/etc/nsswitch.conf</filename>.</para>
@ -54,7 +62,7 @@
<!-- synchronize with other nss-* man pages and factory/etc/nsswitch.conf -->
<programlisting>passwd: compat mymachines <command>systemd</command>
group: compat mymachines <command>systemd</command>
group: compat [SUCCESS=merge] mymachines [SUCCESS=merge] <command>systemd</command>
shadow: compat
hosts: files mymachines resolve [!UNAVAIL=return] dns myhostname

44
man/pam_systemd.xml
View File

@ -32,6 +32,10 @@
<citerefentry><refentrytitle>systemd-logind.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
and hence the systemd control group hierarchy.</para>
<para>The module also applies various resource management and runtime parameters to the new session, as
configured in the <ulink url="https://systemd.io/USER_RECORD">JSON User Record</ulink> of the user, when
one is defined.</para>
<para>On login, this module — in conjunction with <filename>systemd-logind.service</filename> — ensures the
following:</para>
@ -48,7 +52,12 @@
<listitem><para>A new systemd scope unit is created for the session. If this is the first concurrent session of
the user, an implicit per-user slice unit below <filename>user.slice</filename> is automatically created and the
scope placed into it. An instance of the system service <filename>user@.service</filename>, which runs the
systemd user manager instance, is started. </para></listitem>
systemd user manager instance, is started.</para></listitem>
<listitem><para>The <literal>$TZ</literal>, <literal>$EMAIL</literal> and <literal>$LANG</literal>
environment variables are configured for the user, based on the respective data from the user's JSON
record (if it is defined). Moreover, any environment variables explicitly configured in the user record
are imported, and the umask, nice level, and resource limits initialized.</para></listitem>
</orderedlist>
<para>On logout, this module ensures the following:</para>
@ -172,6 +181,15 @@
is not set if the current user is not the original user of the session.</para></listitem>
</varlistentry>
<varlistentry>
<term><varname>$TZ</varname></term>
<term><varname>$EMAIL</varname></term>
<term><varname>$LANG</varname></term>
<listitem><para>If a JSON user record is known for the user logging in these variables are
initialized from the respective data in the record.</para></listitem>
</varlistentry>
</variablelist>
<para>The following environment variables are read by the module and may be used by the PAM service to pass
@ -286,14 +304,23 @@ pam_set_data(handle, "systemd.runtime_max_sec", (void *)"3600", cleanup);
<refsect1>
<title>Example</title>
<para>Here's an example PAM configuration fragment that allows users sessions to be managed by
<filename>systemd-logind.service</filename>:</para>
<programlisting>#%PAM-1.0
auth required pam_unix.so
auth required pam_nologin.so
account required pam_unix.so
password required pam_unix.so
session required pam_unix.so
session required pam_loginuid.so
session required pam_systemd.so</programlisting>
auth sufficient pam_unix.so
auth required pam_deny.so
account required pam_nologin.so
account sufficient pam_unix.so
account required pam_permit.so
password sufficient pam_unix.so sha512 shadow try_first_pass try_authtok
password required pam_deny.so
-session optional pam_loginuid.so
-session optional pam_systemd.so
session required pam_unix.so</programlisting>
</refsect1>
<refsect1>
@ -303,6 +330,7 @@ session required pam_systemd.so</programlisting>
<citerefentry><refentrytitle>systemd-logind.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
<citerefentry><refentrytitle>logind.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
<citerefentry><refentrytitle>loginctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
<citerefentry><refentrytitle>pam_systemd_home</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
<citerefentry project='man-pages'><refentrytitle>pam.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
<citerefentry project='man-pages'><refentrytitle>pam.d</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
<citerefentry project='man-pages'><refentrytitle>pam</refentrytitle><manvolnum>8</manvolnum></citerefentry>,

131
man/pam_systemd_home.xml Normal file
View File

@ -0,0 +1,131 @@
<?xml version='1.0'?> <!--*-nxml-*-->
<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
<!-- SPDX-License-Identifier: LGPL-2.1+ -->
<refentry id="pam_systemd_home" conditional='ENABLE_PAM_HOME'>
<refentryinfo>
<title>pam_systemd_home</title>
<productname>systemd</productname>
</refentryinfo>
<refmeta>
<refentrytitle>pam_systemd_home</refentrytitle>
<manvolnum>8</manvolnum>
</refmeta>
<refnamediv>
<refname>pam_systemd_home</refname>
<refpurpose>Automatically mount home directories managed by <filename>systemd-homed.service</filename> on
login, and unmount them on logout</refpurpose>
</refnamediv>
<refsynopsisdiv>
<para><filename>pam_systemd_home.so</filename></para>
</refsynopsisdiv>
<refsect1>
<title>Description</title>
<para><command>pam_systemd_home</command> ensures that home directories managed by
<citerefentry><refentrytitle>systemd-homed.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
are automatically activated (mounted) on user login, and are deactivated (unmounted) when the last
session of the user ends.</para>
</refsect1>
<refsect1>
<title>Options</title>
<para>The following options are understood:</para>
<variablelist class='pam-directives'>
<varlistentry>
<term><varname>suspend=</varname></term>
<listitem><para>Takes a boolean argument. If true, the home directory of the user will be suspended
automatically during system suspend; if false it will remain active. Automatic suspending of the home
directory improves security substantially as secret key material is automatically removed from memory
before the system is put to sleep and must be re-acquired (through user re-authentication) when
coming back from suspend. It is recommended to set this parameter for all PAM applications that have
support for automatically re-authenticating via PAM on system resume. If multiple sessions of the
same user are open in parallel the user's home directory will be left unsuspended on system suspend
as long as at least one of the sessions does not set this parameter. Defaults to
off.</para></listitem>
</varlistentry>
<varlistentry>
<term><varname>debug</varname><optional>=</optional></term>
<listitem><para>Takes an optional boolean argument. If yes or without the argument, the module will log
debugging information as it operates.</para></listitem>
</varlistentry>
</variablelist>
</refsect1>
<refsect1>
<title>Module Types Provided</title>
<para>The module provides all four management operations: <option>auth</option>, <option>account</option>,
<option>session</option>, <option>password</option>.</para>
</refsect1>
<refsect1>
<title>Environment</title>
<para>The following environment variables are initialized by the module and available to the processes of the
user's session:</para>
<variablelist class='environment-variables'>
<varlistentry>
<term><varname>$SYSTEMD_HOME=1</varname></term>
<listitem><para>Indicates that the user's home directory is managed by <filename>systemd-homed.service</filename>.</para></listitem>
</varlistentry>
</variablelist>
</refsect1>
<refsect1>
<title>Example</title>
<para>Here's an example PAM configuration fragment that permits users managed by
<filename>systemd-homed.service</filename> to log in:</para>
<programlisting>#%PAM-1.0
auth sufficient pam_unix.so
-auth sufficient pam_systemd_home.so
auth required pam_deny.so
account required pam_nologin.so
-account sufficient pam_systemd_home.so
account sufficient pam_unix.so
account required pam_permit.so
-password sufficient pam_systemd_home.so
password sufficient pam_unix.so sha512 shadow try_first_pass try_authtok
password required pam_deny.so
-session optional pam_keyinit.so revoke
-session optional pam_loginuid.so
-session optional pam_systemd_home.so
-session optional pam_systemd.so
session required pam_unix.so</programlisting>
</refsect1>
<refsect1>
<title>See Also</title>
<para>
<citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
<citerefentry><refentrytitle>systemd-homed.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
<citerefentry><refentrytitle>homed.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
<citerefentry><refentrytitle>homectl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
<citerefentry><refentrytitle>pam_systemd</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
<citerefentry project='man-pages'><refentrytitle>pam.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
<citerefentry project='man-pages'><refentrytitle>pam.d</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
<citerefentry project='man-pages'><refentrytitle>pam</refentrytitle><manvolnum>8</manvolnum></citerefentry>
</para>
</refsect1>
</refentry>

28
man/portablectl.xml
View File

@ -133,11 +133,15 @@
<para>By default, after the unit files are attached the service manager's configuration is reloaded, except
when <option>--no-reload</option> is specified (see above). This ensures that the new units made available to
the service manager are seen by it.</para>
<para>If <option>--now</option> and/or <option>--enable</option> are passed, the portable service(s) are
immediately started (blocking operation unless <option>--no-block</option> is passed) and/or enabled after
attaching the image.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><command>detach</command> <replaceable>IMAGE</replaceable></term>
<term><command>detach</command> <replaceable>IMAGE</replaceable> [<replaceable>PREFIX…</replaceable>]</term>
<listitem><para>Detaches a portable service image from the host. This undoes the operations executed by the
<command>attach</command> command above, and removes the unit file copies, drop-ins and image symlink
@ -145,6 +149,10 @@
component of it (i.e. the file or directory name itself, not the path to it) is used for finding matching unit
files. This is a convencience feature to allow all arguments passed as <command>attach</command> also to
<command>detach</command>.</para></listitem>
<para>If <option>--now</option> and/or <option>--enable</option> are passed, the portable service(s) are
immediately stopped (blocking operation) and/or disabled before detaching the image. Prefix(es) are also accepted,
to be used in case the unit names do not match the image name as described in the <command>attach</command>.</para>
</varlistentry>
<varlistentry>
@ -311,6 +319,24 @@
contents of the image.</para></listitem>
</varlistentry>
<varlistentry>
<term><option>--enable</option></term>
<listitem><para>Immediately enable/disable the portable service after attaching/detaching.</para></listitem>
</varlistentry>
<varlistentry>
<term><option>--now</option></term>
<listitem><para>Immediately start/stop the portable service after attaching/before detaching.</para></listitem>
</varlistentry>
<varlistentry>
<term><option>--no-block</option></term>
<listitem><para>Don't block waiting for attach --now to complete.</para></listitem>
</varlistentry>
<xi:include href="user-system-options.xml" xpointer="host" />
<xi:include href="user-system-options.xml" xpointer="machine" />

388
man/repart.d.xml Normal file
View File

@ -0,0 +1,388 @@
<?xml version='1.0'?>
<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
<refentry id="repart.d" conditional='ENABLE_REPART'>
<refentryinfo>
<title>repart.d</title>
<productname>systemd</productname>
</refentryinfo>
<refmeta>
<refentrytitle>repart.d</refentrytitle>
<manvolnum>5</manvolnum>
</refmeta>
<refnamediv>
<refname>repart.d</refname>
<refpurpose>Partition Definition Files for Automatic Boot-Time Repartitioning</refpurpose>
</refnamediv>
<refsynopsisdiv>
<para><literallayout><filename>/etc/repart.d/*.conf</filename>
<filename>/run/repart.d/*.conf</filename>
<filename>/usr/lib/repart.d/*.conf</filename>
</literallayout></para>
</refsynopsisdiv>
<refsect1>
<title>Description</title>
<para><filename>repart.d/*.conf</filename> files describe basic properties of partitions of block
devices of the local system. They may be used to declare types, names and sizes of partitions that shall
exist. The
<citerefentry><refentrytitle>systemd-repart</refentrytitle><manvolnum>8</manvolnum></citerefentry>
service reads these files and attempts to add new partitions currently missing and enlarge existing
partitions according to these definitions. Operation is generally incremental, i.e. when applied, what
exists already is left intact, and partitions are never shrunk, moved or deleted.</para>
<para>These definition files are useful for implementing operating system images that are prepared and
delivered with minimally sized images (for example lacking any state or swap partitions), and which on
first boot automatically take possession of any remaining disk space following a few basic rules.</para>
<para>Currently, support for partition definition files is only implemented for GPT partitition
tables.</para>
<para>Partition files are generally matched against any partitions already existing on disk in a simple
algorithm: the partition files are sorted by their filename (ignoring the directory prefix), and then
compared in order against existing partitions matching the same partition type UUID. Specifically, the
first existing partition with a specific partition type UUID is assigned the first definition file with
the same partition type UUID, and the second existing partition with a specific type UUID the second
partition file with the same type UUID, and so on. Any left-over partition files that have no matching
existing partition are assumed to define new partition that shall be created. Such partitions are
appended to the end of the partition table, in the order defined by their names utilizing the first
partition slot greater than the highest slot number currently in use. Any existing partitions that have
no matching partition file are left as they are.</para>
<para>Note that these partition definition files do not describe the contents of the partitions, such as
the file system used. Separate mechanisms, such as
<citerefentry><refentrytitle>systemd-growfs</refentrytitle><manvolnum>8</manvolnum></citerefentry> and
<command>systemd-makefs</command> maybe be used to initialize or grow the file systems inside of these
partitions.</para>
</refsect1>
<refsect1>
<title>[Partition] Section Options</title>
<variablelist>
<varlistentry>
<term><varname>Type=</varname></term>
<listitem><para>The GPT partition type UUID to match. This may be a GPT partition type UUID such as
<constant>4f68bce3-e8cd-4db1-96e7-fbcaf984b709</constant>, or one of the following special
identifiers:</para>
<table>
<title>GPT partition type identifiers</title>
<tgroup cols='2' align='left' colsep='1' rowsep='1'>
<colspec colname="name" />
<colspec colname="explanation" />
<thead>
<row>
<entry>Identifier</entry>
<entry>Explanation</entry>
</row>
</thead>
<tbody>
<row>
<entry><constant>esp</constant></entry>
<entry>EFI System Partition</entry>
</row>
<row>
<entry><constant>xbootldr</constant></entry>
<entry>Extended Boot Loader Partition</entry>
</row>
<row>
<entry><constant>swap</constant></entry>
<entry>Swap partition</entry>
</row>
<row>
<entry><constant>home</constant></entry>
<entry>Home (<filename>/home/</filename>) partition</entry>
</row>
<row>
<entry><constant>srv</constant></entry>
<entry>Server data (<filename>/srv/</filename>) partition</entry>
</row>
<row>
<entry><constant>var</constant></entry>
<entry>Variable data (<filename>/var/</filename>) partition</entry>
</row>
<row>
<entry><constant>tmp</constant></entry>
<entry>Temporary data (<filename>/var/tmp/</filename>) partition</entry>
</row>
<row>
<entry><constant>linux-generic</constant></entry>
<entry>Generic Linux file system partition</entry>
</row>
<row>
<entry><constant>root</constant></entry>
<entry>Root file system partition type appropriate for the local architecture (an alias for an architecture root file system partition type listed below, e.g. <constant>root-x86-64</constant>)</entry>
</row>
<row>
<entry><constant>root-verity</constant></entry>
<entry>Verity data for the root file system partition for the local architecture</entry>
</row>
<row>
<entry><constant>root-secondary</constant></entry>
<entry>Root file system partition of the secondary architecture of the local architecture; usually the matching 32bit architecture for the local 64bit architecture)</entry>
</row>
<row>
<entry><constant>root-secondary-verity</constant></entry>
<entry>Verity data for the root file system partition of the secondary architecture</entry>
</row>
<row>
<entry><constant>root-x86</constant></entry>
<entry>Root file system partition for the x86 (32bit, aka i386) architecture</entry>
</row>
<row>
<entry><constant>root-x86-verity</constant></entry>
<entry>Verity data for the x86 (32bit) root file system partition</entry>
</row>
<row>
<entry><constant>root-x86-64</constant></entry>
<entry>Root file system partition for the x86_64 (64bit, aka amd64) architecture</entry>
</row>
<row>
<entry><constant>root-x86-64-verity</constant></entry>
<entry>Verity data for the x86_64 (64bit) root file system partition</entry>
</row>
<row>
<entry><constant>root-arm</constant></entry>
<entry>Root file system partition for the ARM (32bit) architecture</entry>
</row>
<row>
<entry><constant>root-arm-verity</constant></entry>
<entry>Verity data for the ARM (32bit) root file system partition</entry>
</row>
<row>
<entry><constant>root-arm64</constant></entry>
<entry>Root file system partition for the ARM (64bit, aka aarch64) architecture</entry>
</row>
<row>
<entry><constant>root-arm64-verity</constant></entry>
<entry>Verity data for the ARM (64bit, aka aarch64) root file system partition</entry>
</row>
<row>
<entry><constant>root-ia64</constant></entry>
<entry>Root file system partition for the ia64 architecture</entry>
</row>
<row>
<entry><constant>root-ia64-verity</constant></entry>
<entry>Verity data for the ia64 root file system partition</entry>
</row>
</tbody>
</tgroup>
</table>
<para>This setting defaults to <constant>linux-generic</constant>.</para>
<para>Most of the partition type UUIDs listed above are defined in the <ulink
url="https://systemd.io/DISCOVERABLE_PARTITIONS">Discoverable Partitions
Specification</ulink>.</para></listitem>
</varlistentry>
<varlistentry>
<term><varname>Label=</varname></term>
<listitem><para>The textual label to assign to the partition if none is assigned yet. Note that this
setting is not used for matching. It is also not used when a label is already set for an existing
partition. It is thus only used when a partition is newly created or when an existing one had a no
label set (that is: an empty label). If not specified a label derived from the partition type is
automatically used.</para></listitem>
</varlistentry>
<varlistentry>
<term><varname>Priority=</varname></term>
<listitem><para>A numeric priority to assign to this partition, in the range -2147483648…2147483647,
with smaller values indicating higher priority, and higher values indicating smaller priority. This
priority is used in case the configured size constraints on the defined partitions do not permit
fitting all partitions onto the available disk space. If the partitions do not fit, the highest
numeric partition priority of all defined partitions is determined, and all defined partitions with
this priority are removed from the list of new partitions to create (which may be multiple, if the
same priority is used for multiple partitions). The fitting algorithm is then tried again. If the
partitions still do not fit, the now highest numeric partition priority is determined, and the
matching partitions removed too, and so on. Partitions of a priority of 0 or lower are never
removed. If all partitions with a priority above 0 are removed and the partitions still do not fit on
the device the operation fails. Note that this priority has no effect on ordering partitions, for
that use the alphabetical order of the filenames of the partition definition files. Defaults to
0.</para></listitem>
</varlistentry>
<varlistentry>
<term><varname>Weight=</varname></term>
<listitem><para>A numeric weight to assign to this partition in the range 0…1000000. Available disk
space is assigned the defined partitions according to their relative weights (subject to the size
constraints configured with <varname>SizeMinBytes=</varname>, <varname>SizeMaxBytes=</varname>), so
that a partition with weight 2000 gets double the space as one with weight 1000, and a partition with
weight 333 a third of that. Defaults to 1000.</para>
<para>The <varname>Weight=</varname> setting is used to distribute available disk space in an
"elastic" fashion, based on the disk size and existing partitions. If a partition shall have a fixed
size use both <varname>SizeMinBytes=</varname> and <varname>SizeMaxBytes=</varname> with the same
value in order to fixate the size to one value, in which case the weight has no
effect.</para></listitem>
</varlistentry>
<varlistentry>
<term><varname>PaddingWeight=</varname></term>
<listitem><para>Similar to <varname>Weight=</varname> but sets a weight for the free space after the
partition (the "padding"). When distributing available space the weights of all partitions and all
defined padding is summed, and then each partition and padding gets the fraction defined by its
weight. Defaults to 0, i.e. by default no padding is applied.</para>
<para>Padding is useful if empty space shall be left for later additions or a safety margin at the
end of the device or between partitions.</para></listitem>
</varlistentry>
<varlistentry>
<term><varname>SizeMinBytes=</varname></term>
<term><varname>SizeMaxBytes=</varname></term>
<listitem><para>Specifies minimum and maximum size constraints in bytes. Takes the usual K, M, G, T,
… suffixes (to the base of 1024). If <varname>SizeMinBytes=</varname> is specified the partition is
created at or grown to at least the specified size. If <varname>SizeMaxBytes=</varname> is specified
the partition is created at or grown to at most the specified size. The precise size is determined
through the weight value value configured with <varname>Weight=</varname>, see above. When
<varname>SizeMinBytes=</varname> is set equal to <varname>SizeMaxBytes=</varname> the configured
weight has no effect as the partition is explicitly sized to the specified fixed value. Note that
partitions are never created smaller than 4096 bytes, and since partitions are never shrunk the
previous size of the partition (in case the partition already exists) is also enforced as lower bound
for the new size. The values should be specified as multiples of 4096 bytes, and are rounded upwards
(in case of <varname>SizeMinBytes=</varname>) or downwards (in case of
<varname>SizeMaxBytes=</varname>) otherwise. If the backing device does not provide enough space to
fulfill the constraints placing the partition will fail. For partitions that shall be created,
depending on the setting of <varname>Priority=</varname> (see above) the partition might be dropped
and the placing algorithm restarted. By default no size constraints are set.</para></listitem>
</varlistentry>
<varlistentry>
<term><varname>PaddingMinBytes=</varname></term>
<term><varname>PaddingMaxBytes=</varname></term>
<listitem><para>Specifies minimum and maximum size constrains in bytes for the free space after the
partition (the "padding"). Semantics are similar to <varname>SizeMinBytes=</varname> and
<varname>SizeMaxBytes=</varname>, except that unlike partition sizes free space can be shrunk and can
be as small as zero. By default no size constraints on padding are set, so that only
<varname>PaddingWeight=</varname> determines the size of the padding applied.</para></listitem>
</varlistentry>
<varlistentry>
<term><varname>FactoryReset=</varname></term>
<listitem><para>Takes a boolean argument. If specified the partition is marked for removal during a
factory reset operation. This functionality is useful to implement schemes where images can be reset
into their original state by removing partitions and creating them anew. Defaults to off.</para></listitem>
</varlistentry>
</variablelist>
</refsect1>
<refsect1>
<title>Examples</title>
<example>
<title>Grow the root partition to the full disk size at first boot</title>
<para>With the following file the root partition is automatically grown to the full disk if possible during boot.</para>
<para><programlisting># /usr/lib/repart.d/50-root.conf
[Partition]
Type=root
</programlisting></para>
</example>
<example>
<title>Create a swap and home partition automatically on boot, if missing</title>
<para>The home partition gets all available disk space while the swap partition gets 1G at most and 64M
at least. We set a priority > 0 on the swap partition to ensure the swap partition is not used if not
enough space is available. For every three bytes assigned to the home partition the swap partition gets
assigned one.</para>
<para><programlisting># /usr/lib/repart.d/60-home.conf
[Partition]
Type=home
</programlisting></para>
<para><programlisting># /usr/lib/repart.d/70-swap.conf
[Partition]
Type=swap
SizeMinBytes=64M
SizeMaxBytes=1G
Priority=1
Weight=333
</programlisting></para>
</example>
<example>
<title>Create B partitions in an A/B Verity setup, if missing</title>
<para>Let's say the vendor intends to update OS images in an A/B setup, i.e. with two root partitions
(and two matching Verity partitions) that shall be used alternatingly during upgrades. To minimize
image sizes the original image is shipped only with one root and one Verity partition (the "A" set),
and the second root and Verity partitions (the "B" set) shall be created on first boot on the free
space on the medium.</para>
<para><programlisting># /usr/lib/repart.d/50-root.conf
[Partition]
Type=root
SizeMinBytes=512M
SizeMaxBytes=512M
</programlisting></para>
<para><programlisting># /usr/lib/repart.d/60-root-verity.conf
[Partition]
Type=root-verity
SizeMinBytes=64M
SizeMaxBytes=64M
</programlisting></para>
<para>The definitions above cover the "A" set of root partition (of a fixed 512M size) and Verity
partition for the root partition (of a fixed 64M size). Let's use symlinks to create the "B" set of
partitions, since after all they shall have the same properties and sizes as the "A" set.</para>
<para><programlisting># ln -s 50-root.conf /usr/lib/repart.d/70-root-b.conf
# ln -s 60-root-verity.conf /usr/lib/repart.d/80-root-verity-b.conf
</programlisting></para>
</example>
</refsect1>
<refsect1>
<title>See Also</title>
<para>
<citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
<citerefentry><refentrytitle>systemd-repart</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
<citerefentry project='man-pages'><refentrytitle>sfdisk</refentrytitle><manvolnum>8</manvolnum></citerefentry>
</para>
</refsect1>
</refentry>

3
man/resolved.conf.xml
View File

@ -214,6 +214,9 @@
resolver is not capable of authenticating the server, so it is
vulnerable to "man-in-the-middle" attacks.</para>
<para>Server Name Indication (SNI) can be used when opening a TLS connection.
Entries in <varname>DNS=</varname> should be in format <literal>address#server_name</literal>.</para>
<para>In addition to this global DNSOverTLS setting
<citerefentry><refentrytitle>systemd-networkd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
also maintains per-link DNSOverTLS settings. For system DNS

44
man/rules/meson.build
View File

@ -17,13 +17,14 @@ manpages = [
['environment.d', '5', [], 'ENABLE_ENVIRONMENT_D'],
['file-hierarchy', '7', [], ''],
['halt', '8', ['poweroff', 'reboot'], ''],
['homectl', '1', [], 'ENABLE_HOMED'],
['hostname', '5', [], ''],
['hostnamectl', '1', [], 'ENABLE_HOSTNAMED'],
['hwdb', '7', [], 'ENABLE_HWDB'],
['journal-remote.conf', '5', ['journal-remote.conf.d'], 'HAVE_MICROHTTPD'],
['journal-upload.conf', '5', ['journal-upload.conf.d'], 'HAVE_MICROHTTPD'],
['journalctl', '1', [], ''],
['journald.conf', '5', ['journald.conf.d'], ''],
['journald.conf', '5', ['journald.conf.d', 'journald@.conf'], ''],
['kernel-command-line', '7', [], ''],
['kernel-install', '8', [], ''],
['libudev', '3', [], ''],
@ -45,8 +46,10 @@ manpages = [
['nss-systemd', '8', ['libnss_systemd.so.2'], 'ENABLE_NSS_SYSTEMD'],
['os-release', '5', [], ''],
['pam_systemd', '8', [], 'HAVE_PAM'],
['pam_systemd_home', '8', [], 'ENABLE_PAM_HOME'],
['portablectl', '1', [], 'ENABLE_PORTABLED'],
['pstore.conf', '5', ['pstore.conf.d'], 'ENABLE_PSTORE'],
['repart.d', '5', [], 'ENABLE_REPART'],
['resolvectl', '1', ['resolvconf'], 'ENABLE_RESOLVE'],
['resolved.conf', '5', ['resolved.conf.d'], 'ENABLE_RESOLVE'],
['runlevel', '8', [], ''],
@ -192,6 +195,7 @@ manpages = [
'sd_bus_open_user_with_description',
'sd_bus_open_with_description'],
''],
['sd_bus_enqueue_for_read', '3', [], ''],
['sd_bus_error',
'3',
['SD_BUS_ERROR_MAKE_CONST',
@ -230,6 +234,7 @@ manpages = [
''],
['sd_bus_message_append_strv', '3', [], ''],
['sd_bus_message_copy', '3', [], ''],
['sd_bus_message_dump', '3', [], ''],
['sd_bus_message_get_cookie', '3', ['sd_bus_message_get_reply_cookie'], ''],
['sd_bus_message_get_monotonic_usec',
'3',
@ -271,6 +276,7 @@ manpages = [
['sd_bus_message_read_array', '3', [], ''],
['sd_bus_message_read_basic', '3', [], ''],
['sd_bus_message_rewind', '3', [], ''],
['sd_bus_message_sensitive', '3', [], ''],
['sd_bus_message_set_destination',
'3',
['sd_bus_message_get_destination',
@ -371,7 +377,15 @@ manpages = [
['sd_bus_wait', '3', [], ''],
['sd_event_add_child',
'3',
['sd_event_child_handler_t', 'sd_event_source_get_child_pid'],
['sd_event_add_child_pidfd',
'sd_event_child_handler_t',
'sd_event_source_get_child_pid',
'sd_event_source_get_child_pidfd',
'sd_event_source_get_child_pidfd_own',
'sd_event_source_get_child_process_own',
'sd_event_source_send_child_signal',
'sd_event_source_set_child_pidfd_own',
'sd_event_source_set_child_process_own'],
''],
['sd_event_add_defer',
'3',
@ -538,7 +552,9 @@ manpages = [
''],
['sd_journal_open',
'3',
['SD_JOURNAL_CURRENT_USER',
['SD_JOURNAL_ALL_NAMESPACES',
'SD_JOURNAL_CURRENT_USER',
'SD_JOURNAL_INCLUDE_DEFAULT_NAMESPACE',
'SD_JOURNAL_LOCAL_ONLY',
'SD_JOURNAL_OS_ROOT',
'SD_JOURNAL_RUNTIME_ONLY',
@ -654,8 +670,11 @@ manpages = [
['systemd-backlight@.service', '8', ['systemd-backlight'], 'ENABLE_BACKLIGHT'],
['systemd-binfmt.service', '8', ['systemd-binfmt'], 'ENABLE_BINFMT'],
['systemd-bless-boot-generator', '8', [], 'ENABLE_EFI'],
['systemd-bless-boot.service', '8', [], 'ENABLE_EFI'],
['systemd-boot-check-no-failures.service', '8', [], ''],
['systemd-bless-boot.service', '8', ['systemd-bless-boot'], 'ENABLE_EFI'],
['systemd-boot-check-no-failures.service',
'8',
['systemd-boot-check-no-failures'],
''],
['systemd-boot-system-token.service', '8', [], 'ENABLE_EFI'],
['systemd-boot', '7', ['sd-boot'], 'ENABLE_EFI'],
['systemd-cat', '1', [], ''],
@ -698,6 +717,7 @@ manpages = [
'8',
['systemd-hibernate-resume'],
'ENABLE_HIBERNATE'],
['systemd-homed.service', '8', ['systemd-homed'], 'ENABLE_HOMED'],
['systemd-hostnamed.service', '8', ['systemd-hostnamed'], 'ENABLE_HOSTNAMED'],
['systemd-hwdb', '8', [], 'ENABLE_HWDB'],
['systemd-id128', '1', [], ''],
@ -724,7 +744,10 @@ manpages = [
['systemd-journald',
'systemd-journald-audit.socket',
'systemd-journald-dev-log.socket',
'systemd-journald.socket'],
'systemd-journald-varlink@.socket',
'systemd-journald.socket',
'systemd-journald@.service',
'systemd-journald@.socket'],
''],
['systemd-localed.service', '8', ['systemd-localed'], 'ENABLE_LOCALED'],
['systemd-logind.service', '8', ['systemd-logind'], 'ENABLE_LOGIND'],
@ -740,6 +763,10 @@ manpages = [
''],
['systemd-modules-load.service', '8', ['systemd-modules-load'], 'HAVE_KMOD'],
['systemd-mount', '1', ['systemd-umount'], ''],
['systemd-network-generator.service',
'8',
['systemd-network-generator'],
'ENABLE_NETWORKD'],
['systemd-networkd-wait-online.service',
'8',
['systemd-networkd-wait-online'],
@ -749,7 +776,7 @@ manpages = [
['systemd-nspawn', '1', [], ''],
['systemd-path', '1', [], ''],
['systemd-portabled.service', '8', ['systemd-portabled'], 'ENABLE_PORTABLED'],
['systemd-pstore', '8', ['systemd-pstore.service'], 'ENABLE_PSTORE'],
['systemd-pstore.service', '8', ['systemd-pstore'], 'ENABLE_PSTORE'],
['systemd-quotacheck.service',
'8',
['systemd-quotacheck'],
@ -760,6 +787,7 @@ manpages = [
'ENABLE_RANDOMSEED'],
['systemd-rc-local-generator', '8', [], ''],
['systemd-remount-fs.service', '8', ['systemd-remount-fs'], ''],
['systemd-repart', '8', ['systemd-repart.service'], 'ENABLE_REPART'],
['systemd-resolved.service', '8', ['systemd-resolved'], 'ENABLE_RESOLVE'],
['systemd-rfkill.service',
'8',
@ -812,6 +840,7 @@ manpages = [
['systemd-update-utmp', 'systemd-update-utmp-runlevel.service'],
'ENABLE_UTMP'],
['systemd-user-sessions.service', '8', ['systemd-user-sessions'], 'HAVE_PAM'],
['systemd-userdbd.service', '8', ['systemd-userdbd'], 'ENABLE_USERDB'],
['systemd-vconsole-setup.service',
'8',
['systemd-vconsole-setup'],
@ -943,6 +972,7 @@ manpages = [
['udev_new', '3', ['udev_ref', 'udev_unref'], ''],
['udevadm', '8', [], ''],
['user@.service', '5', ['user-runtime-dir@.service'], ''],
['userdbctl', '1', [], 'ENABLE_USERDB'],
['vconsole.conf', '5', [], 'ENABLE_VCONSOLE']
]
# Really, do not edit.

1
man/sd-bus.xml
View File

@ -58,6 +58,7 @@
<citerefentry><refentrytitle>sd_bus_message_append_string_memfd</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
<citerefentry><refentrytitle>sd_bus_message_append_strv</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
<citerefentry><refentrytitle>sd_bus_message_copy</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
<citerefentry><refentrytitle>sd_bus_message_dump</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
<citerefentry><refentrytitle>sd_bus_message_get_cookie</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
<citerefentry><refentrytitle>sd_bus_message_get_monotonic_usec</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
<citerefentry><refentrytitle>sd_bus_message_get_signature</refentrytitle><manvolnum>3</manvolnum></citerefentry>,

88
man/sd_bus_enqueue_for_read.xml Normal file
View File

@ -0,0 +1,88 @@
<?xml version='1.0'?>
<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
<!-- SPDX-License-Identifier: LGPL-2.1+ -->
<refentry id="sd_bus_enqueue_for_read"
xmlns:xi="http://www.w3.org/2001/XInclude">
<refentryinfo>
<title>sd_bus_enqueue_for_read</title>
<productname>systemd</productname>
</refentryinfo>
<refmeta>
<refentrytitle>sd_bus_enqueue_for_read</refentrytitle>
<manvolnum>3</manvolnum>
</refmeta>
<refnamediv>
<refname>sd_bus_enqueue_for_read</refname>
<refpurpose>Re-enqueue a bus message on a bus connection, for reading.</refpurpose>
</refnamediv>
<refsynopsisdiv>
<funcsynopsis>
<funcsynopsisinfo>#include &lt;systemd/sd-bus.h&gt;</funcsynopsisinfo>
<funcprototype>
<funcdef>int <function>sd_bus_enqueue_for_read</function></funcdef>
<paramdef>sd_bus *<parameter>bus</parameter></paramdef>
<paramdef>sd_bus_message *<parameter>message</parameter></paramdef>
</funcprototype>
</funcsynopsis>
</refsynopsisdiv>
<refsect1>
<title>Description</title>
<para><function>sd_bus_enqueue_for_read()</function> may be used to re-enqueue an incoming bus message on
the local read queue, so that it is processed and dispatched locally again, similar to how an incoming
message from the peer is processed. Takes a bus connection object and the message to enqueue. A reference
is taken of the message and the caller's reference thus remains in possession of the caller. The message
is enqueued at the end of the queue, thus will be dispatched after all other already queued messages are
dispatched.</para>
<para>This call is primarily useful for dealing with incoming method calls that may be processed only
after an additional asynchronous operation completes. One example are PolicyKit authorization requests
that are determined to be necessary to authorize a newly incoming method call: when the PolicyKit response
is received the original method call may be re-enqueued to process it again, this time with the
authorization result known.</para>
</refsect1>
<refsect1>
<title>Return Value</title>
<para>On success, this function return 0 or a positive integer. On failure, it returns a negative errno-style
error code.</para>
<refsect2>
<title>Errors</title>
<para>Returned errors may indicate the following problems:</para>
<variablelist>
<varlistentry>
<term><constant>-ECHILD</constant></term>
<listitem><para>The bus connection has been created in a different process.</para></listitem>
</varlistentry>
</variablelist>
</refsect2>
</refsect1>
<xi:include href="libsystemd-pkgconfig.xml" />
<refsect1>
<title>See Also</title>
<para>
<citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
<citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
<citerefentry><refentrytitle>sd_bus_send</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
</para>
</refsect1>
</refentry>

107
man/sd_bus_message_dump.xml Normal file
View File

@ -0,0 +1,107 @@
<?xml version='1.0'?>
<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
<!-- SPDX-License-Identifier: LGPL-2.1+ -->
<refentry id="sd_bus_message_dump"
xmlns:xi="http://www.w3.org/2001/XInclude">
<refentryinfo>
<title>sd_bus_message_dump</title>
<productname>systemd</productname>
</refentryinfo>
<refmeta>
<refentrytitle>sd_bus_message_dump</refentrytitle>
<manvolnum>3</manvolnum>
</refmeta>
<refnamediv>
<refname>sd_bus_message_dump</refname>
<refpurpose>Produce a string representation of a message for debugging purposes</refpurpose>
</refnamediv>
<refsynopsisdiv>
<funcsynopsis>
<funcsynopsisinfo>#include &lt;systemd/sd-bus.h&gt;</funcsynopsisinfo>
<funcprototype>
<funcdef>int sd_bus_message_dump</funcdef>
<paramdef>sd_bus_message *<parameter>m</parameter></paramdef>
<paramdef>FILE *<parameter>f</parameter></paramdef>
<paramdef>uint64_t <parameter>flags</parameter></paramdef>
</funcprototype>
</funcsynopsis>
<para>
<constant>SD_BUS_MESSAGE_DUMP_WITH_HEADER</constant>,
<constant>SD_BUS_MESSAGE_DUMP_SUBTREE_ONLY</constant>
</para>
</refsynopsisdiv>
<refsect1>
<title>Description</title>
<para>The <function>sd_bus_message_dump()</function> function writes a textual representation of the
message <parameter>m</parameter> to the stream <parameter>f</parameter>. This function is intended to be
used for debugging purposes, and the output is neither stable nor designed to be machine readable.
</para>
<para>The <parameter>flags</parameter> parameter may be used to modify the output. With
<constant>SD_BUS_MESSAGE_DUMP_WITH_HEADER</constant>, a header that specifies the message type and flags
and some additional metadata is printed. When <constant>SD_BUS_MESSAGE_DUMP_SUBTREE_ONLY</constant> is
not passed, the contents of the whole message are printed. When it <emphasis>is</emphasis> passed,
only the current container in printed.</para>
<para>Note that this function moves the read pointer of the message. It may be necessary to reset the
position afterwards, for example with
<citerefentry><refentrytitle>sd_bus_message_rewind</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
</para>
</refsect1>
<refsect1>
<title>Examples</title>
<para>Output for a signal message (with <constant>SD_BUS_MESSAGE_DUMP_WITH_HEADER</constant>):
<programlisting>
‣ Type=signal Endian=l Flags=1 Version=1 Priority=0 Cookie=22
Path=/value/a Interface=org.freedesktop.DBus.Properties Member=PropertiesChanged
MESSAGE "sa{sv}as" {
STRING "org.freedesktop.systemd.ValueTest";
ARRAY "{sv}" {
DICT_ENTRY "sv" {
STRING "Value";
VARIANT "s" {
STRING "object 0x1e, path /value/a";
};
};
};
ARRAY "s" {
STRING "Value2";
STRING "AnExplicitProperty";
};
};
</programlisting>
</para>
</refsect1>
<refsect1>
<title>Return Value</title>
<para>On success, this function returns 0 or a positive integer. On failure, it returns a negative
errno-style error code. No error codes are currently defined.</para>
</refsect1>
<xi:include href="libsystemd-pkgconfig.xml" />
<refsect1>
<title>See Also</title>
<para>
<citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
<citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>
</para>
</refsect1>
</refentry>

18
man/sd_bus_message_read.xml
View File

@ -60,13 +60,13 @@
<para>For each type specified in the type string, one or more arguments need to be specified
after the <parameter>types</parameter> parameter, in the same order. The arguments must be
pointers to appropriate types (a pointer to <code>int8_t</code> for a <literal>y</literal> in
the type string, a pointer to <code>int32_t</code> for an <literal>i</literal>, a pointer to
<code>const char*</code> for an <literal>s</literal>, ...) which are set based on the values in
pointers to appropriate types (a pointer to <type>int8_t</type> for a <literal>y</literal> in
the type string, a pointer to <type>int32_t</type> for an <literal>i</literal>, a pointer to
<type>const char*</type> for an <literal>s</literal>, ...) which are set based on the values in
the message. As an exception, in case or array and variant types, the first argument is an
"input" argument that further specifies how the message should be read. See the table below for
a complete list of allowed arguments and their types. Note that, if the basic type is a pointer
(e.g., <code>const char *</code> in the case of a string), the argument is a pointer to a
(e.g., <type>const char *</type> in the case of a string), the argument is a pointer to a
pointer, and also the pointer value that is written is only borrowed and the contents must be
copied if they are to be used after the end of the messages lifetime.</para>
@ -99,7 +99,7 @@
<entry><literal>a</literal></entry>
<entry><constant>SD_BUS_TYPE_ARRAY</constant></entry>
<entry>array</entry>
<entry>int, which specifies the expected length <parameter>n</parameter> of the array</entry>
<entry><type>int</type>, which specifies the expected length <parameter>n</parameter> of the array</entry>
<entry><parameter>n</parameter> sets of arguments appropriate for the array element type</entry>
</row>
@ -174,6 +174,14 @@ int64_t x;
sd_bus_message_read(m, "x", &amp;x);</programlisting>
<para>Read a boolean value:</para>
<programlisting>sd_bus_message *m;
int x; /* Do not use C99 'bool' type here, it's typically smaller
in memory and would cause memory corruption */
sd_bus_message_read(m, "b", &amp;x);</programlisting>
<para>Read all types of integers:</para>
<programlisting>uint8_t y;

8
man/sd_bus_message_read_array.xml
View File

@ -48,6 +48,10 @@
appropriate for the data type. The data is part of the message — it may not be modified and is
valid only as long as the message is referenced. After this function returns, the "read pointer"
points at the next element after the array.</para>
<para>Note that this function only supports arrays of trivial types, i.e. arrays of booleans, the various
integer types, as well as floating point numbers. In particular it may not be used for arrays of strings,
structures or similar.</para>
</refsect1>
<refsect1>
@ -68,8 +72,8 @@
<varlistentry>
<term><constant>-EINVAL</constant></term>
<listitem><para>Specified type is invalid or the message parameter or one of the output
parameters are <constant>NULL</constant>.</para></listitem>
<listitem><para>Specified type is invalid or not a trivial type (see above), or the message
parameter or one of the output parameters are <constant>NULL</constant>.</para></listitem>
</varlistentry>
<varlistentry>

54
man/sd_bus_message_read_basic.xml
View File

@ -55,10 +55,10 @@
If <parameter>p</parameter> is not <constant>NULL</constant>, it should contain
a pointer to an appropriate object. For example, if <parameter>type</parameter>
is <constant>'y'</constant>, the object passed in <parameter>p</parameter>
should have type <code>uint8_t *</code>. If <parameter>type</parameter> is
should have type <type>uint8_t *</type>. If <parameter>type</parameter> is
<constant>'s'</constant>, the object passed in <parameter>p</parameter> should
have type <code>const char **</code>. Note that, if the basic type is a pointer
(e.g., <code>const char *</code> in the case of a string), the pointer is only
have type <type>const char **</type>. Note that, if the basic type is a pointer
(e.g., <type>const char *</type> in the case of a string), the pointer is only
borrowed and the contents must be copied if they are to be used after the end
of the messages lifetime. Similarly, during the lifetime of such a pointer, the
message must not be modified. See the table below for a complete list of allowed
@ -85,92 +85,92 @@
<row>
<entry><literal>y</literal></entry>
<entry><constant>SD_BUS_TYPE_BYTE</constant></entry>
<entry>unsigned integer</entry>
<entry>uint8_t *</entry>
<entry>8bit unsigned integer</entry>
<entry><type>uint8_t *</type></entry>
</row>
<row>
<entry><literal>b</literal></entry>
<entry><constant>SD_BUS_TYPE_BOOLEAN</constant></entry>
<entry>boolean</entry>
<entry>int *</entry>
<entry><type>int *</type> (NB: not <type>bool *</type>)</entry>
</row>
<row>
<entry><literal>n</literal></entry>
<entry><constant>SD_BUS_TYPE_INT16</constant></entry>
<entry>signed integer</entry>
<entry>int16_t *</entry>
<entry>16bit signed integer</entry>
<entry><type>int16_t *</type></entry>
</row>
<row>
<entry><literal>q</literal></entry>
<entry><constant>SD_BUS_TYPE_UINT16</constant></entry>
<entry>unsigned integer</entry>
<entry>uint16_t *</entry>
<entry>16bit unsigned integer</entry>
<entry><type>uint16_t *</type></entry>
</row>
<row>
<entry><literal>i</literal></entry>
<entry><constant>SD_BUS_TYPE_INT32</constant></entry>
<entry>signed integer</entry>
<entry>int32_t *</entry>
<entry>32bit signed integer</entry>
<entry><type>int32_t *</type></entry>
</row>
<row>
<entry><literal>u</literal></entry>
<entry><constant>SD_BUS_TYPE_UINT32</constant></entry>
<entry>unsigned integer</entry>
<entry>uint32_t *</entry>
<entry>32bit unsigned integer</entry>
<entry><type>uint32_t *</type></entry>
</row>
<row>
<entry><literal>x</literal></entry>
<entry><constant>SD_BUS_TYPE_INT64</constant></entry>
<entry>signed integer</entry>
<entry>int64_t *</entry>
<entry>64bit signed integer</entry>
<entry><type>int64_t *</type></entry>
</row>
<row>
<entry><literal>t</literal></entry>
<entry><constant>SD_BUS_TYPE_UINT64</constant></entry>
<entry>unsigned integer</entry>
<entry>uint64_t *</entry>
<entry>64bit unsigned integer</entry>
<entry><type>uint64_t *</type></entry>
</row>
<row>
<entry><literal>d</literal></entry>
<entry><constant>SD_BUS_TYPE_DOUBLE</constant></entry>
<entry>floating-point</entry>
<entry>double *</entry>
<entry>IEEE 754 double precision floating-point</entry>
<entry><type>double *</type></entry>
</row>
<row>
<entry><literal>s</literal></entry>
<entry><constant>SD_BUS_TYPE_STRING</constant></entry>
<entry>Unicode string</entry>
<entry>const char **</entry>
<entry>UTF-8 string</entry>
<entry><type>const char **</type></entry>
</row>
<row>
<entry><literal>o</literal></entry>
<entry><constant>SD_BUS_TYPE_OBJECT_PATH</constant></entry>
<entry>object path</entry>
<entry>const char **</entry>
<entry>D-Bus object path string</entry>
<entry><type>const char **</type></entry>
</row>
<row>
<entry><literal>g</literal></entry>
<entry><constant>SD_BUS_TYPE_SIGNATURE</constant></entry>
<entry>signature</entry>
<entry>const char **</entry>
<entry>D-Bus signature string</entry>
<entry><type>const char **</type></entry>
</row>
<row>
<entry><literal>h</literal></entry>
<entry><constant>SD_BUS_TYPE_UNIX_FD</constant></entry>
<entry>UNIX file descriptor</entry>
<entry>int *</entry>
<entry><type>int *</type></entry>
</row>
</tbody>
</tgroup>

85
man/sd_bus_message_sensitive.xml Normal file
View File

@ -0,0 +1,85 @@
<?xml version='1.0'?> <!--*-nxml-*-->
<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
<!-- SPDX-License-Identifier: LGPL-2.1+ -->
<refentry id="sd_bus_message_sensitive" xmlns:xi="http://www.w3.org/2001/XInclude">
<refentryinfo>
<title>sd_bus_message_sensitive</title>
<productname>systemd</productname>
</refentryinfo>
<refmeta>
<refentrytitle>sd_bus_message_sensitive</refentrytitle>
<manvolnum>3</manvolnum>
</refmeta>
<refnamediv>
<refname>sd_bus_message_sensitive</refname>
<refpurpose>Mark a message object as containing sensitive data</refpurpose>
</refnamediv>
<refsynopsisdiv>
<funcsynopsis>
<funcsynopsisinfo>#include &lt;systemd/sd-bus.h&gt;</funcsynopsisinfo>
<funcprototype>
<funcdef>int <function>sd_bus_message_sensitive</function></funcdef>
<paramdef>sd_bus_message *<parameter>message</parameter></paramdef>
</funcprototype>
</funcsynopsis>
</refsynopsisdiv>
<refsect1>
<title>Description</title>
<para><function>sd_bus_message_sensitive()</function> marks an allocated bus message as containing
sensitive data. This ensures that the message data is carefully removed from memory (specifically,
overwritten with zero bytes) when released. It is recommended to mark all incoming and outgoing messages
like this that contain security credentials and similar data that should be dealt with carefully. Note
that it is not possible to unmark messages like this, it's a one way operation. If a message is already
marked sensitive and then marked sensitive a second time the message remains marked so and no further
operation is executed.</para>
<para>As a safety precaution all messages that are created as reply to messages that are marked sensitive
are also implicitly marked so.</para>
</refsect1>
<refsect1>
<title>Return Value</title>
<para>On success, theis functions return 0 or a positive integer. On failure, it returns a
negative errno-style error code.</para>
<refsect2>
<title>Errors</title>
<para>Returned errors may indicate the following problems:</para>
<variablelist>
<varlistentry>
<term><constant>-EINVAL</constant></term>
<listitem><para>The <parameter>message</parameter> parameter is
<constant>NULL</constant>.</para></listitem>
</varlistentry>
</variablelist>
</refsect2>
</refsect1>
<xi:include href="libsystemd-pkgconfig.xml" />
<refsect1>
<title>See Also</title>
<para>
<citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
<citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
<citerefentry><refentrytitle>sd_bus_message_new_method_call</refentrytitle><manvolnum>3</manvolnum></citerefentry>
</para>
</refsect1>
</refentry>

162
man/sd_event_add_child.xml
View File

@ -17,7 +17,14 @@
<refnamediv>
<refname>sd_event_add_child</refname>
<refname>sd_event_add_child_pidfd</refname>
<refname>sd_event_source_get_child_pid</refname>
<refname>sd_event_source_get_child_pidfd</refname>
<refname>sd_event_source_get_child_pidfd_own</refname>
<refname>sd_event_source_set_child_pidfd_own</refname>
<refname>sd_event_source_get_child_process_own</refname>
<refname>sd_event_source_set_child_process_own</refname>
<refname>sd_event_source_send_child_signal</refname>
<refname>sd_event_child_handler_t</refname>
<refpurpose>Add a child process state change event source to an event loop</refpurpose>
@ -46,40 +53,77 @@
<paramdef>void *<parameter>userdata</parameter></paramdef>
</funcprototype>
<funcprototype>
<funcdef>int <function>sd_event_add_child_pidfd</function></funcdef>
<paramdef>sd_event *<parameter>event</parameter></paramdef>
<paramdef>sd_event_source **<parameter>source</parameter></paramdef>
<paramdef>int <parameter>pidfd</parameter></paramdef>
<paramdef>int <parameter>options</parameter></paramdef>
<paramdef>sd_event_child_handler_t <parameter>handler</parameter></paramdef>
<paramdef>void *<parameter>userdata</parameter></paramdef>
</funcprototype>
<funcprototype>
<funcdef>int <function>sd_event_source_get_child_pid</function></funcdef>
<paramdef>sd_event_source *<parameter>source</parameter></paramdef>
<paramdef>pid_t *<parameter>pid</parameter></paramdef>
</funcprototype>
<funcprototype>
<funcdef>int <function>sd_event_source_get_child_pidfd</function></funcdef>
<paramdef>sd_event_source *<parameter>source</parameter></paramdef>
</funcprototype>
<funcprototype>
<funcdef>int <function>sd_event_source_get_child_pidfd_own</function></funcdef>
<paramdef>sd_event_source *<parameter>source</parameter></paramdef>
</funcprototype>
<funcprototype>
<funcdef>int <function>sd_event_source_set_child_pidfd_own</function></funcdef>
<paramdef>sd_event_source *<parameter>source</parameter></paramdef>
<paramdef>int <parameter>own</parameter></paramdef>
</funcprototype>
<funcprototype>
<funcdef>int <function>sd_event_source_get_child_process_own</function></funcdef>
<paramdef>sd_event_source *<parameter>source</parameter></paramdef>
</funcprototype>
<funcprototype>
<funcdef>int <function>sd_event_source_set_child_process_own</function></funcdef>
<paramdef>sd_event_source *<parameter>source</parameter></paramdef>
<paramdef>int <parameter>own</parameter></paramdef>
</funcprototype>
<funcprototype>
<funcdef>int <function>sd_event_source_send_child_signal</function></funcdef>
<paramdef>sd_event_source *<parameter>source</parameter></paramdef>
<paramdef>int <parameter>sig</parameter></paramdef>
<paramdef>const siginfo_t *<parameter>info</parameter></paramdef>
<paramdef>unsigned <parameter>flags</parameter></paramdef>
</funcprototype>
</funcsynopsis>
</refsynopsisdiv>
<refsect1>
<title>Description</title>
<para><function>sd_event_add_child()</function> adds a new child
process state change event source to an event loop. The event loop
object is specified in the <parameter>event</parameter> parameter,
the event source object is returned in the
<parameter>source</parameter> parameter. The
<parameter>pid</parameter> parameter specifies the PID of the
process to watch. The <parameter>handler</parameter> must
reference a function to call when the process changes state. The
handler function will be passed the
<parameter>userdata</parameter> pointer, which may be chosen
freely by the caller. The handler also receives a pointer to a
<structname>siginfo_t</structname> structure containing
information about the child process event. The
<parameter>options</parameter> parameter determines which state
changes will be watched for. It must contain an OR-ed mask of
<constant>WEXITED</constant> (watch for the child process
terminating), <constant>WSTOPPED</constant> (watch for the child
process being stopped by a signal), and
<constant>WCONTINUED</constant> (watch for the child process being
resumed by a signal). See <citerefentry
project='man-pages'><refentrytitle>waitid</refentrytitle><manvolnum>2</manvolnum></citerefentry>
for further information.</para>
<para><function>sd_event_add_child()</function> adds a new child process state change event source to an
event loop. The event loop object is specified in the <parameter>event</parameter> parameter, the event
source object is returned in the <parameter>source</parameter> parameter. The <parameter>pid</parameter>
parameter specifies the PID of the process to watch, which must be a direct child process of the invoking
process. The <parameter>handler</parameter> must reference a function to call when the process changes
state. The handler function will be passed the <parameter>userdata</parameter> pointer, which may be
chosen freely by the caller. The handler also receives a pointer to a <structname>siginfo_t</structname>
structure containing information about the child process event. The <parameter>options</parameter>
parameter determines which state changes will be watched for. It must contain an OR-ed mask of
<constant>WEXITED</constant> (watch for the child process terminating), <constant>WSTOPPED</constant>
(watch for the child process being stopped by a signal), and <constant>WCONTINUED</constant> (watch for
the child process being resumed by a signal). See <citerefentry
project='man-pages'><refentrytitle>waitid</refentrytitle><manvolnum>2</manvolnum></citerefentry> for
further information.</para>
<para>Only a single handler may be installed for a specific
child process. The handler is enabled for a single event
@ -100,6 +144,12 @@
<constant>SD_EVENT_OFF</constant> with
<citerefentry><refentrytitle>sd_event_source_set_enabled</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para>
<para>The <constant>SIGCHLD</constant> signal must be blocked in all threads before this function is
called (using <citerefentry
project='man-pages'><refentrytitle>sigprocmask</refentrytitle><manvolnum>2</manvolnum></citerefentry> or
<citerefentry
project='man-pages'><refentrytitle>pthread_sigmask</refentrytitle><manvolnum>3</manvolnum></citerefentry>).</para>
<para>If the second parameter of
<function>sd_event_add_child()</function> is passed as NULL no
reference to the event source object is returned. In this case the
@ -121,6 +171,17 @@
processed first, it should leave the child processes for which
child process state change event sources are installed unreaped.</para>
<para><function>sd_event_add_child_pidfd()</function> is similar to
<function>sd_event_add_child()</function> but takes a file descriptor referencing the process ("pidfd")
instead of the numeric PID. A suitable file descriptor may be acquired via <citerefentry
project='man-pages'><refentrytitle>pidfd_open</refentrytitle><manvolnum>2</manvolnum></citerefentry> and
related calls. The passed file descriptor is not closed when the event source is freed again, unless
<function>sd_event_source_set_child_pidfd_own()</function> is used to turn this behaviour on. Note that
regardless which of <function>sd_event_add_child()</function> and
<function>sd_event_add_child_pidfd()</function> is used for allocating an event source, the watched
process has to be a direct child process of the invoking process. Also in both cases
<constant>SIGCHLD</constant> has to be blocked in the invoking process.</para>
<para><function>sd_event_source_get_child_pid()</function>
retrieves the configured PID of a child process state change event
source created previously with
@ -129,6 +190,45 @@
pointer to a <type>pid_t</type> variable to return the process ID
in.
</para>
<para><function>sd_event_source_get_child_pidfd()</function> retrieves the file descriptor referencing
the watched process ("pidfd") if this functionality is available. On kernels that support the concept the
event loop will make use of pidfds to watch child processes, regardless if the individual event sources
are allocated via <function>sd_event_add_child()</function> or
<function>sd_event_add_child_pidfd()</function>. If the latter call was used to allocate the event
source, this function returns the file descriptor used for allocation. On kernels that do not support the
pidfd concept this function will fail with <constant>EOPNOTSUPP</constant>. This call takes the event
source object as the <parameter>source</parameter> parameter and returns the numeric file descriptor.
</para>
<para><function>sd_event_source_get_child_pidfd_own()</function> may be used to query whether the pidfd
the event source encapsulates shall be closed when the event source is freed. This function returns zero
if the pidfd shall be left open, and positive if it shall be closed automatically. By default this
setting defaults to on if the event source was allocated via <function>sd_event_add_child()</function>
and off if it was allocated via <function>sd_event_add_child_pidfd()</function>. The
<function>sd_event_source_set_child_pidfd_own()</function> function may be used to change the setting and
takes a boolean parameter with the new setting.</para>
<para><function>sd_event_source_get_child_process_own()</function> may be used to query whether the
process the event source watches shall be killed (with <constant>SIGKILL</constant>) and reaped when the
event source is freed. This function returns zero if the process shell be left running, and positive if
it shall be killed and reaped automatically. By default this setting defaults to off. The
<function>sd_event_source_set_child_process_own()</function> function may be used to change the setting
and takes a boolean parameter with the new setting. Note that currently if the calling process is
terminated abnormally the watched process might survive even thought the event source ceases to
exist. This behaviour might change eventually.</para>
<para><function>sd_event_source_send_child_signal()</function> may be used to send a UNIX signal to the
watched process. If the pidfd concept is supported in the kernel, this is implemented via <citerefentry
project='man-pages'><refentrytitle>pidfd_send_signal</refentrytitle><manvolnum>2</manvolnum></citerefentry>
and otherwise via <citerefentry
project='man-pages'><refentrytitle>rt_sigqueueinfo</refentrytitle><manvolnum>2</manvolnum></citerefentry>
(or via <citerefentry
project='man-pages'><refentrytitle>kill</refentrytitle><manvolnum>2</manvolnum></citerefentry> in case
<parameter>info</parameter> is <constant>NULL</constant>). The specified parameters match those of these
underlying system calls, except that the <parameter>info</parameter> is never modified (and is thus
declared constant). Like for the underlying system calls, the <parameter>flags</parameter> parameter
currently must be zero.</para>
</refsect1>
<refsect1>
@ -165,8 +265,8 @@
<varlistentry>
<term><constant>-EBUSY</constant></term>
<listitem><para>A handler is already installed for this
child process.</para></listitem>
<listitem><para>A handler is already installed for this child process, or
<constant>SIGCHLD</constant> is not blocked.</para></listitem>
</varlistentry>
@ -190,6 +290,12 @@
<listitem><para>The passed event source is not a child process event source.</para></listitem>
</varlistentry>
<varlistentry>
<term><constant>-EOPNOTSUPP</constant></term>
<listitem><para>A pidfd was requested but the kernel does not support this concept.</para></listitem>
</varlistentry>
</variablelist>
</refsect2>
</refsect1>
@ -214,7 +320,13 @@
<citerefentry><refentrytitle>sd_event_source_set_userdata</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
<citerefentry><refentrytitle>sd_event_source_set_description</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
<citerefentry><refentrytitle>sd_event_source_set_floating</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
<citerefentry project='man-pages'><refentrytitle>waitid</refentrytitle><manvolnum>2</manvolnum></citerefentry>
<citerefentry project='man-pages'><refentrytitle>waitid</refentrytitle><manvolnum>2</manvolnum></citerefentry>,
<citerefentry project='man-pages'><refentrytitle>sigprocmask</refentrytitle><manvolnum>2</manvolnum></citerefentry>,
<citerefentry project='man-pages'><refentrytitle>pthread_sigmask</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
<citerefentry project='man-pages'><refentrytitle>pidfd_open</refentrytitle><manvolnum>2</manvolnum></citerefentry>,
<citerefentry project='man-pages'><refentrytitle>pidfd_send_signal</refentrytitle><manvolnum>2</manvolnum></citerefentry>,
<citerefentry project='man-pages'><refentrytitle>rt_sigqueueinfo</refentrytitle><manvolnum>2</manvolnum></citerefentry>,
<citerefentry project='man-pages'><refentrytitle>kill</refentrytitle><manvolnum>2</manvolnum></citerefentry>
</para>
</refsect1>

17
man/sd_event_add_signal.xml
View File

@ -75,14 +75,13 @@
project='man-pages'><refentrytitle>signalfd</refentrytitle><manvolnum>2</manvolnum></citerefentry>
for further information.</para>
<para>Only a single handler may be installed for a specific
signal. The signal will be unblocked by this call, and must be
blocked before this function is called in all threads (using
<para>Only a single handler may be installed for a specific signal. The signal must be blocked in all
threads before this function is called (using <citerefentry
project='man-pages'><refentrytitle>sigprocmask</refentrytitle><manvolnum>2</manvolnum></citerefentry> or
<citerefentry
project='man-pages'><refentrytitle>sigprocmask</refentrytitle><manvolnum>2</manvolnum></citerefentry>). If
the handler is not specified (<parameter>handler</parameter> is
<constant>NULL</constant>), a default handler which causes the
program to exit cleanly will be used.</para>
project='man-pages'><refentrytitle>pthread_sigmask</refentrytitle><manvolnum>3</manvolnum></citerefentry>). If
the handler is not specified (<parameter>handler</parameter> is <constant>NULL</constant>), a default
handler which causes the program to exit cleanly will be used.</para>
<para>By default, the event source is enabled permanently
(<constant>SD_EVENT_ON</constant>), but this may be changed with
@ -189,7 +188,9 @@
<citerefentry><refentrytitle>sd_event_source_set_userdata</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
<citerefentry><refentrytitle>sd_event_source_set_floating</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
<citerefentry project='man-pages'><refentrytitle>signal</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
<citerefentry project='man-pages'><refentrytitle>signalfd</refentrytitle><manvolnum>2</manvolnum></citerefentry>
<citerefentry project='man-pages'><refentrytitle>signalfd</refentrytitle><manvolnum>2</manvolnum></citerefentry>,
<citerefentry project='man-pages'><refentrytitle>sigprocmask</refentrytitle><manvolnum>2</manvolnum></citerefentry>,
<citerefentry project='man-pages'><refentrytitle>pthread_sigmask</refentrytitle><manvolnum>3</manvolnum></citerefentry>
</para>
</refsect1>

22
man/sd_journal_open.xml
View File

@ -29,6 +29,8 @@
<refname>SD_JOURNAL_SYSTEM</refname>
<refname>SD_JOURNAL_CURRENT_USER</refname>
<refname>SD_JOURNAL_OS_ROOT</refname>
<refname>SD_JOURNAL_ALL_NAMESPACES</refname>
<refname>SD_JOURNAL_INCLUDE_DEFAULT_NAMESPACE</refname>
<refpurpose>Open the system journal for reading</refpurpose>
</refnamediv>
@ -42,6 +44,13 @@
<paramdef>int <parameter>flags</parameter></paramdef>
</funcprototype>
<funcprototype>
<funcdef>int <function>sd_journal_open_namespace</function></funcdef>
<paramdef>sd_journal **<parameter>ret</parameter></paramdef>
<paramdef>const char *<parameter>namespace</parameter></paramdef>
<paramdef>int <parameter>flags</parameter></paramdef>
</funcprototype>
<funcprototype>
<funcdef>int <function>sd_journal_open_directory</function></funcdef>
<paramdef>sd_journal **<parameter>ret</parameter></paramdef>
@ -101,6 +110,19 @@
<constant>SD_JOURNAL_CURRENT_USER</constant> are specified, all
journal file types will be opened.</para>
<para><function>sd_journal_open_namespace()</function> is similar to
<function>sd_journal_open()</function> but takes an additional <parameter>namespace</parameter> parameter
that specifies which journal namespace to operate on. If specified as <constant>NULL</constant> the call
is identical to <function>sd_journal_open()</function>. If non-<constant>NULL</constant> only data from
the namespace identified by the specified parameter is accessed. This call understands two additional
flags: if <constant>SD_JOURNAL_ALL_NAMESPACES</constant> is specified the
<parameter>namespace</parameter> parameter is ignored and all defined namespaces are accessed
simultaneously; if <constant>SD_JOURNAL_INCLUDE_DEFAULT_NAMESPACE</constant> the specified namespace and
the default namespace are accessed but no others (this flag has no effect when
<parameter>namespace</parameter> is passed as <constant>NULL</constant>). For details about journal
namespaces see
<citerefentry><refentrytitle>systemd-journald.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para>
<para><function>sd_journal_open_directory()</function> is similar to <function>sd_journal_open()</function> but
takes an absolute directory path as argument. All journal files in this directory will be opened and interleaved
automatically. This call also takes a flags argument. The flags parameters accepted by this call are

2
man/sd_journal_print.xml
View File

@ -70,7 +70,7 @@
journal. The first argument is a priority value. This is followed by a format string and its parameters, similar to
<citerefentry project='man-pages'><refentrytitle>printf</refentrytitle><manvolnum>3</manvolnum></citerefentry> or
<citerefentry project='man-pages'><refentrytitle>syslog</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
Note that currently the resulting message will be trucated to <constant>LINE_MAX - 8</constant>.
Note that currently the resulting message will be truncated to <constant>LINE_MAX - 8</constant>.
The priority value is one of <constant>LOG_EMERG</constant>, <constant>LOG_ALERT</constant>,
<constant>LOG_CRIT</constant>, <constant>LOG_ERR</constant>, <constant>LOG_WARNING</constant>,
<constant>LOG_NOTICE</constant>, <constant>LOG_INFO</constant>, <constant>LOG_DEBUG</constant>, as defined in

Some files were not shown because too many files have changed in this diff Show More