mirror of
https://git.proxmox.com/git/systemd
synced 2025-08-06 17:58:33 +00:00
New upstream version 251~rc1
This commit is contained in:
parent
9cde670fff
commit
f5caa8faf7
@ -1,7 +1,7 @@
|
||||
# This configuration file can be used to auto-format the code base.
|
||||
# Not all guidelines specified in CODING_STYLE are followed, so the
|
||||
# result MUST NOT be committed indiscriminately, but each automated
|
||||
# change should be reviewed and only the appropriate ones commited.
|
||||
# change should be reviewed and only the appropriate ones committed.
|
||||
#
|
||||
# The easiest way to apply the formatting to your changes ONLY,
|
||||
# is to use the git-clang-format script (usually installed with clang-format).
|
||||
|
5
.clusterfuzzlite/Dockerfile
Normal file
5
.clusterfuzzlite/Dockerfile
Normal file
@ -0,0 +1,5 @@
|
||||
FROM gcr.io/oss-fuzz-base/base-builder@sha256:14b332de0e18683f37386eaedbf735bc6e8d81f9c0e1138d620f2178e20cd30a
|
||||
ENV MERGE_WITH_OSS_FUZZ_CORPORA=yes
|
||||
COPY . $SRC/systemd
|
||||
WORKDIR $SRC/systemd
|
||||
COPY tools/oss-fuzz.sh $SRC/build.sh
|
2
.github/ISSUE_TEMPLATE/Bug_report.md
vendored
2
.github/ISSUE_TEMPLATE/Bug_report.md
vendored
@ -10,7 +10,7 @@ SPDX-License-Identifier: LGPL-2.1-or-later
|
||||
<!-- **NOTE:** Do not submit bug reports about anything but the two most recently released *major* systemd versions upstream! -->
|
||||
<!-- If there have been multiple stable releases for that major version, please consider updating to a recent one before reporting an issue. -->
|
||||
<!-- When using a distro package, please make sure that the version reported is meaningful for upstream. -->
|
||||
<!-- See https://github.com/systemd/systemd-stable/releases for the list of most recent releases. -->
|
||||
<!-- See https://github.com/systemd/systemd-stable/tags for the list of most recent releases. -->
|
||||
<!-- For older version please use distribution trackers (see https://systemd.io/CONTRIBUTING#filing-issues). -->
|
||||
|
||||
**Used distribution**
|
||||
|
7
.github/dependabot.yml
vendored
7
.github/dependabot.yml
vendored
@ -5,10 +5,15 @@ updates:
|
||||
- package-ecosystem: "github-actions"
|
||||
directory: "/"
|
||||
schedule:
|
||||
interval: "weekly"
|
||||
interval: "monthly"
|
||||
open-pull-requests-limit: 2
|
||||
- package-ecosystem: "pip"
|
||||
directory: "/.github/workflows"
|
||||
schedule:
|
||||
interval: "monthly"
|
||||
open-pull-requests-limit: 2
|
||||
- package-ecosystem: "docker"
|
||||
directory: "/.clusterfuzzlite"
|
||||
schedule:
|
||||
interval: "monthly"
|
||||
open-pull-requests-limit: 2
|
||||
|
18
.github/workflows/build_test.sh
vendored
18
.github/workflows/build_test.sh
vendored
@ -9,9 +9,8 @@ success() { echo >&2 -e "\033[32;1m$1\033[0m"; }
|
||||
|
||||
ARGS=(
|
||||
"--optimization=0"
|
||||
"--optimization=2"
|
||||
"--optimization=s"
|
||||
"--optimization=3 -Db_lto=true"
|
||||
"--optimization=3 -Db_lto=true -Ddns-over-tls=false"
|
||||
"--optimization=3 -Db_lto=false"
|
||||
"--optimization=3 -Ddns-over-tls=openssl"
|
||||
"--optimization=3 -Dfexecve=true -Dstandalone-binaries=true -Dstatic-libsystemd=true -Dstatic-libudev=true"
|
||||
@ -63,6 +62,7 @@ PACKAGES=(
|
||||
COMPILER="${COMPILER:?}"
|
||||
COMPILER_VERSION="${COMPILER_VERSION:?}"
|
||||
LINKER="${LINKER:?}"
|
||||
CRYPTOLIB="${CRYPTOLIB:?}"
|
||||
RELEASE="$(lsb_release -cs)"
|
||||
|
||||
bash -c "echo 'deb-src http://archive.ubuntu.com/ubuntu/ $RELEASE main restricted universe multiverse' >>/etc/apt/sources.list"
|
||||
@ -117,18 +117,28 @@ ninja --version
|
||||
for args in "${ARGS[@]}"; do
|
||||
SECONDS=0
|
||||
|
||||
# meson fails with
|
||||
# src/boot/efi/meson.build:52: WARNING: Not using lld as efi-ld, falling back to bfd
|
||||
# src/boot/efi/meson.build:52:16: ERROR: Fatal warnings enabled, aborting
|
||||
# when LINKER is set to lld so let's just not turn meson warnings into errors with lld
|
||||
# to make sure that the build systemd can pick up the correct efi-ld linker automatically.
|
||||
if [[ "$LINKER" != lld ]]; then
|
||||
additional_meson_args="--fatal-meson-warnings"
|
||||
fi
|
||||
info "Checking build with $args"
|
||||
# shellcheck disable=SC2086
|
||||
if ! AR="$AR" \
|
||||
CC="$CC" CC_LD="$LINKER" CFLAGS="-Werror" \
|
||||
CXX="$CXX" CXX_LD="$LINKER" CXXFLAGS="-Werror" \
|
||||
meson -Dtests=unsafe -Dslow-tests=true -Dfuzz-tests=true --werror \
|
||||
$args build; then
|
||||
-Dnobody-group=nogroup $additional_meson_args \
|
||||
-Dcryptolib="${CRYPTOLIB:?}" $args build; then
|
||||
|
||||
cat build/meson-logs/meson-log.txt
|
||||
fatal "meson failed with $args"
|
||||
fi
|
||||
|
||||
if ! meson compile -C build; then
|
||||
if ! meson compile -C build -v; then
|
||||
fatal "'meson compile' failed with $args"
|
||||
fi
|
||||
|
||||
|
14
.github/workflows/build_test.yml
vendored
14
.github/workflows/build_test.yml
vendored
@ -19,20 +19,20 @@ jobs:
|
||||
build:
|
||||
runs-on: ubuntu-20.04
|
||||
concurrency:
|
||||
group: ${{ github.workflow }}-${{ matrix.env.COMPILER }}-${{ matrix.env.COMPILER_VERSION }}-${{ matrix.env.LINKER }}-${{ github.ref }}
|
||||
group: ${{ github.workflow }}-${{ toJSON(matrix.env) }}-${{ github.ref }}
|
||||
cancel-in-progress: true
|
||||
strategy:
|
||||
fail-fast: false
|
||||
matrix:
|
||||
env:
|
||||
- { COMPILER: "gcc", COMPILER_VERSION: "10", LINKER: "bfd" }
|
||||
- { COMPILER: "gcc", COMPILER_VERSION: "11", LINKER: "gold" }
|
||||
- { COMPILER: "clang", COMPILER_VERSION: "11", LINKER: "bfd" }
|
||||
- { COMPILER: "clang", COMPILER_VERSION: "12", LINKER: "gold" }
|
||||
- { COMPILER: "clang", COMPILER_VERSION: "13", LINKER: "lld" }
|
||||
- { COMPILER: "gcc", COMPILER_VERSION: "10", LINKER: "bfd", CRYPTOLIB: "gcrypt" }
|
||||
- { COMPILER: "gcc", COMPILER_VERSION: "11", LINKER: "gold", CRYPTOLIB: "openssl" }
|
||||
- { COMPILER: "clang", COMPILER_VERSION: "11", LINKER: "bfd", CRYPTOLIB: "auto" }
|
||||
- { COMPILER: "clang", COMPILER_VERSION: "12", LINKER: "gold", CRYPTOLIB: "gcrypt" }
|
||||
- { COMPILER: "clang", COMPILER_VERSION: "13", LINKER: "lld", CRYPTOLIB: "openssl" }
|
||||
env: ${{ matrix.env }}
|
||||
steps:
|
||||
- name: Repository checkout
|
||||
uses: actions/checkout@ec3a7ce113134d7a93b817d10a8272cb61118579
|
||||
- name: Build check (${{ env.COMPILER }}-${{ env.COMPILER_VERSION }}-${{ env.LINKER }})
|
||||
- name: ${{ format('Build check ({0}-{1}-{2}-{3})', env.COMPILER, env.COMPILER_VERSION, env.LINKER, env.CRYPTOLIB) }}
|
||||
run: sudo -E .github/workflows/build_test.sh
|
||||
|
39
.github/workflows/cflite_pr.yml
vendored
Normal file
39
.github/workflows/cflite_pr.yml
vendored
Normal file
@ -0,0 +1,39 @@
|
||||
---
|
||||
# vi: ts=2 sw=2 et:
|
||||
# SPDX-License-Identifier: LGPL-2.1-or-later
|
||||
#
|
||||
name: ClusterFuzzLite PR fuzzing
|
||||
on:
|
||||
pull_request:
|
||||
branches:
|
||||
- main
|
||||
- v[0-9]+-stable
|
||||
|
||||
permissions: read-all
|
||||
|
||||
jobs:
|
||||
PR:
|
||||
runs-on: ubuntu-latest
|
||||
if: github.repository != 'systemd/systemd' || github.event.pull_request.user.login == 'dependabot[bot]'
|
||||
concurrency:
|
||||
group: ${{ github.workflow }}-${{ matrix.sanitizer }}-${{ github.ref }}
|
||||
cancel-in-progress: true
|
||||
strategy:
|
||||
fail-fast: false
|
||||
matrix:
|
||||
sanitizer: [address, undefined, memory]
|
||||
steps:
|
||||
- name: Build Fuzzers (${{ matrix.sanitizer }})
|
||||
id: build
|
||||
uses: google/clusterfuzzlite/actions/build_fuzzers@41dccd0566905e2a7d1724e7883edbfa66d78877
|
||||
with:
|
||||
sanitizer: ${{ matrix.sanitizer }}
|
||||
github-token: ${{ secrets.GITHUB_TOKEN }}
|
||||
- name: Run Fuzzers (${{ matrix.sanitizer }})
|
||||
id: run
|
||||
uses: google/clusterfuzzlite/actions/run_fuzzers@41dccd0566905e2a7d1724e7883edbfa66d78877
|
||||
with:
|
||||
github-token: ${{ secrets.GITHUB_TOKEN }}
|
||||
fuzz-seconds: 1200
|
||||
mode: 'code-change'
|
||||
sanitizer: ${{ matrix.sanitizer }}
|
2
.github/workflows/cifuzz.yml
vendored
2
.github/workflows/cifuzz.yml
vendored
@ -39,6 +39,8 @@ jobs:
|
||||
oss-fuzz-project-name: 'systemd'
|
||||
dry-run: false
|
||||
allowed-broken-targets-percentage: 0
|
||||
# keep-unaffected-fuzz-targets should be removed once https://github.com/google/oss-fuzz/issues/7011 is fixed
|
||||
keep-unaffected-fuzz-targets: true
|
||||
sanitizer: ${{ matrix.sanitizer }}
|
||||
- name: Run Fuzzers (${{ matrix.sanitizer }})
|
||||
uses: google/oss-fuzz/infra/cifuzz/actions/run_fuzzers@master
|
||||
|
8
.github/workflows/codeql-analysis.yml
vendored
8
.github/workflows/codeql-analysis.yml
vendored
@ -11,6 +11,8 @@ on:
|
||||
- .github/codeql-config.yml
|
||||
- .github/codeql-custom.qls
|
||||
- .github/workflows/codeql-analysis.yml
|
||||
- .github/workflows/requirements.txt
|
||||
- .github/workflows/unit_tests.sh
|
||||
# It takes the workflow approximately 30 minutes to analyze the code base
|
||||
# so it doesn't seem to make much sense to trigger it on every PR or commit.
|
||||
# It runs daily at 01:00 to avoid colliding with the Coverity workflow.
|
||||
@ -41,7 +43,7 @@ jobs:
|
||||
uses: actions/checkout@ec3a7ce113134d7a93b817d10a8272cb61118579
|
||||
|
||||
- name: Initialize CodeQL
|
||||
uses: github/codeql-action/init@5f532563584d71fdef14ee64d17bafb34f751ce5
|
||||
uses: github/codeql-action/init@75f07e7ab2ee63cba88752d8c696324e4df67466
|
||||
with:
|
||||
languages: ${{ matrix.language }}
|
||||
config-file: ./.github/codeql-config.yml
|
||||
@ -49,7 +51,7 @@ jobs:
|
||||
- run: sudo -E .github/workflows/unit_tests.sh SETUP
|
||||
|
||||
- name: Autobuild
|
||||
uses: github/codeql-action/autobuild@5f532563584d71fdef14ee64d17bafb34f751ce5
|
||||
uses: github/codeql-action/autobuild@75f07e7ab2ee63cba88752d8c696324e4df67466
|
||||
|
||||
- name: Perform CodeQL Analysis
|
||||
uses: github/codeql-action/analyze@5f532563584d71fdef14ee64d17bafb34f751ce5
|
||||
uses: github/codeql-action/analyze@75f07e7ab2ee63cba88752d8c696324e4df67466
|
||||
|
2
.github/workflows/coverity.yml
vendored
2
.github/workflows/coverity.yml
vendored
@ -28,7 +28,7 @@ jobs:
|
||||
uses: actions/checkout@ec3a7ce113134d7a93b817d10a8272cb61118579
|
||||
# https://docs.github.com/en/free-pro-team@latest/actions/reference/workflow-commands-for-github-actions#setting-an-environment-variable
|
||||
- name: Set the $COVERITY_SCAN_NOTIFICATION_EMAIL env variable
|
||||
run: echo "COVERITY_SCAN_NOTIFICATION_EMAIL=$(git log -1 ${{ github.sha }} --pretty=\"%aE\")" >> $GITHUB_ENV
|
||||
run: echo "COVERITY_SCAN_NOTIFICATION_EMAIL=$(git log -1 ${{ github.sha }} --pretty=\"%aE\")" >> "$GITHUB_ENV"
|
||||
- name: Install Coverity tools
|
||||
run: tools/get-coverity.sh
|
||||
# Reuse the setup phase of the unit test script to avoid code duplication
|
||||
|
2
.github/workflows/labeler.yml
vendored
2
.github/workflows/labeler.yml
vendored
@ -16,7 +16,7 @@ jobs:
|
||||
permissions:
|
||||
pull-requests: write
|
||||
steps:
|
||||
- uses: actions/labeler@69da01b8e0929f147b8943611bee75ee4175a49e
|
||||
- uses: actions/labeler@3d612d72e6784a1a65365cc6d33b5a001c12bf10
|
||||
with:
|
||||
repo-token: "${{ secrets.GITHUB_TOKEN }}"
|
||||
configuration-path: .github/labeler.yml
|
||||
|
6
.github/workflows/linter.yml
vendored
6
.github/workflows/linter.yml
vendored
@ -29,9 +29,10 @@ jobs:
|
||||
fetch-depth: 0
|
||||
|
||||
- name: Lint Code Base
|
||||
uses: github/super-linter@563be7dc5568017515b9e700329e9c6d3862f2b7
|
||||
uses: github/super-linter/slim@b8641364ca9a79b3cf07f3c4c59a82709cd39094
|
||||
env:
|
||||
DEFAULT_BRANCH: main
|
||||
MULTI_STATUS: false
|
||||
# Excludes:
|
||||
# - man/.* - all snippets in man pages (false positives due to
|
||||
# missing shebangs)
|
||||
@ -40,7 +41,6 @@ jobs:
|
||||
# - .*\.(in|SKELETON) - all template/skeleton files
|
||||
# - tools/coverity\.sh - external file (with some modifications)
|
||||
FILTER_REGEX_EXCLUDE: .*/(man/.*|src/kernel-install/.*|.*\.(in|SKELETON)|tools/coverity\.sh)$
|
||||
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
|
||||
MULTI_STATUS: true
|
||||
VALIDATE_ALL_CODEBASE: false
|
||||
VALIDATE_BASH: true
|
||||
VALIDATE_GITHUB_ACTIONS: true
|
||||
|
46
.github/workflows/mkosi.yml
vendored
46
.github/workflows/mkosi.yml
vendored
@ -26,30 +26,50 @@ jobs:
|
||||
ci:
|
||||
runs-on: ubuntu-20.04
|
||||
concurrency:
|
||||
group: ${{ github.workflow }}-${{ matrix.distro }}-${{ github.ref }}
|
||||
group: ${{ github.workflow }}-${{ matrix.distro }}-${{ matrix.release }}-${{ github.ref }}
|
||||
cancel-in-progress: true
|
||||
strategy:
|
||||
fail-fast: false
|
||||
matrix:
|
||||
distro:
|
||||
- arch
|
||||
- debian
|
||||
- ubuntu
|
||||
- fedora
|
||||
- opensuse
|
||||
include:
|
||||
- distro: arch
|
||||
release: rolling
|
||||
- distro: debian
|
||||
release: testing
|
||||
- distro: ubuntu
|
||||
release: focal
|
||||
- distro: fedora
|
||||
release: "35"
|
||||
- distro: opensuse
|
||||
release: tumbleweed
|
||||
- distro: centos_epel
|
||||
release: 8-stream
|
||||
- distro: centos_epel
|
||||
release: 9-stream
|
||||
|
||||
steps:
|
||||
- uses: actions/checkout@ec3a7ce113134d7a93b817d10a8272cb61118579
|
||||
- uses: systemd/mkosi@4d64fc8134f93d87ac584183e7762ac1d0efa0e5
|
||||
- uses: systemd/mkosi@0dd39c20a4b3a2fab6efdc54da92bffad7c7b7ca
|
||||
|
||||
- name: Install
|
||||
run: sudo apt-get update && sudo apt-get install --no-install-recommends python3-pexpect python3-jinja2
|
||||
|
||||
- name: Configure
|
||||
run: echo -e "[Distribution]\nDistribution=${{ matrix.distro }}\n" >mkosi.default
|
||||
run: |
|
||||
tee mkosi.default <<- EOF
|
||||
[Distribution]
|
||||
Distribution=${{ matrix.distro }}
|
||||
Release=${{ matrix.release }}
|
||||
|
||||
[Content]
|
||||
Environment=CI_BUILD=1
|
||||
|
||||
[Output]
|
||||
KernelCommandLine=${{ env.KERNEL_CMDLINE }}
|
||||
EOF
|
||||
|
||||
- name: Build ${{ matrix.distro }}
|
||||
run: ./.github/workflows/run_mkosi.sh --build-environment=CI_BUILD=1 --kernel-command-line "${{ env.KERNEL_CMDLINE }}" build
|
||||
run: ./.github/workflows/run_mkosi.sh build
|
||||
|
||||
- name: Show ${{ matrix.distro }} image summary
|
||||
run: ./.github/workflows/run_mkosi.sh summary
|
||||
@ -60,8 +80,14 @@ jobs:
|
||||
- name: Check ${{ matrix.distro }} systemd-nspawn
|
||||
run: ./.github/workflows/run_mkosi.sh shell bash -c "[[ -e /testok ]] || { cat /failed-services; exit 1; }"
|
||||
|
||||
# TODO: Remove CentOS exclusion once Ubuntu 22.04 is available in GA.
|
||||
# See https://github.com/systemd/systemd/pull/22417 and https://github.com/systemd/mkosi/pull/907 for
|
||||
# more information.
|
||||
|
||||
- name: Boot ${{ matrix.distro }} QEMU
|
||||
if: ${{ matrix.distro != 'centos_epel' }}
|
||||
run: ./.github/workflows/run_mkosi.sh qemu
|
||||
|
||||
- name: Check ${{ matrix.distro }} QEMU
|
||||
if: ${{ matrix.distro != 'centos_epel' }}
|
||||
run: ./.github/workflows/run_mkosi.sh shell bash -c "[[ -e /testok ]] || { cat /failed-services; exit 1; }"
|
||||
|
6
.github/workflows/requirements.txt
vendored
6
.github/workflows/requirements.txt
vendored
@ -1,6 +1,6 @@
|
||||
meson==0.60.2 \
|
||||
--hash=sha256:64e6968565bf1b8152f4f9d6ca8154efb9e14caa9aabf7b22e71e6c5d053e921 \
|
||||
--hash=sha256:f486659a8c723ec8d54dbe00a9a8b4696fc75f499a60a566a9b0d02952ac0be9
|
||||
meson==0.61.2 \
|
||||
--hash=sha256:0233a7f8d959079318f6052b0939c27f68a5de86ba601f25c9ee6869fb5f5889 \
|
||||
--hash=sha256:2e2d71c4d8e47624cc9fdff6de92915b3e143fc800cc44ccedd2a88362ebe4dd
|
||||
ninja==1.10.2.3 \
|
||||
--hash=sha256:0560eea57199e41e86ac2c1af0108b63ae77c3ca4d05a9425a750e908135935a \
|
||||
--hash=sha256:21a1d84d4c7df5881bfd86c25cce4cf7af44ba2b8b255c57bc1c434ec30a2dfc \
|
||||
|
4
.github/workflows/run_mkosi.sh
vendored
4
.github/workflows/run_mkosi.sh
vendored
@ -22,7 +22,7 @@ for ((i = 0; i < 5; i++)); do
|
||||
EC=0
|
||||
(sudo python3 -m mkosi --extra-tree="$TEMP_EXTRA_TREE" "$@") |& tee "$TEMPFILE" || EC=$?
|
||||
if [[ $EC -eq 0 ]]; then
|
||||
# The command passed - let's return immediatelly
|
||||
# The command passed — let's return immediately
|
||||
break
|
||||
fi
|
||||
|
||||
@ -32,7 +32,7 @@ for ((i = 0; i < 5; i++)); do
|
||||
exit $EC
|
||||
fi
|
||||
|
||||
# The command failed due to the dissect-related timeout - let's try again
|
||||
# The command failed due to the dissect-related timeout — let's try again
|
||||
sleep 1
|
||||
done
|
||||
|
||||
|
23
.github/workflows/unit_tests.sh
vendored
23
.github/workflows/unit_tests.sh
vendored
@ -9,6 +9,7 @@ ADDITIONAL_DEPS=(
|
||||
expect
|
||||
fdisk
|
||||
jekyll
|
||||
libbpf-dev
|
||||
libfdisk-dev
|
||||
libfido2-dev
|
||||
libp11-kit-dev
|
||||
@ -16,10 +17,12 @@ ADDITIONAL_DEPS=(
|
||||
libqrencode-dev
|
||||
libssl-dev
|
||||
libtss2-dev
|
||||
libxkbcommon-dev
|
||||
libzstd-dev
|
||||
perl
|
||||
python3-libevdev
|
||||
python3-pyparsing
|
||||
rpm
|
||||
zstd
|
||||
)
|
||||
|
||||
@ -27,6 +30,13 @@ function info() {
|
||||
echo -e "\033[33;1m$1\033[0m"
|
||||
}
|
||||
|
||||
function run_meson() {
|
||||
if ! meson "$@"; then
|
||||
find . -type f -name meson-log.txt -exec cat '{}' +
|
||||
return 1
|
||||
fi
|
||||
}
|
||||
|
||||
set -ex
|
||||
|
||||
MESON_ARGS=(-Dcryptolib=${CRYPTOLIB:-auto})
|
||||
@ -41,6 +51,7 @@ for phase in "${PHASES[@]}"; do
|
||||
apt-get -y update
|
||||
apt-get -y build-dep systemd
|
||||
apt-get -y install "${ADDITIONAL_DEPS[@]}"
|
||||
pip3 install -r .github/workflows/requirements.txt --require-hashes
|
||||
;;
|
||||
RUN|RUN_GCC|RUN_CLANG)
|
||||
if [[ "$phase" = "RUN_CLANG" ]]; then
|
||||
@ -49,22 +60,26 @@ for phase in "${PHASES[@]}"; do
|
||||
# The docs build is slow and is not affected by compiler/flags, so do it just once
|
||||
MESON_ARGS+=(-Dman=true)
|
||||
fi
|
||||
meson --werror -Dtests=unsafe -Dslow-tests=true -Dfuzz-tests=true "${MESON_ARGS[@]}" build
|
||||
run_meson --fatal-meson-warnings -Dnobody-group=nogroup --werror -Dtests=unsafe -Dslow-tests=true -Dfuzz-tests=true "${MESON_ARGS[@]}" build
|
||||
ninja -C build -v
|
||||
meson test -C build --print-errorlogs
|
||||
;;
|
||||
RUN_ASAN_UBSAN|RUN_GCC_ASAN_UBSAN|RUN_CLANG_ASAN_UBSAN)
|
||||
RUN_ASAN_UBSAN|RUN_GCC_ASAN_UBSAN|RUN_CLANG_ASAN_UBSAN|RUN_CLANG_ASAN_UBSAN_NO_DEPS)
|
||||
MESON_ARGS=(--optimization=1)
|
||||
|
||||
if [[ "$phase" = "RUN_CLANG_ASAN_UBSAN" ]]; then
|
||||
if [[ "$phase" =~ ^RUN_CLANG_ASAN_UBSAN ]]; then
|
||||
export CC=clang
|
||||
export CXX=clang++
|
||||
# Build fuzzer regression tests only with clang (for now),
|
||||
# see: https://github.com/systemd/systemd/pull/15886#issuecomment-632689604
|
||||
# -Db_lundef=false: See https://github.com/mesonbuild/meson/issues/764
|
||||
MESON_ARGS+=(-Db_lundef=false -Dfuzz-tests=true)
|
||||
|
||||
if [[ "$phase" == "RUN_CLANG_ASAN_UBSAN_NO_DEPS" ]]; then
|
||||
MESON_ARGS+=(-Dskip-deps=true)
|
||||
fi
|
||||
fi
|
||||
meson --werror -Dtests=unsafe -Db_sanitize=address,undefined "${MESON_ARGS[@]}" build
|
||||
run_meson --fatal-meson-warnings -Dnobody-group=nogroup --werror -Dtests=unsafe -Db_sanitize=address,undefined "${MESON_ARGS[@]}" build
|
||||
ninja -C build -v
|
||||
|
||||
export ASAN_OPTIONS=strict_string_checks=1:detect_stack_use_after_return=1:check_initialization_order=1:strict_init_order=1
|
||||
|
2
.github/workflows/unit_tests.yml
vendored
2
.github/workflows/unit_tests.yml
vendored
@ -21,7 +21,7 @@ jobs:
|
||||
strategy:
|
||||
fail-fast: false
|
||||
matrix:
|
||||
run_phase: [GCC, GCC_ASAN_UBSAN, CLANG, CLANG_ASAN_UBSAN]
|
||||
run_phase: [GCC, GCC_ASAN_UBSAN, CLANG, CLANG_ASAN_UBSAN, CLANG_ASAN_UBSAN_NO_DEPS]
|
||||
cryptolib: [auto]
|
||||
include:
|
||||
- run_phase: GCC
|
||||
|
1
.gitignore
vendored
1
.gitignore
vendored
@ -31,6 +31,7 @@ __pycache__/
|
||||
/mkosi.builddir/
|
||||
/mkosi.output/
|
||||
/mkosi.default
|
||||
/mkosi.installdir/
|
||||
# Ignore any mkosi config files with "local" in the name
|
||||
/mkosi.default.d/**/*local*.conf
|
||||
/tags
|
||||
|
@ -4,6 +4,8 @@
|
||||
|
||||
# Explicitly enable certain checks which are hidden by default
|
||||
queries:
|
||||
# See: https://github.com/github/codeql/issues/8409
|
||||
- exclude: cpp/missing-return
|
||||
- include: cpp/bad-strncpy-size
|
||||
- include: cpp/declaration-hides-variable
|
||||
- include: cpp/inconsistent-null-check
|
||||
|
@ -13,6 +13,7 @@ downstream_package_name: systemd
|
||||
# `git describe` returns in systemd's case 'v245-xxx' which breaks RPM version
|
||||
# detection (that expects 245-xxxx'). Let's tweak the version string accordingly
|
||||
upstream_tag_template: "v{version}"
|
||||
srpm_build_deps: []
|
||||
|
||||
actions:
|
||||
post-upstream-clone:
|
||||
@ -40,4 +41,5 @@ jobs:
|
||||
- fedora-rawhide-aarch64
|
||||
- fedora-rawhide-i386
|
||||
- fedora-rawhide-ppc64le
|
||||
- fedora-rawhide-s390x
|
||||
- fedora-rawhide-x86_64
|
||||
|
@ -42,7 +42,7 @@ apt-get -q --allow-releaseinfo-change update
|
||||
apt-get -y dist-upgrade
|
||||
apt-get install -y eatmydata
|
||||
# The following four are needed as long as these deps are not covered by Debian's own packaging
|
||||
apt-get install -y fdisk tree libfdisk-dev libp11-kit-dev libssl-dev libpwquality-dev
|
||||
apt-get install -y fdisk tree libfdisk-dev libp11-kit-dev libssl-dev libpwquality-dev rpm
|
||||
apt-get purge --auto-remove -y unattended-upgrades
|
||||
systemctl unmask systemd-networkd
|
||||
systemctl enable systemd-networkd
|
||||
|
@ -48,6 +48,7 @@ The following exceptions apply:
|
||||
- src/systemctl/systemd-sysv-install.SKELETON
|
||||
- tools/check-includes.pl
|
||||
- all examples under man/
|
||||
- config files and examples under /network
|
||||
* the following sources are under **Public Domain** (LicenseRef-murmurhash2-public-domain):
|
||||
- src/basic/MurmurHash2.c
|
||||
- src/basic/MurmurHash2.h
|
||||
|
610
NEWS
610
NEWS
@ -1,5 +1,452 @@
|
||||
systemd System and Service Manager
|
||||
|
||||
CHANGES WITH 251:
|
||||
|
||||
Backwards-incompatible changes:
|
||||
|
||||
* The minimum kernel version required has been bumped from 3.13 to 3.15,
|
||||
and CLOCK_BOOTTIME is now assumed to always exist.
|
||||
|
||||
* In v250, a systemd-networkd feature that automatically configures
|
||||
routes to addresses specified in AllowedIPs= was added and enabled by
|
||||
default. However, this causes network connectivity issues in many
|
||||
existing setups. Hence, it has been disabled by default since
|
||||
systemd-stable 250.3. The feature can still be used by explicitly
|
||||
configuring RouteTable= setting in .netdev files.
|
||||
|
||||
* Jobs started via StartUnitWithFlags() will no longer return 'skipped'
|
||||
when a Condition*= check does not succeed, restoring the JobRemoved
|
||||
signal to the behaviour it had before v250.
|
||||
|
||||
* The org.freedesktop.portable1 methods GetMetadataWithExtensions() and
|
||||
GetImageMetadataWithExtensions() have been fixed to provide an extra
|
||||
return parameter, containing the actual extension release metadata.
|
||||
The current implementation was judged to be broken and unusable, and
|
||||
thus the usual procedure of adding a new set of methods was skipped,
|
||||
and backward compatibility broken instead on the assumption that
|
||||
nobody can be affected given the current state of this interface.
|
||||
|
||||
* All kernels supported by systemd mix RDRAND (or similar) into the
|
||||
entropy pool at early boot. This means that on those systems, even if
|
||||
/dev/urandom is not yet initialized, it still returns bytes that that
|
||||
are at least as high quality as RDRAND. For that reason, we no longer
|
||||
have reason to invoke RDRAND from systemd itself, which has
|
||||
historically been a source of bugs. Furthermore, kernels ≥5.6 provide
|
||||
the getrandom(GRND_INSECURE) interface for returning random bytes
|
||||
before the entropy pool is initialized without warning into kmsg,
|
||||
which is what we attempt to use if available. systemd's direct usage
|
||||
of RDRAND has been removed. x86 systems ≥Broadwell that are running
|
||||
an older kernel may experience kmsg warnings that were not seen with
|
||||
250. For newer kernels, non-x86 systems, or older x86 systems, there
|
||||
should be no visible changes.
|
||||
|
||||
* sd-boot will now measure the kernel command line into TPM PCR 12
|
||||
rather than PCR 8. This improves usefulness of the measurements on
|
||||
systems where sd-boot is chainloaded from Grub. Grub measures all
|
||||
commands its executes into PCR 8, which makes it very hard to use
|
||||
reasonably, hence separate ourselves from that and use PCR 12
|
||||
instead, which is what certain Ubuntu editions already do. To retain
|
||||
compatibility with systems running older systemd systems a new meson
|
||||
option 'efi-tpm-pcr-compat' has been added (which defaults to false).
|
||||
If enabled, the measurement is done twice: into the new-style PCR 12
|
||||
*and* the old-style PCR 8. It's strongly advised to migrate all users
|
||||
to PCR 12 for this purpose in the long run, as we intend to remove
|
||||
this compatibility feature in two year's time.
|
||||
|
||||
* busctl capture now writes output in the newer pcapng format instead
|
||||
of pcap.
|
||||
|
||||
* An udev rule that imported hwdb matches for USB devices with
|
||||
lowercase hexadecimal vendor/product ID digits was added in systemd
|
||||
250. This has been reverted, since uppercase hexadecimal digits are
|
||||
supposed to be used, and we already had a rule that with the
|
||||
appropriate match.
|
||||
|
||||
Users might need to adjust their local hwdb entries.
|
||||
|
||||
* arch_prctl(2) has been moved to the @default set in the syscall filters
|
||||
(as exposed via the SystemCallFilter= setting in service unit files).
|
||||
It is apparently used by the linker now.
|
||||
|
||||
Changes in the Boot Loader Specification, kernel-install and sd-boot:
|
||||
|
||||
* kernel-install's and bootctl's Boot Loader Specification Type #1
|
||||
entry generation logic has been reworked. The user may now pick
|
||||
explicitly by which "token" string to name the installation's boot
|
||||
entries, via the new /etc/kernel/entry-token file or the new
|
||||
--entry-token= switch to bootctl. By default — as before — the
|
||||
entries are named after the local machine ID. However, in "golden
|
||||
image" environments, where the machine ID shall be initialized on
|
||||
first boot (as opposed to at installation time before first boot) the
|
||||
machine ID will not be available at build time. In this case the
|
||||
--entry-token= switch to bootctl (or the /etc/kernel/entry-token
|
||||
file) may be used to override the "token" for the entries, for
|
||||
example the IMAGE_ID= or ID= fields from /etc/os-release. This will
|
||||
make the OS images independent of any machine ID, and ensure that the
|
||||
images will not carry any identifiable information before first boot,
|
||||
but on the other hand means that multiple parallel installations of
|
||||
the very same image on the same disk cannot be supported.
|
||||
|
||||
Summary: if you are building golden images that shall acquire
|
||||
identity information exclusively on first boot, make sure to both
|
||||
remove /etc/machine-id *and* to write /etc/kernel/entry-token to the
|
||||
value of the IMAGE_ID= or ID= field of /etc/os-release or another
|
||||
suitable identifier before deploying the image.
|
||||
|
||||
* The Boot Loader Specification has been extended with
|
||||
/loader/entries.srel file located in the EFI System Partition (ESP)
|
||||
that disambiguates the format of the entries in the /loader/entries/
|
||||
directory (in order to discern them from incompatible uses of this
|
||||
directory by other projects). For entries that follow the
|
||||
Specification, the string "type1" is stored in this file.
|
||||
|
||||
bootctl will now write this file automatically when installing the
|
||||
systemd-boot boot loader.
|
||||
|
||||
* kernel-install supports a new initrd_generator= setting in
|
||||
/etc/kernel/install.conf, that is exported as
|
||||
$KERNEL_INSTALL_INITRD_GENERATOR to kernel-install plugins. This
|
||||
allows choosing different initrd generators.
|
||||
|
||||
* kernel-install will now create a "staging area" (an initially-empty
|
||||
directory to gather files for a Boot Loader Specification Type #1
|
||||
entry). The path to this directory is exported as
|
||||
$KERNEL_INSTALL_STAGING_AREA to kernel-install plugins, which should
|
||||
drop files there instead of writing them directly to the final
|
||||
location. kernel-install will move them when all files have been
|
||||
prepared successfully.
|
||||
|
||||
* New option sort-key= has been added to the Boot Loader Specification
|
||||
to override the sorting order of the entries in the boot menu. It is
|
||||
read by sd-boot and bootctl, and will be written by kernel-install,
|
||||
with the default value of IMAGE_ID= or ID= fields from
|
||||
os-release. Together, this means that on multiboot installations,
|
||||
entries should be grouped and sorted in a predictable way.
|
||||
|
||||
* The sort order of boot entries has been updated: entries which have
|
||||
the new field sort-key= are sorted by it first, and all entries
|
||||
without it are ordered later. After that, entries are sorted by
|
||||
version so that newest entries are towards the beginning of the list.
|
||||
|
||||
* The kernel-install tool gained a new 'inspect' verb which shows the
|
||||
paths and other settings used.
|
||||
|
||||
* sd-boot can now optionally beep when the menu is shown and menu
|
||||
entries are selected, which can be useful on machines without a
|
||||
working display. (Controllable via a loader.conf setting.)
|
||||
|
||||
* The --make-machine-id-directory= switch to bootctl has been replaced
|
||||
by --make-entry-directory=, given that the entry directory is not
|
||||
necessarily named after the machine ID, but after some other suitable
|
||||
ID as selected via --entry-token= described above. The old name of
|
||||
the option is still understood to maximize compatibility.
|
||||
|
||||
* 'bootctl list' gained support for a new --json= switch to output boot
|
||||
menu entries in JSON format.
|
||||
|
||||
Changes in systemd-homed:
|
||||
|
||||
* Starting with v250 systemd-homed uses UID/GID mapping on the mounts
|
||||
of activated home directories it manages (if the kernel and selected
|
||||
file systems support it). So far it mapped three UID ranges: the
|
||||
range from 0…60000, the user's own UID, and the range 60514…65534,
|
||||
leaving everything else unmapped (in other words, the 16bit UID range
|
||||
is mapped almost fully, with the exception of the UID subrange used
|
||||
for systemd-homed users, with one exception: the user's own UID).
|
||||
Unmapped UIDs may not be used for file ownership in the home
|
||||
directory — any chown() attempts with them will fail. With this
|
||||
release a fourth range is added to these mappings:
|
||||
524288…1879048191. This range is the UID range intended for container
|
||||
uses, see:
|
||||
|
||||
https://systemd.io/UIDS-GIDS
|
||||
|
||||
This range may be used for container managers that place container OS
|
||||
trees in the home directory (which is a questionable approach, for
|
||||
quota, permission, SUID handling and network file system
|
||||
compatibility reasons, but nonetheless apparently commonplace). Note
|
||||
that this mapping is mapped 1:1 in a pass-through fashion, i.e. the
|
||||
UID assignments from the range are not managed or mapped by
|
||||
`systemd-homed`, and must be managed with other mechanisms, in the
|
||||
context of the local system.
|
||||
|
||||
Typically, a better approach to user namespacing in relevant
|
||||
container managers would be to leave container OS trees on disk at
|
||||
UID offset 0, but then map them to a dynamically allocated runtime
|
||||
UID range via another UID mount map at container invocation
|
||||
time. That way user namespace UID ranges become strictly a runtime
|
||||
concept, and do not leak into persistent file systems, persistent
|
||||
user databases or persistent configuration, thus greatly simplifying
|
||||
handling, and improving compatibility with home directories intended
|
||||
to be portable like the ones managed by systemd-homed.
|
||||
|
||||
Changes in shared libraries:
|
||||
|
||||
* A new libsystemd-core-<version>.so private shared library is
|
||||
installed under /usr/lib/systemd/system, mirroring the existing
|
||||
libsystemd-shared-<version>.so library. This allows the total
|
||||
installation size to be reduced by binary code reuse.
|
||||
|
||||
* The <version> tag used in the name of libsystemd-shared.so and
|
||||
libsystemd-core.so can be configured via the meson option
|
||||
'shared-lib-tag'. Distributions may build subsequent versions of the
|
||||
systemd package with unique tags (e.g. the full package version),
|
||||
thus allowing multiple installations of those shared libraries to be
|
||||
available at the same time. This is intended to fix an issue where
|
||||
programs that link to those libraries would fail to execute because
|
||||
they were installed earlier or later than the appropriate version of
|
||||
the library.
|
||||
|
||||
* The sd-id128 API gained a new call sd_id128_to_uuid_string() that is
|
||||
similar to sd_id128_to_string() but formats the ID in RFC 4122 UUID
|
||||
format instead of simple series of hex characters.
|
||||
|
||||
Changes in PID1, systemctl, and systemd-oomd:
|
||||
|
||||
* A new set of service monitor environment variables will be passed to
|
||||
OnFailure=/OnSuccess= handlers, but only if exactly one unit lists the
|
||||
handler unit as OnFailure=/OnSuccess=. The variables are:
|
||||
$MONITOR_SERVICE_RESULT, $MONITOR_EXIT_CODE, $MONITOR_EXIT_STATUS,
|
||||
$MONITOR_INVOCATION_ID and $MONITOR_UNIT. For cases when a single
|
||||
handler needs to watch multiple units, use a templated handler.
|
||||
|
||||
* A new ExtensionDirectories= setting in service unit files allows
|
||||
system extensions to be loaded from a directory. (It is similar to
|
||||
ExtensionImages=, but takes paths to directories, instead of
|
||||
disk image files.)
|
||||
|
||||
'portablectl attach --extension=' now also accepts directory paths.
|
||||
|
||||
* The user.delegate and user.invocation_id extended attributes on
|
||||
cgroups are used in addition to trusted.delegate and
|
||||
trusted.invocation_id. The latter pair requires privileges to set,
|
||||
but the former doesn't and can be also set by the unprivileged user
|
||||
manager.
|
||||
|
||||
(Only supported on kernels ≥5.6.)
|
||||
|
||||
* Units that were killed by systemd-oomd will now have a service result
|
||||
of 'oom-kill'. The number of times a service was killed is tallied
|
||||
in the 'user.oomd_ooms' extended attribute.
|
||||
|
||||
The OOMPolicy= unit file setting is now also honoured by
|
||||
systemd-oomd.
|
||||
|
||||
* In unit files the new %y/%Y specifiers can be used to refer to
|
||||
normalized unit file path, which is particularly useful for symlinked
|
||||
unit files.
|
||||
|
||||
The new %R specifier resolves to the pretty hostname
|
||||
(i.e. PRETTY_HOSTNAME= from /etc/machine-info).
|
||||
|
||||
The new %d specifier resolves to the credentials directory of a
|
||||
service (same as $CREDENTIALS_DIRECTORY).
|
||||
|
||||
* The RootDirectory=, MountAPIVFS=, ExtensionDirectories=,
|
||||
*Capabilities*=, ProtectHome=, *Directory=, TemporaryFileSystem=,
|
||||
PrivateTmp=, PrivateDevices=, PrivateNetwork=, NetworkNamespacePath=,
|
||||
PrivateIPC=, IPCNamespacePath=, PrivateUsers=, ProtectClock=,
|
||||
ProtectKernelTunables=, ProtectKernelModules=, ProtectKernelLogs=,
|
||||
MountFlags= service settings now also work in unprivileged user
|
||||
services, i.e. those run by the user's --user service manager, as long
|
||||
as user namespaces are enabled on the system.
|
||||
|
||||
* Services with Restart=always and a failing ExecCondition= will no
|
||||
longer be restarted, to bring ExecCondition= behaviour in line with
|
||||
Condition*= settings.
|
||||
|
||||
* LoadCredential= now accepts a directory as the argument; all files
|
||||
from the directory will be loaded as credentials.
|
||||
|
||||
* A new D-Bus property ControlGroupId is now exposed on service units,
|
||||
that encapsulates the service's numeric cgroup ID that newer kernels
|
||||
assign to each cgroup.
|
||||
|
||||
* PID 1 gained support for configuring the "pre-timeout" of watchdog
|
||||
devices and the associated governor, via the new
|
||||
RuntimeWatchdogPreSec= and RuntimeWatchdogPreGovernor= configuration
|
||||
options in /etc/systemd/system.conf.
|
||||
|
||||
* systemctl's --timestamp= option gained a new choice "unix", to show
|
||||
timestamp as unix times, i.e. seconds since 1970, Jan 1st.
|
||||
|
||||
* 'systemctl enable' and similar commands will now create relative
|
||||
symlinks in .wants/ and .requires/ and for aliases. Most of the time
|
||||
systemd itself doesn't care, but absolute symlinks were causing wrong
|
||||
behaviour in case of aliases to linked unit files. The change was
|
||||
necessary to fix this aspect. Absolute links are interpreted as
|
||||
before, and it is still possible to create them via other means.
|
||||
|
||||
Changes in systemd-journald:
|
||||
|
||||
* The journal JSON export format has been added to listed of stable
|
||||
interfaces (https://systemd.io/PORTABILITY_AND_STABILITY/).
|
||||
|
||||
* journalctl --list-boots now supports JSON output and the --reverse option.
|
||||
|
||||
* Under docs/: JOURNAL_EXPORT_FORMATS was imported from the wiki and
|
||||
updated, BUILDING_IMAGES is new:
|
||||
|
||||
https://systemd.io/JOURNAL_EXPORT_FORMATS
|
||||
https://systemd.io/BUILDING_IMAGES
|
||||
|
||||
Changes in udev:
|
||||
|
||||
* Two new hwdb files have been added. One lists "handhelds" (PDAs,
|
||||
calculators, etc.), the other AV production devices (DJ tables,
|
||||
keypads, etc.) that should accessible to the seat owner user by
|
||||
default.
|
||||
|
||||
* udevadm trigger gained a new --prioritized-subsystem= option to
|
||||
process certain subsystems (and all their parent devices) earlier.
|
||||
|
||||
systemd-udev-trigger.service now uses this new option to trigger
|
||||
block and TPM devices first, hopefully making the boot a bit faster.
|
||||
|
||||
* udevadm trigger now implements --type=all, --initialized-match,
|
||||
--initialized-nomatch to trigger both subsystems and devices, only
|
||||
already-initialized devices, and only devices which haven't been
|
||||
initialized yet, respectively.
|
||||
|
||||
* .link files gained support for setting MDI/MID-X on a link.
|
||||
|
||||
* .link files gained support for [Match] Firmware= setting to match on
|
||||
the device firmware description string. By mistake, it was previously
|
||||
only supported in .network files.
|
||||
|
||||
* .link files gained support for [Link] SR-IOVVirtualFunctions= setting
|
||||
and [SR-IOV] section to configure SR-IOV virtual functions.
|
||||
|
||||
Changes in systemd-networkd:
|
||||
|
||||
* The default scope for unicast routes configured through [Route]
|
||||
section is changed to "link", to make the behavior consistent with
|
||||
"ip route" command. The manual configuration of [Route] Scope= is
|
||||
still honored.
|
||||
|
||||
* A new unit systemd-networkd-wait-online@<interface>.service has been
|
||||
added that can be used to wait for a specific network interface to be
|
||||
up.
|
||||
|
||||
* systemd-networkd gained a new [Bridge] Isolated=true|false setting
|
||||
that configures the eponymous kernel attribute on the bridge.
|
||||
|
||||
* .netdev files now can be used to create virtual WLAN devices, and
|
||||
configure various settings on them, via the [WLAN] section.
|
||||
|
||||
* .link/.network files gained support for [Match] Kind= setting to match
|
||||
on device kind ("bond", "bridge", "gre", "tun", "veth", etc.)
|
||||
|
||||
This value is also shown by 'networkctl status'.
|
||||
|
||||
* The Local= setting in .netdev files for various virtual network
|
||||
devices gained support for specifying, in addition to the network
|
||||
address, the name of a local interface which must have the specified
|
||||
address.
|
||||
|
||||
* systemd-networkd gained a new [Tunnel] External= setting in .netdev
|
||||
files, to configure tunnels in external mode (a.k.a. collect metadata
|
||||
mode).
|
||||
|
||||
* [Network] L2TP= setting was removed. Please use interface specifier in
|
||||
Local= setting in .netdev files of corresponding L2TP interface.
|
||||
|
||||
* New [DHCPServer] BootServerName=, BootServerAddress=, and
|
||||
BootFilename= settings can be used to configure the server address,
|
||||
server name, and file name sent in the DHCP packet (e.g. to configure
|
||||
PXE boot).
|
||||
|
||||
Changes in systemd-resolved:
|
||||
|
||||
* systemd-resolved is started earlier (in sysinit.target), so it
|
||||
available earlier and will also be started in the initrd if installed
|
||||
there.
|
||||
|
||||
Changes in disk encryption:
|
||||
|
||||
* systemd-cryptenroll can now control whether to require the user to
|
||||
enter a PIN when using TPM-based unlocking of a volume via the new
|
||||
--tpm2-with-pin= option.
|
||||
|
||||
Option tpm2-pin= can be used in /etc/crypttab.
|
||||
|
||||
* When unlocking devices via TPM, TPM2 parameter encryption is now
|
||||
used, to ensure that communication between CPU and discrete TPM chips
|
||||
cannot be eavesdropped to acquire disk encryption keys.
|
||||
|
||||
Changes in systemd-hostnamed:
|
||||
|
||||
* HARDWARE_VENDOR= and HARDWARE_MODEL= can be set in /etc/machine-info
|
||||
to override the values gleaned from the hwdb.
|
||||
|
||||
* A ID_CHASSIS property can be set in the hwdb (for the DMI device
|
||||
/sys/class/dmi/id) to override the chassis that is reported by
|
||||
hostnamed.
|
||||
|
||||
* hostnamed's D-Bus interface gained a new method GetHardwareSerial()
|
||||
for reading the hardware serial number, as reportd by DMI.
|
||||
|
||||
Changes in other components:
|
||||
|
||||
* /etc/locale.conf is now populated through tmpfiles.d factory /etc/
|
||||
handling with the values that were configured during systemd build
|
||||
(if /etc/locale.conf has not been created through some other
|
||||
mechanism). This means that /etc/locale.conf should always have
|
||||
reasonable contents and we avoid a potential mismatch in defaults.
|
||||
|
||||
* The userdbctl tool will now show UID range information as part of the
|
||||
list of known users.
|
||||
|
||||
* A new build-time configuration setting default-user-shell= can be
|
||||
used to set the default shell for user records and nspawn shell
|
||||
invocations (instead of of the default /bin/bash).
|
||||
|
||||
Experimental features:
|
||||
|
||||
* sd-boot gained a new *experimental* setting "reboot-for-bitlocker" in
|
||||
loader.conf that implements booting Microsoft Windows from the
|
||||
sd-boot in a way that first reboots the system, to reset the TPM
|
||||
PCRs. This improves compatibility with BitLocker's TPM use, as the
|
||||
PCRs will only record the Windows boot process, and not sd-boot
|
||||
itself, thus retaining the PCR measurements not involving sd-boot.
|
||||
Note that this feature is experimental for now, and is likely going
|
||||
to be generalized and renamed in a future release, without retaining
|
||||
compatibility with the current implementation.
|
||||
|
||||
* A new systemd-sysupdate component has been added that automatically
|
||||
discovers, downloads, and installs A/B-style updates for the host
|
||||
installation itself, or container images, portable service images,
|
||||
and other assets. See the new systemd-sysupdate man page for updates.
|
||||
|
||||
Contributions from: 4piu, Adam Williamson, adrian5, Albert Brox,
|
||||
AlexCatze, Alfonso Sánchez-Beato, Alvin Šipraga, Andrea Pappacoda,
|
||||
Andy Chi, Anita Zhang, Antonio Alvarez Feijoo,
|
||||
Arfrever Frehtes Taifersar Arahesis, ash, Bastien Nocera, Be,
|
||||
bearhoney, Benjamin Berg, Christian Brauner, Clyde Byrd III,
|
||||
Curtis Klein, Daan De Meyer, Danilo Krummrich, David, David Bond,
|
||||
Davide Cavalca, David Tardon, dependabot[bot], Donald Chan,
|
||||
Dorian Clay, Eduard Tolosa, Erik Sjölund, Evgeny Vereshchagin,
|
||||
Federico Ceratto, Franck Bui, Frantisek Sumsal, Gaël PORTAY,
|
||||
Georges Basile Stavracas Neto, Goffredo Baroncelli, Grigori Goronzy,
|
||||
Hans de Goede, Heiko Becker, Hugo Carvalho, James Hilliard,
|
||||
Jan Janssen, Jason A. Donenfeld, Joan Bruguera, Joerie de Gram,
|
||||
Josh Triplett, Julia Kartseva, ksa678491784, Lan Tian, Laura Barcziova,
|
||||
Lennart Poettering, Leviticoh, licunlong, Lidong Zhong, lincoln auster,
|
||||
Lubomir Rintel, Luca Boccassi, Luca BRUNO, Ludwig Nussel,
|
||||
Marcel Hellwig, march1993, Marco Scardovi, Markus Weippert,
|
||||
Martin Wilck, Matija Skala, Matthias Lisin, Matt Walton, Max Gautier,
|
||||
Michael Biebl, Michael Olbrich, Michal Koutný, Mike Gilbert,
|
||||
Morten Linderud, Nishal Kulkarni, Noel Kuntze, Peter Hutterer,
|
||||
Peter Morrow, Pigmy-penguin, prumian, Richard Neill,
|
||||
Rike-Benjamin Schuppner, Romain Naour, Ruben Kerkhof, Ryan Hendrickson,
|
||||
Santa Wiryaman, Seth Falco, Stephen Hemminger, tawefogo,
|
||||
Temuri Doghonadze, Thomas Batten, Thomas Haller, Tobias Stoeckmann,
|
||||
Tyson Whitehead, Vishal Chillara Srinivas, Vivien Didelot, Weblate,
|
||||
Xiaotian Wu, yangmingtai, YmrDtnJu, Yonathan Randolph, Yu Watanabe,
|
||||
Zbigniew Jędrzejewski-Szmek, наб
|
||||
|
||||
— Warsaw, 2022-03---
|
||||
|
||||
CHANGES WITH 250:
|
||||
|
||||
* Support for encrypted and authenticated credentials has been added.
|
||||
@ -100,9 +547,9 @@ CHANGES WITH 250:
|
||||
time-out for the boot.
|
||||
|
||||
* A new setting DefaultOOMScoreAdjust= is now supported in
|
||||
/etc/systemd/system.conf + /etc/systemd/user.conf that may be used to
|
||||
set the default process OOM score adjustment value for processes
|
||||
forked off the service manager. For per-user service managers this
|
||||
/etc/systemd/system.conf and /etc/systemd/user.conf. It may be used
|
||||
to set the default process OOM score adjustment value for processes
|
||||
started by the service manager. For per-user service managers this
|
||||
now defaults to 100, but for per-system service managers is left as
|
||||
is. This means that by default now services forked off the user
|
||||
service manager are more likely to be killed by the OOM killer than
|
||||
@ -145,7 +592,7 @@ CHANGES WITH 250:
|
||||
ProtectKernelLogs=yes can now be used.
|
||||
|
||||
* The default maximum numbers of inodes have been raised from 64k to 1M
|
||||
for /dev, and from 400k to 1M for /tmp.
|
||||
for /dev/, and from 400k to 1M for /tmp/.
|
||||
|
||||
* The per-user service manager learnt support for communicating with
|
||||
systemd-oomd to acquire OOM kill information.
|
||||
@ -271,36 +718,6 @@ CHANGES WITH 250:
|
||||
monotonic clock even without RTC hardware and with some robustness
|
||||
against abnormal system shutdown.
|
||||
|
||||
* .network files gained a new UplinkInterface in the [IPv6SendRA]
|
||||
section, for automatically propagating DNS settings from other
|
||||
interfaces.
|
||||
|
||||
* The static lease DHCP server logic in systemd-networkd may now serve
|
||||
IP addresses outside of the configured IP pool range for the server.
|
||||
|
||||
* CAN support in systemd-networkd gained four new settings Loopback=,
|
||||
OneShot=, PresumeAck=, ClassicDataLengthCode= for tweaking CAN
|
||||
control modes. It gained a number of further settings for tweaking
|
||||
CAN timing quanta.
|
||||
|
||||
* The [CAN] section in .network file gained new TimeQuantaNSec=,
|
||||
PropagationSegment=, PhaseBufferSegment1=, PhaseBufferSegment2=,
|
||||
SyncJumpWidth=, DataTimeQuantaNSec=, DataPropagationSegment=,
|
||||
DataPhaseBufferSegment1=, DataPhaseBufferSegment2=, and
|
||||
DataSyncJumpWidth= settings to control bit-timing processed by the
|
||||
CAN interface.
|
||||
|
||||
* DHCPv4 client support in systemd-networkd learnt a new Label= option
|
||||
for configuring the address label to apply to configure IPv4
|
||||
addresses.
|
||||
|
||||
* The various systemd-udevd "ethtool" buffer settings now understand
|
||||
the special value "max" to configure the buffers to the maximum the
|
||||
hardware supports.
|
||||
|
||||
* systemd-udevd's .link files may now configure a large variety of
|
||||
NIC coalescing settings, plus more hardware offload settings.
|
||||
|
||||
* systemd-analyze verify gained support for a pair of new --image= +
|
||||
--root= switches for verifying units below a specific root
|
||||
directory/image instead of on the host.
|
||||
@ -331,7 +748,7 @@ CHANGES WITH 250:
|
||||
non-essential output. It's honored by the "dot", "syscall-filter",
|
||||
"filesystems" commands.
|
||||
|
||||
* systemd-analyze security gained a --profile option that can be used
|
||||
* systemd-analyze security gained a --profile= option that can be used
|
||||
to take into account a portable profile when analyzing portable
|
||||
services, since a lot of the security-related settings are enabled
|
||||
through them.
|
||||
@ -341,40 +758,33 @@ CHANGES WITH 250:
|
||||
including the build-id and other info described on:
|
||||
https://systemd.io/COREDUMP_PACKAGE_METADATA/
|
||||
|
||||
* .network files gained a new UplinkInterface= in the [IPv6SendRA]
|
||||
section, for automatically propagating DNS settings from other
|
||||
interfaces.
|
||||
|
||||
* The static lease DHCP server logic in systemd-networkd may now serve
|
||||
IP addresses outside of the configured IP pool range for the server.
|
||||
|
||||
* CAN support in systemd-networkd gained four new settings Loopback=,
|
||||
OneShot=, PresumeAck=, ClassicDataLengthCode= for tweaking CAN
|
||||
control modes. It gained a number of further settings for tweaking
|
||||
CAN timing quanta.
|
||||
|
||||
* The [CAN] section in .network file gained new TimeQuantaNSec=,
|
||||
PropagationSegment=, PhaseBufferSegment1=, PhaseBufferSegment2=,
|
||||
SyncJumpWidth=, DataTimeQuantaNSec=, DataPropagationSegment=,
|
||||
DataPhaseBufferSegment1=, DataPhaseBufferSegment2=, and
|
||||
DataSyncJumpWidth= settings to control bit-timing processed by the
|
||||
CAN interface.
|
||||
|
||||
* DHCPv4 client support in systemd-networkd learnt a new Label= option
|
||||
for configuring the address label to apply to configure IPv4
|
||||
addresses.
|
||||
|
||||
* The [IPv6AcceptRA] section of .network files gained support for a new
|
||||
UseMTU= setting that may be used to control whether to apply the
|
||||
announced MTU settings to the local interface.
|
||||
|
||||
* systemd-networkd now ships with new default .network files:
|
||||
80-container-vb.network which matches host-side network bridge device
|
||||
created by systemd-nspawn's --network-bridge or --network-zone
|
||||
switch, and 80-6rd-tunnel.network which matches automatically created
|
||||
sit tunnel with 6rd prefix when the DHCP 6RD option is received.
|
||||
|
||||
* systemd-networkd and systemd-udevd now support IP over InfiniBand
|
||||
interfaces. The Kind= setting in .netdev file accepts "ipoib". And
|
||||
systemd.netdev files gained the [IPoIB] section.
|
||||
|
||||
* systemd-networkd and systemd-udevd now support net.ifname-policy=
|
||||
option on the kernel command-line. This is implemented through the
|
||||
systemd-network-generator service that automatically generates
|
||||
appropriate .link, .network, and .netdev files.
|
||||
|
||||
* systemd-networkd's handling of Endpoint= resolution for WireGuard
|
||||
interfaces has been improved.
|
||||
|
||||
* systemd-networkd will now automatically configure routes to addresses
|
||||
specified in AllowedIPs=. This feature can be controlled via RouteTable=
|
||||
and RouteMetric= settings in [WireGuard] or [WireGuardPeer] sections.
|
||||
|
||||
* systemd-networkd will now once again automatically generate persistent
|
||||
MAC addresses for batadv and bridge interfaces. Users can disable this
|
||||
by using MACAddress=none in .netdev files.
|
||||
|
||||
* .link files gained a new WakeOnLanPassword= setting in the [Link]
|
||||
section that allows to specify a WoL "SecureOn" password on hardware
|
||||
that supports this.
|
||||
|
||||
* The [DHCPv4] section in .network file gained a new Use6RD= boolean
|
||||
setting to control whether the DHCPv4 client request and process the
|
||||
DHCP 6RD option.
|
||||
@ -395,17 +805,12 @@ CHANGES WITH 250:
|
||||
whether to use the relevant fields from the IPv6 Router Advertisement
|
||||
records.
|
||||
|
||||
* The ForceDHCPv6PDOtherInformation= setting in the [DHCPv6] section is
|
||||
now deprecated. Please use the WithoutRA= and UseDelegatedPrefix=
|
||||
* The ForceDHCPv6PDOtherInformation= setting in the [DHCPv6] section
|
||||
has been removed. Please use the WithoutRA= and UseDelegatedPrefix=
|
||||
settings in the [DHCPv6] section and the DHCPv6Client= setting in the
|
||||
[IPv6AcceptRA] section to control when the DHCPv6 client is started
|
||||
and how the delegated prefixes are handled by the DHCPv6 client.
|
||||
|
||||
* The [CAKE] section of .network files gained various new settings
|
||||
AutoRateIngress=, CompensationMode=, FlowIsolationMode=, NAT=,
|
||||
MPUBytes=, PriorityQueueingPreset=, FirewallMark=, Wash=, SplitGSO=,
|
||||
and UseRawPacketSize= for configuring CAKE.
|
||||
|
||||
* The IPv6Token= section in the [Network] section is deprecated, and
|
||||
the [IPv6AcceptRA] section gained the Token= setting for its
|
||||
replacement. The [IPv6Prefix] section also gained the Token= setting.
|
||||
@ -425,6 +830,49 @@ CHANGES WITH 250:
|
||||
* The [DHCPServer] section of .network file gained a new Router=
|
||||
setting to specify the router address.
|
||||
|
||||
* The [CAKE] section of .network files gained various new settings
|
||||
AutoRateIngress=, CompensationMode=, FlowIsolationMode=, NAT=,
|
||||
MPUBytes=, PriorityQueueingPreset=, FirewallMark=, Wash=, SplitGSO=,
|
||||
and UseRawPacketSize= for configuring CAKE.
|
||||
|
||||
* systemd-networkd now ships with new default .network files:
|
||||
80-container-vb.network which matches host-side network bridge device
|
||||
created by systemd-nspawn's --network-bridge or --network-zone
|
||||
switch, and 80-6rd-tunnel.network which matches automatically created
|
||||
sit tunnel with 6rd prefix when the DHCP 6RD option is received.
|
||||
|
||||
* systemd-networkd's handling of Endpoint= resolution for WireGuard
|
||||
interfaces has been improved.
|
||||
|
||||
* systemd-networkd will now automatically configure routes to addresses
|
||||
specified in AllowedIPs=. This feature can be controlled via
|
||||
RouteTable= and RouteMetric= settings in [WireGuard] or
|
||||
[WireGuardPeer] sections.
|
||||
|
||||
* systemd-networkd will now once again automatically generate persistent
|
||||
MAC addresses for batadv and bridge interfaces. Users can disable this
|
||||
by using MACAddress=none in .netdev files.
|
||||
|
||||
* systemd-networkd and systemd-udevd now support IP over InfiniBand
|
||||
interfaces. The Kind= setting in .netdev file accepts "ipoib". And
|
||||
systemd.netdev files gained the [IPoIB] section.
|
||||
|
||||
* systemd-networkd and systemd-udevd now support net.ifname-policy=
|
||||
option on the kernel command-line. This is implemented through the
|
||||
systemd-network-generator service that automatically generates
|
||||
appropriate .link, .network, and .netdev files.
|
||||
|
||||
* The various systemd-udevd "ethtool" buffer settings now understand
|
||||
the special value "max" to configure the buffers to the maximum the
|
||||
hardware supports.
|
||||
|
||||
* systemd-udevd's .link files may now configure a large variety of
|
||||
NIC coalescing settings, plus more hardware offload settings.
|
||||
|
||||
* .link files gained a new WakeOnLanPassword= setting in the [Link]
|
||||
section that allows to specify a WoL "SecureOn" password on hardware
|
||||
that supports this.
|
||||
|
||||
* systemd-nspawn's --setenv= switch now supports an additional syntax:
|
||||
if only a variable name is specified (i.e. without being suffixed by
|
||||
a '=' character and a value) the current value of the environment
|
||||
@ -522,15 +970,13 @@ CHANGES WITH 250:
|
||||
may be used to set the boot menu time-out of the boot loader (for all
|
||||
or just the subsequent boot).
|
||||
|
||||
* bootctl and kernel-install will now read KERNEL_INSTALL_MACHINE_ID
|
||||
and KERNEL_INSTALL_LAYOUT from kernel/install.conf. The first
|
||||
variable specifies the machine-id to use for installation. It would
|
||||
previously be used if set in the environment, and now it'll also be
|
||||
read automatically from the config file. The second variable is new.
|
||||
When set, it specifies the layout to use for installation directories
|
||||
on the boot partition, so that tools don't need to guess it based on
|
||||
the already-existing directories. The only value that is defined
|
||||
natively is "bls", corresponding to the layout specified in
|
||||
* bootctl and kernel-install will now read variables
|
||||
KERNEL_INSTALL_LAYOUT= from /etc/machine-info and layout= from
|
||||
/etc/kernel/install.conf. When set, it specifies the layout to use
|
||||
for installation directories on the boot partition, so that tools
|
||||
don't need to guess it based on the already-existing directories. The
|
||||
only value that is defined natively is "bls", corresponding to the
|
||||
layout specified in
|
||||
https://systemd.io/BOOT_LOADER_SPECIFICATION/. Plugins for
|
||||
kernel-install that implement a different layout can declare other
|
||||
values for this variable.
|
||||
@ -12359,7 +12805,7 @@ CHANGES WITH 197:
|
||||
based on a calendar time specification such as "Thu,Fri
|
||||
2013-*-1,5 11:12:13" which refers to 11:12:13 of the first
|
||||
or fifth day of any month of the year 2013, given that it is
|
||||
a thursday or friday. This brings timer event support
|
||||
a Thursday or a Friday. This brings timer event support
|
||||
considerably closer to cron's capabilities. For details on
|
||||
the supported calendar time specification language see
|
||||
systemd.time(7).
|
||||
|
4
README
4
README
@ -30,7 +30,7 @@ LICENSE:
|
||||
LGPL-2.1-or-later for all code, exceptions noted in LICENSES/README.md
|
||||
|
||||
REQUIREMENTS:
|
||||
Linux kernel >= 3.13
|
||||
Linux kernel >= 3.15
|
||||
Linux kernel >= 4.2 for unified cgroup hierarchy support
|
||||
Linux kernel >= 4.10 for cgroup-bpf egress and ingress hooks
|
||||
Linux kernel >= 4.15 for cgroup-bpf device hook
|
||||
@ -88,7 +88,7 @@ REQUIREMENTS:
|
||||
CONFIG_{TMPFS,EXT4_FS,XFS,BTRFS_FS,...}_POSIX_ACL
|
||||
CONFIG_SECCOMP
|
||||
CONFIG_SECCOMP_FILTER (required for seccomp support)
|
||||
CONFIG_CHECKPOINT_RESTORE (for the kcmp() syscall)
|
||||
CONFIG_KCMP (for the kcmp() syscall, used to be under CONFIG_CHECKPOINT_RESTORE before ~5.12)
|
||||
|
||||
Required for CPUShares= in resource control unit settings
|
||||
CONFIG_CGROUP_SCHED
|
||||
|
105
TODO
105
TODO
@ -78,6 +78,52 @@ Janitorial Clean-ups:
|
||||
|
||||
Features:
|
||||
|
||||
* improve scope units to support creation by pidfd instead of by PID
|
||||
|
||||
* deprecate cgroupsv1 (i.e. taint system with it, print log message at boot)
|
||||
|
||||
* systemd-dissect: add --cat switch for dumping files such as /etc/os-release
|
||||
|
||||
* per-service sandboxing option: ProtectIds=. If used, will overmount
|
||||
/etc/machine-id and /proc/sys/kernel/random/boot_id with synthetic files, to
|
||||
make it harder for the service to identify the host. Depending on the user
|
||||
setting it should be fully randomized at invocation time, or a hash of the
|
||||
real thing, keyed by the unit name or so. Of course, there are other ways to
|
||||
get these IDs (e.g. journal) or similar ids (e.g. MAC addresses, DMI ids, CPU
|
||||
ids), so this knob would only be useful in combination with other lockdown
|
||||
options. Particularly useful for portable services, and anything else that
|
||||
uses RootDirectory= or RootImage=. (Might also over-mount
|
||||
/sys/class/dmi/id/*{uuid,serial} with /dev/null).
|
||||
|
||||
* journalctl/timesyncd: whenever timesyncd acquires a synchronization from NTP,
|
||||
create a structured log entry that contains boot ID, monotonic clock and
|
||||
realtime clock (I mean, this requires no special work, as these three fields
|
||||
are implicit). Then in journalctl when attempting to display the realtime
|
||||
timestamp of a log entry, first search for the closest later log entry
|
||||
of this kinda that has a matching boot id, and convert the monotonic clock
|
||||
timestamp of the entry to the realtime clock using this info. This way we can
|
||||
retroactively correct the wallclock timestamps, in particular for systems
|
||||
without RTC, i.e. where initially wallclock timestamps carry rubbish, until
|
||||
an NTP sync is acquired.
|
||||
|
||||
* kernel-install:
|
||||
- add --all switch for rerunning kernel-install for all installed kernels
|
||||
- maybe add env var that shortcuts kernel-install for installers that want to
|
||||
call it at the end only
|
||||
|
||||
* doc: prep a document explaining resolved's internal objects, i.e. Query
|
||||
vs. Question vs. Transaction vs. Stream and so on.
|
||||
|
||||
* doc: prep a document explaining PID 1's internal logic, i.e. transactions,
|
||||
jobs, units
|
||||
|
||||
* bootspec: remove tries counter from boot entry ids
|
||||
|
||||
* bootspec: bring UEFI and userspace enumeration of bootspec entries back into
|
||||
sync, i.e. parse out tries in both
|
||||
|
||||
* automatically ignore threaded cgroups in cg_xyz().
|
||||
|
||||
* add linker script that implicitly adds symbol for build ID and new coredump
|
||||
json package metadata, and use that when logging
|
||||
|
||||
@ -215,21 +261,33 @@ Features:
|
||||
|
||||
* rework recursive read-only remount to use new mount API
|
||||
|
||||
* PAM: pick auf one authentication token from credentials
|
||||
|
||||
* tpm2: figure out if we need to do anything for TPM2 parameter encryption? And
|
||||
if so, what precisely?
|
||||
* PAM: pick up authentication token from credentials
|
||||
|
||||
* when mounting disk images: if IMAGE_ID/IMAGE_VERSION is set in os-release
|
||||
data in the image, make sure the image filename actually matches this, so
|
||||
that images cannot be misused.
|
||||
|
||||
* New udev block device symlink names:
|
||||
/dev/disk/by-parttypelabel/<pttype>/<ptlabel>. Use case: if pt label is used
|
||||
/dev/disk/by-parttypelabel/<pttype>-<ptlabel>. Use case: if pt label is used
|
||||
as partition image version string, this is a safe way to reference a specific
|
||||
version of a specific partition type, in particular where related partitions
|
||||
are processed (e.g. verity + rootfs both named "LennartOS_0.7").
|
||||
|
||||
* sysupdate:
|
||||
- add fuzzing to the pattern parser
|
||||
- support casync as download mechanism
|
||||
- direct TPM2 PCR change handling, possible renrolling LUKS2 media if needed.
|
||||
- "systemd-sysupdate update --all" support, that iterates through all components
|
||||
defined on the host, plus all images installed into /var/lib/machines/,
|
||||
/var/lib/portable/ and so on.
|
||||
- figure out what to do about system extensions (i.e. they need to imply an
|
||||
update component, since otherwise system extenion' sysupdate.d/ files would
|
||||
override the host's update files.)
|
||||
- Allow invocation with a single transfer definition, i.e. with
|
||||
--definitions= pointing to a file rather than a dir.
|
||||
- add ability to disable implicit decompression of downloaded artifacts,
|
||||
i.e. a Compress=no option in the transfer definitions
|
||||
|
||||
* in sd-id128: also parse UUIDs in RFC4122 URN syntax (i.e. chop off urn:uuid: prefix)
|
||||
|
||||
* DynamicUser= + StateDirectory= → use uid mapping mounts, too, in order to
|
||||
@ -272,9 +330,6 @@ Features:
|
||||
* importd: support image signature verification with PKCS#7 + OpenBSD signify
|
||||
logic, as alternative to crummy gpg
|
||||
|
||||
* sysext: optionally, if the merged trees allow it use bind mounts instead of
|
||||
overlayfs
|
||||
|
||||
* add "systemd-analyze debug" + AttachDebugger= in unit files: The former
|
||||
specifies a command to execute; the latter specifies that an already running
|
||||
"systemd-analyze debug" instance shall be contacted and execution paused
|
||||
@ -303,16 +358,9 @@ Features:
|
||||
- make gatwayd/remote read key via creds logic
|
||||
- add sd_notify() command for flushing out creds not needed anymore
|
||||
|
||||
* teach LoadCredential= the ability to load all files from a specified dir as
|
||||
individual creds
|
||||
|
||||
* add tpm.target or so which is delayed until TPM2 device showed up in case
|
||||
firmware indicates there is one.
|
||||
|
||||
* tpm2: support a PIN policy, i.e. allowing windows-style short authentication
|
||||
passwords by using the TPM2 to enforce ratelimiting and such, use for
|
||||
cryptsetup and homed
|
||||
|
||||
* Add concept for upgrading TPM2 enrollments, maybe a new switch
|
||||
--pcrs=4:<hash> or so, i.e. select a PCR to include in the hash, and then
|
||||
override its hash
|
||||
@ -417,8 +465,6 @@ Features:
|
||||
* seccomp: don't install filters for ABIs that are masked anyway for the
|
||||
specific service
|
||||
|
||||
* seccomp: maybe merge all filters we install into one with that libseccomp API that allows merging.
|
||||
|
||||
* busctl: maybe expose a verb "ping" for pinging a dbus service to see if it
|
||||
exists and responds.
|
||||
|
||||
@ -598,9 +644,7 @@ Features:
|
||||
selected user is resolvable in the service even if it ships its own /etc/passwd)
|
||||
|
||||
* Fix DECIMAL_STR_MAX or DECIMAL_STR_WIDTH. One includes a trailing NUL, the
|
||||
other doesn't. What a disaster. Probably to exclude it. Also
|
||||
DECIMAL_STR_WIDTH should probably add an extra "-" into account for negative
|
||||
numbers.
|
||||
other doesn't. What a disaster. Probably to exclude it.
|
||||
|
||||
* Check that users of inotify's IN_DELETE_SELF flag are using it properly, as
|
||||
usually IN_ATTRIB is the right way to watch deleted files, as the former only
|
||||
@ -700,7 +744,7 @@ Features:
|
||||
* beef up pam_systemd to take unit file settings such as cgroups properties as
|
||||
parameters
|
||||
|
||||
* maybe hook of xfs/ext4 quotactl() with services? i.e. automatically manage
|
||||
* maybe hook up xfs/ext4 quotactl() with services? i.e. automatically manage
|
||||
the quota of the user indicated in User= via unit file settings, like the
|
||||
other resource management concepts. Would mix nicely with DynamicUser=1. Or
|
||||
alternatively, do this with projids, so that we can also cover services
|
||||
@ -723,10 +767,6 @@ Features:
|
||||
|
||||
ReadWritePaths=:/var/lib/foobar
|
||||
|
||||
* hostnamed: populate form factor data from a new hwdb database, so that old
|
||||
yogas can be recognized as "convertible" too, even if they predate the DMI
|
||||
"convertible" form factor
|
||||
|
||||
* Add ExecMonitor= setting. May be used multiple times. Forks off a process in
|
||||
the service cgroup, which is supposed to monitor the service, and when it
|
||||
exits the service is considered failed by its monitor.
|
||||
@ -801,8 +841,6 @@ Features:
|
||||
|
||||
* when we detect that there are waiting jobs but no running jobs, do something
|
||||
|
||||
* 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)
|
||||
|
||||
* there's probably something wrong with having user mounts below /sys,
|
||||
@ -994,8 +1032,7 @@ Features:
|
||||
- add verification of [Install] section to systemd-analyze verify
|
||||
|
||||
* timer units:
|
||||
- timer units should get the ability to trigger when:
|
||||
o DST changes
|
||||
- timer units should get the ability to trigger when DST changes
|
||||
- Modulate timer frequency based on battery state
|
||||
|
||||
* add libsystemd-password or so to query passwords during boot using the password agent logic
|
||||
@ -1006,8 +1043,6 @@ Features:
|
||||
|
||||
* make repeated alt-ctrl-del presses printing a dump
|
||||
|
||||
* hostnamed: before returning information from /etc/machine-info.conf check the modification data and reread. Similar for localed, ...
|
||||
|
||||
* currently x-systemd.timeout is lost in the initrd, since crypttab is copied into dracut, but fstab is not
|
||||
|
||||
* add a pam module that passes the hdd passphrase into the PAM stack and then expires it, for usage by gdm auto-login.
|
||||
@ -1126,6 +1161,10 @@ Features:
|
||||
- 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
|
||||
- bootspec: properly support boot attempt counters when parsing entry file names
|
||||
|
||||
* kernel-install:
|
||||
- optionally, support generating type #2 entries instead of type #1, including signing them
|
||||
|
||||
* logind:
|
||||
- logind: optionally, ignore idle-hint logic for autosuspend, block suspend as long as a session is around
|
||||
@ -1312,6 +1351,10 @@ Features:
|
||||
can easily set overall quota for all users
|
||||
- on login, if we can't fallocate initially, but rebalance is on, then allow
|
||||
login in discard mode, then immediately rebalance, then turn off discard
|
||||
- extend user records with optional "bulk" data. Specifically, a user
|
||||
avatar/photo or so. This data should be stored along with the user record,
|
||||
but probably shouldn't be part of the record itself, since it might be
|
||||
large.
|
||||
|
||||
* add a new switch --auto-definitions=yes/no or so to systemd-repart. If
|
||||
specified, synthesize a definition automatically if we can: enlarge last
|
||||
|
@ -18,7 +18,7 @@ support_url = get_option('support-url')
|
||||
support_sed = 's~%SUPPORT_URL%~@0@~'.format(support_url)
|
||||
|
||||
foreach file : in_files
|
||||
custom_target(
|
||||
catalogs += custom_target(
|
||||
file,
|
||||
input : file + '.in',
|
||||
output: file,
|
||||
|
@ -526,3 +526,11 @@ be updated to operate in a hotplug fashion without depending on
|
||||
systemd-udev-settle.service:
|
||||
|
||||
@OFFENDING_UNITS@
|
||||
|
||||
-- 7c8a41f37b764941a0e1780b1be2f037
|
||||
Subject: Initial clock synchronization
|
||||
Defined-By: systemd
|
||||
Support: %SUPPORT_URL%
|
||||
|
||||
For the first time during the current boot an NTP synchronization has been
|
||||
acquired and the local system clock adjustment has been initiated.
|
||||
|
@ -165,7 +165,7 @@
|
||||
} while (false)
|
||||
|
||||
#define LIST_JUST_US(name,item) \
|
||||
(!(item)->name##_prev && !(item)->name##_next) \
|
||||
(!(item)->name##_prev && !(item)->name##_next)
|
||||
#define LIST_FOREACH(name,i,head) \
|
||||
for ((i) = (head); (i); (i) = (i)->name##_next)
|
||||
#define LIST_FOREACH_SAFE(name,i,n,head) \
|
||||
|
13
coccinelle/mempcpy.cocci
Normal file
13
coccinelle/mempcpy.cocci
Normal file
@ -0,0 +1,13 @@
|
||||
/* SPDX-License-Identifier: LGPL-2.1-or-later */
|
||||
@@
|
||||
expression x, y, z;
|
||||
@@
|
||||
- memcpy(x, y, z);
|
||||
- x += z;
|
||||
+ x = mempcpy(x, y, z);
|
||||
@@
|
||||
expression x, y, z;
|
||||
@@
|
||||
- memcpy_safe(x, y, z);
|
||||
- x += z;
|
||||
+ x = mempcpy_safe(x, y, z);
|
73
coccinelle/timestamp-is-set.cocci
Normal file
73
coccinelle/timestamp-is-set.cocci
Normal file
@ -0,0 +1,73 @@
|
||||
/* SPDX-License-Identifier: LGPL-2.1-or-later */
|
||||
@@
|
||||
expression x;
|
||||
constant USEC_INFINITY = USEC_INFINITY;
|
||||
/* We want to stick with the literal expression in the implementation of timestamp_is_set(), i.e. in time-util.c */
|
||||
position p : script:python() { p[0].file != "src/basic/time-util.h" };
|
||||
@@
|
||||
(
|
||||
- x > 0 && x < USEC_INFINITY
|
||||
+ timestamp_is_set(x)
|
||||
|
|
||||
- x < USEC_INFINITY && x > 0
|
||||
+ timestamp_is_set(x)
|
||||
|
|
||||
- x@p > 0 && x != USEC_INFINITY
|
||||
+ timestamp_is_set(x)
|
||||
|
|
||||
- x != USEC_INFINITY && x > 0
|
||||
+ timestamp_is_set(x)
|
||||
|
|
||||
- x != 0 && x < USEC_INFINITY
|
||||
+ timestamp_is_set(x)
|
||||
|
|
||||
- x < USEC_INFINITY && x != 0
|
||||
+ timestamp_is_set(x)
|
||||
|
|
||||
- x != 0 && x != USEC_INFINITY
|
||||
+ timestamp_is_set(x)
|
||||
|
|
||||
- x != USEC_INFINITY && x != 0
|
||||
+ timestamp_is_set(x)
|
||||
|
|
||||
- !IN_SET(x, 0, USEC_INFINITY)
|
||||
+ timestamp_is_set(x)
|
||||
|
|
||||
- !IN_SET(x, USEC_INFINITY, 0)
|
||||
+ timestamp_is_set(x)
|
||||
)
|
||||
@@
|
||||
expression x;
|
||||
constant USEC_INFINITY = USEC_INFINITY;
|
||||
@@
|
||||
(
|
||||
- x <= 0 || x >= USEC_INFINITY
|
||||
+ !timestamp_is_set(x)
|
||||
|
|
||||
- x >= USEC_INFINITY || x <= 0
|
||||
+ !timestamp_is_set(x)
|
||||
|
|
||||
- x <= 0 || x == USEC_INFINITY
|
||||
+ !timestamp_is_set(x)
|
||||
|
|
||||
- x == USEC_INFINITY || x <= 0
|
||||
+ !timestamp_is_set(x)
|
||||
|
|
||||
- x == 0 || x >= USEC_INFINITY
|
||||
+ !timestamp_is_set(x)
|
||||
|
|
||||
- x >= USEC_INFINITY || x == 0
|
||||
+ !timestamp_is_set(x)
|
||||
|
|
||||
- x == 0 || x == USEC_INFINITY
|
||||
+ !timestamp_is_set(x)
|
||||
|
|
||||
- x == USEC_INFINITY || x == 0
|
||||
+ !timestamp_is_set(x)
|
||||
|
|
||||
- IN_SET(x, 0, USEC_INFINITY)
|
||||
+ !timestamp_is_set(x)
|
||||
|
|
||||
- IN_SET(x, USEC_INFINITY, 0)
|
||||
+ !timestamp_is_set(x)
|
||||
)
|
@ -25,7 +25,7 @@ taking a BSD file lock on the block device node. Specifically, whenever
|
||||
lock using [`flock(2)`](http://man7.org/linux/man-pages/man2/flock.2.html) on
|
||||
the main block device (i.e. never on any partition block device, but on the
|
||||
device the partition belongs to). If this lock cannot be taken (i.e. `flock()`
|
||||
returns `EBUSY`), it refrains from processing the device. If it manages to take
|
||||
returns `EAGAIN`), it refrains from processing the device. If it manages to take
|
||||
the lock it is kept for the entire time the device is processed.
|
||||
|
||||
Note that `systemd-udevd` also watches all block device nodes it manages for
|
||||
|
@ -148,6 +148,6 @@ names for them in UIs.
|
||||
|
||||
[Boot Loader Specification](https://systemd.io/BOOT_LOADER_SPECIFICATION)<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)
|
||||
[`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)
|
||||
|
@ -232,6 +232,16 @@ spaces from its value. The following keys are known:
|
||||
other installed operating systems. This ID shall be formatted as 32 lower
|
||||
case hexadecimal characters (i.e. without any UUID formatting). This key is
|
||||
optional. Example: `4098b3f648d74c13b1f04ccfba7798e8`.
|
||||
* `sort-key` shall contain a short string used for sorting entries on
|
||||
display. This can be defined freely though should typically be initialized
|
||||
from `IMAGE_ID=` or `ID=` from `/etc/os-release` of the relevant entry,
|
||||
possibly suffixed. This field is optional. If set, it is used as primary
|
||||
sorting key for the entries on display (lexicographically increasing). It
|
||||
does not have to be unique (and usually is not). If non-unique the the
|
||||
`machine-id` (lexicographically increasing) and `version` (lexicographically
|
||||
decreasing, i.e. newest version first) fields described above are used as
|
||||
secondary/ternary sorting keys. If this field is not set entries are
|
||||
typically sorted by the `.conf` file name of the entry.
|
||||
* `linux` refers to the Linux kernel to spawn and shall be a path relative to
|
||||
`$BOOT`. It is recommended that every distribution creates a machine id and
|
||||
version specific subdirectory below `$BOOT` and places its kernels and
|
||||
@ -269,8 +279,9 @@ key and is otherwise not valid. Here's an example for a complete drop-in file:
|
||||
|
||||
# /boot/loader/entries/6a9857a393724b7a981ebb5b8495b9ea-3.8.0-2.fc19.x86_64.conf
|
||||
title Fedora 19 (Rawhide)
|
||||
version 3.8.0-2.fc19.x86_64
|
||||
sort-key fedora
|
||||
machine-id 6a9857a393724b7a981ebb5b8495b9ea
|
||||
version 3.8.0-2.fc19.x86_64
|
||||
options root=UUID=6d3376e4-fc93-4509-95ec-a21d68011da2
|
||||
architecture x64
|
||||
linux /6a9857a393724b7a981ebb5b8495b9ea/3.8.0-2.fc19.x86_64/linux
|
||||
@ -298,6 +309,18 @@ focus for this specification. More specifically, on non-EFI systems
|
||||
configuration snippets following this specification cannot be used to spawn
|
||||
other operating systems (such as Windows).
|
||||
|
||||
Unfortunately, there are implementations of boot loading infrastructure that
|
||||
are also using the /loader/entries/ directory, but place files in them that are
|
||||
not valid by this specification. In order to minimize confusion a boot loader
|
||||
implementation may place a file /loader/entries.srel next to the
|
||||
/loader/entries/ directory containing the ASCII string "type1" (suffixed
|
||||
with a UNIX newline). Tools that need to determine whether an existing
|
||||
directory implements the semantics described here may check for this file and
|
||||
contents: if it exists and contains the mentioned string, it shall assume a
|
||||
standards compliant implementation is in place. If it exists but contains a
|
||||
different string it shall assume non-standard semantics are implemented. If the
|
||||
file does not exist no assumptions should be made.
|
||||
|
||||
### Type #2 EFI Unified Kernel Images
|
||||
|
||||
A unified kernel image is a single EFI PE executable combining an EFI stub
|
||||
@ -358,10 +381,10 @@ simply reads all files `$BOOT/loader/entries/*.conf`, and populates its boot
|
||||
menu with this. On EFI, it then extends this with any unified kernel images
|
||||
found in `$BOOT/EFI/Linux/*.efi`. It may also add additional entries, for
|
||||
example a "Reboot into firmware" option. Optionally it may sort the menu based
|
||||
on the `machine-id` and `version` fields, and possibly others. It uses the file
|
||||
name to identify specific items, for example in case it supports storing away
|
||||
default entry information somewhere. A boot loader should generally not modify
|
||||
these files.
|
||||
on the `sort-key`, `machine-id` and `version` fields, and possibly others. It
|
||||
uses the file name to identify specific items, for example in case it supports
|
||||
storing away default entry information somewhere. A boot loader should
|
||||
generally not modify these files.
|
||||
|
||||
For "Boot Loader Specification Entries" (Type #1), the _kernel package
|
||||
installer_ installs the kernel and initrd images to `$BOOT` (it is recommended
|
||||
@ -417,6 +440,6 @@ There are a couple of items that are out of focus for this specification:
|
||||
[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)<br>
|
||||
[systemd-gpt-auto-generator(8)](https://www.freedesktop.org/software/systemd/man/systemd-gpt-auto-generator.html)
|
||||
[`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)
|
||||
|
267
docs/BUILDING_IMAGES.md
Normal file
267
docs/BUILDING_IMAGES.md
Normal file
@ -0,0 +1,267 @@
|
||||
---
|
||||
title: Safely Building Images
|
||||
category: Concepts
|
||||
layout: default
|
||||
SPDX-License-Identifier: LGPL-2.1-or-later
|
||||
---
|
||||
|
||||
# Safely Building Images
|
||||
|
||||
In many scenarios OS installations are shipped as pre-built images, that
|
||||
require no further installation process beyond simple `dd`-ing the image to
|
||||
disk and booting it up. When building such "golden" OS images for
|
||||
`systemd`-based OSes a few points should be taken into account.
|
||||
|
||||
Most of the points described here are implemented by the
|
||||
[`mkosi`](https://github.com/systemd/mkosi) OS image builder developed and
|
||||
maintained by the systemd project. If you are using or working on another image
|
||||
builder it's recommended to keep the following concepts and recommendations in
|
||||
mind.
|
||||
|
||||
## Resources to Reset
|
||||
|
||||
Typically the same OS image shall be deployable in multiple instances, and each
|
||||
instance should automatically acquire its own identifying credentials on first
|
||||
boot. For that it's essential to:
|
||||
|
||||
1. Remove the
|
||||
[`/etc/machine-id`](https://www.freedesktop.org/software/systemd/man/machine-id.html)
|
||||
file or write the string `uninitialized\n` into it. This file is supposed to
|
||||
carry a 128bit identifier unique to the system. Only when it is reset it
|
||||
will be auto-generated on first boot and thus be truly unique. If this file
|
||||
is not reset, and carries a valid ID every instance of the system will come
|
||||
up with the same ID and that will likely lead to problems sooner or later,
|
||||
as many network-visible identifiers are commonly derived from the machine
|
||||
ID, for example IPv6 addresses or transient MAC addresses.
|
||||
|
||||
2. Remove the `/var/lib/systemd/random-seed` file (see
|
||||
[`systemd-random-seed(8)`](https://www.freedesktop.org/software/systemd/man/systemd-random-seed.service.html)),
|
||||
which is used to seed the kernel's random pool on boot. If this file is
|
||||
shipped pre-initialized, every instance will seed its random pool with the
|
||||
same random data that is included in the image, and thus possibly generate
|
||||
random data that is more similar to other instances booted off the same
|
||||
image than advisable.
|
||||
|
||||
3. Remove the `/loader/random-seed` file (see
|
||||
[`systemd-boot(7)`](https://www.freedesktop.org/software/systemd/man/systemd-boot.html))
|
||||
from the UEFI System Partition (ESP), in case the `systemd-boot` boot loader
|
||||
is used in the image.
|
||||
|
||||
4. It might also make sense to remove
|
||||
[`/etc/hostname`](https://www.freedesktop.org/software/systemd/man/hostname.html)
|
||||
and
|
||||
[`/etc/machine-info`](https://www.freedesktop.org/software/systemd/man/machine-info.html)
|
||||
which carry additional identifying information about the OS image.
|
||||
|
||||
## Boot Menu Entry Identifiers
|
||||
|
||||
The
|
||||
[`kernel-install(8)`](https://www.freedesktop.org/software/systemd/man/kernel-install.html)
|
||||
logic used to generate [Boot Loader Specification Type
|
||||
1](https://systemd.io/BOOT_LOADER_SPECIFICATION) entries by default uses the
|
||||
machine ID as stored in `/etc/machine-id` for naming boot menu entries and the
|
||||
directories in the ESP to place kernel images in. This is done in order to
|
||||
allow multiple installations of the same OS on the same system without
|
||||
conflicts. However, this is problematic if the machine ID shall be generated
|
||||
automatically on first boot: if the ID is not known before the first boot it
|
||||
cannot be used to name the most basic resources required for the boot process
|
||||
to complete.
|
||||
|
||||
Thus, for images that shall acquire their identity on first boot only, it is
|
||||
required to use a different identifier for naming boot menu entries. To allow
|
||||
this the `kernel-install` logic knows the generalized *entry* *token* concept,
|
||||
which can be a freely chosen string to use for identifying the boot menu
|
||||
resources of the OS. If not configured explicitly it defaults to the machine
|
||||
ID. The file `/etc/kernel/entry-token` may be used to configure this string
|
||||
explicitly. Thus, golden image builders should write a suitable identifier into
|
||||
this file, for example the `IMAGE_ID=` or `ID=` field from
|
||||
[`/etc/os-release`](https://www.freedesktop.org/software/systemd/man/os-release.html)
|
||||
(also see below). It is recommended to do this before the `kernel-install`
|
||||
functionality is invoked (i.e. before the package manager is used to install
|
||||
packages into the OS tree being prepared), so that the selected string is
|
||||
automatically used for all entries to be generated.
|
||||
|
||||
## Booting with Empty `/var/` and/or Empty Root File System
|
||||
|
||||
`systemd` is designed to be able to come up safely and robustly if the `/var/`
|
||||
file system or even the entire root file system (with exception of `/usr/`,
|
||||
i.e. the vendor OS resources) is empty (i.e. "unpopulated"). With this in mind
|
||||
it's relatively easy to build images that only ship a `/usr/` tree, and
|
||||
otherwise carry no other data, populating the rest of the directory hierarchy
|
||||
on first boot as needed.
|
||||
|
||||
Specifically, the following mechanisms are in place:
|
||||
|
||||
1. The `swich-root` logic in systemd, that is used to switch from the initrd
|
||||
phase to the host will create the basic OS hierarchy skeleton if missing. It
|
||||
will create a couple of directories strictly necessary to boot up
|
||||
successfully, plus essential symlinks (such as those necessary for the
|
||||
dynamic loader `ld.so` to function).
|
||||
|
||||
2. PID 1 will initialize `/etc/machine-id` automatically if not initialized yet
|
||||
(see above).
|
||||
|
||||
3. The
|
||||
[`nss-systemd(8)`](https://www.freedesktop.org/software/systemd/man/nss-systemd.html)
|
||||
glibc NSS module ensures the `root` and `nobody` users and groups remain
|
||||
resolvable, even without `/etc/passwd` and `/etc/group` around.
|
||||
|
||||
4. The
|
||||
[`systemd-sysusers(8)`](https://www.freedesktop.org/software/systemd/man/systemd-sysusers.service.html)
|
||||
will component automatically populate `/etc/passwd` and `/etc/group` on
|
||||
first boot with further necessary system users.
|
||||
|
||||
5. The
|
||||
[`systemd-tmpfiles(8)`](https://www.freedesktop.org/software/systemd/man/systemd-tmpfiles-setup.service.html)
|
||||
component ensures that various files and directories below `/etc/`, `/var/`
|
||||
and other places are created automatically at boot if missing. Unlike the
|
||||
directories/symlinks created by the `switch-root` logic above this logic is
|
||||
extensible by packages, and can adjust access modes, file ownership and
|
||||
more. Among others this will also link `/etc/os-release` →
|
||||
`/usr/lib/os-release`, ensuring that the OS release information is
|
||||
unconditionally accessible through `/etc/os-release`.
|
||||
|
||||
6. The
|
||||
[`nss-myhostname(8)`](https://www.freedesktop.org/software/systemd/man/nss-myhostname.html)
|
||||
glibc NSS module will ensure the local host name as well as `localhost`
|
||||
remains resolvable, even without `/etc/hosts` around.
|
||||
|
||||
With these mechanisms the hierarchies below `/var/` and `/etc/` can be safely
|
||||
and robustly populated on first boot, so that the OS can safely boot up. Note
|
||||
that some auxiliary package are not prepared to operate correctly if their
|
||||
configuration data in `/etc/` or their state directories in `/var/` are
|
||||
missing. This can typically be addressed via `systemd-tmpfiles` lines that
|
||||
ensure the missing files and directories are created if missing. In particular,
|
||||
configuration files that are necessary for operation can be automatically
|
||||
copied or symlinked from the `/usr/share/factory/etc/` tree via the `C` or `L`
|
||||
line types. That said, we recommend that all packages safely fall back to
|
||||
internal defaults if their configuration is missing, making such additional
|
||||
steps unnecessary.
|
||||
|
||||
Note that while `systemd` itself explicitly supports booting up with entirely
|
||||
unpopulated images (`/usr/` being the only required directory to be populated)
|
||||
distributions might not be there yet: depending on your distribution further,
|
||||
manual work might be required to make this scenario work.
|
||||
|
||||
## Adapting OS Images to Storage
|
||||
|
||||
Typically, if an image is `dd`-ed onto a target disk it will be minimal:
|
||||
i.e. only consist of necessary vendor data, and lack "payload" data, that shall
|
||||
be individual to the system, and dependent on host parameters. On first boot,
|
||||
the OS should take possession of the backing storage as necessary, dynamically
|
||||
using available space. Specifically:
|
||||
|
||||
1. Additional partitions should be created, that make no sense to ship
|
||||
pre-built in the image. For example `/tmp/` or `/home/` partitions, or even
|
||||
`/var/` or the root file system (see above).
|
||||
|
||||
2. Additional partitions should be created that shall function as A/B
|
||||
secondaries for partitions shipped in the original image. In other words: if
|
||||
the `/usr/` file system shall be updated in an A/B fashion it typically
|
||||
makes sense to ship the original A file system in the deployed image, but
|
||||
create the B partition on first boot.
|
||||
|
||||
3. Partitions covering only a part of the disk should be grown to the full
|
||||
extent of the disk.
|
||||
|
||||
4. File systems in uninitialized partitions should be formatted with a file
|
||||
system of choice.
|
||||
|
||||
5. File systems covering only a part of a partition should be grown to the full
|
||||
extent of the partition.
|
||||
|
||||
6. Partitions should be encrypted with cryptographic keys generated locally on
|
||||
the machine the system is first booted on, ensuring these keys remain local
|
||||
and are not shared with any other instance of the OS image.
|
||||
|
||||
Or any combination of the above: i.e. first create a partition, then encrypt
|
||||
it, then format it.
|
||||
|
||||
`systemd` provides multiple tools to implement the above logic:
|
||||
|
||||
1. The
|
||||
[`systemd-repart(8)`](https://www.freedesktop.org/software/systemd/man/systemd-repart.service.html)
|
||||
component may manipulate GPT partition tables automatically on boot, growing
|
||||
partitions or adding in partitions taking the backing storage size into
|
||||
account. It can also encrypt partitions automatically it creates (even bind
|
||||
to TPM2, automatically) and populate partitions from various sources. It
|
||||
does this all in a robust fashion so that aborted invocations will not leave
|
||||
incompletely set up partitions around.
|
||||
|
||||
2. The
|
||||
[`systemd-growfs@(8).service`](https://www.freedesktop.org/software/systemd/man/systemd-growfs.html)
|
||||
tool can automatically grow a file system to the partition it is contained
|
||||
in. The `x-systemd.growfs` mount option in `/etc/fstab` is sufficient to
|
||||
enable this logic for specific mounts. Alternatively appropriately set up
|
||||
partitions can set GPT partition flag 59 to request this behaviour, see the
|
||||
[Discoverable Partitions
|
||||
Specification](https://systemd.io/DISCOVERABLE_PARTITIONS) for details. If
|
||||
the file system is already grown it executes no operation.
|
||||
|
||||
3. Similar, the `systemd-makefs@.service` and `systemd-makeswap@.service`
|
||||
services can format file systems and swap spaces before first use, if they
|
||||
carry no file system signature yet. The `x-systemd.makefs` mount option in
|
||||
`/etc/fstab` may be used to request this functionality.
|
||||
|
||||
## Provisioning Image Settings
|
||||
|
||||
While a lot of work has gone into ensuring `systemd` systems can safely boot
|
||||
with unpopulated `/etc/` trees, it sometimes is desirable to set a couple of
|
||||
basic settings *after* `dd`-ing the image to disk, but *before* first boot. For
|
||||
this the tool
|
||||
[`systemd-firstboot(1)`](https://www.freedesktop.org/software/systemd/man/systemd-firstboot.html)
|
||||
can be useful, with its `--image=` switch. It may be used to set very basic
|
||||
settings, such as the root password or hostname on an OS disk image or
|
||||
installed block device.
|
||||
|
||||
## Distinguishing First Boot
|
||||
|
||||
For various purposes it's useful to be able to distinguish the first boot-up of
|
||||
the system from later boot-ups (for example, to set up TPM hardware
|
||||
specifically, or register a system somewhere). `systemd` provides mechanisms to
|
||||
implement that. Specifically, the `ConditionFirstBoot=` and `AssertFirstBoot=`
|
||||
settings may be used to conditionalize units to only run on first boot. See
|
||||
[`systemd.unit(5)`](https://www.freedesktop.org/software/systemd/man/systemd.unit.html#ConditionFirstBoot=)
|
||||
for details.
|
||||
|
||||
A special target unit `first-boot-complete.target` may be used as milestone to
|
||||
safely handle first boots where the system is powered off too early: if the
|
||||
first boot process is aborted before this target is reached, the following boot
|
||||
process will be considered a first boot, too. Once the target is reached,
|
||||
subsequent boots will not be considered first boots anymore, even if the boot
|
||||
process is aborted immediately after. Thus, services that must complete fully
|
||||
before a system shall be considered fully past the first boot should be ordered
|
||||
before this target unit.
|
||||
|
||||
Whether a system will come up in first boot state or not is derived from the
|
||||
initialization status of `/etc/machine-id`: if the file already carries a valid
|
||||
ID the system is already past the first boot. If it is not initialized yet it
|
||||
is still considered in the first boot state. For details see
|
||||
[`machine-id(5)`](https://www.freedesktop.org/software/systemd/man/machine-id.html).
|
||||
|
||||
## Image Metadata
|
||||
|
||||
Typically, when operating with golden disk images it is useful to be able to
|
||||
identify them and their version. For this the two fields `IMAGE_ID=` and
|
||||
`IMAGE_VERSION=` have been defined in
|
||||
[`os-release(5)`](https://www.freedesktop.org/software/systemd/man/os-release.html). These
|
||||
fields may be accessed from unit files and similar via the `%M` and `%A`
|
||||
specifiers.
|
||||
|
||||
Depending on how the images are put together it might make sense to leave the
|
||||
OS distribution's `os-release` file as is in `/usr/lib/os-release` but to
|
||||
replace the usual `/etc/os-release` symlink with a regular file that extends
|
||||
the distribution's file with one augmented with these two additional
|
||||
fields.
|
||||
|
||||
## Links
|
||||
|
||||
[`machine-id(5)`](https://www.freedesktop.org/software/systemd/man/machine-id.html)<br>
|
||||
[`systemd-random-seed(8)`](https://www.freedesktop.org/software/systemd/man/systemd-random-seed.service.html)<br>
|
||||
[`os-release(5)`](https://www.freedesktop.org/software/systemd/man/os-release.html)<br>
|
||||
[Boot Loader Specification](https://systemd.io/BOOT_LOADER_SPECIFICATION)<br>
|
||||
[Discoverable Partitions Specification](https://systemd.io/DISCOVERABLE_PARTITIONS)<br>
|
||||
[`mkosi`](https://github.com/systemd/mkosi)<br>
|
||||
[`systemd-boot(7)`](https://www.freedesktop.org/software/systemd/man/systemd-boot.html)<br>
|
||||
[`systemd-repart(8)`](https://www.freedesktop.org/software/systemd/man/systemd-repart.service.html)<br>
|
||||
[`systemd-growfs@(8).service`](https://www.freedesktop.org/software/systemd/man/systemd-growfs.html)<br>
|
@ -253,6 +253,13 @@ So, if you want to do your own raw cgroups kernel level access, then allocate a
|
||||
scope unit, or a service unit (or just use the service unit you already have
|
||||
for your service code), and turn on delegation for it.
|
||||
|
||||
The service manager sets the `user.delegate` extended attribute (readable via
|
||||
`getxattr(2)` and related calls) to the character `1` on cgroup directories
|
||||
where delegation is enabled (and removes it on those cgroups where it is
|
||||
not). This may be used by service programs to determine whether a cgroup tree
|
||||
was delegated to them. Note that this is only supported on kernels 5.6 and
|
||||
newer in combination with systemd 251 and newer.
|
||||
|
||||
(OK, here's one caveat: if you turn on delegation for a service, and that
|
||||
service has `ExecStartPost=`, `ExecReload=`, `ExecStop=` or `ExecStopPost=`
|
||||
set, then these commands will be executed within the `.control/` sub-cgroup of
|
||||
@ -266,6 +273,15 @@ tree by the time it notifies the service manager about start-up readiness, so
|
||||
that the service's main cgroup is definitely an inner node by the time the
|
||||
service manager might start `ExecStartPost=`.)
|
||||
|
||||
(Also note, if you intend to use "threaded" cgroups — as added in Linux 4.14 —,
|
||||
then you should do that *two* levels down from the main service cgroup your
|
||||
turned delegation on for. Why that? You need one level so that systemd can
|
||||
properly create the `.control` subgroup, as described above. But that one
|
||||
cannot be threaded, since that would mean `.control` has to be threaded too —
|
||||
this is a requirement of threaded cgroups: either a cgroup and all its siblings
|
||||
are threaded or none –, but systemd expects it to be a regular cgroup. Thus you
|
||||
have to nest a second cgroup beneath it which then can be threaded.)
|
||||
|
||||
## Three Scenarios
|
||||
|
||||
Let's say you write a container manager, and you wonder what to do regarding
|
||||
@ -356,7 +372,7 @@ but of course that's between you and those other tenants, and systemd won't
|
||||
care. Replicating the cgroup hierarchies in those unsupported controllers would
|
||||
mean replicating the full cgroup paths in them, and hence the prefixing
|
||||
`.slice` components too, otherwise the hierarchies will start being orthogonal
|
||||
after all, and that's not really desirable. On more thing: systemd will clean
|
||||
after all, and that's not really desirable. One more thing: systemd will clean
|
||||
up after you in the hierarchies it manages: if your daemon goes down, its
|
||||
cgroups will be removed too. You basically get the guarantee that you start
|
||||
with a pristine cgroup sub-tree for your service or scope whenever it is
|
||||
|
@ -51,8 +51,8 @@ available functionality:
|
||||
|
||||
9. There are multiple CI systems in use that run on every github PR submission.
|
||||
|
||||
10. [Coverity](https://scan.coverity.com/) is analyzing systemd master in
|
||||
regular intervals. The reports are available
|
||||
10. [Coverity](https://scan.coverity.com/) is analyzing systemd `main` branch
|
||||
in regular intervals. The reports are available
|
||||
[online](https://scan.coverity.com/projects/systemd).
|
||||
|
||||
11. [oss-fuzz](https://oss-fuzz.com/) is continuously fuzzing the
|
||||
@ -65,7 +65,7 @@ available functionality:
|
||||
13. When building systemd from a git checkout the build scripts will
|
||||
automatically enable a git commit hook that ensures whitespace cleanliness.
|
||||
|
||||
14. [LGTM](https://lgtm.com/) analyzes every commit pushed to master. The list
|
||||
14. [LGTM](https://lgtm.com/) analyzes every commit pushed to `main`. The list
|
||||
of active alerts can be found
|
||||
[here](https://lgtm.com/projects/g/systemd/systemd/alerts/?mode=list).
|
||||
|
||||
@ -75,7 +75,7 @@ available functionality:
|
||||
for more information.
|
||||
|
||||
16. Fossies provides [source code misspelling reports](https://fossies.org/features.html#codespell).
|
||||
The systemd report can be found [here](https://fossies.org/linux/test/systemd-master.tar.gz/codespell.html).
|
||||
The systemd report can be found [here](https://fossies.org/linux/misc/systemd/codespell.html).
|
||||
|
||||
Access to Coverity and oss-fuzz reports is limited. Please reach out to the
|
||||
maintainers if you need access.
|
||||
|
@ -79,8 +79,61 @@ SPDX-License-Identifier: LGPL-2.1-or-later
|
||||
dont_find_waldo();
|
||||
```
|
||||
|
||||
- Please define flags types like this:
|
||||
|
||||
```c
|
||||
typedef enum FoobarFlags {
|
||||
FOOBAR_QUUX = 1 << 0,
|
||||
FOOBAR_WALDO = 1 << 1,
|
||||
FOOBAR_XOXO = 1 << 2,
|
||||
…
|
||||
} FoobarFlags;
|
||||
```
|
||||
|
||||
i.e. use an enum for it, if possible. Indicate bit values via `1 <<`
|
||||
expressions, and align them vertically. Define both an enum and a type for
|
||||
it.
|
||||
|
||||
- If you define (non-flags) enums, follow this template:
|
||||
|
||||
```c
|
||||
typedef enum FoobarMode {
|
||||
FOOBAR_AAA,
|
||||
FOOBAR_BBB,
|
||||
FOOBAR_CCC,
|
||||
…
|
||||
_FOOBAR_MAX,
|
||||
_FOOBAR_INVALID = -EINVAL,
|
||||
} FoobarMode;
|
||||
```
|
||||
|
||||
i.e. define a `_MAX` enum for the largest defined enum value, plus one. Since
|
||||
this is not a regular enum value, prefix it with `_`. Also, define a special
|
||||
"invalid" enum value, and set it to `-EINVAL`. That way the enum type can
|
||||
safely be used to propagate conversion errors.
|
||||
|
||||
- If you define an enum in a public API, be extra careful, as the size of the
|
||||
enum might change when new values are added, which would break ABI
|
||||
compatibility. Since we typically want to allow adding new enum values to an
|
||||
existing enum type with later API versions, please use the
|
||||
`_SD_ENUM_FORCE_S64()` macro in the enum definition, which forces the size of
|
||||
the enum to be signed 64bit wide.
|
||||
|
||||
## Code Organization and Semantics
|
||||
|
||||
- For our codebase we intend to use ISO C11 *with* GNU extensions (aka
|
||||
"gnu11"). Public APIs (i.e. those we expose via `libsystemd.so`
|
||||
i.e. `systemd/sd-*.h`) should only use ISO C89 however (with a very limited
|
||||
set of conservative and common extensions, such as fixed size integer types
|
||||
from `<inttypes.h>`), so that we don't force consuming programs into C11
|
||||
mode. (This discrepancy in particular means one thing: internally we use C99
|
||||
`bool` booleans, externally C89-compatible `int` booleans which generally
|
||||
have different size in memory and slightly different semantics, also see
|
||||
below.) Both for internal and external code it's OK to use even newer
|
||||
features and GCC extension than "gnu11", as long as there's reasonable
|
||||
fallback #ifdeffery in place to ensure compatibility is retained with older
|
||||
compilers.
|
||||
|
||||
- Please name structures in `PascalCase` (with exceptions, such as public API
|
||||
structs), variables and functions in `snake_case`.
|
||||
|
||||
@ -358,7 +411,7 @@ SPDX-License-Identifier: LGPL-2.1-or-later
|
||||
|
||||
- For every function you add, think about whether it is a "logging" function or
|
||||
a "non-logging" function. "Logging" functions do (non-debug) logging on their
|
||||
own, "non-logging" function never log on their own (except at debug level)
|
||||
own, "non-logging" functions never log on their own (except at debug level)
|
||||
and expect their callers to log. All functions in "library" code, i.e. in
|
||||
`src/shared/` and suchlike must be "non-logging". Every time a "logging"
|
||||
function calls a "non-logging" function, it should log about the resulting
|
||||
@ -491,7 +544,8 @@ SPDX-License-Identifier: LGPL-2.1-or-later
|
||||
|
||||
- Use the bool type for booleans, not integers. One exception: in public
|
||||
headers (i.e those in `src/systemd/sd-*.h`) use integers after all, as `bool`
|
||||
is C99 and in our public APIs we try to stick to C89 (with a few extensions).
|
||||
is C99 and in our public APIs we try to stick to C89 (with a few extensions;
|
||||
also see above).
|
||||
|
||||
## Deadlocks
|
||||
|
||||
@ -518,7 +572,7 @@ SPDX-License-Identifier: LGPL-2.1-or-later
|
||||
|
||||
- It's a good idea to use `O_NONBLOCK` when opening 'foreign' regular files,
|
||||
i.e. file system objects that are supposed to be regular files whose paths
|
||||
where specified by the user and hence might actually refer to other types of
|
||||
were specified by the user and hence might actually refer to other types of
|
||||
file system objects. This is a good idea so that we don't end up blocking on
|
||||
'strange' file nodes, for example if the user pointed us to a FIFO or device
|
||||
node which may block when opening. Moreover even for actual regular files
|
||||
|
@ -37,18 +37,18 @@ manager, please consider supporting the following interfaces.
|
||||
in this context.)
|
||||
|
||||
3. Pre-mount `/dev/` as (container private) `tmpfs` for the container and bind
|
||||
mount some suitable TTY to `/dev/console`. If this is a pty, make sure to not
|
||||
close the controlling pty master during systemd's lifetime. PID1 will close
|
||||
mount some suitable TTY to `/dev/console`. If this is a pty, make sure to
|
||||
not close the controlling pty during systemd's lifetime. PID1 will close
|
||||
ttys, to avoid being killed by SAK. It only opens ttys for the time it
|
||||
actually needs to print something. 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.
|
||||
actually needs to print something. 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.
|
||||
|
||||
@ -277,7 +277,7 @@ care should be taken to avoid naming conflicts. `systemd` (and in particular
|
||||
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
|
||||
capability. If you take away the capability, then 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
|
||||
|
@ -31,7 +31,7 @@ See [reporting of security vulnerabilities](SECURITY.md).
|
||||
|
||||
## Posting Pull Requests
|
||||
|
||||
* Make sure to post PRs only relative to a very recent git master.
|
||||
* Make sure to post PRs only relative to a very recent git tip.
|
||||
* Follow our [Coding Style](CODING_STYLE.md) when contributing code. This is a requirement for all code we merge.
|
||||
* Please make sure to test your change before submitting the PR. See the [Hacking guide](HACKING.md) for details on how to do this.
|
||||
* Make sure to run the test suite locally, before posting your PR. We use a CI system, meaning we don't even look at your PR, if the build and tests don't pass.
|
||||
|
@ -92,9 +92,9 @@ $ ./generate-package-notes.py --rpm systemd-248~rc2-1.fc33.arm32 --cpe cpe:/o:fe
|
||||
SECTIONS
|
||||
{
|
||||
.note.package (READONLY) : ALIGN(4) {
|
||||
BYTE(0x04) BYTE(0x00) BYTE(0x00) BYTE(0x00) /* Length of Owner including NUL */
|
||||
BYTE(0x7b) BYTE(0x00) BYTE(0x00) BYTE(0x00) /* Length of Value including NUL */
|
||||
BYTE(0x7e) BYTE(0x1a) BYTE(0xfe) BYTE(0xca) /* Note ID */
|
||||
LONG(0x0004) /* Length of Owner including NUL */
|
||||
LONG(0x007b) /* Length of Value including NUL */
|
||||
LONG(0xcafe1a7e) /* Note ID */
|
||||
BYTE(0x46) BYTE(0x44) BYTE(0x4f) BYTE(0x00) /* Owner: 'FDO\x00' */
|
||||
BYTE(0x7b) BYTE(0x22) BYTE(0x74) BYTE(0x79) /* Value: '{"type":"rpm","name":"systemd","version":"248~rc2-1.fc33","architecture":"arm32","osCpe":"cpe:/o:fedoraproject:fedora:33"}\x00\x00' */
|
||||
BYTE(0x70) BYTE(0x65) BYTE(0x22) BYTE(0x3a)
|
||||
|
@ -97,13 +97,13 @@ to create appropriate units for the autostart directory
|
||||
(`systemd-xdg-autostart-generator`).
|
||||
Desktop Environments can opt-in to using this by starting
|
||||
`xdg-desktop-autostart.target`. The systemd generator correctly handles
|
||||
`OnlyShowIn=` and `NotShowin=`. It also handles the KDE and GNOME specific
|
||||
`X-KDE-autostart-condition=` and `AutostartCondition=` by using desktop
|
||||
environment provided binaries in an `ExecCondition=` line.
|
||||
`OnlyShowIn=` and `NotShowIn=`. It also handles the KDE and GNOME specific
|
||||
`X-KDE-autostart-condition=` and `AutostartCondition=` by using desktop-environment-provided
|
||||
binaries in an `ExecCondition=` line.
|
||||
|
||||
However, this generator is somewhat limited in what it supports. For example,
|
||||
all generated units will have `After=graphical-session.target` set on them,
|
||||
it may therefore not be useful to start session services.
|
||||
and therefore may not be useful to start session services.
|
||||
|
||||
Desktop files can be marked to be explicitly excluded from the generator using the line
|
||||
`X-systemd-skip=true`. This should be set if an application provides its own
|
||||
|
@ -407,3 +407,12 @@ available.
|
||||
|
||||
The `gdisk` tool (from version 1.0.5 onward) and its variants (`sgdisk`,
|
||||
`cgdisk`) also support creation of partitions with a matching type code.
|
||||
|
||||
## Links
|
||||
|
||||
[Boot Loader Specification](https://systemd.io/BOOT_LOADER_SPECIFICATION)<br>
|
||||
[Boot Loader Interface](https://systemd.io/BOOT_LOADER_INTERFACE)<br>
|
||||
[Safely Building Images](https://systemd.io/BUILDING_IMAGES)<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)
|
||||
|
@ -43,6 +43,11 @@ All tools:
|
||||
debugging, in order to test generators and other code against specific kernel
|
||||
command lines.
|
||||
|
||||
* `$SYSTEMD_OS_RELEASE` — if set, use this path instead of `/etc/os-release` or
|
||||
`/usr/lib/os-release`. When operating under some root (e.g. `systemctl
|
||||
--root=…`), the path is taken relative to the outside root. Only useful for
|
||||
debugging.
|
||||
|
||||
* `$SYSTEMD_FSTAB` — if set, use this path instead of `/etc/fstab`. Only useful
|
||||
for debugging.
|
||||
|
||||
@ -97,9 +102,6 @@ All tools:
|
||||
systems built with libxcrypt and is ignored on systems using glibc's
|
||||
original, internal `crypt()` implementation.)
|
||||
|
||||
* `$SYSTEMD_RDRAND=0` — if set, the RDRAND instruction will never be used,
|
||||
even if the CPU supports it.
|
||||
|
||||
* `$SYSTEMD_SECCOMP=0` — if set, seccomp filters will not be enforced, even if
|
||||
support for it is compiled in and available in the kernel.
|
||||
|
||||
@ -321,7 +323,7 @@ fuzzers:
|
||||
* `$SYSTEMD_FUZZ_RUNS` — The number of times execution should be repeated in
|
||||
manual invocations.
|
||||
|
||||
Note that is may be also useful to set `$SYSTEMD_LOG_LEVEL`, since all logging
|
||||
Note that it may be also useful to set `$SYSTEMD_LOG_LEVEL`, since all logging
|
||||
is suppressed by default.
|
||||
|
||||
`systemd-importd`:
|
||||
|
@ -7,7 +7,7 @@ SPDX-License-Identifier: LGPL-2.1-or-later
|
||||
|
||||
# GVariant D-Bus Message Serialization
|
||||
|
||||
We stay close to the original dbus1 framing as possible, but make
|
||||
We stay as close to the original dbus1 framing as possible, but make
|
||||
certain changes to adapt for GVariant. dbus1 has the following
|
||||
framing:
|
||||
|
||||
|
@ -27,7 +27,7 @@ Please also have a look at our list of [code quality tools](CODE_QUALITY.md) we
|
||||
have setup for systemd, to ensure our codebase stays in good shape.
|
||||
|
||||
Please always test your work before submitting a PR. For many of the components
|
||||
of systemd testing is straight-forward as you can simply compile systemd and
|
||||
of systemd testing is straightforward as you can simply compile systemd and
|
||||
run the relevant tool from the build directory.
|
||||
|
||||
For some components (most importantly, systemd/PID1 itself) this is not
|
||||
@ -330,3 +330,43 @@ To debug systemd components other than PID 1, set "program" to the full path of
|
||||
debug and set "processId" to "${command:pickProcess}". Now, when starting the debugger, VSCode will ask you
|
||||
the PID of the process you want to debug. Run `systemctl show --property MainPID --value <component>` in the
|
||||
container to figure out the PID and enter it when asked and VSCode will attach to that process instead.
|
||||
|
||||
# Debugging systemd-boot
|
||||
|
||||
During boot, systemd-boot and the stub loader will output a message like `systemd-boot@0x0A,0x0B`,
|
||||
providing the location of the text and data sections. These location can then be used to attach
|
||||
to a QEMU session (provided it was run with `-s`) with these gdb commands:
|
||||
|
||||
```
|
||||
(gdb) file build/src/boot/efi/systemd-bootx64.efi
|
||||
(gdb) add-symbol-file build/src/boot/efi/systemd_boot.so 0x0A -s .data 0x0B
|
||||
(gdb) set architecture i386:x86-64
|
||||
(gdb) target remote :1234
|
||||
```
|
||||
|
||||
This process can be automated by using the `debug-sd-boot.sh` script in the tools folder. If run
|
||||
without arguments it will provide usage information.
|
||||
|
||||
If the debugger is too slow to attach to examine an early boot code passage, we can uncomment the
|
||||
call to `debug_break()` inside of `efi_main()`. As soon as the debugger has control we can then run
|
||||
`set variable wait = 0` or `return` to continue. Once the debugger has attached, setting breakpoints
|
||||
will work like usual.
|
||||
|
||||
To debug systemd-boot in an IDE such as VSCode we can use a launch configuration like this:
|
||||
```json
|
||||
{
|
||||
"name": "systemd-boot",
|
||||
"type": "cppdbg",
|
||||
"request": "launch",
|
||||
"program": "${workspaceFolder}/build/src/boot/efi/systemd-bootx64.efi",
|
||||
"cwd": "${workspaceFolder}",
|
||||
"MIMode": "gdb",
|
||||
"miDebuggerServerAddress": ":1234",
|
||||
"setupCommands": [
|
||||
{ "text": "shell mkfifo /tmp/sdboot.{in,out}" },
|
||||
{ "text": "shell qemu-system-x86_64 [...] -s -serial pipe:/tmp/sdboot" },
|
||||
{ "text": "shell ${workspaceFolder}/tools/debug-sd-boot.sh ${workspaceFolder}/build/src/boot/efi/systemd-bootx64.efi /tmp/sdboot.out systemd-boot.gdb" },
|
||||
{ "text": "source /tmp/systemd-boot.gdb" },
|
||||
]
|
||||
}
|
||||
```
|
||||
|
@ -9,11 +9,11 @@ SPDX-License-Identifier: LGPL-2.1-or-later
|
||||
|
||||
[`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
|
||||
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.
|
||||
the format used by these home directories, in the context of the storage
|
||||
mechanism used.
|
||||
|
||||
## General Structure
|
||||
|
||||
@ -22,7 +22,7 @@ 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
|
||||
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
|
||||
@ -35,13 +35,13 @@ 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
|
||||
command line) the home directory requires no special setup 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
|
||||
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
|
||||
@ -54,19 +54,19 @@ 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
|
||||
`trusted.fscrypt_slot2`, … is maintained. Its 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
|
||||
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.
|
||||
by `fscrypt` and hence are suitable for carrying 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
|
||||
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
|
||||
@ -85,7 +85,7 @@ 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
|
||||
`773f91ef-66d4-49b5-bd83-d683bf40ad16`. Its partition label must be the
|
||||
user name.
|
||||
|
||||
* This partition must contain a LUKS2 volume, whose label must be the user
|
||||
@ -106,24 +106,24 @@ media). (Use `--storage=luks` on the `homectl` command line.) Specifically:
|
||||
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
|
||||
The image file should 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
|
||||
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/`,
|
||||
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
|
||||
medium. (Moreover, it allows embedding additional partitions later on, for
|
||||
example on 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 LUKS2 header:
|
||||
@ -133,7 +133,7 @@ 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
|
||||
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
|
||||
@ -145,10 +145,10 @@ do not show up in the user's home directory.
|
||||
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
|
||||
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 distinguish
|
||||
those that already are a directory), a clear logic is defined to distinguish
|
||||
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
|
||||
@ -161,7 +161,7 @@ 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
|
||||
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.
|
||||
|
||||
@ -169,7 +169,7 @@ 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 `luksDiscard` setting of the user record either the backing
|
||||
Depending on the `luksDiscard` 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.
|
||||
|
||||
|
@ -12,7 +12,7 @@ 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
|
||||
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
|
||||
|
156
docs/JOURNAL_EXPORT_FORMATS.md
Normal file
156
docs/JOURNAL_EXPORT_FORMATS.md
Normal file
@ -0,0 +1,156 @@
|
||||
---
|
||||
title: Journal Export Format
|
||||
category: Interfaces
|
||||
layout: default
|
||||
SPDX-License-Identifier: LGPL-2.1-or-later
|
||||
---
|
||||
|
||||
# Journal Export Format
|
||||
|
||||
_Note that this document describes the binary serialization format of journals only, as used for transfer across the network.
|
||||
For interfacing with web technologies there's the Journal JSON Format, described below.
|
||||
The binary format on disk is documented as the [Journal File Format](https://systemd.io/JOURNAL_FILE_FORMAT/)._
|
||||
|
||||
_Before reading on, please make sure you are aware of the [basic properties of journal entries](https://www.freedesktop.org/software/systemd/man/systemd.journal-fields.html), in particular realize that they may include binary non-text data (though usually don't), and the same field might have multiple values assigned within the same entry (though usually hasn't)._
|
||||
|
||||
When exporting journal data for other uses or transferring it via the network/local IPC the _journal export format_ is used. It's a simple serialization of journal entries, that is easy to read without any special tools, but still binary safe where necessary. The format is like this:
|
||||
|
||||
* Two journal entries that follow each other are separated by a double newline.
|
||||
* Journal fields consisting only of valid non-control UTF-8 codepoints are serialized as they are (i.e. the field name, followed by '=', followed by field data), followed by a newline as separator to the next field. Note that fields containing newlines cannot be formatted like this. Non-control UTF-8 codepoints are the codepoints with value at or above 32 (' '), or equal to 9 (TAB).
|
||||
* Other journal fields are serialized in a special binary safe way: field name, followed by newline, followed by a binary 64bit little endian size value, followed by the binary field data, followed by a newline as separator to the next field.
|
||||
* Entry metadata that is not actually a field is serialized like it was a field, but beginning with two underscores. More specifically, `__CURSOR=`, `__REALTIME_TIMESTAMP=`, `__MONOTONIC_TIMESTAMP=` are introduced this way. Note that these meta-fields are only generated when actual journal files are serialized. They are omitted for entries that do not originate from a journal file (for example because they are transferred for the first time to be stored in one). Or in other words: if you are generating this format you shouldn't care about these special double-underscore fields. But you might find them usable when you deserialize the format generated by us. Additional fields prefixed with two underscores might be added later on, your parser should skip over the fields it does not know.
|
||||
* The order in which fields appear in an entry is undefined and might be different for each entry that is serialized.
|
||||
And that's already it.
|
||||
|
||||
This format can be generated via `journalctl -o export`.
|
||||
|
||||
Here's an example for two serialized entries which consist only of text data:
|
||||
|
||||
```
|
||||
__CURSOR=s=739ad463348b4ceca5a9e69c95a3c93f;i=4ece7;b=6c7c6013a26343b29e964691ff25d04c;m=4fc72436e;t=4c508a72423d9;x=d3e5610681098c10;p=system.journal
|
||||
__REALTIME_TIMESTAMP=1342540861416409
|
||||
__MONOTONIC_TIMESTAMP=21415215982
|
||||
_BOOT_ID=6c7c6013a26343b29e964691ff25d04c
|
||||
_TRANSPORT=syslog
|
||||
PRIORITY=4
|
||||
SYSLOG_FACILITY=3
|
||||
SYSLOG_IDENTIFIER=gdm-password]
|
||||
SYSLOG_PID=587
|
||||
MESSAGE=AccountsService-DEBUG(+): ActUserManager: ignoring unspecified session '8' since it's not graphical: Success
|
||||
_PID=587
|
||||
_UID=0
|
||||
_GID=500
|
||||
_COMM=gdm-session-wor
|
||||
_EXE=/usr/libexec/gdm-session-worker
|
||||
_CMDLINE=gdm-session-worker [pam/gdm-password]
|
||||
_AUDIT_SESSION=2
|
||||
_AUDIT_LOGINUID=500
|
||||
_SYSTEMD_CGROUP=/user/lennart/2
|
||||
_SYSTEMD_SESSION=2
|
||||
_SELINUX_CONTEXT=system_u:system_r:xdm_t:s0-s0:c0.c1023
|
||||
_SOURCE_REALTIME_TIMESTAMP=1342540861413961
|
||||
_MACHINE_ID=a91663387a90b89f185d4e860000001a
|
||||
_HOSTNAME=epsilon
|
||||
|
||||
__CURSOR=s=739ad463348b4ceca5a9e69c95a3c93f;i=4ece8;b=6c7c6013a26343b29e964691ff25d04c;m=4fc72572f;t=4c508a7243799;x=68597058a89b7246;p=system.journal
|
||||
__REALTIME_TIMESTAMP=1342540861421465
|
||||
__MONOTONIC_TIMESTAMP=21415221039
|
||||
_BOOT_ID=6c7c6013a26343b29e964691ff25d04c
|
||||
_TRANSPORT=syslog
|
||||
PRIORITY=6
|
||||
SYSLOG_FACILITY=9
|
||||
SYSLOG_IDENTIFIER=/USR/SBIN/CROND
|
||||
SYSLOG_PID=8278
|
||||
MESSAGE=(root) CMD (run-parts /etc/cron.hourly)
|
||||
_PID=8278
|
||||
_UID=0
|
||||
_GID=0
|
||||
_COMM=run-parts
|
||||
_EXE=/usr/bin/bash
|
||||
_CMDLINE=/bin/bash /bin/run-parts /etc/cron.hourly
|
||||
_AUDIT_SESSION=8
|
||||
_AUDIT_LOGINUID=0
|
||||
_SYSTEMD_CGROUP=/user/root/8
|
||||
_SYSTEMD_SESSION=8
|
||||
_SELINUX_CONTEXT=system_u:system_r:crond_t:s0-s0:c0.c1023
|
||||
_SOURCE_REALTIME_TIMESTAMP=1342540861416351
|
||||
_MACHINE_ID=a91663387a90b89f185d4e860000001a
|
||||
_HOSTNAME=epsilon
|
||||
|
||||
```
|
||||
|
||||
A message with a binary field produced by
|
||||
```bash
|
||||
python3 -c 'from systemd import journal; journal.send("foo\nbar")'
|
||||
journalctl -n1 -o export
|
||||
```
|
||||
|
||||
```
|
||||
__CURSOR=s=bcce4fb8ffcb40e9a6e05eee8b7831bf;i=5ef603;b=ec25d6795f0645619ddac9afdef453ee;m=545242e7049;t=50f1202
|
||||
__REALTIME_TIMESTAMP=1423944916375353
|
||||
__MONOTONIC_TIMESTAMP=5794517905481
|
||||
_BOOT_ID=ec25d6795f0645619ddac9afdef453ee
|
||||
_TRANSPORT=journal
|
||||
_UID=1001
|
||||
_GID=1001
|
||||
_CAP_EFFECTIVE=0
|
||||
_SYSTEMD_OWNER_UID=1001
|
||||
_SYSTEMD_SLICE=user-1001.slice
|
||||
_MACHINE_ID=5833158886a8445e801d437313d25eff
|
||||
_HOSTNAME=bupkis
|
||||
_AUDIT_LOGINUID=1001
|
||||
_SELINUX_CONTEXT=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
|
||||
CODE_LINE=1
|
||||
CODE_FUNC=<module>
|
||||
SYSLOG_IDENTIFIER=python3
|
||||
_COMM=python3
|
||||
_EXE=/usr/bin/python3.4
|
||||
_AUDIT_SESSION=35898
|
||||
_SYSTEMD_CGROUP=/user.slice/user-1001.slice/session-35898.scope
|
||||
_SYSTEMD_SESSION=35898
|
||||
_SYSTEMD_UNIT=session-35898.scope
|
||||
MESSAGE
|
||||
^G^@^@^@^@^@^@^@foo
|
||||
bar
|
||||
CODE_FILE=<string>
|
||||
_PID=16853
|
||||
_CMDLINE=python3 -c from systemd import journal; journal.send("foo\nbar")
|
||||
_SOURCE_REALTIME_TIMESTAMP=1423944916372858
|
||||
```
|
||||
|
||||
# Journal JSON Format
|
||||
|
||||
_Note that this section describes the JSON serialization format of the journal only, as used for interfacing with web technologies.
|
||||
For binary transfer of journal data across the network there's the Journal Export Format described above.
|
||||
The binary format on disk is documented as [Journal File Format](https://systemd.io/JOURNAL_FILE_FORMAT)._
|
||||
|
||||
_Before reading on, please make sure you are aware of the [basic properties of journal entries](https://www.freedesktop.org/software/systemd/man/systemd.journal-fields.html), in particular realize that they may include binary non-text data (though usually don't), and the same field might have multiple values assigned within the same entry (though usually hasn't)._
|
||||
|
||||
In most cases the Journal JSON serialization is the obvious mapping of the entry field names (as JSON strings) to the entry field values (also as JSON strings) encapsulated in one JSON object. However, there are a few special cases to handle:
|
||||
|
||||
* A field that contains non-printable or non-UTF8 is serialized as a number array instead. This is necessary to handle binary data in a safe way without losing data, since JSON cannot embed binary data natively. Each byte of the binary field will be mapped to its numeric value in the range 0…255.
|
||||
* The JSON serializer can optionally skip huge (as in larger than a specific threshold) data fields from the JSON object. If that is enabled and a data field is too large, the field name is still included in the JSON object but assigned _null_.
|
||||
* Within the same entry, Journal fields may have multiple values assigned. This is not allowed in JSON. The serializer will hence create a single JSON field only for these cases, and assign it an array of values (which the can be strings, _null_ or number arrays, see above).
|
||||
* If the JSON data originates from a journal file it may include the special addressing fields `__CURSOR`, `__REALTIME_TIMESTAMP`, `__MONOTONIC_TIMESTAMP`, which contain the cursor string of this entry as string, and the realtime/monotonic timestamps of this entry as formatted numeric string of usec since the respective epoch.
|
||||
|
||||
Here's an example, illustrating all cases mentioned above. Consider this entry:
|
||||
|
||||
```
|
||||
MESSAGE=Hello World
|
||||
_UDEV_DEVNODE=/dev/waldo
|
||||
_UDEV_DEVLINK=/dev/alias1
|
||||
_UDEV_DEVLINK=/dev/alias2
|
||||
BINARY=this is a binary value \a
|
||||
LARGE=this is a super large value (let's pretend at least, for the sake of this example)
|
||||
```
|
||||
|
||||
This translates into the following JSON Object:
|
||||
```json
|
||||
{
|
||||
"MESSAGE" : "Hello World",
|
||||
"_UDEV_DEVNODE" : "/dev/waldo",
|
||||
"_UDEV_DEVLINK" : [ "/dev/alias1", "/dev/alias2" ],
|
||||
"BINARY" : [ 116, 104, 105, 115, 32, 105, 115, 32, 97, 32, 98, 105, 110, 97, 114, 121, 32, 118, 97, 108, 117, 101, 32, 7 ],
|
||||
"LARGE" : null
|
||||
}
|
||||
```
|
@ -297,7 +297,7 @@ STATE_ARCHIVED. If a writer is asked to write to a file that is not in
|
||||
STATE_OFFLINE it should immediately rotate the file and start a new one,
|
||||
without changing the file.
|
||||
|
||||
After and before the state field is changed `fdatasync()` should be executed on
|
||||
After and before the state field is changed, `fdatasync()` should be executed on
|
||||
the file to ensure the dirty state hits disk.
|
||||
|
||||
|
||||
|
@ -17,7 +17,7 @@ SPDX-License-Identifier: LGPL-2.1-or-later
|
||||
|
||||
The latter is what this document is about: if you are developing a program and
|
||||
want to pass structured log data to `journald`, it's the Journal's native
|
||||
protocol what you want to use. The systemd project provides the
|
||||
protocol that you want to use. The systemd project provides the
|
||||
[`sd_journal_print(3)`](https://www.freedesktop.org/software/systemd/man/sd_journal_print.html)
|
||||
API that implements the client side of this protocol. This document explains
|
||||
what this interface does behind the scenes, in case you'd like to implement a
|
||||
@ -60,7 +60,7 @@ bytes however, as well as any other binary data. Keys may not include the `=`
|
||||
or newline characters (or any other control characters or non-ASCII characters)
|
||||
and may not be empty.
|
||||
|
||||
Serialization into the datagram payload or `memfd` is straight-forward: each
|
||||
Serialization into the datagram payload or `memfd` is straightforward: each
|
||||
key/value pair is serialized via one of two methods:
|
||||
|
||||
* The first method inserts a `=` character between key and value, and suffixes
|
||||
@ -185,7 +185,7 @@ took place for the current program.
|
||||
|
||||
If you are looking for alternative implementations of this protocol (besides
|
||||
systemd's own in `sd_journal_print()`), consider
|
||||
[GLib's](https://gitlab.gnome.org/GNOME/glib/-/blob/master/glib/gmessages.c) or
|
||||
[GLib's](https://gitlab.gnome.org/GNOME/glib/-/blob/main/glib/gmessages.c) or
|
||||
[`dbus-broker`'s](https://github.com/bus1/dbus-broker/blob/main/src/util/log.c).
|
||||
|
||||
And that's already all there is to it.
|
||||
|
@ -34,7 +34,7 @@ It is easy to write additional agents. The basic algorithm to follow looks like
|
||||
|
||||
Again, it is essential that you stop showing the password box/notification/status icon if the `ask.xxx` file is removed or when `NotAfter=` elapses (if it is set `!= 0`)!
|
||||
|
||||
It may happen that multiple password entries are pending at the same time. Your agent needs to be able to deal with that. Depending on your environment you may either choose to show all outstanding passwords at the same time or instead only one and as soon as the user replied to that one go on to the next one.
|
||||
It may happen that multiple password entries are pending at the same time. Your agent needs to be able to deal with that. Depending on your environment you may either choose to show all outstanding passwords at the same time or instead only one and as soon as the user has replied to that one go on to the next one.
|
||||
|
||||
You may test this all with manually invoking the "`systemd-ask-password`" tool on the command line. Pass `--no-tty` to ensure the password is asked via the agent system. Note that only privileged users may use this tool (after all this is intended purely for system-level passwords).
|
||||
|
||||
|
@ -101,6 +101,7 @@ And now, here's the list of (hopefully) all APIs that we have introduced with sy
|
||||
| [Link file format](https://www.freedesktop.org/software/systemd/man/systemd.link.html) | File format | yes | yes | no | no | - | no |
|
||||
| [Journal File Format](https://systemd.io/JOURNAL_FILE_FORMAT) | File format | yes | yes | - | maybe | - | no |
|
||||
| [Journal Export Format](https://systemd.io/JOURNAL_EXPORT_FORMATS#journal-export-format) | File format | yes | yes | - | yes | - | no |
|
||||
| [Journal JSON Format](https://systemd.io/JOURNAL_EXPORT_FORMATS#journal-json-format) | 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://systemd.io/PASSWORD_AGENTS) | Socket+Files | yes | yes | - | yes | - | no |
|
||||
| [udev multi-seat properties](https://www.freedesktop.org/software/systemd/man/sd-login.html) | udev Property | yes | yes | X11, gdm | no | - | no |
|
||||
|
@ -284,9 +284,12 @@ following must be also be observed:
|
||||
4. The upper extension(s) image(s) must at least contain one matching unit file each,
|
||||
with the right name prefix and suffix (see above).
|
||||
|
||||
5. As with the base/OS image, the upper extension(s) image(s) must be a plain
|
||||
sub-directory, a btrfs subvolume or a raw disk image.
|
||||
|
||||
```
|
||||
# portablectl attach --extension foobar_0.7.23.raw debian-runtime_11.1.raw foobar
|
||||
# portablectl attach --extension barbaz_7.0.23.raw debian-runtime_11.1.raw barbaz
|
||||
# portablectl attach --extension barbaz_7.0.23/ debian-runtime_11.1.raw barbaz
|
||||
```
|
||||
|
||||
## Execution Environment
|
||||
@ -331,3 +334,10 @@ behaviour, by setting the `ProtectSystem=strict` option. In this case writable
|
||||
service data may be placed on the host file system. Use `StateDirectory=` in
|
||||
the unit files to enable such behaviour and add a local data directory to the
|
||||
services copied onto the host.
|
||||
|
||||
## Links
|
||||
|
||||
[`portablectl(1)`](https://www.freedesktop.org/software/systemd/man/portablectl.html)<br>
|
||||
[`systemd-portabled.service(8)`](https://www.freedesktop.org/software/systemd/man/systemd-portabled.service.html)<br>
|
||||
[Walkthrough for Portable Services](https://0pointer.net/blog/walkthrough-for-portable-services.html)<br>
|
||||
[Repo with examples](https://github.com/systemd/portable-walkthrough)
|
||||
|
@ -53,9 +53,6 @@ architecture.
|
||||
support booting into OS trees that have an empty root directory with only
|
||||
`/usr/` mounted in.
|
||||
|
||||
7. If your architecture has a CPU opcode similar to x86' RDRAND consider adding
|
||||
native support for it to `src/basic/random-util.c`'s `rdrand()` function.
|
||||
|
||||
8. If your architecture supports VM virtualization and provides CPU opcodes
|
||||
7. If your architecture supports VM virtualization and provides CPU opcodes
|
||||
similar to x86' CPUID consider adding native support for detecting VMs this
|
||||
way to `src/basic/virt.c`.
|
||||
|
@ -144,33 +144,11 @@ acquired.
|
||||
## Keeping `systemd'`s Demand on the Kernel Entropy Pool Minimal
|
||||
|
||||
Since most of systemd's own use of random numbers do not require
|
||||
cryptographic-grade RNGs, it tries to avoid reading entropy from the kernel
|
||||
entropy pool if possible. If it succeeds this has the benefit that there's no
|
||||
need to delay the early boot process until entropy is available, and noisy
|
||||
kernel log messages about early reading from `/dev/urandom` are avoided
|
||||
too. Specifically:
|
||||
|
||||
1. When generating [Type 4
|
||||
UUIDs](https://en.wikipedia.org/wiki/Universally_unique_identifier#Version_4_\(random\)),
|
||||
systemd tries to use Intel's and AMD's RDRAND CPU opcode directly, if
|
||||
available. While some doubt the quality and trustworthiness of the entropy
|
||||
provided by these opcodes, they should be good enough for generating UUIDs,
|
||||
if not key material (though, as mentioned, today's big distributions opted
|
||||
to trust it for that too, now, see above — but we are not going to make that
|
||||
decision for you, and for anything key material related will only use the
|
||||
kernel's entropy pool). If RDRAND is not available or doesn't work, it will
|
||||
use synchronous `getrandom()` as fallback, and `/dev/urandom` on old kernels
|
||||
where that system call doesn't exist yet. This means on non-Intel/AMD
|
||||
systems UUID generation will block on kernel entropy initialization.
|
||||
|
||||
2. For seeding hash tables, and all the other similar purposes systemd first
|
||||
tries RDRAND, and if that's not available will try to use asynchronous
|
||||
`getrandom()` (if the kernel doesn't support this system call,
|
||||
`/dev/urandom` is used). This may fail too in case the pool is not
|
||||
initialized yet, in which case it will fall back to glibc's internal rand()
|
||||
calls, i.e. weak pseudo-random numbers. This should make sure we use good
|
||||
random bytes if we can, but neither delay boot nor trigger noisy kernel log
|
||||
messages during early boot for these use-cases.
|
||||
cryptographic-grade RNGs, it tries to avoid blocking reads to the kernel's RNG,
|
||||
opting instead for using `getrandom(GRND_INSECURE)`. After the pool is
|
||||
initialized, this is identical to `getrandom(0)`, returning cryptographically
|
||||
secure random numbers, but before it's initialized it has the nice effect of
|
||||
not blocking system boot.
|
||||
|
||||
## `systemd`'s Support for Filling the Kernel Entropy Pool
|
||||
|
||||
@ -280,10 +258,8 @@ early-boot entropy in most cases. Specifically:
|
||||
hosting provider if they don't. For VMs used in testing environments,
|
||||
`systemd.random_seed=` may be used as an alternative to a virtualized RNG.
|
||||
|
||||
3. On Intel/AMD systems systemd's own reliance on the kernel entropy pool is
|
||||
minimal (as RDRAND is used on those for UUID generation). This only works if
|
||||
the CPU has RDRAND of course, which most physical CPUs do (but I hear many
|
||||
virtualized CPUs do not. Pity.)
|
||||
3. In general, systemd's own reliance on the kernel entropy pool is minimal
|
||||
(due to the use of `GRND_INSECURE`).
|
||||
|
||||
4. In all other cases, `systemd-random-seed.service` will help a bit, but — as
|
||||
mentioned — is too late to help with early boot.
|
||||
|
@ -21,4 +21,4 @@ SPDX-License-Identifier: LGPL-2.1-or-later
|
||||
12. "Draft" a new release on github (https://github.com/systemd/systemd/releases/new), mark "This is a pre-release" if appropriate.
|
||||
13. Check that announcement to systemd-devel, with a copy&paste from NEWS, was sent. This should happen automatically.
|
||||
14. Update IRC topic (`/msg chanserv TOPIC #systemd Version NNN released`)
|
||||
15. [FINAL] Push commits to stable, create an empty -stable branch: `git push systemd-stable origin/master:master origin/master:refs/heads/${version}-stable`, and change the default branch to latest release (https://github.com/systemd/systemd-stable/settings/branches).
|
||||
15. [FINAL] Push commits to stable, create an empty -stable branch: `git push systemd-stable --atomic origin/main:main origin/main:refs/heads/${version}-stable`, and change the default branch to latest release (https://github.com/systemd/systemd-stable/settings/branches).
|
||||
|
@ -66,7 +66,7 @@ a network interface may configure.
|
||||
differentiate them. i.e. `~foo.com` is a configured routing domain, while
|
||||
`foo.com` would be a configured search domain.
|
||||
|
||||
One routing domain is particular interesting: `~.` — the catch-all routing
|
||||
One routing domain is particularly interesting: `~.` — the catch-all routing
|
||||
domain. (The *dot* domain `.` is how DNS denotes the "root" domain, i.e. the
|
||||
parent domain of all domains, but itself.) When used on an interface any DNS
|
||||
traffic is preferably routed to its DNS servers. (A search domain – i.e. `.`
|
||||
|
@ -81,7 +81,7 @@ available during earliest boot, including in the initial RAM disk).
|
||||
above). However, it does define some special group/GID assignments, which are
|
||||
primarily used for `systemd-udevd`'s device management. The precise list of the
|
||||
currently defined groups is found in this `sysusers.d` snippet:
|
||||
[basic.conf](https://raw.githubusercontent.com/systemd/systemd/master/sysusers.d/basic.conf.in)
|
||||
[basic.conf](https://raw.githubusercontent.com/systemd/systemd/main/sysusers.d/basic.conf.in)
|
||||
|
||||
It's strongly recommended that downstream distributions include these groups in
|
||||
their default group databases.
|
||||
@ -176,7 +176,7 @@ Systemd has compile-time default for these boundaries. Using those defaults is
|
||||
recommended. It will nevertheless query `/etc/login.defs` at runtime, when
|
||||
compiled with `-Dcompat-mutable-uid-boundaries=true` and that file is present.
|
||||
Support for this is considered only a compatibility feature and should not be
|
||||
used except when upgrading systems which were creating with different defaults.
|
||||
used except when upgrading systems which were created with different defaults.
|
||||
|
||||
## Considerations for container managers
|
||||
|
||||
@ -233,6 +233,27 @@ safely use the NSS user database as allocation check, too. Note that if you
|
||||
follow this scheme no changes to `/etc/passwd` need to be made, thus minimizing
|
||||
the artifacts the container manager persistently leaves in the system.
|
||||
|
||||
5. `systemd-homed` by default mounts the home directories it manages with UID
|
||||
mapping applied. It will map four UID ranges into that uidmap, and leave
|
||||
everything else unmapped: the range from 0…60000, the user's own UID, the range
|
||||
60514…65534, and the container range 524288…1879048191. This means
|
||||
files/directories in home directories managed by `systemd-homed` cannot be
|
||||
owned by UIDs/GIDs outside of these four ranges (attempts to `chown()` files to
|
||||
UIDs outside of these ranges will fail). Thus, if container trees are to be
|
||||
placed within a home directory managed by `systemd-homed` they should take
|
||||
these ranges into consideration and either place the trees at base UID 0 (and
|
||||
then map them to a higher UID range for use in user namespacing via another
|
||||
level of UID mapped mounts, at *runtime*) or at a base UID from the container
|
||||
UID range. That said, placing container trees (and in fact any
|
||||
files/directories not owned by the home directory's user) in home directories
|
||||
is generally a questionable idea (regardless of whether `systemd-homed` is used
|
||||
or not), given this typically breaks quota assumptions, makes it impossible for
|
||||
users to properly manage all files in their own home directory due to
|
||||
permission problems, introduces security issues around SETUID and severely
|
||||
restricts compatibility with networked home directories. Typically, it's a much
|
||||
better idea to place container images outside of the home directory,
|
||||
i.e. somewhere below `/var/` or similar.
|
||||
|
||||
## Summary
|
||||
|
||||
| UID/GID | Purpose | Defined By | Listed in |
|
||||
@ -255,18 +276,19 @@ the artifacts the container manager persistently leaves in the system.
|
||||
| 2147483648…4294967294 | HIC SVNT LEONES | | |
|
||||
| 4294967295 | 32bit `(uid_t) -1` | Linux | |
|
||||
|
||||
Note that "Unused" in the table above doesn't meant that these ranges are
|
||||
Note that "Unused" in the table above doesn't mean that these ranges are
|
||||
really unused. It just means that these ranges have no well-established
|
||||
pre-defined purposes between Linux, generic low-level distributions and
|
||||
`systemd`. There might very well be other packages that allocate from these
|
||||
ranges.
|
||||
|
||||
Note that the range 2147483648…4294967294 (i.e. 2^31…2^32-2) should be handled
|
||||
with care. Various programs (including kernel file systems, see `devpts`) have
|
||||
trouble with UIDs outside of the signed 32bit range, i.e any UIDs equal to or
|
||||
above 2147483648. It is thus strongly recommended to stay away from this range
|
||||
in order to avoid complications. This range should be considered reserved for
|
||||
future, special purposes.
|
||||
with care. Various programs (including kernel file systems — see `devpts` — or
|
||||
even kernel syscalls – see `setfsuid()`) have trouble with UIDs outside of the
|
||||
signed 32bit range, i.e any UIDs equal to or above 2147483648. It is thus
|
||||
strongly recommended to stay away from this range in order to avoid
|
||||
complications. This range should be considered reserved for future, special
|
||||
purposes.
|
||||
|
||||
## Notes on resolvability of user and group names
|
||||
|
||||
|
@ -241,7 +241,7 @@ 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.)
|
||||
to talk to, the client needs to provide the name in each request.)
|
||||
|
||||
The `GetGroupRecord` method call works analogously but for groups.
|
||||
|
||||
@ -257,7 +257,7 @@ with `more` set, so that multiple replies can be returned (since typically
|
||||
there 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
|
||||
allow implementation of multiple services 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`.
|
||||
@ -270,7 +270,7 @@ 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
|
||||
acquire the full list of memberships. The full list can only be 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
|
||||
|
@ -114,7 +114,7 @@ warning is shown if the specified user name does not qualify by the strict
|
||||
rules above.
|
||||
|
||||
* No embedded NUL bytes (rationale: handling in C must be possible and
|
||||
straight-forward)
|
||||
straightforward)
|
||||
|
||||
* No names consisting fully of digits (rationale: avoid confusion with numeric
|
||||
UID/GID specifications)
|
||||
|
@ -333,7 +333,7 @@ values, which is then inherited by all the user's processes, see
|
||||
[`setrlimit()`](http://man7.org/linux/man-pages/man2/setrlimit.2.html) for more
|
||||
information.
|
||||
|
||||
`locked` → A boolean value. If true the user account is locked, the user may
|
||||
`locked` → A boolean value. If true, the user account is locked, the user may
|
||||
not log in. If this field is missing it should be assumed to be false,
|
||||
i.e. logins are permitted. This field corresponds to the `sp_expire` field of
|
||||
`struct spwd` (i.e. the `/etc/shadow` data for a user) being set to zero or
|
||||
@ -359,11 +359,11 @@ directory, also containing the `~/.identity` user record; `luks` is a per-user
|
||||
LUKS volume that is mounted as home directory, and `cifs` a home directory
|
||||
mounted from a Windows File Share. The five latter types are primarily used by
|
||||
`systemd-homed` when managing home directories, but may be used if other
|
||||
managers are used too. If this is not set `classic` is the implied default.
|
||||
managers are used too. If this is not set, `classic` is the implied default.
|
||||
|
||||
`diskSize` → An unsigned 64bit integer, indicating the intended home directory
|
||||
disk space in bytes to assign to the user. Depending on the selected storage
|
||||
type this might be implement differently: for `luks` this is the intended size
|
||||
type this might be implemented differently: for `luks` this is the intended size
|
||||
of the file system and LUKS volume, while for the others this likely translates
|
||||
to classic file system quota settings.
|
||||
|
||||
@ -425,7 +425,7 @@ the top-level directory of the CIFS share is used.
|
||||
|
||||
`imagePath` → A string with an absolute file system path to the file, directory
|
||||
or block device to use for storage backing the home directory. If the `luks`
|
||||
storage is used this refers to the loopback file or block device node to store
|
||||
storage is used, this refers to the loopback file or block device node to store
|
||||
the LUKS volume on. For `fscrypt`, `directory`, `subvolume` this refers to the
|
||||
directory to bind mount as home directory on login. Not defined for `classic`
|
||||
or `cifs`.
|
||||
@ -465,7 +465,7 @@ relevant when the storage mechanism used is `luks`.
|
||||
referencing the file system UUID the home directory is located in. This is
|
||||
primarily relevant when the storage mechanism used is `luks`.
|
||||
|
||||
`luksDiscard` → A boolean. If true and `luks` storage is used controls whether
|
||||
`luksDiscard` → A boolean. If true and `luks` storage is used, controls whether
|
||||
the loopback block devices, LUKS and the file system on top shall be used in
|
||||
`discard` mode, i.e. erased sectors should always be returned to the underlying
|
||||
storage. If false and `luks` storage is used turns this behavior off. In
|
||||
@ -579,7 +579,7 @@ against all plugged in security tokens and if there's exactly one matching
|
||||
private key found with it it is used.
|
||||
|
||||
`fido2HmacCredential` → An array of strings, each with a Base64-encoded FIDO2
|
||||
credential ID that shell be used for authentication with FIDO2 devices that
|
||||
credential ID that shall be used for authentication with FIDO2 devices that
|
||||
implement the `hmac-secret` extension. The salt to pass to the FIDO2 device is
|
||||
found in `fido2HmacSalt`.
|
||||
|
||||
|
@ -1,7 +1,7 @@
|
||||
<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
|
||||
|
||||
<footer class="site-footer">
|
||||
<p>© systemd, 2021</p>
|
||||
<p>© systemd, 2022</p>
|
||||
|
||||
<p><a href="https://github.com/systemd/systemd/tree/main/docs">Website source</a></p>
|
||||
</footer>
|
||||
|
3
factory/templates/locale.conf.in
Normal file
3
factory/templates/locale.conf.in
Normal file
@ -0,0 +1,3 @@
|
||||
# This is the fallback locale configuration provided by systemd.
|
||||
|
||||
LANG="{{ SYSTEMD_DEFAULT_LOCALE }}"
|
11
factory/templates/meson.build
Normal file
11
factory/templates/meson.build
Normal file
@ -0,0 +1,11 @@
|
||||
# SPDX-License-Identifier: LGPL-2.1-or-later
|
||||
|
||||
factory_etc_dir = factorydir / 'etc'
|
||||
|
||||
custom_target(
|
||||
'locale.conf',
|
||||
input : 'locale.conf.in',
|
||||
output : 'locale.conf',
|
||||
command : [meson_render_jinja2, config_h, '@INPUT@', '@OUTPUT@'],
|
||||
install : true,
|
||||
install_dir : factory_etc_dir)
|
2415
hwdb.d/20-OUI.hwdb
2415
hwdb.d/20-OUI.hwdb
File diff suppressed because it is too large
Load Diff
@ -51,6 +51,9 @@ acpi:ATML*:
|
||||
acpi:AUTH*:
|
||||
ID_VENDOR_FROM_DATABASE=AuthenTec
|
||||
|
||||
acpi:AWDZ*:
|
||||
ID_VENDOR_FROM_DATABASE=Shanghai Aiwei Electronic Technology Co., Ltd.
|
||||
|
||||
acpi:BABA*:
|
||||
ID_VENDOR_FROM_DATABASE=Alibaba Co., Ltd.
|
||||
|
||||
@ -219,6 +222,9 @@ acpi:MSHW*:
|
||||
acpi:MXIM*:
|
||||
ID_VENDOR_FROM_DATABASE=Maxim Integrated
|
||||
|
||||
acpi:NOLO*:
|
||||
ID_VENDOR_FROM_DATABASE=NOLO VR
|
||||
|
||||
acpi:NVDA*:
|
||||
ID_VENDOR_FROM_DATABASE=Nvidia
|
||||
|
||||
@ -273,6 +279,9 @@ acpi:SECC*:
|
||||
acpi:SHRP*:
|
||||
ID_VENDOR_FROM_DATABASE=Sharp Corporation
|
||||
|
||||
acpi:SILC*:
|
||||
ID_VENDOR_FROM_DATABASE=Silicom Ltd. Connectivity Solutions
|
||||
|
||||
acpi:SNSL*:
|
||||
ID_VENDOR_FROM_DATABASE=Sensel, Inc.
|
||||
|
||||
@ -912,6 +921,9 @@ acpi:ATV*:
|
||||
acpi:ATX*:
|
||||
ID_VENDOR_FROM_DATABASE=Athenix Corporation
|
||||
|
||||
acpi:AUD*:
|
||||
ID_VENDOR_FROM_DATABASE=AudioControl
|
||||
|
||||
acpi:AUG*:
|
||||
ID_VENDOR_FROM_DATABASE=August Home, Inc.
|
||||
|
||||
@ -6036,6 +6048,9 @@ acpi:SBS*:
|
||||
acpi:SBT*:
|
||||
ID_VENDOR_FROM_DATABASE=Senseboard Technologies AB
|
||||
|
||||
acpi:SCA*:
|
||||
ID_VENDOR_FROM_DATABASE=Schneider Consumer Group
|
||||
|
||||
acpi:SCB*:
|
||||
ID_VENDOR_FROM_DATABASE=SeeCubic B.V.
|
||||
|
||||
@ -6156,6 +6171,9 @@ acpi:SES*:
|
||||
acpi:SET*:
|
||||
ID_VENDOR_FROM_DATABASE=SendTek Corporation
|
||||
|
||||
acpi:SFL*:
|
||||
ID_VENDOR_FROM_DATABASE=Shiftall Inc.
|
||||
|
||||
acpi:SFM*:
|
||||
ID_VENDOR_FROM_DATABASE=TORNADO Company
|
||||
|
||||
|
@ -1,5 +1,5 @@
|
||||
--- 20-acpi-vendor.hwdb.base 2021-12-23 19:33:43.195441335 +0900
|
||||
+++ 20-acpi-vendor.hwdb 2021-12-23 19:33:43.215441358 +0900
|
||||
--- 20-acpi-vendor.hwdb.base 2022-03-29 12:18:39.832815359 +0200
|
||||
+++ 20-acpi-vendor.hwdb 2022-03-29 12:18:39.838815428 +0200
|
||||
@@ -3,6 +3,8 @@
|
||||
# Data imported from:
|
||||
# https://uefi.org/uefi-pnp-export
|
||||
@ -19,7 +19,7 @@
|
||||
acpi:AMDI*:
|
||||
ID_VENDOR_FROM_DATABASE=AMD
|
||||
|
||||
@@ -325,6 +324,9 @@
|
||||
@@ -334,6 +333,9 @@
|
||||
acpi:AAA*:
|
||||
ID_VENDOR_FROM_DATABASE=Avolites Ltd
|
||||
|
||||
@ -29,7 +29,7 @@
|
||||
acpi:AAE*:
|
||||
ID_VENDOR_FROM_DATABASE=Anatek Electronics Inc.
|
||||
|
||||
@@ -352,6 +354,9 @@
|
||||
@@ -361,6 +363,9 @@
|
||||
acpi:ABO*:
|
||||
ID_VENDOR_FROM_DATABASE=D-Link Systems Inc
|
||||
|
||||
@ -39,7 +39,7 @@
|
||||
acpi:ABS*:
|
||||
ID_VENDOR_FROM_DATABASE=Abaco Systems, Inc.
|
||||
|
||||
@@ -397,7 +402,7 @@
|
||||
@@ -406,7 +411,7 @@
|
||||
acpi:ACO*:
|
||||
ID_VENDOR_FROM_DATABASE=Allion Computer Inc.
|
||||
|
||||
@ -48,7 +48,7 @@
|
||||
ID_VENDOR_FROM_DATABASE=Aspen Tech Inc
|
||||
|
||||
acpi:ACR*:
|
||||
@@ -673,6 +678,9 @@
|
||||
@@ -682,6 +687,9 @@
|
||||
acpi:AMT*:
|
||||
ID_VENDOR_FROM_DATABASE=AMT International Industry
|
||||
|
||||
@ -58,7 +58,7 @@
|
||||
acpi:AMX*:
|
||||
ID_VENDOR_FROM_DATABASE=AMX LLC
|
||||
|
||||
@@ -721,6 +729,9 @@
|
||||
@@ -730,6 +738,9 @@
|
||||
acpi:AOA*:
|
||||
ID_VENDOR_FROM_DATABASE=AOpen Inc.
|
||||
|
||||
@ -68,7 +68,7 @@
|
||||
acpi:AOE*:
|
||||
ID_VENDOR_FROM_DATABASE=Advanced Optics Electronics, Inc.
|
||||
|
||||
@@ -730,6 +741,9 @@
|
||||
@@ -739,6 +750,9 @@
|
||||
acpi:AOT*:
|
||||
ID_VENDOR_FROM_DATABASE=Alcatel
|
||||
|
||||
@ -78,7 +78,7 @@
|
||||
acpi:APC*:
|
||||
ID_VENDOR_FROM_DATABASE=American Power Conversion
|
||||
|
||||
@@ -905,7 +919,7 @@
|
||||
@@ -917,7 +931,7 @@
|
||||
ID_VENDOR_FROM_DATABASE=ALPS ALPINE CO., LTD.
|
||||
|
||||
acpi:AUO*:
|
||||
@ -87,7 +87,7 @@
|
||||
|
||||
acpi:AUR*:
|
||||
ID_VENDOR_FROM_DATABASE=Aureal Semiconductor
|
||||
@@ -985,6 +999,9 @@
|
||||
@@ -997,6 +1011,9 @@
|
||||
acpi:AXE*:
|
||||
ID_VENDOR_FROM_DATABASE=Axell Corporation
|
||||
|
||||
@ -97,7 +97,7 @@
|
||||
acpi:AXI*:
|
||||
ID_VENDOR_FROM_DATABASE=American Magnetics
|
||||
|
||||
@@ -1135,6 +1152,9 @@
|
||||
@@ -1147,6 +1164,9 @@
|
||||
acpi:BML*:
|
||||
ID_VENDOR_FROM_DATABASE=BIOMED Lab
|
||||
|
||||
@ -107,7 +107,7 @@
|
||||
acpi:BMS*:
|
||||
ID_VENDOR_FROM_DATABASE=BIOMEDISYS
|
||||
|
||||
@@ -1147,6 +1167,9 @@
|
||||
@@ -1159,6 +1179,9 @@
|
||||
acpi:BNO*:
|
||||
ID_VENDOR_FROM_DATABASE=Bang & Olufsen
|
||||
|
||||
@ -117,7 +117,7 @@
|
||||
acpi:BNS*:
|
||||
ID_VENDOR_FROM_DATABASE=Boulder Nonlinear Systems
|
||||
|
||||
@@ -1390,6 +1413,9 @@
|
||||
@@ -1402,6 +1425,9 @@
|
||||
acpi:CHA*:
|
||||
ID_VENDOR_FROM_DATABASE=Chase Research PLC
|
||||
|
||||
@ -127,7 +127,7 @@
|
||||
acpi:CHD*:
|
||||
ID_VENDOR_FROM_DATABASE=ChangHong Electric Co.,Ltd
|
||||
|
||||
@@ -1552,6 +1578,9 @@
|
||||
@@ -1564,6 +1590,9 @@
|
||||
acpi:COD*:
|
||||
ID_VENDOR_FROM_DATABASE=CODAN Pty. Ltd.
|
||||
|
||||
@ -137,7 +137,7 @@
|
||||
acpi:COI*:
|
||||
ID_VENDOR_FROM_DATABASE=Codec Inc.
|
||||
|
||||
@@ -1961,7 +1990,7 @@
|
||||
@@ -1973,7 +2002,7 @@
|
||||
ID_VENDOR_FROM_DATABASE=Dragon Information Technology
|
||||
|
||||
acpi:DJE*:
|
||||
@ -146,7 +146,7 @@
|
||||
|
||||
acpi:DJP*:
|
||||
ID_VENDOR_FROM_DATABASE=Maygay Machines, Ltd
|
||||
@@ -2299,6 +2328,9 @@
|
||||
@@ -2311,6 +2340,9 @@
|
||||
acpi:EIN*:
|
||||
ID_VENDOR_FROM_DATABASE=Elegant Invention
|
||||
|
||||
@ -156,7 +156,7 @@
|
||||
acpi:EKA*:
|
||||
ID_VENDOR_FROM_DATABASE=MagTek Inc.
|
||||
|
||||
@@ -2563,6 +2595,9 @@
|
||||
@@ -2575,6 +2607,9 @@
|
||||
acpi:FCG*:
|
||||
ID_VENDOR_FROM_DATABASE=First International Computer Ltd
|
||||
|
||||
@ -166,7 +166,7 @@
|
||||
acpi:FCS*:
|
||||
ID_VENDOR_FROM_DATABASE=Focus Enhancements, Inc.
|
||||
|
||||
@@ -2939,7 +2974,7 @@
|
||||
@@ -2951,7 +2986,7 @@
|
||||
ID_VENDOR_FROM_DATABASE=General Standards Corporation
|
||||
|
||||
acpi:GSM*:
|
||||
@ -175,7 +175,7 @@
|
||||
|
||||
acpi:GSN*:
|
||||
ID_VENDOR_FROM_DATABASE=Grandstream Networks, Inc.
|
||||
@@ -3040,6 +3075,9 @@
|
||||
@@ -3052,6 +3087,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
|
||||
|
||||
@@ -3172,6 +3210,9 @@
|
||||
@@ -3184,6 +3222,9 @@
|
||||
acpi:HSD*:
|
||||
ID_VENDOR_FROM_DATABASE=HannStar Display Corp
|
||||
|
||||
@ -195,7 +195,7 @@
|
||||
acpi:HSM*:
|
||||
ID_VENDOR_FROM_DATABASE=AT&T Microelectronics
|
||||
|
||||
@@ -3298,6 +3339,9 @@
|
||||
@@ -3310,6 +3351,9 @@
|
||||
acpi:ICI*:
|
||||
ID_VENDOR_FROM_DATABASE=Infotek Communication Inc
|
||||
|
||||
@ -205,7 +205,7 @@
|
||||
acpi:ICM*:
|
||||
ID_VENDOR_FROM_DATABASE=Intracom SA
|
||||
|
||||
@@ -3394,6 +3438,9 @@
|
||||
@@ -3406,6 +3450,9 @@
|
||||
acpi:IKE*:
|
||||
ID_VENDOR_FROM_DATABASE=Ikegami Tsushinki Co. Ltd.
|
||||
|
||||
@ -215,7 +215,7 @@
|
||||
acpi:IKS*:
|
||||
ID_VENDOR_FROM_DATABASE=Ikos Systems Inc
|
||||
|
||||
@@ -3439,6 +3486,9 @@
|
||||
@@ -3451,6 +3498,9 @@
|
||||
acpi:IMT*:
|
||||
ID_VENDOR_FROM_DATABASE=Inmax Technology Corporation
|
||||
|
||||
@ -225,7 +225,7 @@
|
||||
acpi:INA*:
|
||||
ID_VENDOR_FROM_DATABASE=Inventec Corporation
|
||||
|
||||
@@ -3955,6 +4005,9 @@
|
||||
@@ -3967,6 +4017,9 @@
|
||||
acpi:LAN*:
|
||||
ID_VENDOR_FROM_DATABASE=Sodeman Lancom Inc
|
||||
|
||||
@ -235,7 +235,7 @@
|
||||
acpi:LAS*:
|
||||
ID_VENDOR_FROM_DATABASE=LASAT Comm. A/S
|
||||
|
||||
@@ -4003,6 +4056,9 @@
|
||||
@@ -4015,6 +4068,9 @@
|
||||
acpi:LED*:
|
||||
ID_VENDOR_FROM_DATABASE=Long Engineering Design Inc
|
||||
|
||||
@ -245,7 +245,7 @@
|
||||
acpi:LEG*:
|
||||
ID_VENDOR_FROM_DATABASE=Legerity, Inc
|
||||
|
||||
@@ -4018,6 +4074,9 @@
|
||||
@@ -4030,6 +4086,9 @@
|
||||
acpi:LGC*:
|
||||
ID_VENDOR_FROM_DATABASE=Logic Ltd
|
||||
|
||||
@ -255,7 +255,7 @@
|
||||
acpi:LGI*:
|
||||
ID_VENDOR_FROM_DATABASE=Logitech Inc
|
||||
|
||||
@@ -4075,6 +4134,9 @@
|
||||
@@ -4087,6 +4146,9 @@
|
||||
acpi:LND*:
|
||||
ID_VENDOR_FROM_DATABASE=Land Computer Company Ltd
|
||||
|
||||
@ -265,7 +265,7 @@
|
||||
acpi:LNK*:
|
||||
ID_VENDOR_FROM_DATABASE=Link Tech Inc
|
||||
|
||||
@@ -4109,7 +4171,7 @@
|
||||
@@ -4121,7 +4183,7 @@
|
||||
ID_VENDOR_FROM_DATABASE=Design Technology
|
||||
|
||||
acpi:LPL*:
|
||||
@ -274,7 +274,7 @@
|
||||
|
||||
acpi:LSC*:
|
||||
ID_VENDOR_FROM_DATABASE=LifeSize Communications
|
||||
@@ -4285,6 +4347,9 @@
|
||||
@@ -4297,6 +4359,9 @@
|
||||
acpi:MCX*:
|
||||
ID_VENDOR_FROM_DATABASE=Millson Custom Solutions Inc.
|
||||
|
||||
@ -284,7 +284,7 @@
|
||||
acpi:MDA*:
|
||||
ID_VENDOR_FROM_DATABASE=Media4 Inc
|
||||
|
||||
@@ -4525,6 +4590,9 @@
|
||||
@@ -4537,6 +4602,9 @@
|
||||
acpi:MOM*:
|
||||
ID_VENDOR_FROM_DATABASE=Momentum Data Systems
|
||||
|
||||
@ -294,7 +294,7 @@
|
||||
acpi:MOS*:
|
||||
ID_VENDOR_FROM_DATABASE=Moses Corporation
|
||||
|
||||
@@ -4759,6 +4827,9 @@
|
||||
@@ -4771,6 +4839,9 @@
|
||||
acpi:NAL*:
|
||||
ID_VENDOR_FROM_DATABASE=Network Alchemy
|
||||
|
||||
@ -304,7 +304,7 @@
|
||||
acpi:NAT*:
|
||||
ID_VENDOR_FROM_DATABASE=NaturalPoint Inc.
|
||||
|
||||
@@ -5281,6 +5352,9 @@
|
||||
@@ -5293,6 +5364,9 @@
|
||||
acpi:PCX*:
|
||||
ID_VENDOR_FROM_DATABASE=PC Xperten
|
||||
|
||||
@ -314,7 +314,7 @@
|
||||
acpi:PDM*:
|
||||
ID_VENDOR_FROM_DATABASE=Psion Dacom Plc.
|
||||
|
||||
@@ -5344,9 +5418,6 @@
|
||||
@@ -5356,9 +5430,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
|
||||
|
||||
@@ -5437,9 +5508,6 @@
|
||||
@@ -5449,9 +5520,6 @@
|
||||
acpi:PNL*:
|
||||
ID_VENDOR_FROM_DATABASE=Panelview, Inc.
|
||||
|
||||
@ -334,7 +334,7 @@
|
||||
acpi:PNR*:
|
||||
ID_VENDOR_FROM_DATABASE=Planar Systems, Inc.
|
||||
|
||||
@@ -5575,15 +5643,9 @@
|
||||
@@ -5587,15 +5655,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
|
||||
|
||||
@@ -5899,9 +5961,6 @@
|
||||
@@ -5911,9 +5973,6 @@
|
||||
acpi:RTI*:
|
||||
ID_VENDOR_FROM_DATABASE=Rancho Tech Inc
|
||||
|
||||
@ -360,7 +360,7 @@
|
||||
acpi:RTL*:
|
||||
ID_VENDOR_FROM_DATABASE=Realtek Semiconductor Company Ltd
|
||||
|
||||
@@ -6070,9 +6129,6 @@
|
||||
@@ -6085,9 +6144,6 @@
|
||||
acpi:SEE*:
|
||||
ID_VENDOR_FROM_DATABASE=SeeColor Corporation
|
||||
|
||||
@ -370,7 +370,7 @@
|
||||
acpi:SEI*:
|
||||
ID_VENDOR_FROM_DATABASE=Seitz & Associates Inc
|
||||
|
||||
@@ -6541,6 +6597,9 @@
|
||||
@@ -6559,6 +6615,9 @@
|
||||
acpi:SVD*:
|
||||
ID_VENDOR_FROM_DATABASE=SVD Computer
|
||||
|
||||
@ -380,7 +380,7 @@
|
||||
acpi:SVI*:
|
||||
ID_VENDOR_FROM_DATABASE=Sun Microsystems
|
||||
|
||||
@@ -6625,6 +6684,9 @@
|
||||
@@ -6643,6 +6702,9 @@
|
||||
acpi:SZM*:
|
||||
ID_VENDOR_FROM_DATABASE=Shenzhen MTC Co., Ltd
|
||||
|
||||
@ -390,7 +390,7 @@
|
||||
acpi:TAA*:
|
||||
ID_VENDOR_FROM_DATABASE=Tandberg
|
||||
|
||||
@@ -6715,6 +6777,9 @@
|
||||
@@ -6733,6 +6795,9 @@
|
||||
acpi:TDG*:
|
||||
ID_VENDOR_FROM_DATABASE=Six15 Technologies
|
||||
|
||||
@ -400,7 +400,7 @@
|
||||
acpi:TDM*:
|
||||
ID_VENDOR_FROM_DATABASE=Tandem Computer Europe Inc
|
||||
|
||||
@@ -6757,6 +6822,9 @@
|
||||
@@ -6775,6 +6840,9 @@
|
||||
acpi:TEV*:
|
||||
ID_VENDOR_FROM_DATABASE=Televés, S.A.
|
||||
|
||||
@ -410,7 +410,7 @@
|
||||
acpi:TEZ*:
|
||||
ID_VENDOR_FROM_DATABASE=Tech Source Inc.
|
||||
|
||||
@@ -6880,9 +6948,6 @@
|
||||
@@ -6898,9 +6966,6 @@
|
||||
acpi:TNC*:
|
||||
ID_VENDOR_FROM_DATABASE=TNC Industrial Company Ltd
|
||||
|
||||
@ -420,7 +420,7 @@
|
||||
acpi:TNM*:
|
||||
ID_VENDOR_FROM_DATABASE=TECNIMAGEN SA
|
||||
|
||||
@@ -7192,14 +7257,14 @@
|
||||
@@ -7210,14 +7275,14 @@
|
||||
acpi:UNC*:
|
||||
ID_VENDOR_FROM_DATABASE=Unisys Corporation
|
||||
|
||||
@ -441,7 +441,7 @@
|
||||
|
||||
acpi:UNI*:
|
||||
ID_VENDOR_FROM_DATABASE=Uniform Industry Corp.
|
||||
@@ -7234,6 +7299,9 @@
|
||||
@@ -7252,6 +7317,9 @@
|
||||
acpi:USA*:
|
||||
ID_VENDOR_FROM_DATABASE=Utimaco Safeware AG
|
||||
|
||||
@ -451,7 +451,7 @@
|
||||
acpi:USD*:
|
||||
ID_VENDOR_FROM_DATABASE=U.S. Digital Corporation
|
||||
|
||||
@@ -7489,9 +7557,6 @@
|
||||
@@ -7507,9 +7575,6 @@
|
||||
acpi:WAL*:
|
||||
ID_VENDOR_FROM_DATABASE=Wave Access
|
||||
|
||||
@ -461,7 +461,7 @@
|
||||
acpi:WAV*:
|
||||
ID_VENDOR_FROM_DATABASE=Wavephore
|
||||
|
||||
@@ -7616,7 +7681,7 @@
|
||||
@@ -7634,7 +7699,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.
|
||||
@@ -7630,9 +7695,6 @@
|
||||
@@ -7648,9 +7713,6 @@
|
||||
acpi:XDM*:
|
||||
ID_VENDOR_FROM_DATABASE=XDM Ltd.
|
||||
|
||||
@ -480,7 +480,7 @@
|
||||
acpi:XES*:
|
||||
ID_VENDOR_FROM_DATABASE=Extreme Engineering Solutions, Inc.
|
||||
|
||||
@@ -7663,9 +7725,6 @@
|
||||
@@ -7681,9 +7743,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
|
||||
|
||||
@@ -7732,6 +7791,9 @@
|
||||
@@ -7750,6 +7809,9 @@
|
||||
acpi:ZBX*:
|
||||
ID_VENDOR_FROM_DATABASE=Zebax Technologies
|
||||
|
||||
|
@ -4,3 +4,7 @@
|
||||
dmi:bvnLENOVO*
|
||||
ID_SYSFS_ATTRIBUTE_MODEL=product_version
|
||||
ID_VENDOR_FROM_DATABASE=Lenovo
|
||||
|
||||
# Microsoft Surface 1's chassis type
|
||||
dmi:bvnMicrosoft Corporation*:pvrSurface with Windows 8 Pro*
|
||||
ID_CHASSIS=tablet
|
||||
|
@ -612,7 +612,7 @@ pci:v*d*sv*sd*bc12sc00*
|
||||
ID_PCI_SUBCLASS_FROM_DATABASE=Processing accelerators
|
||||
|
||||
pci:v*d*sv*sd*bc12sc01*
|
||||
ID_PCI_SUBCLASS_FROM_DATABASE=AI Inference Accelerator
|
||||
ID_PCI_SUBCLASS_FROM_DATABASE=SNIA Smart Data Accelerator Interface (SDXI) controller
|
||||
|
||||
pci:v*d*sv*sd*bc13*
|
||||
ID_PCI_CLASS_FROM_DATABASE=Non-Essential Instrumentation
|
||||
|
File diff suppressed because it is too large
Load Diff
@ -8078,6 +8078,12 @@ usb:v046Dp0846*
|
||||
usb:v046Dp084B*
|
||||
ID_MODEL_FROM_DATABASE=ConferenceCam Connect Video
|
||||
|
||||
usb:v046Dp084C*
|
||||
ID_MODEL_FROM_DATABASE=ConferenceCam Connect Audio
|
||||
|
||||
usb:v046Dp084E*
|
||||
ID_MODEL_FROM_DATABASE=ConferenceCam Connect
|
||||
|
||||
usb:v046Dp0850*
|
||||
ID_MODEL_FROM_DATABASE=QuickCam Web
|
||||
|
||||
@ -8235,7 +8241,7 @@ usb:v046Dp08D9*
|
||||
ID_MODEL_FROM_DATABASE=QuickCam IM/Connect
|
||||
|
||||
usb:v046Dp08DA*
|
||||
ID_MODEL_FROM_DATABASE=QuickCam Messanger
|
||||
ID_MODEL_FROM_DATABASE=QuickCam Messenger
|
||||
|
||||
usb:v046Dp08DD*
|
||||
ID_MODEL_FROM_DATABASE=QuickCam for Notebooks
|
||||
@ -8652,7 +8658,7 @@ usb:v046DpC06C*
|
||||
ID_MODEL_FROM_DATABASE=Optical Mouse
|
||||
|
||||
usb:v046DpC077*
|
||||
ID_MODEL_FROM_DATABASE=M105 Optical Mouse
|
||||
ID_MODEL_FROM_DATABASE=Mouse
|
||||
|
||||
usb:v046DpC07C*
|
||||
ID_MODEL_FROM_DATABASE=M-R0017 [G700s Rechargeable Gaming Mouse]
|
||||
@ -8676,7 +8682,7 @@ usb:v046DpC08B*
|
||||
ID_MODEL_FROM_DATABASE=G502 SE HERO Gaming Mouse
|
||||
|
||||
usb:v046DpC092*
|
||||
ID_MODEL_FROM_DATABASE=G203 LIGHTSYNC Gaming Mouse
|
||||
ID_MODEL_FROM_DATABASE=G102/G203 LIGHTSYNC Gaming Mouse
|
||||
|
||||
usb:v046DpC101*
|
||||
ID_MODEL_FROM_DATABASE=UltraX Media Remote
|
||||
@ -9122,6 +9128,9 @@ usb:v046DpC534*
|
||||
usb:v046DpC537*
|
||||
ID_MODEL_FROM_DATABASE=Cordless Mouse Receiver
|
||||
|
||||
usb:v046DpC539*
|
||||
ID_MODEL_FROM_DATABASE=Cordless Mouse Receiver
|
||||
|
||||
usb:v046DpC53A*
|
||||
ID_MODEL_FROM_DATABASE=PowerPlay Wireless Charging System
|
||||
|
||||
@ -58655,6 +58664,9 @@ usb:v1A86p5523*
|
||||
usb:v1A86p5584*
|
||||
ID_MODEL_FROM_DATABASE=CH341 in parallel mode, usb to printer port converter
|
||||
|
||||
usb:v1A86p7522*
|
||||
ID_MODEL_FROM_DATABASE=CH340 serial converter
|
||||
|
||||
usb:v1A86p7523*
|
||||
ID_MODEL_FROM_DATABASE=CH340 serial converter
|
||||
|
||||
@ -58665,7 +58677,7 @@ usb:v1A86p7584*
|
||||
ID_MODEL_FROM_DATABASE=CH340S
|
||||
|
||||
usb:v1A86pE008*
|
||||
ID_MODEL_FROM_DATABASE=HID-based serial adapater
|
||||
ID_MODEL_FROM_DATABASE=HID-based serial adapter
|
||||
|
||||
usb:v1A89*
|
||||
ID_VENDOR_FROM_DATABASE=Dynalith Systems Co., Ltd.
|
||||
@ -60954,7 +60966,7 @@ usb:v1D50p6054*
|
||||
ID_MODEL_FROM_DATABASE=Satlab/AAUSAT3 BlueBox
|
||||
|
||||
usb:v1D50p6055*
|
||||
ID_MODEL_FROM_DATABASE=RADiuS ER900TRS-02 transciever with SMA Connector
|
||||
ID_MODEL_FROM_DATABASE=RADiuS ER900TRS-02 transceiver with SMA Connector
|
||||
|
||||
usb:v1D50p6056*
|
||||
ID_MODEL_FROM_DATABASE=The Glitch
|
||||
@ -61365,16 +61377,16 @@ usb:v1D50p60EE*
|
||||
ID_MODEL_FROM_DATABASE=Duet 3 motion control electronics
|
||||
|
||||
usb:v1D50p60F0*
|
||||
ID_MODEL_FROM_DATABASE=UDAD-T1 data aquisition device (boot)
|
||||
ID_MODEL_FROM_DATABASE=UDAD-T1 data acquisition device (boot)
|
||||
|
||||
usb:v1D50p60F1*
|
||||
ID_MODEL_FROM_DATABASE=UDAD-T1 data aquisition device
|
||||
ID_MODEL_FROM_DATABASE=UDAD-T1 data acquisition device
|
||||
|
||||
usb:v1D50p60F2*
|
||||
ID_MODEL_FROM_DATABASE=UDAD-T2 data aquisition device (boot)
|
||||
ID_MODEL_FROM_DATABASE=UDAD-T2 data acquisition device (boot)
|
||||
|
||||
usb:v1D50p60F3*
|
||||
ID_MODEL_FROM_DATABASE=UDAD-T2 data aquisition device
|
||||
ID_MODEL_FROM_DATABASE=UDAD-T2 data acquisition device
|
||||
|
||||
usb:v1D50p60F4*
|
||||
ID_MODEL_FROM_DATABASE=Uniti ARC motor controller
|
||||
@ -61421,6 +61433,9 @@ usb:v1D50p6122*
|
||||
usb:v1D50p614C*
|
||||
ID_MODEL_FROM_DATABASE=dwtk In-Circuit Emulator
|
||||
|
||||
usb:v1D50p614D*
|
||||
ID_MODEL_FROM_DATABASE=Generic Display
|
||||
|
||||
usb:v1D50p8085*
|
||||
ID_MODEL_FROM_DATABASE=Box0 (box0-v5)
|
||||
|
||||
@ -61473,7 +61488,7 @@ usb:v1D57pAF03*
|
||||
ID_MODEL_FROM_DATABASE=Wireless Receiver
|
||||
|
||||
usb:v1D57pFA20*
|
||||
ID_MODEL_FROM_DATABASE=2.4GHz Wireless Reciever (Mini Keyboard & Mouse)
|
||||
ID_MODEL_FROM_DATABASE=2.4GHz Wireless Receiver (Mini Keyboard & Mouse)
|
||||
|
||||
usb:v1D5B*
|
||||
ID_VENDOR_FROM_DATABASE=Smartronix, Inc.
|
||||
@ -62397,7 +62412,22 @@ usb:v1FBD*
|
||||
ID_VENDOR_FROM_DATABASE=Delphin Technology AG
|
||||
|
||||
usb:v1FBDp0001*
|
||||
ID_MODEL_FROM_DATABASE=Expert Key - Data aquisition system
|
||||
ID_MODEL_FROM_DATABASE=Expert Key - Data acquisition system
|
||||
|
||||
usb:v1FBDp0004*
|
||||
ID_MODEL_FROM_DATABASE=MetiOS Device (RNDIS)
|
||||
|
||||
usb:v1FBDp0005*
|
||||
ID_MODEL_FROM_DATABASE=Loggito
|
||||
|
||||
usb:v1FBDp0006*
|
||||
ID_MODEL_FROM_DATABASE=LoggitoLab 8 AI-RTD
|
||||
|
||||
usb:v1FBDp0007*
|
||||
ID_MODEL_FROM_DATABASE=LoggitoLab 8 TC
|
||||
|
||||
usb:v1FBDp0008*
|
||||
ID_MODEL_FROM_DATABASE=LoggitoLab 4 AI-RTD 4 TC
|
||||
|
||||
usb:v1FC9*
|
||||
ID_VENDOR_FROM_DATABASE=NXP Semiconductors
|
||||
@ -67871,6 +67901,30 @@ usb:v3195pF280*
|
||||
usb:v3195pF281*
|
||||
ID_MODEL_FROM_DATABASE=MSO-28
|
||||
|
||||
usb:v3197*
|
||||
ID_VENDOR_FROM_DATABASE=Katusha
|
||||
|
||||
usb:v3197p1001*
|
||||
ID_MODEL_FROM_DATABASE=M151
|
||||
|
||||
usb:v3197p1002*
|
||||
ID_MODEL_FROM_DATABASE=M250
|
||||
|
||||
usb:v3197p1003*
|
||||
ID_MODEL_FROM_DATABASE=P130
|
||||
|
||||
usb:v3197p1004*
|
||||
ID_MODEL_FROM_DATABASE=M130
|
||||
|
||||
usb:v3197p1101*
|
||||
ID_MODEL_FROM_DATABASE=P247
|
||||
|
||||
usb:v3197p1102*
|
||||
ID_MODEL_FROM_DATABASE=M247
|
||||
|
||||
usb:v3197p1103*
|
||||
ID_MODEL_FROM_DATABASE=M348
|
||||
|
||||
usb:v31C9*
|
||||
ID_VENDOR_FROM_DATABASE=BeiJing LanXum Computer Technology Co., Ltd.
|
||||
|
||||
@ -69653,9 +69707,24 @@ usb:v8086p07D3*
|
||||
usb:v8086p07DC*
|
||||
ID_MODEL_FROM_DATABASE=Bluetooth 4.0* Smart Ready (low energy)
|
||||
|
||||
usb:v8086p0A66*
|
||||
ID_MODEL_FROM_DATABASE=RealSense 3D Camera (Front F200)
|
||||
|
||||
usb:v8086p0AA5*
|
||||
ID_MODEL_FROM_DATABASE=RealSense SR300
|
||||
|
||||
usb:v8086p0AD2*
|
||||
ID_MODEL_FROM_DATABASE=RealSense D410
|
||||
|
||||
usb:v8086p0AD3*
|
||||
ID_MODEL_FROM_DATABASE=RealSense D415
|
||||
|
||||
usb:v8086p0B07*
|
||||
ID_MODEL_FROM_DATABASE=RealSense D435
|
||||
|
||||
usb:v8086p0B64*
|
||||
ID_MODEL_FROM_DATABASE=RealSense L515
|
||||
|
||||
usb:v8086p0DAD*
|
||||
ID_MODEL_FROM_DATABASE=Cherry MiniatureCard Keyboard
|
||||
|
||||
@ -69731,6 +69800,9 @@ usb:v8086p9500*
|
||||
usb:v8086p9890*
|
||||
ID_MODEL_FROM_DATABASE=82930 Test Board
|
||||
|
||||
usb:v8086pA36D*
|
||||
ID_MODEL_FROM_DATABASE=Host Controller
|
||||
|
||||
usb:v8086pBEEF*
|
||||
ID_MODEL_FROM_DATABASE=SCM Miniature Card Reader/Writer
|
||||
|
||||
@ -69815,9 +69887,6 @@ usb:v8087p8008*
|
||||
usb:v8087p800A*
|
||||
ID_MODEL_FROM_DATABASE=Hub
|
||||
|
||||
usb:v8087p8087*
|
||||
ID_MODEL_FROM_DATABASE=07da Centrino Advanced-N 6235
|
||||
|
||||
usb:v80EE*
|
||||
ID_VENDOR_FROM_DATABASE=VirtualBox
|
||||
|
||||
|
@ -148,6 +148,7 @@ usb:v04F3p0C58*
|
||||
# Supported by libfprint driver elanmoc
|
||||
usb:v04F3p0C7D*
|
||||
usb:v04F3p0C7E*
|
||||
usb:v04F3p0C82*
|
||||
ID_AUTOSUSPEND=1
|
||||
ID_PERSIST=0
|
||||
|
||||
@ -185,7 +186,6 @@ usb:v06CBp00DF*
|
||||
usb:v06CBp00F9*
|
||||
usb:v06CBp00FC*
|
||||
usb:v06CBp00C2*
|
||||
usb:v06CBp00C9*
|
||||
usb:v06CBp0100*
|
||||
usb:v06CBp00F0*
|
||||
usb:v06CBp0103*
|
||||
@ -272,15 +272,19 @@ usb:v06CBp008A*
|
||||
usb:v06CBp009A*
|
||||
usb:v06CBp009B*
|
||||
usb:v06CBp00A2*
|
||||
usb:v06CBp00A8*
|
||||
usb:v06CBp00B7*
|
||||
usb:v06CBp00BB*
|
||||
usb:v06CBp00BE*
|
||||
usb:v06CBp00C4*
|
||||
usb:v06CBp00CB*
|
||||
usb:v06CBp00C9*
|
||||
usb:v06CBp00D8*
|
||||
usb:v06CBp00DA*
|
||||
usb:v06CBp00DC*
|
||||
usb:v06CBp00E7*
|
||||
usb:v06CBp00E9*
|
||||
usb:v06CBp00FD*
|
||||
usb:v0A5Cp5801*
|
||||
usb:v0A5Cp5805*
|
||||
usb:v0A5Cp5834*
|
||||
@ -292,6 +296,7 @@ usb:v0A5Cp5844*
|
||||
usb:v0A5Cp5845*
|
||||
usb:v0BDAp5812*
|
||||
usb:v10A5p0007*
|
||||
usb:v10A5p9200*
|
||||
usb:v1188p9545*
|
||||
usb:v138Ap0007*
|
||||
usb:v138Ap003A*
|
||||
@ -309,6 +314,7 @@ usb:v1491p0088*
|
||||
usb:v16D1p1027*
|
||||
usb:v1C7Ap0300*
|
||||
usb:v1C7Ap0575*
|
||||
usb:v1C7Ap0576*
|
||||
usb:v27C6p5042*
|
||||
usb:v27C6p5110*
|
||||
usb:v27C6p5117*
|
||||
@ -328,7 +334,9 @@ usb:v27C6p55A2*
|
||||
usb:v27C6p55A4*
|
||||
usb:v27C6p55B4*
|
||||
usb:v27C6p5740*
|
||||
usb:v27C6p5E0A*
|
||||
usb:v2808p9338*
|
||||
usb:v298Dp2020*
|
||||
usb:v298Dp2033*
|
||||
usb:v3538p0930*
|
||||
ID_AUTOSUSPEND=1
|
||||
|
@ -591,6 +591,24 @@ evdev:name:MSFT0001:02 04F3:304B Touchpad:dmi:*svnLENOVO:*pvrLenovoLegionY9000X2
|
||||
EVDEV_ABS_35=::31
|
||||
EVDEV_ABS_36=::30
|
||||
|
||||
#########################################
|
||||
# Microsoft
|
||||
#########################################
|
||||
|
||||
# Surface Laptop 2 (13")
|
||||
evdev:name:Microsoft Surface 045E:0933 Touchpad:dmi:*svnMicrosoftCorporation:*pnSurfaceLaptop2**
|
||||
EVDEV_ABS_00=::38
|
||||
EVDEV_ABS_01=::38
|
||||
EVDEV_ABS_35=::38
|
||||
EVDEV_ABS_36=::38
|
||||
|
||||
# Surface Laptop 3 (15")
|
||||
evdev:name:Microsoft Surface 045E:09AF Touchpad:dmi:*svnMicrosoftCorporation:*pnSurfaceLaptop3**
|
||||
EVDEV_ABS_00=::39
|
||||
EVDEV_ABS_01=::37
|
||||
EVDEV_ABS_35=::39
|
||||
EVDEV_ABS_36=::37
|
||||
|
||||
#########################################
|
||||
# NEWYES
|
||||
#########################################
|
||||
|
@ -70,4 +70,13 @@ id-input:modalias:input:b0005v046DpB00De0700*
|
||||
|
||||
# Logitech MX Keys
|
||||
id-input:modalias:input:b0003v046Dp408Ae0111*
|
||||
ID_INPUT_MOUSE=0
|
||||
ID_INPUT_MOUSE=0
|
||||
|
||||
# Logitech Craft Keyboard
|
||||
id-input:modalias:input:b0003v046Dp4066e0111*
|
||||
ID_INPUT_MOUSE=0
|
||||
|
||||
# CH Products Pro Pedals
|
||||
id-input:modalias:input:b0003v068Ep00F2e0100*
|
||||
ID_INPUT_ACCELEROMETER=0
|
||||
ID_INPUT_JOYSTICK=1
|
||||
|
@ -164,6 +164,12 @@ evdev:atkbd:dmi:bvn*:bvr*:bd*:svnAcer*:pnPredator*PH*315-52:*
|
||||
KEYBOARD_KEY_ef=kbdillumup # Fn+F10
|
||||
KEYBOARD_KEY_f0=kbdillumdown # Fn+F9
|
||||
|
||||
# Travelmate B311-31, B311R-31, B311RN-31
|
||||
evdev:atkbd:dmi:bvn*:bvr*:bd*:svnAcer*:pnTravelMateB311-31*:pvr*
|
||||
evdev:atkbd:dmi:bvn*:bvr*:bd*:svnAcer*:pnTravelMateB311R-31*:pvr*
|
||||
evdev:atkbd:dmi:bvn*:bvr*:bd*:svnAcer*:pnTravelMateB311RN-31*:pvr*
|
||||
KEYBOARD_KEY_8a=f20 # Microphone mute
|
||||
|
||||
# Travelmate C300
|
||||
evdev:atkbd:dmi:bvn*:bvr*:bd*:svnAcer*:pnTravelMate*C3[01]0*:*
|
||||
KEYBOARD_KEY_67=f24 # FIXME: rotate screen
|
||||
@ -231,6 +237,14 @@ evdev:name:Asus Laptop extra buttons:dmi:bvn*:bvr*:bd*:svnASUS*:pn*:*
|
||||
evdev:input:b0003v0B05p1869*
|
||||
KEYBOARD_KEY_ff31007c=f20 # Remap micmute to f20
|
||||
|
||||
# Asus TF103C misses the home button in its PNP0C40 GPIO resources
|
||||
# causing the volume-button mappings to be off by one, correct this
|
||||
evdev:name:gpio-keys:phys:gpio-keys/input0:ev:3:dmi:*:svnASUSTeKCOMPUTERINC.:pnTF103C*:*
|
||||
KEYBOARD_KEY_1=volumeup
|
||||
|
||||
evdev:name:gpio-keys:phys:gpio-keys/input0:ev:100003:dmi:*:svnASUSTeKCOMPUTERINC.:pnTF103C*:*
|
||||
KEYBOARD_KEY_0=volumedown
|
||||
|
||||
###########################################################
|
||||
# BenQ
|
||||
###########################################################
|
||||
@ -588,6 +602,18 @@ evdev:atkbd:dmi:bvn*:bvr*:bd*:svnHewlett-Packard*:pnHP*G60*Notebook*PC:*
|
||||
evdev:atkbd:dmi:bvn*:bvr*:bd*:svnHewlett-Packard*:pn*2570p*:*
|
||||
KEYBOARD_KEY_f8=wlan # Wireless HW switch button
|
||||
|
||||
# Elitebook 2760p
|
||||
evdev:atkbd:dmi:bvn*:bvr*:bd*:svnHewlett-Packard*:pn*2760p*:*
|
||||
KEYBOARD_KEY_89=battery # Fn+F8
|
||||
KEYBOARD_KEY_f8=unknown # rfkill is also reported by HP Wireless hotkeys
|
||||
KEYBOARD_KEY_86=volumeup
|
||||
KEYBOARD_KEY_87=volumedown
|
||||
KEYBOARD_KEY_92=brightnessdown
|
||||
KEYBOARD_KEY_97=brightnessup
|
||||
KEYBOARD_KEY_d8=!f23 # touchpad off
|
||||
KEYBOARD_KEY_d9=!f22 # touchpad on
|
||||
KEYBOARD_KEY_b3=unknown # FIXME: Auto brightness
|
||||
|
||||
# TX2
|
||||
evdev:atkbd:dmi:bvn*:bvr*:bd*:svnHewlett-Packard*:pn*[tT][xX]2*:*
|
||||
KEYBOARD_KEY_c2=media
|
||||
@ -625,6 +651,8 @@ evdev:atkbd:dmi:bvn*:bvr*:bd*:svnHewlett-Packard*:pnHPLicrice:*
|
||||
# HP EliteBook
|
||||
evdev:atkbd:dmi:bvn*:bvr*:bd*:svnHewlett-Packard*:pnHPEliteBook*:*
|
||||
evdev:atkbd:dmi:bvn*:bvr*:bd*:svnHP*:pnHPEliteBook*:*
|
||||
# HP Elite x360
|
||||
evdev:atkbd:dmi:bvn*:bvr*:bd*:svnHP*:pnHPElite*x360*:*
|
||||
# HP Elite Dragonfly
|
||||
evdev:atkbd:dmi:bvn*:bvr*:bd*:svnHP*:pnHPEliteDragonfly*:*
|
||||
# HP ProBook 440 G2
|
||||
@ -711,8 +739,8 @@ evdev:name:gpio-keys:phys:gpio-keys/input0:ev:3:dmi:*:svnHewlett-Packard:pnHPStr
|
||||
evdev:name:gpio-keys:phys:gpio-keys/input0:ev:23:dmi:*:svnHewlett-Packard:pnHPStream7Tablet:*
|
||||
KEYBOARD_KEY_0=unknown
|
||||
|
||||
# HP Omen 15
|
||||
evdev:atkbd:dmi:bvn*:bvr*:bd*:svnHP:pnOMENLaptop15*:pvr*
|
||||
# HP Omen
|
||||
evdev:atkbd:dmi:bvn*:bvr*:bd*:svnHP:pnOMEN*:pvr*
|
||||
KEYBOARD_KEY_a1=!calc
|
||||
|
||||
##########################################################
|
||||
@ -1337,6 +1365,17 @@ 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
|
||||
|
||||
##########################################
|
||||
# NEC
|
||||
##########################################
|
||||
|
||||
# VersaPro VG-S
|
||||
evdev:atkbd:dmi:bvn*:bvr*:bd*:svnNEC:pnPC-VK22TGSGS:pvr*
|
||||
KEYBOARD_KEY_a8=f21 # Fn+Space touchpad toggle
|
||||
KEYBOARD_KEY_67=brightnessdown # Fn+F7 brightness down
|
||||
KEYBOARD_KEY_65=brightnessup # Fn+F8 brightness up
|
||||
KEYBOARD_KEY_71=battery # Fn+F4 ECO
|
||||
|
||||
###########################################################
|
||||
# Olimex
|
||||
###########################################################
|
||||
@ -1883,6 +1922,20 @@ evdev:input:b0003v1038p0310*
|
||||
KEYBOARD_KEY_7002f=f11
|
||||
KEYBOARD_KEY_70046=f6
|
||||
|
||||
###########################################################
|
||||
# CZC
|
||||
###########################################################
|
||||
|
||||
evdev:atkbd:dmi:bvn*:bvr*:bd*:svnCZC:pnODEON*TPC-10:*
|
||||
KEYBOARD_KEY_01=leftmeta # Home button held for 2s
|
||||
KEYBOARD_KEY_db=prog1 # Home button
|
||||
KEYBOARD_KEY_dd=rfkill # Second button labeled Wi-Fi
|
||||
|
||||
evdev:atkbd:dmi:bvn*:bvr*:bd*:svnViewSonic:pnVPAD10:*
|
||||
KEYBOARD_KEY_01=leftmeta # Home button held for 2s
|
||||
KEYBOARD_KEY_db=prog1 # Home button
|
||||
KEYBOARD_KEY_dd=back # Second button labeled Back
|
||||
|
||||
###########################################################
|
||||
# Other
|
||||
###########################################################
|
||||
|
@ -426,6 +426,10 @@ sensor:modalias:acpi:KIOX000A*:dmi:bvnAmericanMegatrendsInc.:bvr5.11:bd03/20/201
|
||||
sensor:modalias:acpi:KIOX000A*:dmi:bvnAmericanMegatrendsInc.:bvr5.11:bd05/25/2017:*svnDefaultstring:pnDefaultstring:pvrDefaultstring:rvnAMICorporation:rnDefaultstring:rvrDefaultstring:cvnDefaultstring:ct3:cvrDefaultstring:*
|
||||
ACCEL_LOCATION=base
|
||||
|
||||
# GPD Pocket 3
|
||||
sensor:modalias:acpi:MXC6655*:dmi:*:svnGPD:pnG1621-02:*
|
||||
ACCEL_MOUNT_MATRIX=-1, 0, 0; 0, 1, 0; 0, 0, 1
|
||||
|
||||
#########################################
|
||||
# Hometech
|
||||
########################################
|
||||
@ -747,6 +751,10 @@ sensor:modalias:acpi:SMO8500*:dmi:*:svnPEAQ:pnPEAQPMMC1010MD99187:*
|
||||
sensor:modalias:acpi:KIOX000A*:dmi:*:svnPIPO:pnW2S:*
|
||||
ACCEL_MOUNT_MATRIX=1, 0, 0; 0, -1, 0; 0, 0, 1
|
||||
|
||||
# Pipo W2Pro
|
||||
sensor:modalias:acpi:KIOX0008*:dmi:*svnPIPO:pnW2pro:*
|
||||
ACCEL_MOUNT_MATRIX=1, 0, 0; 0, -1, 0; 0, 0, 1
|
||||
|
||||
# Pipo W4
|
||||
sensor:modalias:acpi:SMO8500*:dmi:*:bvrV8L_WIN32_CHIPHD_*_DX:*:rvnAMICorporation:rnAptioCRB:*
|
||||
ACCEL_MOUNT_MATRIX=0, -1, 0; -1, 0, 0; 0, 0, 1
|
||||
|
147
hwdb.d/70-av-production.hwdb
Normal file
147
hwdb.d/70-av-production.hwdb
Normal file
@ -0,0 +1,147 @@
|
||||
# This file is part of systemd.
|
||||
#
|
||||
# Database for AV production controllers that should be accessible to the seat owner.
|
||||
#
|
||||
# This covers DJ tables, music-oriented key pads, and streaming-oriented key pads
|
||||
# such as Elgato Stream Deck
|
||||
#
|
||||
# To add local entries, copy this file to
|
||||
# /etc/udev/hwdb.d/
|
||||
# and add your rules there. To load the new rules execute (as root):
|
||||
# systemd-hwdb update
|
||||
# udevadm trigger
|
||||
|
||||
################
|
||||
# Ableton
|
||||
################
|
||||
# Push 2
|
||||
usb:v2982p1967*
|
||||
ID_AV_PRODUCTION_CONTROLLER=1
|
||||
|
||||
################
|
||||
# Eks
|
||||
################
|
||||
# Otus
|
||||
usb:v1157p0300*
|
||||
ID_AV_PRODUCTION_CONTROLLER=1
|
||||
|
||||
################
|
||||
# Elgato
|
||||
################
|
||||
# Stream Deck Original (gen 1)
|
||||
usb:v0FD9p0060*
|
||||
ID_AV_PRODUCTION_CONTROLLER=1
|
||||
|
||||
# Stream Deck Mini
|
||||
usb:v0FD9p0063*
|
||||
ID_AV_PRODUCTION_CONTROLLER=1
|
||||
|
||||
# Stream Deck XL
|
||||
usb:v0FD9p006C*
|
||||
ID_AV_PRODUCTION_CONTROLLER=1
|
||||
|
||||
# Stream Deck Original (gen 2)
|
||||
usb:v0FD9p006D*
|
||||
ID_AV_PRODUCTION_CONTROLLER=1
|
||||
|
||||
# Stream Deck MK.2
|
||||
usb:v0FD9p0080*
|
||||
ID_AV_PRODUCTION_CONTROLLER=1
|
||||
|
||||
#############################
|
||||
# Hercules (Guillemot Corp)
|
||||
#############################
|
||||
# DJ Console MP3e2
|
||||
usb:v06F8pB105*
|
||||
ID_AV_PRODUCTION_CONTROLLER=1
|
||||
|
||||
# DJ Console MP3 LE / Glow
|
||||
usb:v06F8pB120*
|
||||
ID_AV_PRODUCTION_CONTROLLER=1
|
||||
|
||||
# DJ Console Mk2
|
||||
usb:v06F8pB100*
|
||||
ID_AV_PRODUCTION_CONTROLLER=1
|
||||
|
||||
# DJ Console Mk4
|
||||
usb:v06F8pB107*
|
||||
ID_AV_PRODUCTION_CONTROLLER=1
|
||||
|
||||
#####################
|
||||
# Native Instruments
|
||||
#####################
|
||||
|
||||
# Maschine 2
|
||||
usb:v17CCp1140*
|
||||
ID_AV_PRODUCTION_CONTROLLER=1
|
||||
|
||||
# Maschine 2 Mikro
|
||||
usb:v17CCp1110*
|
||||
ID_AV_PRODUCTION_CONTROLLER=1
|
||||
|
||||
# Maschine 2 Studio
|
||||
usb:v17CCp1300*
|
||||
ID_AV_PRODUCTION_CONTROLLER=1
|
||||
|
||||
# Maschine Jam
|
||||
usb:v17CCp1500*
|
||||
ID_AV_PRODUCTION_CONTROLLER=1
|
||||
|
||||
# Maschine 3
|
||||
usb:v17CCp1600*
|
||||
ID_AV_PRODUCTION_CONTROLLER=1
|
||||
|
||||
# Traktor Kontrol D2
|
||||
usb:v17CCp1400*
|
||||
ID_AV_PRODUCTION_CONTROLLER=1
|
||||
|
||||
# Traktor Kontrol F1
|
||||
usb:v17CCp1120*
|
||||
ID_AV_PRODUCTION_CONTROLLER=1
|
||||
|
||||
# Traktor Kontrol S2 Mk2
|
||||
usb:v17CCp1320*
|
||||
ID_AV_PRODUCTION_CONTROLLER=1
|
||||
|
||||
# Traktor Kontrol S2 Mk3
|
||||
usb:v17CCp1710*
|
||||
ID_AV_PRODUCTION_CONTROLLER=1
|
||||
|
||||
# Traktor Kontrol S3
|
||||
usb:v17CCp1900*
|
||||
ID_AV_PRODUCTION_CONTROLLER=1
|
||||
|
||||
# Traktor Kontrol S4 Mk2
|
||||
usb:v17CCp1310*
|
||||
ID_AV_PRODUCTION_CONTROLLER=1
|
||||
|
||||
# Traktor Kontrol S4 Mk3
|
||||
usb:v17CCp1720*
|
||||
ID_AV_PRODUCTION_CONTROLLER=1
|
||||
|
||||
# Traktor Kontrol S5
|
||||
usb:v17CCp1420*
|
||||
ID_AV_PRODUCTION_CONTROLLER=1
|
||||
|
||||
# Traktor Kontrol S8
|
||||
usb:v17CCp1370*
|
||||
ID_AV_PRODUCTION_CONTROLLER=1
|
||||
|
||||
# Traktor Kontrol X1 Mk2
|
||||
usb:v17CCp1220*
|
||||
ID_AV_PRODUCTION_CONTROLLER=1
|
||||
|
||||
# Traktor Kontrol Z1
|
||||
usb:v17CCp1210*
|
||||
ID_AV_PRODUCTION_CONTROLLER=1
|
||||
|
||||
# Traktor Kontrol Z2
|
||||
usb:v17CCp1130*
|
||||
ID_AV_PRODUCTION_CONTROLLER=1
|
||||
|
||||
####################
|
||||
# Pioneer
|
||||
####################
|
||||
# CDJ 2000 NXS 2
|
||||
usb:v2B73p0005*
|
||||
ID_AV_PRODUCTION_CONTROLLER=1
|
@ -166,6 +166,14 @@ mouse:bluetooth:v05acp030d:name:*:*
|
||||
mouse:usb:v04f2p0963:name:Chicony 2.4G Multimedia Wireless Kit:*
|
||||
MOUSE_DPI=1000@142
|
||||
|
||||
##########################################
|
||||
# CST
|
||||
##########################################
|
||||
|
||||
# CST Laser Trackball
|
||||
mouse:usb:v5332p1400:name:Clearly Superior Technologies. CST Laser Trackball:*
|
||||
MOUSE_DPI=400@1000 *800@1000 1600@1000
|
||||
|
||||
##########################################
|
||||
# Dell
|
||||
##########################################
|
||||
@ -198,6 +206,17 @@ mouse:usb:v0461p4d46:name:USB Optical Mouse:*
|
||||
mouse:usb:v056ep010d:name:ELECOM TrackBall Mouse HUGE TrackBall:*
|
||||
MOUSE_DPI=500@125 *1000@125 1500@125
|
||||
|
||||
# Elecom DEFT Pro TrackBall (M-DPT1MR)
|
||||
mouse:usb:v056ep0131:name:ELECOM TrackBall Mouse DEFT Pro TrackBall Mouse:*
|
||||
MOUSE_DPI=*500 1000 1500
|
||||
MOUSE_WHEEL_CLICK_ANGLE=10
|
||||
|
||||
# Elecom Relacon (M-RT1DR)
|
||||
mouse:usb:v056ep0155:name:ELECOM ELECOM Relacon:*
|
||||
ID_INPUT_TRACKBALL=1
|
||||
MOUSE_DPI=*500 1000 1500
|
||||
MOUSE_WHEEL_CLICK_ANGLE=30
|
||||
|
||||
##########################################
|
||||
# Fujitsu Siemens
|
||||
##########################################
|
||||
|
50
hwdb.d/70-pda.hwdb
Normal file
50
hwdb.d/70-pda.hwdb
Normal file
@ -0,0 +1,50 @@
|
||||
# This file is part of systemd.
|
||||
#
|
||||
# Database for handhelds (PDAs, calculators, etc.) that should be accessible
|
||||
# the seat owner.
|
||||
#
|
||||
# Permitted keys:
|
||||
# Specify if a device is a handheld
|
||||
# ID_PDA=1|0
|
||||
|
||||
###########################################################
|
||||
# HP Inc.
|
||||
###########################################################
|
||||
# HP x9G+ Calculator
|
||||
usb:v03F0p0121*
|
||||
ID_PDA=1
|
||||
|
||||
# HP Prime
|
||||
usb:v03F0p1541*
|
||||
ID_PDA=1
|
||||
|
||||
###########################################################
|
||||
# Texas Instruments
|
||||
###########################################################
|
||||
# SilverLink
|
||||
usb:v0451pE001*
|
||||
ID_PDA=1
|
||||
|
||||
# TI-84 Plus DirectLink
|
||||
usb:v0451pE003*
|
||||
ID_PDA=1
|
||||
|
||||
# TI-89 Titanium DirectLink
|
||||
usb:v0451pE004*
|
||||
ID_PDA=1
|
||||
|
||||
# TI-84 Plus Silver Edition DirectLink
|
||||
usb:v0451pE008*
|
||||
ID_PDA=1
|
||||
|
||||
# TI-Nspire DirectLink
|
||||
usb:v0451pE012*
|
||||
ID_PDA=1
|
||||
|
||||
# TI-Nspire Lab Cradle
|
||||
usb:v0451pE01C*
|
||||
ID_PDA=1
|
||||
|
||||
# TI-Nspire CX II DirectLink
|
||||
usb:v0451pE022*
|
||||
ID_PDA=1
|
@ -110,6 +110,9 @@
|
||||
<tr class="even"><td>Purism SPC</td><td>PURI</td><td>06/10/2021</td> </tr>
|
||||
<tr class="odd"><td>Lontium Semiconductor Corporation</td><td>LTSC</td><td>07/21/2021</td> </tr>
|
||||
<tr class="even"><td>Wacom Technology</td><td>WACF</td><td>09/21/2021</td> </tr>
|
||||
<tr class="odd"><td>Shanghai Aiwei Electronic Technology Co., Ltd.</td><td>AWDZ</td><td>12/31/2021</td> </tr>
|
||||
<tr class="even"><td>Silicom Ltd. Connectivity Solutions</td><td>SILC</td><td>03/28/2022</td> </tr>
|
||||
<tr class="odd"><td>NOLO VR</td><td>NOLO</td><td>03/28/2022</td> </tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</body>
|
||||
|
@ -6,7 +6,7 @@ import sys
|
||||
from pyparsing import (Word, White, Literal, Regex,
|
||||
LineEnd, SkipTo,
|
||||
ZeroOrMore, OneOrMore, Combine, Optional, Suppress,
|
||||
Group,
|
||||
Group, ParserElement,
|
||||
stringEnd, pythonStyleComment)
|
||||
|
||||
EOL = LineEnd().suppress()
|
||||
@ -20,6 +20,8 @@ COMMENTLINE = pythonStyleComment + EOL
|
||||
EMPTYLINE = LineEnd()
|
||||
text_eol = lambda name: Regex(r'[^\n]+')(name) + EOL
|
||||
|
||||
ParserElement.set_default_whitespace_chars(' \n')
|
||||
|
||||
def klass_grammar():
|
||||
klass_line = Literal('C ').suppress() + NUM2('klass') + text_eol('text')
|
||||
subclass_line = TAB + NUM2('subclass') + text_eol('text')
|
||||
@ -35,8 +37,12 @@ def klass_grammar():
|
||||
def usb_ids_grammar():
|
||||
vendor_line = NUM4('vendor') + text_eol('text')
|
||||
device_line = TAB + NUM4('device') + text_eol('text')
|
||||
interface_line = TAB + TAB + NUM4('interface') + NUM4('interface2') + text_eol('text')
|
||||
device = (device_line +
|
||||
ZeroOrMore(Group(interface_line)
|
||||
^ COMMENTLINE.suppress()))
|
||||
vendor = (vendor_line('VENDOR') +
|
||||
ZeroOrMore(Group(device_line)('VENDOR_DEV*') ^ COMMENTLINE.suppress()))
|
||||
ZeroOrMore(Group(device)('VENDOR_DEV*') ^ COMMENTLINE.suppress()))
|
||||
|
||||
klass = klass_grammar()
|
||||
|
||||
|
3741
hwdb.d/ma-large.txt
3741
hwdb.d/ma-large.txt
File diff suppressed because it is too large
Load Diff
1000
hwdb.d/ma-medium.txt
1000
hwdb.d/ma-medium.txt
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
@ -27,9 +27,11 @@ hwdb_files_test = files(
|
||||
'60-seat.hwdb',
|
||||
'60-sensor.hwdb',
|
||||
'70-analyzers.hwdb',
|
||||
'70-av-production.hwdb',
|
||||
'70-cameras.hwdb',
|
||||
'70-joystick.hwdb',
|
||||
'70-mouse.hwdb',
|
||||
'70-pda.hwdb',
|
||||
'70-pointingstick.hwdb',
|
||||
'70-touchpad.hwdb',
|
||||
'80-ieee1394-unit-function.hwdb')
|
||||
|
@ -121,7 +121,7 @@ def hwdb_grammar():
|
||||
def property_grammar():
|
||||
ParserElement.setDefaultWhitespaceChars(' ')
|
||||
|
||||
dpi_setting = Group(Optional('*')('DEFAULT') + INTEGER('DPI') + Suppress('@') + INTEGER('HZ'))('SETTINGS*')
|
||||
dpi_setting = Group(Optional('*')('DEFAULT') + INTEGER('DPI') + Optional(Suppress('@') + INTEGER('HZ')))('SETTINGS*')
|
||||
mount_matrix_row = SIGNED_REAL + ',' + SIGNED_REAL + ',' + SIGNED_REAL
|
||||
mount_matrix = Group(mount_matrix_row + ';' + mount_matrix_row + ';' + mount_matrix_row)('MOUNT_MATRIX')
|
||||
xkb_setting = Optional(Word(alphanums + '+-/@._'))
|
||||
@ -135,7 +135,9 @@ def property_grammar():
|
||||
('MOUSE_WHEEL_CLICK_COUNT', INTEGER),
|
||||
('MOUSE_WHEEL_CLICK_COUNT_HORIZONTAL', INTEGER),
|
||||
('ID_AUTOSUSPEND', Or((Literal('0'), Literal('1')))),
|
||||
('ID_AV_PRODUCTION_CONTROLLER', Or((Literal('0'), Literal('1')))),
|
||||
('ID_PERSIST', Or((Literal('0'), Literal('1')))),
|
||||
('ID_PDA', Or((Literal('0'), Literal('1')))),
|
||||
('ID_INPUT', Or((Literal('0'), Literal('1')))),
|
||||
('ID_INPUT_ACCELEROMETER', Or((Literal('0'), Literal('1')))),
|
||||
('ID_INPUT_JOYSTICK', Or((Literal('0'), Literal('1')))),
|
||||
|
300
hwdb.d/pci.ids
300
hwdb.d/pci.ids
@ -1,8 +1,8 @@
|
||||
#
|
||||
# List of PCI ID's
|
||||
#
|
||||
# Version: 2021.12.15
|
||||
# Date: 2021-12-15 03:15:02
|
||||
# Version: 2022.03.22
|
||||
# Date: 2022-03-22 03:15:02
|
||||
#
|
||||
# Maintained by Albert Pool, Martin Mares, and other volunteers from
|
||||
# the PCI ID Project at https://pci-ids.ucw.cz/.
|
||||
@ -105,14 +105,24 @@
|
||||
0731 7215 JM7200
|
||||
9200 JM9200
|
||||
920a JH920
|
||||
0731 920a JH920
|
||||
0731 920b JH920-I
|
||||
0731 920c JH920-M
|
||||
920b JH920-I
|
||||
920c JH920-M
|
||||
9210 JM9210
|
||||
0731 9210 JM9210
|
||||
0731 9211 JM9210-I
|
||||
9211 JM9210-I
|
||||
9230 JM9230
|
||||
0731 9230 JM9230
|
||||
0731 9231 JM9230-I
|
||||
9231 JM9231-I
|
||||
9250 JM9250
|
||||
0731 9250 JM9250
|
||||
930a JH930-I
|
||||
0731 930a JH930-I
|
||||
0731 930b JH930-M
|
||||
930b JH930-M
|
||||
0777 Ubiquiti Networks, Inc.
|
||||
0795 Wired Inc.
|
||||
@ -821,14 +831,16 @@
|
||||
1028 200c HBA355i Front
|
||||
1028 200d HBA355e Adapter
|
||||
1028 200e HBA350i MX
|
||||
1028 2170 HBA350i MM
|
||||
1028 2175 HBA350i Adapter
|
||||
1028 2197 HBA350i MM LP
|
||||
1d49 0205 ThinkSystem 440-16i SAS/SATA PCIe Gen4 12Gb Internal HBA
|
||||
1d49 0206 ThinkSystem 440-16e SAS/SATA PCIe Gen4 12Gb HBA
|
||||
1d49 0207 ThinkSystem 440-8i SAS/SATA PCIe Gen4 12Gb HBA
|
||||
1d49 0208 ThinkSystem 440-16i SAS/SATA PCIe Gen4 12Gb HBA
|
||||
1d49 0209 ThinkSystem 440-8e SAS/SATA PCIe Gen4 12Gb HBA
|
||||
8086 4050 Storage Controller RS3P4QF160F
|
||||
8086 4070 Storage Controller RS3P4GF016F
|
||||
8086 4050 Storage Controller RS3P4QF160J
|
||||
8086 4070 Storage Controller RS3P4GF016J
|
||||
00e7 Fusion-MPT 12GSAS/PCIe Unsupported SAS38xx
|
||||
# Tampered part
|
||||
1028 200b HBA355i Adapter Tampered
|
||||
@ -932,6 +944,8 @@
|
||||
10e2 MegaRAID 12GSAS/PCIe Secure SAS39xx
|
||||
# 9560 16 internal port RAID controller
|
||||
1000 4000 MegaRAID 9560-16i
|
||||
# 9561 16 internal port RAID controller
|
||||
1000 4002 MegaRAID 9561-16i
|
||||
# 9560 8 internal port RAID controller
|
||||
1000 4010 MegaRAID 9560-8i
|
||||
# 9580 8 internal & 8 external port RAID controller
|
||||
@ -965,6 +979,7 @@
|
||||
1028 2173 PERC H355 Front
|
||||
1028 2174 PERC H350 Mini
|
||||
1028 2177 PERC H350 Adapter
|
||||
1028 2199 PERC H350 Mini LP
|
||||
1d49 0505 ThinkSystem RAID 540-8i PCIe Gen4 12Gb Adapter
|
||||
1d49 0506 ThinkSystem RAID 540-16i PCIe Gen4 12Gb Adapter
|
||||
10e7 MegaRAID 12GSAS/PCIe Unsupported SAS38xx
|
||||
@ -986,6 +1001,7 @@
|
||||
c010 PEX88048 50 lane, 50 port, PCI Express Gen 4.0 ExpressFabric Platform
|
||||
c012 PEX880xx PCIe Gen 4 Switch
|
||||
1d49 0003 ThinkSystem 1611-8P PCIe Gen4 NVMe Switch Adapter
|
||||
c030 PEX890xx PCIe Gen 5 Switch
|
||||
1001 Kolter Electronic
|
||||
0010 PCI 1616 Measurement card with 32 digital I/O lines
|
||||
0011 OPTO-PCI Opto-Isolated digital I/O board
|
||||
@ -1062,7 +1078,7 @@
|
||||
163f VanGogh
|
||||
164c Lucienne
|
||||
164d Rembrandt
|
||||
1681 Rembrandt
|
||||
1681 Rembrandt [Radeon 680M]
|
||||
1714 BeaverCreek HDMI Audio [Radeon HD 6500D and 6400G-6600G series]
|
||||
103c 168b ProBook 4535s
|
||||
3150 RV380/M24 [Mobility Radeon X600]
|
||||
@ -2032,9 +2048,10 @@
|
||||
174b a240 Radeon R7 240 OEM
|
||||
174b d340 Radeon R7 340 OEM
|
||||
1b0a 90d3 Radeon R7 240 OEM
|
||||
6613 Oland PRO [Radeon R7 240/340]
|
||||
6613 Oland PRO [Radeon R7 240/340 / Radeon 520]
|
||||
148c 7340 Radeon R7 340
|
||||
1682 7240 R7 240 2048 MB
|
||||
1dcf 3000 Oland PRO [Radeon R7 240/340 / Radeon 520]
|
||||
6631 Oland
|
||||
6640 Saturn XT [FirePro M6100]
|
||||
106b 014b Tropo XT [Radeon R9 M380 Mac Edition]
|
||||
@ -3742,23 +3759,29 @@
|
||||
73a2 Navi 21 Pro-XTA [Radeon Pro W6900X]
|
||||
73a3 Navi 21 GL-XL [Radeon PRO W6800]
|
||||
73a4 Navi 21 USB
|
||||
73a5 Navi 21 [Radeon RX 6950 XT]
|
||||
73ab Navi 21 Pro-XLA [Radeon Pro W6800X/Radeon Pro W6800X Duo]
|
||||
73af Navi 21 [Radeon RX 6900 XT]
|
||||
148c 2414 Navi 21 XTXH [PowerColor Red Devil RX 6900 XT Ultimate]
|
||||
73bf Navi 21 [Radeon RX 6800/6800 XT / 6900 XT]
|
||||
1002 0e3a Radeon RX 6900 XT
|
||||
148c 2408 Red Devil AMD Radeon RX 6900 XT
|
||||
1eae 6701 XFX Speedster MERC 319 AMD Radeon RX 6800 XT Black
|
||||
73c3 Navi 22
|
||||
73c4 Navi 22 USB
|
||||
73df Navi 22 [Radeon RX 6700/6700 XT / 6800M]
|
||||
73df Navi 22 [Radeon RX 6700/6700 XT/6750 XT / 6800M]
|
||||
73e0 Navi 23
|
||||
73e1 Navi 23 WKS-XM [Radeon PRO W6600M]
|
||||
73e3 Navi 23 WKS-XL [Radeon PRO W6600]
|
||||
73e4 Navi 23 USB
|
||||
73ef Navi 23 [Radeon RX 6650 XT]
|
||||
73ff Navi 23 [Radeon RX 6600/6600 XT/6600M]
|
||||
148c 2412 PowerColor Red Devil RX 6600 XT
|
||||
7408 Aldebaran
|
||||
740c Aldebaran
|
||||
740f Aldebaran
|
||||
743f Navi 24 [Radeon RX 6400 / 6500 XT]
|
||||
1da2 e457 PULSE AMD Radeon RX 6500 XT
|
||||
7833 RS350 Host Bridge
|
||||
7834 RS350 [Radeon 9100 PRO/XT IGP]
|
||||
7835 RS350M [Mobility Radeon 9000 IGP]
|
||||
@ -4161,7 +4184,7 @@
|
||||
ab10 Lexa HDMI Audio
|
||||
ab18 Vega 12 HDMI Audio
|
||||
ab20 Vega 20 HDMI Audio [Radeon VII]
|
||||
ab28 Navi 21 HDMI Audio [Radeon RX 6800/6800 XT / 6900 XT]
|
||||
ab28 Navi 21/23 HDMI/DP Audio Controller
|
||||
ab38 Navi 10 HDMI Audio
|
||||
ac00 Theater 506 World-Wide Analog Decoder
|
||||
ac01 Theater 506 World-Wide Analog Decoder
|
||||
@ -4956,14 +4979,14 @@
|
||||
1043 876b PRIME Motherboard
|
||||
17aa 5124 ThinkPad E595
|
||||
ea50 ce19 mCOM10-L1900
|
||||
15e2 Raven/Raven2/FireFlight/Renoir Audio Processor
|
||||
15e2 ACP/ACP3X/ACP6x Audio Coprocessor
|
||||
17aa 5124 ThinkPad E595
|
||||
ea50 ce19 mCOM10-L1900
|
||||
15e3 Family 17h (Models 10h-1fh) HD Audio Controller
|
||||
15e3 Family 17h/19h HD Audio Controller
|
||||
103c 8615 Pavilion Laptop 15-cw1xxx
|
||||
1043 86c7 PRIME B450M-A Motherboard
|
||||
17aa 5124 ThinkPad E595
|
||||
15e4 Raven/Raven2/Renoir Sensor Fusion Hub
|
||||
15e4 Sensor Fusion Hub
|
||||
15e5 Raven2 USB 3.1
|
||||
ea50 ce19 mCOM10-L1900
|
||||
15e6 Raven/Raven2/Renoir Non-Sensor Fusion Hub KMDF driver
|
||||
@ -5139,6 +5162,13 @@
|
||||
43c7 400 Series Chipset PCIe Port
|
||||
43c8 400 Series Chipset SATA Controller
|
||||
43d5 400 Series Chipset USB 3.1 XHCI Controller
|
||||
43e9 500 Series Chipset Switch Upstream Port
|
||||
43eb 500 Series Chipset SATA Controller
|
||||
# or ASM106X Serial ATA Controller
|
||||
1b21 1062 ASM1062 Serial ATA Controller
|
||||
43ee 500 Series Chipset USB 3.1 XHCI Controller
|
||||
# maybe
|
||||
1b21 1142 ASM1042A USB 3.0 Host Controller
|
||||
57a3 Matisse PCIe GPP Bridge
|
||||
57a4 Matisse PCIe GPP Bridge
|
||||
57ad Matisse Switch Upstream
|
||||
@ -11492,6 +11522,7 @@
|
||||
10ef GP102 HDMI Audio Controller
|
||||
10f0 GP104 High Definition Audio Controller
|
||||
10f1 GP106 High Definition Audio Controller
|
||||
1043 85b6 DUAL-GTX1060-O6G [GeForce GTX 1060 6GB Dual]
|
||||
10f7 TU102 High Definition Audio Controller
|
||||
10f8 TU104 HD Audio Controller
|
||||
10f9 TU106 High Definition Audio Controller
|
||||
@ -12189,6 +12220,7 @@
|
||||
1c01 GP106
|
||||
1c02 GP106 [GeForce GTX 1060 3GB]
|
||||
1c03 GP106 [GeForce GTX 1060 6GB]
|
||||
1043 85b6 DUAL-GTX1060-O6G [GeForce GTX 1060 6GB Dual]
|
||||
1c04 GP106 [GeForce GTX 1060 5GB]
|
||||
1c06 GP106 [GeForce GTX 1060 6GB Rev. 2]
|
||||
1c07 GP106 [P106-100]
|
||||
@ -12321,6 +12353,7 @@
|
||||
1ef5 TU104GLM [Quadro RTX 5000 Mobile Refresh]
|
||||
1f02 TU106 [GeForce RTX 2070]
|
||||
1043 8673 TURBO RTX 2070
|
||||
1f03 TU106 [GeForce RTX 2060 12GB]
|
||||
1f04 TU106
|
||||
1f06 TU106 [GeForce RTX 2060 SUPER]
|
||||
1f07 TU106 [GeForce RTX 2070 Rev. A]
|
||||
@ -12354,21 +12387,32 @@
|
||||
1f99 TU117M
|
||||
1f9c TU117M [GeForce MX450]
|
||||
1f9d TU117M [GeForce GTX 1650 Mobile / Max-Q]
|
||||
# via Lenovo 496.90
|
||||
1f9f TU117M [GeForce MX550]
|
||||
1fa0 TU117M [GeForce MX550]
|
||||
1fae TU117GL
|
||||
1fb0 TU117GLM [Quadro T1000 Mobile]
|
||||
1fb1 TU117GL [T600]
|
||||
1fb2 TU117GLM [Quadro T400 Mobile]
|
||||
1fb6 TU117GLM [T600 Laptop GPU]
|
||||
1fb7 TU117GLM [T550 Laptop GPU]
|
||||
1fb8 TU117GLM [Quadro T2000 Mobile / Max-Q]
|
||||
1fb9 TU117GLM [Quadro T1000 Mobile]
|
||||
1fba TU117GLM [T600 Mobile]
|
||||
1fbb TU117GLM [Quadro T500 Mobile]
|
||||
1fbc TU117GLM [T1200 Laptop GPU]
|
||||
1fbf TU117GL
|
||||
1fd9 TU117BM [GeForce GTX 1650 Mobile Refresh]
|
||||
1fdd TU117BM [GeForce GTX 1650 Mobile Refresh]
|
||||
1ff0 TU117GL [T1000 8GB]
|
||||
1ff2 TU117GL [T400 4GB]
|
||||
1ff9 TU117GLM [Quadro T1000 Mobile]
|
||||
2082 GA100 [CMP 170HX]
|
||||
20b0 GA100 [A100 SXM4 40GB]
|
||||
20b1 GA100 [A100 PCIe 40GB]
|
||||
20b2 GA100 [A100 SXM4 80GB]
|
||||
# 20B3 14A7 10DE PG506-242 / 20B3 14A8 10DE PG506-243
|
||||
20b3 GA100 [PG506-242/243]
|
||||
20b5 GA100 [A100 PCIe 80GB]
|
||||
20b6 GA100GL [PG506-232]
|
||||
20b7 GA100GL [A30 PCIe]
|
||||
@ -12376,7 +12420,9 @@
|
||||
20be GA100 [GRID A100A]
|
||||
20bf GA100 [GRID A100B]
|
||||
20c2 GA100 [CMP 170HX]
|
||||
20f0 GA100 [A100-PG506-207]
|
||||
20f1 GA100 [A100 PCIe 40GB]
|
||||
20f2 GA100 [A100-PG506-217]
|
||||
2182 TU116 [GeForce GTX 1660 Ti]
|
||||
2183 TU116
|
||||
2184 TU116 [GeForce GTX 1660]
|
||||
@ -12399,6 +12445,7 @@
|
||||
10de 146d GA102 [GeForce RTX 3080 20GB]
|
||||
1462 3892 RTX 3080 10GB GAMING X TRIO
|
||||
2208 GA102 [GeForce RTX 3080 Ti]
|
||||
220a GA102 [GeForce RTX 3080 12GB]
|
||||
220d GA102 [CMP 90HX]
|
||||
2216 GA102 [GeForce RTX 3080 Lite Hash Rate]
|
||||
222b GA102 [GeForce RTX 3090 Engineering Sample]
|
||||
@ -12406,15 +12453,20 @@
|
||||
2230 GA102GL [RTX A6000]
|
||||
2231 GA102GL [RTX A5000]
|
||||
2232 GA102GL [RTX A4500]
|
||||
2233 GA102GL [RTX A5500]
|
||||
2235 GA102GL [A40]
|
||||
2236 GA102GL [A10]
|
||||
2237 GA102GL [A10G]
|
||||
2238 GA102GL [A10M]
|
||||
223f GA102GL
|
||||
228b GA104 High Definition Audio Controller
|
||||
2296 Tegra PCIe Endpoint Virtual Network
|
||||
2302 GA103
|
||||
2321 GA103
|
||||
2414 GA103 [GeForce RTX 3060 Ti]
|
||||
2420 GA103M [GeForce RTX 3080 Ti Mobile]
|
||||
2438 GA103GLM [RTX A5500 Laptop GPU]
|
||||
2460 GA103M [GeForce RTX 3080 Ti Laptop GPU]
|
||||
2482 GA104 [GeForce RTX 3070 Ti]
|
||||
2483 GA104
|
||||
2484 GA104 [GeForce RTX 3070]
|
||||
@ -12436,29 +12488,46 @@
|
||||
24b6 GA104GLM [RTX A5000 Mobile]
|
||||
24b7 GA104GLM [RTX A4000 Mobile]
|
||||
24b8 GA104GLM [RTX A3000 Mobile]
|
||||
24b9 GA104GLM [RTX A3000 12GB Laptop GPU]
|
||||
24ba GA104GLM [RTX A4500 Laptop GPU]
|
||||
24bb GA104GLM [RTX A3000 Laptop GPU]
|
||||
24bf GA104 [GeForce RTX 3070 Engineering Sample]
|
||||
24dc GA104M [GeForce RTX 3080 Mobile / Max-Q 8GB/16GB]
|
||||
24dd GA104M [GeForce RTX 3070 Mobile / Max-Q]
|
||||
24e0 GA104M [Geforce RTX 3070 Ti Laptop GPU]
|
||||
24fa GA104 [RTX A4500 Embedded GPU ]
|
||||
2501 GA106 [GeForce RTX 3060]
|
||||
2503 GA106 [GeForce RTX 3060]
|
||||
2504 GA106 [GeForce RTX 3060 Lite Hash Rate]
|
||||
2505 GA106
|
||||
2507 GA106 [Geforce RTX 3050]
|
||||
2520 GA106M [GeForce RTX 3060 Mobile / Max-Q]
|
||||
2523 GA106M [GeForce RTX 3050 Ti Mobile / Max-Q]
|
||||
252f GA106 [GeForce RTX 3060 Engineering Sample]
|
||||
2531 GA106 [RTX A2000]
|
||||
2560 GA106M [GeForce RTX 3060 Mobile / Max-Q]
|
||||
2563 GA106M [GeForce RTX 3050 Ti Mobile / Max-Q]
|
||||
2571 GA106 [RTX A2000 12GB]
|
||||
2583 GA107 [GeForce RTX 3050]
|
||||
25a0 GA107M [GeForce RTX 3050 Ti Mobile]
|
||||
25a2 GA107M [GeForce RTX 3050 Mobile]
|
||||
25a4 GA107
|
||||
25a5 GA107M [GeForce RTX 3050 Mobile]
|
||||
25a6 GA107M [GeForce MX570]
|
||||
25a7 GA107M [GeForce MX570]
|
||||
25a9 GA107M [GeForce RTX 2050]
|
||||
25af GA107 [GeForce RTX 3050 Engineering Sample]
|
||||
25b5 GA107GLM [RTX A4 Mobile]
|
||||
# A16 - 25B6 10DE 14A9 / A2 - 25B6 10DE 157E
|
||||
25b6 GA107GL [A2 / A16]
|
||||
25b8 GA107GLM [RTX A2000 Mobile]
|
||||
25b9 GA107GLM [RTX A1000 Laptop GPU]
|
||||
25ba GA107GLM [RTX A2000 8GB Laptop GPU]
|
||||
25e0 GA107BM [GeForce RTX 3050 Ti Mobile]
|
||||
25e2 GA107BM [GeForce RTX 3050 Mobile]
|
||||
25e5 GA107BM [GeForce RTX 3050 Mobile]
|
||||
25f9 GA107 [RTX A1000 Embedded GPU ]
|
||||
25fa GA107 [RTX A2000 Embedded GPU]
|
||||
10df Emulex Corporation
|
||||
0720 OneConnect NIC (Skyhawk)
|
||||
103c 1934 FlexFabric 20Gb 2-port 650M Adapter
|
||||
@ -12689,6 +12758,7 @@
|
||||
1028 09be Latitude 7410
|
||||
17aa 224f ThinkPad X1 Carbon 5th Gen
|
||||
5260 RTS5260 PCI Express Card Reader
|
||||
5261 RTS5261 PCI Express Card Reader
|
||||
5286 RTS5286 PCI Express Card Reader
|
||||
5287 RTL8411B PCI Express Card Reader
|
||||
1025 1094 Acer Aspire E5-575G
|
||||
@ -12790,6 +12860,8 @@
|
||||
103c 2a6f Asus IPIBL-LB Motherboard
|
||||
103c 825b OMEN-17-w001nv
|
||||
103c 8615 Pavilion Laptop 15-cw1xxx
|
||||
# Rev 29, uses r8169 Driver on Linux
|
||||
103c 8882 HP ProDesk 405 G8 Desktop Mini PC
|
||||
1043 11f5 Notebook motherboard (one of many models)
|
||||
1043 16d5 U6V/U31J laptop
|
||||
1043 81aa P5B
|
||||
@ -13699,6 +13771,8 @@
|
||||
9082 Standard AHCI 1.0 SATA Controller
|
||||
9140 HDMI Audio Device
|
||||
9201 USB3.0 Controller
|
||||
# Centaur CNS Coprocessor
|
||||
9380 Ncore Coprocessor
|
||||
9530 VX800/820/900 Series Secure Digital Memory Card Controller
|
||||
95d0 VX800/820/900 Series SDIO Host Controller
|
||||
a208 PT890 PCI to PCI Bridge Controller
|
||||
@ -16795,6 +16869,7 @@
|
||||
# PI7C9X20508GP 5Port-8Lane PCI Express Switch GreenPacket Family
|
||||
0508 PI7C9X20508GP PCI Express Switch 5Port-8Lane
|
||||
2304 PI7C9X2G304 EL/SL PCIe2 3-Port/4-Lane Packet Switch
|
||||
2308 PI7C9X2G308GP 8-lane PCI Express 2.0 Switch with 3 PCI Express ports
|
||||
2404 PI7C9X2G404 EL/SL PCIe2 4-Port/4-Lane Packet Switch
|
||||
2608 PI7C9X2G608GP PCIe2 6-Port/8-Lane Packet Switch
|
||||
ea50 cc10 RXi2-BP
|
||||
@ -17454,6 +17529,8 @@
|
||||
13a3 0036 DX1730 Acceleration Card
|
||||
0037 8204 Acceleration Processor
|
||||
13a3 0036 DX1740 Acceleration Card
|
||||
9240 XR9240 Compression and Security Coprocessor [Panther II]
|
||||
13a3 9200 DX2040 Compression and Security Acceleration Card [Panther II]
|
||||
13a4 Rascom Inc
|
||||
13a5 Audio Digital Imaging Inc
|
||||
13a6 Videonics Inc
|
||||
@ -19077,11 +19154,15 @@
|
||||
103c 1240 Myrinet M2L-PCI64/2-3.0 LANai 7.4 (HP OEM)
|
||||
14c2 DTK Computer
|
||||
14c3 MEDIATEK Corp.
|
||||
0608 RZ608 Wi-Fi 6E 80MHz
|
||||
0616 MT7922 802.11ax PCI Express Wireless Network Adapter
|
||||
7612 MT7612E 802.11acbgn PCI Express Wireless Network Adapter
|
||||
7615 MT7615E 802.11ac PCI Express Wireless Network Adapter
|
||||
7630 MT7630e 802.11bgn Wireless Network Adapter
|
||||
# MT7612E too?
|
||||
7662 MT7662E 802.11ac PCI Express Wireless Network Adapter
|
||||
7915 MT7915E 802.11ax PCI Express Wireless Network Adapter
|
||||
7961 MT7921 802.11ax PCI Express Wireless Network Adapter
|
||||
14c4 IWASAKI Information Systems Co Ltd
|
||||
14c5 Automation Products AB
|
||||
14c6 Data Race Inc
|
||||
@ -19424,6 +19505,10 @@
|
||||
1259 2708 AT-2712 FX
|
||||
# The Broadcom 57800 device has two 1Gig ports and two 10Gig ports. The subsystem information can be used to differentiate.
|
||||
168a NetXtreme II BCM57800 1/10 Gigabit Ethernet
|
||||
# SFP+ ports
|
||||
1014 0493 PCIe2 LP 4-Port (10Gb+1GbE) SR+RJ45 Adapter (FC EN0T; CCIN 2CC3)
|
||||
# RJ-45 ports
|
||||
1014 0494 PCIe2 LP 4-Port (10Gb+1GbE) SR+RJ45 Adapter (FC EN0T; CCIN 2CC3)
|
||||
1028 1f5c BCM57800 10-Gigabit Ethernet
|
||||
1028 1f5d BCM57800 10-Gigabit Ethernet
|
||||
1028 1f67 BCM57800 1-Gigabit Ethernet
|
||||
@ -20635,6 +20720,7 @@
|
||||
07b0 VMXNET3 Ethernet Controller
|
||||
07c0 PVSCSI SCSI Controller
|
||||
07e0 SATA AHCI controller
|
||||
07f0 NVMe SSD Controller
|
||||
0801 Virtual Machine Interface
|
||||
15ad 0800 Hypervisor ROM Interface
|
||||
0820 Paravirtual RDMA controller
|
||||
@ -20668,6 +20754,8 @@
|
||||
021d MT43244 Family [BlueField-3 Secure Flash Recovery]
|
||||
021e CX8 Family [ConnectX-8 Flash Recovery]
|
||||
021f CX8 Family [ConnectX-8 Secure Flash Recovery]
|
||||
0220 BF4 Family Flash Recovery [BlueField-4 SoC Flash Recovery]
|
||||
0221 BF4 Family Secure Flash Recovery [BlueField-4 Secure Flash Recovery]
|
||||
024e MT53100 [Spectrum-2, Flash recovery mode]
|
||||
024f MT53100 [Spectrum-2, Secure Flash recovery mode]
|
||||
0250 Spectrum-3, Flash recovery mode
|
||||
@ -20679,6 +20767,7 @@
|
||||
0256 Abir GearBox
|
||||
0257 Quantum-2 in Flash Recovery Mode
|
||||
0258 Quantum-2 RMA
|
||||
0259 Abir Chiplet
|
||||
0262 MT27710 [ConnectX-4 Lx Programmable] EN
|
||||
0263 MT27710 [ConnectX-4 Lx Programmable Virtual Function] EN
|
||||
0264 Innova-2 Flex Burn image
|
||||
@ -20686,6 +20775,7 @@
|
||||
0271 Spectrum-4L, RMA
|
||||
0274 Spectrum-4C, Flash recovery mode
|
||||
0275 Spectrum-4C RMA
|
||||
0277 Spectrum-4TOR RMA
|
||||
0281 NPS-600 Flash Recovery
|
||||
1002 MT25400 Family [ConnectX-2 Virtual Function]
|
||||
1003 MT27500 Family [ConnectX-3]
|
||||
@ -20857,10 +20947,14 @@
|
||||
a2da MT43244 BlueField-3 SoC Crypto enabled
|
||||
a2db MT43244 BlueField-3 SoC Crypto disabled
|
||||
a2dc MT43244 BlueField-3 integrated ConnectX-7 network controller
|
||||
a2dd BF4 Family Crypto enabled [BlueField-4 SoC Crypto enabled]
|
||||
a2de BF4 Family Crypto disabled [BlueField-4 SoC Crypto disabled]
|
||||
a2df BF4 Family integrated network controller [BlueField-4 integrated network controller]
|
||||
c2d2 MT416842 BlueField SoC management interfac
|
||||
c2d3 MT42822 BlueField-2 SoC Management Interface
|
||||
c2d4 MT43162 BlueField-3 Lx SoC Management Interface
|
||||
c2d5 MT43244 BlueField-3 SoC Management Interface
|
||||
c2d6 BF4 Family Management Interface [BlueField-4 SoC Management Interface]
|
||||
# SwitchX-2, 40GbE switch
|
||||
c738 MT51136
|
||||
c739 MT51136 GW
|
||||
@ -20956,8 +21050,9 @@
|
||||
15cc Hotrail Inc
|
||||
15cd Dreamtech Co Ltd
|
||||
15ce Genrad Inc
|
||||
15cf Hilscher GmbH
|
||||
0000 CIFX 50E-DP(M/S)
|
||||
# https://www.hilscher.com/imprint/
|
||||
15cf Hilscher Gesellschaft für Systemautomation mbH
|
||||
0000 CIFX PCI/PCIe
|
||||
15d1 Infineon Technologies AG
|
||||
15d2 FIC (First International Computer Inc)
|
||||
15d3 NDS Technologies Israel Ltd
|
||||
@ -21819,6 +21914,32 @@
|
||||
a036 ThunderX RAD (RAID acceleration engine) virtual function
|
||||
a037 THUNDERX ZIP virtual function
|
||||
a040 THUNDERX CPT Cryptographic Accelerator
|
||||
# MAC found on OcteonTx2 series of silicons
|
||||
a059 Octeon TX2 CGX (MAC)
|
||||
# MAC found on Octeon 10 series of silicons
|
||||
a060 Octeon 10 RPM (MAC)
|
||||
# Octeon Tx2 Loopback Interface block
|
||||
a061 Octeon Tx2 Loopback Interface (LBK)
|
||||
# Octeon Tx2 Resource Virtualization Unit Physical Function
|
||||
a063 Octeon Tx2 RVU Physical Function
|
||||
# Octeon Tx2 Resource Virtualization Unit Virtual Function
|
||||
a064 Octeon Tx2 RVU Virtual Function
|
||||
# Octeon Tx2 Resource Virtualization Unit Admin Function
|
||||
a065 Octeon Tx2 RVU Admin Function
|
||||
# PTP Timestamping unit on Octeon 10 silicon series
|
||||
a09e Octeon 10 PTP controller
|
||||
# Cryptographic Accelerator found on Octeon 10 series of silicons
|
||||
a0f2 Octeon 10 CPT Cryptographic Accelerator, Physical function
|
||||
a0f3 Octeon 10 CPT Cryptographic Accelerator, Virtual function
|
||||
# Octeon Tx2 System DPI Interface (SDP) Physical Function
|
||||
a0f6 Octeon Tx2 SDP Physical Function
|
||||
# Octeon Tx2 System DPI Interface (SDP) Virtual Function
|
||||
a0f7 Octeon Tx2 SDP Virtual Function
|
||||
a0f8 Octeon Tx2 Loopback Interface Virtual Function (LBKVF)
|
||||
# Cryptographic Accelerator found on OcteonTx2 series of silicons
|
||||
a0fd Octeon Tx2 CPT Cryptographic Accelerator, Physical function
|
||||
# Cryptographic Accelerator found on OcteonTx2 series of silicons
|
||||
a0fe Octeon Tx2 CPT Cryptographic Accelerator, Virtual function
|
||||
a100 THUNDERX CN88XX 48 core SoC
|
||||
a200 OCTEON TX CN81XX/CN80XX
|
||||
a300 OCTEON TX CN83XX
|
||||
@ -21933,6 +22054,8 @@
|
||||
0401 Datacenter Technologies QDF2400 PCI Express Root Port
|
||||
1000 QCS405 PCIe Root Complex
|
||||
1101 QCA6390 Wireless Network Adapter [AX500-DBS (2x2)]
|
||||
1103 Atheros QCNFA765
|
||||
1104 QCN6024/9024/9074 Wireless Network Adapter
|
||||
17cc NetChip Technology, Inc
|
||||
2280 USB 2.0
|
||||
17cd Cadence Design Systems, Inc.
|
||||
@ -22806,6 +22929,10 @@
|
||||
0011 FlexCard PMC-II Ethernet
|
||||
0018 FlexCard PXIe3
|
||||
0019 FlexCard PCIe3
|
||||
# IO card for std ethernet and automotive ethernet (ieee 1000Base-T1)
|
||||
001a FlexCard PXIe Ethernet
|
||||
# IO card for std ethernet and automotive ethernet (ieee 1000Base-T1)
|
||||
001b FlexCard PCIe Ethernet
|
||||
1976 TRENDnet
|
||||
1977 Parsec
|
||||
197b JMicron Technology Corp.
|
||||
@ -23137,6 +23264,11 @@
|
||||
1aa8 Ciprico, Inc.
|
||||
0009 RAIDCore Controller
|
||||
000a RAIDCore Controller
|
||||
1aa9 Schweitzer Engineering Laboratories
|
||||
000d SEL-3390S8 Serial Adapter
|
||||
000e SEL-3390E4 Ethernet Adapter
|
||||
0014 SEL-3390T Time and Ethernet Adapter
|
||||
0018 SEL-3390E4 Ethernet Adapter
|
||||
1aae Global Velocity, Inc.
|
||||
1ab4 Distributed Management Task Force, Inc. (DMTF)
|
||||
1ab6 CalDigit, Inc.
|
||||
@ -23207,6 +23339,8 @@
|
||||
0a58 microEnable 5 VD8-CL
|
||||
# CameraLink frame grabber
|
||||
0a5a microEnable 5 AD8-CL
|
||||
# CoaXpress frame grabber
|
||||
0a64 imaWorx CXP-12 Quad
|
||||
# OEM product
|
||||
0b52 mE5 Abacus 4G Base
|
||||
# OEM product
|
||||
@ -23311,12 +23445,15 @@
|
||||
1080 ASM1083/1085 PCIe to PCI Bridge
|
||||
1849 1080 Motherboard
|
||||
1142 ASM1042A USB 3.0 Host Controller
|
||||
1166 ASM1166 Serial ATA Controller
|
||||
1182 ASM1182e 2-Port PCIe x1 Gen2 Packet Switch
|
||||
1b21 118f ASM1182e 2-Port PCIe x1 Gen2 Packet Switch
|
||||
1184 ASM1184e 4-Port PCIe x1 Gen2 Packet Switch
|
||||
1849 1184 ASM1184e 4-Port PCIe x1 Gen2 Packet Switch
|
||||
1187 ASM1187e 7-Port PCIe x1 Gen2 Packet Switch
|
||||
1242 ASM1142 USB 3.1 Host Controller
|
||||
1343 ASM1143 USB 3.1 Host Controller
|
||||
1812 ASM1812 6-Port PCIe x4 Gen2 Packet Switch
|
||||
2142 ASM2142 USB 3.1 Host Controller
|
||||
1462 7a72 H270 PC MATE
|
||||
2824 ASM2824 PCIe Gen3 Packet Switch
|
||||
@ -23392,6 +23529,8 @@
|
||||
2241 88NR2241 Non-Volatile memory controller
|
||||
1028 2112 BOSS-N1 Monolithic
|
||||
1028 2113 BOSS-N1 Modular
|
||||
1028 2151 BOSS-N1 Modular ET
|
||||
1028 2196 ROR-N100
|
||||
1d49 0306 ThinkSystem M.2 NVMe 2-Bay RAID Enablement Kit
|
||||
1d49 0307 ThinkSystem 7mm NVMe 2-Bay Rear RAID Enablement Kit
|
||||
9120 88SE9120 SATA 6Gb/s Controller
|
||||
@ -23401,6 +23540,7 @@
|
||||
9128 88SE9128 PCIe SATA 6 Gb/s RAID controller
|
||||
9130 88SE9128 PCIe SATA 6 Gb/s RAID controller with HyperDuo
|
||||
1043 8438 P8P67 Deluxe Motherboard
|
||||
9170 88SE9170 PCIe 2.0 x1 2-port SATA 6 Gb/s Controller
|
||||
9172 88SE9172 SATA 6Gb/s Controller
|
||||
9178 88SE9170 PCIe SATA 6Gb/s Controller
|
||||
917a 88SE9172 SATA III 6Gb/s RAID Controller
|
||||
@ -23532,9 +23672,22 @@
|
||||
1bb1 0151 Nytro 5520
|
||||
# Kersey 2.5" TCG
|
||||
1bb1 0152 Nytro 5520 TCG
|
||||
# Nytro 5050H (Ebonhawk - High Performance)
|
||||
1bb1 0153 Nytro 5050H
|
||||
# Nytro 5050H TCG (Ebonhawk High Performance)
|
||||
1bb1 0154 Nytro 5050H TCG
|
||||
# Nytro 5050M (Ebonhawk Mainstream Performance)
|
||||
1bb1 0155 Nytro 5050M
|
||||
# Nytro 5050M TCG (Ebonhawk Mainstream Performance)
|
||||
1bb1 0156 Nytro 5050M TCG
|
||||
# Nytro 5050M (Ebonhawk Mainstream Performance) - 7mm
|
||||
1bb1 0157 Nytro 5050M 7mm
|
||||
# Nytro 5050M (Ebonhawk Mainstream Performance) TCG - 7mm
|
||||
1bb1 0158 Nytro 5050M TCG 7mm
|
||||
1bb1 01a1 Nytro XP7102
|
||||
5012 FireCuda 510 SSD
|
||||
5016 FireCuda 520 SSD
|
||||
5018 FireCuda 530 SSD
|
||||
1bb3 Bluecherry
|
||||
4304 BC-04120A MPEG4 4 port video encoder / decoder
|
||||
4309 BC-08240A MPEG4 4 port video encoder / decoder
|
||||
@ -23688,8 +23841,22 @@
|
||||
1028 2149 DC NVMe SED PE8010 RI U.2 7.68TB
|
||||
1028 214a DC NVMe PE8010 RI U.2 7.68TB
|
||||
1c5c 0100 PE8000 Series NVMe Solid State Drive
|
||||
2849 PE81x0 U.2/3 NVMe Solid State Drive
|
||||
1c5f Beijing Memblaze Technology Co. Ltd.
|
||||
000d PBlaze5 520/526
|
||||
000e PBlaze6 6530
|
||||
1c5f 0b20 NVMe SSD PBlaze6 6530 1920G AIC
|
||||
1c5f 0b21 NVMe SSD PBlaze6 6530 1920G 2.5" U.2
|
||||
1c5f 0b30 NVMe SSD PBlaze6 6530 3840G AIC
|
||||
1c5f 0b31 NVMe SSD PBlaze6 6530 3840G 2.5" U.2
|
||||
1c5f 0b40 NVMe SSD PBlaze6 6530 7680G AIC
|
||||
1c5f 0b41 NVMe SSD PBlaze6 6530 7680G 2.5" U.2
|
||||
1c5f 4b20 NVMe SSD PBlaze6 6530 1600G AIC
|
||||
1c5f 4b21 NVMe SSD PBlaze6 6530 1600G 2.5" U.2
|
||||
1c5f 4b30 NVMe SSD PBlaze6 6530 3200G AIC
|
||||
1c5f 4b31 NVMe SSD PBlaze6 6530 3200G 2.5" U.2
|
||||
1c5f 4b40 NVMe SSD PBlaze6 6530 6400G AIC
|
||||
1c5f 4b41 NVMe SSD PBlaze6 6530 6400G 2.5" U.2
|
||||
003d PBlaze5 920/926
|
||||
003e PBlaze6 6920
|
||||
1c5f 0a31 NVMe SSD PBlaze6 6920 3840GB 2.5" U.2
|
||||
@ -23738,6 +23905,8 @@
|
||||
0002 Clarett
|
||||
1cb8 Dawning Information Industry Co., Ltd.
|
||||
1cc1 ADATA Technology Co., Ltd.
|
||||
# 256GB NVMe SSD
|
||||
5766 ADATA XPG GAMMIXS1 1L Media
|
||||
8201 XPG SX8200 Pro PCIe Gen3x4 M.2 2280 Solid State Drive
|
||||
1cc4 Union Memory (Shenzhen)
|
||||
1203 NVMe SSD Controller UHXXXa series
|
||||
@ -23751,6 +23920,7 @@
|
||||
1cc4 a213 NVMe SSD UHXXXa series U.2 3200GB
|
||||
1cc4 a214 NVMe SSD UHXXXa series U.2 6400GB
|
||||
17ab NVMe 256G SSD device
|
||||
6303 AM630 PCIe 4.0 x4 NVMe SSD Controller
|
||||
1cc5 Embedded Intelligence, Inc.
|
||||
0100 CAN-PCIe-02
|
||||
1cc7 Radian Memory Systems Inc.
|
||||
@ -23946,6 +24116,7 @@
|
||||
101c AR-ARK-SRIOV-VF [Arkville Virtual Function]
|
||||
101d AR-ARK-NIC [Arkville ArkNIC Kernel Path Device]
|
||||
101e AR-ARKA-FX1 [Arkville 64B DPDK Data Mover for Agilex R-Tile]
|
||||
101f AR-TK242 [2x100GbE Packet Capture Device]
|
||||
4200 A5PL-E1-10GETI [10 GbE Ethernet Traffic Instrument]
|
||||
1d72 Xiaomi
|
||||
1d78 DERA Storage
|
||||
@ -24157,6 +24328,9 @@
|
||||
2000 NoLoad Hardware Development Kit
|
||||
3000 eBPF-based PCIe Accelerator
|
||||
1ded Alibaba (China) Co., Ltd.
|
||||
# A RDMA (iWarp) device provided by Alibaba Cloud used in ECS environment
|
||||
107f Elastic RDMA Adapter
|
||||
5007 Elastic RDMA Adapter
|
||||
8000 M1 Root Port
|
||||
8001 ACC-RCiEP
|
||||
8002 RCiEP VF
|
||||
@ -24264,9 +24438,20 @@
|
||||
1028 210e Dell Ent NVMe FIPS CM6 MU 1.6TB
|
||||
1028 210f Dell Ent NVMe FIPS CM6 MU 3.2TB
|
||||
1028 2110 Dell Ent NVMe FIPS CM6 MU 6.4TB
|
||||
1e0f 0001 Generic NVMe CM6 RI 3.84TB
|
||||
1e0f 0001 Generic NVMe CM6
|
||||
0009 NVMe SSD
|
||||
1e0f 0001 Toshiba RC500 NVMe SSD 500GB
|
||||
0011 NVMe SSD Controller CD7
|
||||
1028 2189 DC NVMe SED CD7 RI 960GB
|
||||
1028 218a DC NVMe CD7 RI 960GB
|
||||
1028 218b DC NVMe SED CD7 RI 1.92TB
|
||||
1028 218c DC NVMe CD7 RI 1.92TB
|
||||
1028 218d DC NVMe SED CD7 RI 3.84TB
|
||||
1028 218e DC NVMe CD7 RI 3.84TB
|
||||
1028 218f DC NVMe SED CD7 RI 7.68TB
|
||||
1028 2190 DC NVMe CD7 RI 7.68TB
|
||||
1028 2191 DC NVMe SED CD7 RI 15.36TB
|
||||
1028 2192 DC NVMe CD7 RI 15.36TB
|
||||
1e17 Arnold & Richter Cine Technik GmbH & Co. Betriebs KG
|
||||
1e24 Squirrels Research Labs
|
||||
0101 Acorn CLE-101
|
||||
@ -24296,7 +24481,7 @@
|
||||
0102 Xplorer X1600
|
||||
# https://www.medion.com/
|
||||
1e39 MEDION AG
|
||||
1e3b Shenzhen DAPU Microelectronics Co., Ltd
|
||||
1e3b DapuStor Corporation
|
||||
0600 NVMe SSD Controller DPU600
|
||||
1e3b 0030 Enterprise NVMe SSD U.2 3.84TB (J5100)
|
||||
1e3b 0031 Enterprise NVMe SSD U.2 7.68TB (J5100)
|
||||
@ -24359,6 +24544,7 @@
|
||||
1e3b 0091 Enterprise NVMe SSD HHHL 0.75TB (H3900)
|
||||
1e3d Burlywood, Inc
|
||||
1e49 Yangtze Memory Technologies Co.,Ltd
|
||||
0041 ZHITAI TiPro7000
|
||||
# YMTC PCIe/NVMe SSD
|
||||
1013 PC210
|
||||
1e4b MAXIO Technology (Hangzhou) Ltd.
|
||||
@ -24377,6 +24563,9 @@
|
||||
0000 0100 PY8800 64GB Accelerator
|
||||
1e59 Oxford Nanopore Technologies
|
||||
0001 MinION Mk1C
|
||||
1e5d ASR Microelectronics
|
||||
7000 AI controller A7000
|
||||
7010 AI controller A7010
|
||||
1e60 Hailo Technologies Ltd.
|
||||
2864 Hailo-8 AI Processor
|
||||
1e68 Jiangsu Xinsheng Intelligent Technology Co., Ltd
|
||||
@ -24414,14 +24603,22 @@
|
||||
1eab Hefei DATANG Storage Technology Co.,LTD.
|
||||
300a NVMe SSD Controller 300A
|
||||
300b NVMe SSD Controller 300B
|
||||
1eac Quectel Wireless Solutions Co., Ltd.
|
||||
1001 EM120R-GL LTE Modem
|
||||
1002 EM160R-GL LTE Modem
|
||||
1eae XFX Limited
|
||||
1eb1 VeriSilicon Inc
|
||||
1001 Video Accelerator
|
||||
1eb4 Quantum Nebula Microelectronics Technology Co.,Ltd.
|
||||
3401 SSD Contoller
|
||||
1ebd EMERGETECH Company Ltd.
|
||||
0101 Seirios 2063 Video Codec
|
||||
1ed2 FuriosaAI, Inc.
|
||||
0000 Warboy
|
||||
1ed3 Yeston
|
||||
1ed5 Moore Threads Technology Co.,Ltd
|
||||
0100 MTT S10
|
||||
0101 MTT S30
|
||||
1ed8 Digiteq Automotive
|
||||
0101 FG4 PCIe Frame Grabber
|
||||
1ed9 Myrtle.ai
|
||||
@ -24439,6 +24636,13 @@
|
||||
5220 IG5220-Based NVMe SSD
|
||||
5236 IG5236-Based NVMe SSD
|
||||
5636 IG5636-Based NVMe SSD
|
||||
1f2f China Mobile (Hangzhou) Information Technology Co.Ltd.
|
||||
1513 DERA MENG NVMe Controller
|
||||
1f2f 6113 KM660 U.2 1.6TB NVMe SSD
|
||||
1f2f 6114 KM560 U.2 1.92TB NVMe SSD
|
||||
1f2f 6115 KM660 U.2 3.2TB NVMe SSD
|
||||
1f2f 6116 KM560 U.2 3.84TB NVMe SSD
|
||||
1f2f 6118 KM560 U.2 7.68TB NVMe SSD
|
||||
1fab Unifabrix Ltd.
|
||||
0000 Nexus Alpha IVPU
|
||||
# nee Tumsan Oy
|
||||
@ -25182,6 +25386,12 @@
|
||||
1400 CooVOX TDM GSM Module
|
||||
1600 CooVOX TDM E1/T1 Module
|
||||
1800 CooVOX TDM BRI Module
|
||||
6766 Glenfly Tech Co., Ltd.
|
||||
3d00 Arise-GT-10C0
|
||||
3d02 Arise 1020
|
||||
3d40 Arise-GT-10C0 High Definition Audio Controller
|
||||
3d41 Arise 1020 High Definition Audio Controller
|
||||
6899 ZT Systems
|
||||
# nee Qumranet
|
||||
6900 Red Hat, Inc.
|
||||
7063 pcHDTV
|
||||
@ -25194,6 +25404,9 @@
|
||||
7401 EndRun Technologies
|
||||
e100 PTP3100 PCIe PTP Slave Clock
|
||||
7470 TP-LINK Technologies Co., Ltd.
|
||||
7526 HongQin (Beijing) Technology Co., Ltd.
|
||||
0082 HQ SSD 1TB
|
||||
0083 HQ SSD 2TB M.2 NVMe
|
||||
7604 O.N. Electronic Co Ltd.
|
||||
7bde MIDAC Corporation
|
||||
7fed PowerTV
|
||||
@ -26006,6 +26219,12 @@
|
||||
1028 2102 NVMe RI U.2 1.92TB (P5500)
|
||||
1028 2103 NVMe RI U.2 3.84TB (P5500)
|
||||
1028 2104 NVMe RI U.2 7.68TB (P5500)
|
||||
1028 219a NVMe P5316 RI 15.36TB
|
||||
1028 219b NVMe P5316 RI 30.72TB
|
||||
1028 219c NVMe SED P5316 RI 15.36
|
||||
1028 219d NVMe SED P5316 RI 30.72
|
||||
1028 219e NVMe FIPS P5316 RI 15.36TB
|
||||
1028 219f NVMe FIPS P5316 RI 30.72
|
||||
8086 8008 NVMe Datacenter SSD [3DNAND] SE 2.5" U.2 (P5510)
|
||||
8086 8d08 NVMe Datacenter SSD [3DNAND] VE 2.5" U.2 (P5316)
|
||||
8086 8d1d NVMe Datacenter SSD [3DNAND] VE E1.L 9.5/18mm (P5316)
|
||||
@ -26114,8 +26333,15 @@
|
||||
8086 0001 Ethernet Controller XXV710 Intel(R) FPGA Programmable Acceleration Card N3000 for Networking
|
||||
0d9f Ethernet Controller (2) I225-IT
|
||||
0dd2 Ethernet Network Adapter I710
|
||||
1137 0000 I710T4LG 4x1 GbE RJ45 PCIe NIC
|
||||
1137 02e3 I710T4LG 4x1 GbE RJ45 PCIe NIC
|
||||
8086 0000 Ethernet Network Adapter I710-T4L
|
||||
8086 000d Ethernet Network Adapter I710-T4L
|
||||
8086 0010 Ethernet Network Adapter I710-T4L for OCP 3.0
|
||||
8086 401a Ethernet Network Adapter I710-T4L
|
||||
8086 401b Ethernet Network Adapter I710-T4L for OCP 3.0
|
||||
0dda Ethernet Connection X722 for 10GbE SFP+
|
||||
1bd4 0076 Ethernet Connection X722 for 10GbE SFP+
|
||||
0e00 Xeon E7 v2/Xeon E5 v2/Core i7 DMI2
|
||||
1028 04f7 Xeon E5 v2 on PowerEdge R320 server
|
||||
15d9 066b X9SRL-F
|
||||
@ -27466,6 +27692,7 @@
|
||||
8086 000c Ethernet 100G 2P E810-C OCP
|
||||
8086 000d Ethernet Network Adapter E810-L-Q2 for OCP 3.0
|
||||
8086 000e Ethernet Network Adapter E810-2C-Q2
|
||||
8086 0010 Ethernet 100G 2P E810-C-stg Adapter
|
||||
1593 Ethernet Controller E810-C for SFP
|
||||
1137 02c3 E810XXVDA4 4x25/10 GbE SFP28 PCIe NIC
|
||||
8086 0002 Ethernet Network Adapter E810-L-2
|
||||
@ -27478,7 +27705,10 @@
|
||||
8086 000c Ethernet Network Adapter E810-XXV-4 for OCP 3.0
|
||||
8086 000d Ethernet 25G 4P E810-XXV OCP
|
||||
8086 000e Ethernet Network Adapter E810-XXV-4T
|
||||
8086 000f Ethernet 25G 4P E810-XXV-stg Adapter
|
||||
8086 0010 Ethernet 25G 4P E810-XXV-st Adapter
|
||||
1599 Ethernet Controller E810-XXV for backplane
|
||||
8086 0001 Ethernet 25G 2P E810-XXV-k Mezz
|
||||
159a Ethernet Controller E810-XXV for QSFP
|
||||
159b Ethernet Controller E810-XXV for SFP
|
||||
1137 02be E810XXVDA2 2x25/10 GbE SFP28 PCIe NIC
|
||||
@ -31187,6 +31417,7 @@
|
||||
3432 5520/5500/X58 Chipset QuickData Technology Device
|
||||
3433 5520/5500/X58 Chipset QuickData Technology Device
|
||||
3438 7500/5520/5500/X58 I/O Hub Throttle Registers
|
||||
347e Ice Lake Xeon Non-Transparent Bridge
|
||||
3482 Ice Lake-LP LPC Controller
|
||||
34a3 Ice Lake-LP SMBus Controller
|
||||
34a4 Ice Lake-LP SPI Controller
|
||||
@ -31997,8 +32228,10 @@
|
||||
8086 02a4 Wireless-AC 9462
|
||||
444e Turbo Memory Controller
|
||||
460d 12th Gen Core Processor PCI Express x16 Controller #1
|
||||
461d Alder Lake Innovation Platform Framework Processor Participant
|
||||
461e Alder Lake-P Thunderbolt 4 USB Controller
|
||||
461f Alder Lake-P Thunderbolt 4 PCI Express Root Port #3
|
||||
4626 Alder Lake-P Integrated Graphics Controller
|
||||
4629 12th Gen Core Processor Host Bridge/DRAM Registers
|
||||
462f Alder Lake-P Thunderbolt 4 PCI Express Root Port #2
|
||||
463d 12th Gen Core Processor PCI Express x4 Controller #2
|
||||
@ -32007,6 +32240,7 @@
|
||||
4641 12th Gen Core Processor Host Bridge/DRAM Registers
|
||||
464d 12th Gen Core Processor PCI Express x4 Controller #0
|
||||
464f 12th Gen Core Processor Gaussian & Neural Accelerator
|
||||
4660 12th Gen Core Processor Host Bridge/DRAM Registers
|
||||
466d Alder Lake-P Thunderbolt 4 NHI #1
|
||||
466e Alder Lake-P Thunderbolt 4 PCI Express Root Port #0
|
||||
467d Platform Monitoring Technology
|
||||
@ -32015,6 +32249,7 @@
|
||||
46a0 AlderLake-P GT2
|
||||
46a1 UHD Graphics
|
||||
46a3 Alder Lake-P GT1 [UHD Graphics]
|
||||
46a6 Alder Lake-P Integrated Graphics Controller
|
||||
46c0 AlderLake-M GT1
|
||||
4905 DG1 [Iris Xe MAX Graphics]
|
||||
4906 DG1 [Iris Xe Pod]
|
||||
@ -32026,8 +32261,9 @@
|
||||
4c8b RocketLake-S GT1 [UHD Graphics 730]
|
||||
4c90 RocketLake-S GT1 [UHD Graphics P750]
|
||||
4c9a RocketLake-S [UHD Graphics]
|
||||
4da3 JaserLake SMBus
|
||||
4da4 JaserLake SPI (flash) Controller
|
||||
4da3 Jasper Lake SMBus
|
||||
4da4 Jasper Lake SPI Controller
|
||||
4dc8 Jasper Lake HD Audio
|
||||
4de0 Management Engine Interface
|
||||
4de8 Serial IO I2C Host Controller
|
||||
4de9 Serial IO I2C Host Controller
|
||||
@ -32088,8 +32324,11 @@
|
||||
504b EP80579 Reserved
|
||||
504c EP80579 Integrated Processor with QuickAssist TDM
|
||||
5181 Alder Lake PCH-P LPC/eSPI Controller
|
||||
5182 Alder Lake PCH eSPI Controller
|
||||
51a3 Alder Lake PCH-P SMBus Host Controller
|
||||
51a4 Alder Lake-P PCH SPI Controller
|
||||
51a8 Alder Lake PCH UART #0
|
||||
51a9 Alder Lake PCH UART #1
|
||||
51bf Alder Lake PCH-P PCI Express Root Port #9
|
||||
51c5 Alder Lake-P Serial IO I2C Controller #0
|
||||
51c6 Alder Lake-P Serial IO I2C Controller #1
|
||||
@ -32471,6 +32710,20 @@
|
||||
10b4 202f Lightspeed 740
|
||||
8086 0000 Terminator 2x/i
|
||||
8086 0100 Intel740 Graphics Accelerator
|
||||
# Unlike other PCH components. The eSPI controller is specific to each chipset model
|
||||
7a84 Z690 Chipset LPC/eSPI Controller
|
||||
7aa3 Alder Lake-S PCH SMBus Controller
|
||||
7aa4 Alder Lake-S PCH SPI Controller
|
||||
7aa7 Alder Lake-S PCH Shared SRAM
|
||||
7ab4 Alder Lake-S PCH PCI Express Root Port #13
|
||||
7abd Alder Lake-S PCH PCI Express Root Port #6
|
||||
7acc Alder Lake-S PCH I2C Controller #0
|
||||
7ad0 Alder Lake-S HD Audio Controller
|
||||
7ae0 Alder Lake-S PCH USB 3.2 Gen 2x2 XHCI Controller
|
||||
7ae2 Alder Lake-S PCH SATA Controller [AHCI Mode]
|
||||
7ae8 Alder Lake-S PCH HECI Controller #1
|
||||
7af0 Alder Lake-S PCH CNVi WiFi
|
||||
8086 0094 Wi-Fi 6 AX201 160MHz
|
||||
8002 Trusted Execution Technology Registers
|
||||
8003 Trusted Execution Technology Registers
|
||||
8100 US15W/US15X SCH [Poulsbo] Host Bridge
|
||||
@ -32840,6 +33093,7 @@
|
||||
1028 09be Latitude 7410
|
||||
9b63 10th Gen Core Processor Host Bridge/DRAM Registers
|
||||
9b64 10th Gen Core Processor Host Bridge/DRAM Registers
|
||||
9ba8 CometLake-S GT1 [UHD Graphics 610]
|
||||
9bc4 CometLake-H GT2 [UHD Graphics]
|
||||
9bc5 CometLake-S GT2 [UHD Graphics 630]
|
||||
9bc8 CometLake-S GT2 [UHD Graphics 630]
|
||||
@ -33040,6 +33294,7 @@
|
||||
9d3d Sunrise Point-LP Active Management Technology - SOL
|
||||
103c 8079 EliteBook 840 G3
|
||||
17aa 2247 ThinkPad T570
|
||||
9d3e iTouch Controller
|
||||
9d43 Sunrise Point-LP LPC Controller
|
||||
17aa 382a B51-80 Laptop
|
||||
9d46 LPC/eSPI Controller
|
||||
@ -33094,6 +33349,7 @@
|
||||
9da4 Cannon Point-LP SPI Controller
|
||||
9da8 Cannon Point-LP Serial IO UART Controller #2
|
||||
9daa Cannon Point-LP Serial IO SPI Controller
|
||||
9dab Cannon Point-LP Serial IO SPI Controller
|
||||
9db0 Cannon Point-LP PCI Express Root Port #9
|
||||
9db1 Cannon Point-LP PCI Express Root Port #10
|
||||
9db2 Cannon Point-LP PCI Express Root Port #1
|
||||
@ -33104,6 +33360,7 @@
|
||||
9dbc Cannon Point-LP PCI Express Root Port #5
|
||||
9dbe Cannon Point-LP PCI Express Root Port #7
|
||||
9dbf Cannon Point PCI Express Root Port #8
|
||||
9dc4 Cannon Point-LP SD Host Controller
|
||||
9dc5 Cannon Point-LP Serial IO I2C Host Controller
|
||||
9dc8 Cannon Point-LP High Definition Audio Controller
|
||||
1028 089e Inspiron 5482
|
||||
@ -33467,7 +33724,7 @@
|
||||
a397 Comet Lake PCI Express Root Port #08
|
||||
a398 Comet Lake PCI Express Root Port 9
|
||||
a39a Comet Lake PCI Express Root Port 11
|
||||
a3a1 Memory controller
|
||||
a3a1 Cannon Lake PCH Power Management Controller
|
||||
a3a3 Comet Lake PCH-V SMBus Host Controller
|
||||
a3af Comet Lake PCH-V USB Controller
|
||||
a3b1 Comet Lake PCH-V Thermal Subsystem
|
||||
@ -33958,6 +34215,8 @@
|
||||
1bd4 0070 RS0800M5E24i
|
||||
1bd4 0071 RS0800M5H16i
|
||||
1bd4 0072 RS0800M5E16i
|
||||
1cc4 0101 Ramaxel FBGF-RAD PM8204
|
||||
1cc4 0201 Ramaxel FBGF-RAD PM8222
|
||||
1d49 0220 ThinkSystem 4350-8i SAS/SATA 12Gb HBA
|
||||
1d49 0221 ThinkSystem 4350-16i SAS/SATA 12Gb HBA
|
||||
1d49 0520 ThinkSystem RAID 5350-8i PCIe 12Gb Adapter
|
||||
@ -34244,6 +34503,8 @@ cddd Tyzx, Inc.
|
||||
0101 DeepSea 1 High Speed Stereo Vision Frame Grabber
|
||||
0200 DeepSea 2 High Speed Stereo Vision Frame Grabber
|
||||
ceba KEBA AG
|
||||
cf86 Spectrum-4TOR
|
||||
0276 Spectrum-4TOR in Flash Recovery Mode
|
||||
d161 Digium, Inc.
|
||||
0120 Wildcard TE120P single-span T1/E1/J1 card
|
||||
0205 Wildcard TE205P/TE207P dual-span T1/E1/J1 card 5.0V
|
||||
@ -34728,8 +34989,7 @@ C 11 Signal processing controller
|
||||
80 Signal processing controller
|
||||
C 12 Processing accelerators
|
||||
00 Processing accelerators
|
||||
# For the class of PCI attached devices which perform a function of Deep Learning Neural Network inference acceleration
|
||||
01 AI Inference Accelerator
|
||||
01 SNIA Smart Data Accelerator Interface (SDXI) controller
|
||||
C 13 Non-Essential Instrumentation
|
||||
C 40 Coprocessor
|
||||
C ff Unassigned class
|
||||
|
@ -2499,6 +2499,9 @@
|
||||
<tr class="odd"><td>Kopin Corporation</td><td>KOP</td><td>10/01/2021</td> </tr>
|
||||
<tr class="even"><td>Anker Innovations Limited</td><td>AKR</td><td>12/10/2021</td> </tr>
|
||||
<tr class="odd"><td>SAMPO CORPORATION</td><td>SPO</td><td>12/10/2021</td> </tr>
|
||||
<tr class="even"><td>Shiftall Inc.</td><td>SFL</td><td>12/31/2021</td> </tr>
|
||||
<tr class="odd"><td>AudioControl</td><td>AUD</td><td>12/31/2021</td> </tr>
|
||||
<tr class="even"><td>Schneider Consumer Group</td><td>SCA</td><td>02/08/2022</td> </tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</body>
|
||||
|
@ -9,8 +9,8 @@
|
||||
# The latest version can be obtained from
|
||||
# http://www.linux-usb.org/usb.ids
|
||||
#
|
||||
# Version: 2021.10.24
|
||||
# Date: 2021-10-24 20:34:08
|
||||
# Version: 2022.03.18
|
||||
# Date: 2022-03-18 20:34:09
|
||||
#
|
||||
|
||||
# Vendors, devices and interfaces. Please keep sorted.
|
||||
@ -2712,6 +2712,8 @@
|
||||
0845 ConferenceCam CC3000e Camera
|
||||
0846 ConferenceCam CC3000e Speakerphone
|
||||
084b ConferenceCam Connect Video
|
||||
084c ConferenceCam Connect Audio
|
||||
084e ConferenceCam Connect
|
||||
0850 QuickCam Web
|
||||
0857 Logi Group Speakerphone
|
||||
085c C922 Pro Stream Webcam
|
||||
@ -2764,7 +2766,7 @@
|
||||
08d7 QuickCam Communicate STX
|
||||
08d8 QuickCam for Notebook Deluxe
|
||||
08d9 QuickCam IM/Connect
|
||||
08da QuickCam Messanger
|
||||
08da QuickCam Messenger
|
||||
08dd QuickCam for Notebooks
|
||||
08e0 QuickCam Express
|
||||
08e1 Labtec Webcam
|
||||
@ -2903,7 +2905,7 @@
|
||||
c06a USB Optical Mouse
|
||||
c06b G700 Wireless Gaming Mouse
|
||||
c06c Optical Mouse
|
||||
c077 M105 Optical Mouse
|
||||
c077 Mouse
|
||||
c07c M-R0017 [G700s Rechargeable Gaming Mouse]
|
||||
c07d G502 Mouse
|
||||
c07e G402 Gaming Mouse
|
||||
@ -2911,7 +2913,7 @@
|
||||
c083 G403 Prodigy Gaming Mouse
|
||||
c084 G203 Gaming Mouse
|
||||
c08b G502 SE HERO Gaming Mouse
|
||||
c092 G203 LIGHTSYNC Gaming Mouse
|
||||
c092 G102/G203 LIGHTSYNC Gaming Mouse
|
||||
c101 UltraX Media Remote
|
||||
c110 Harmony 785/880/885 Remote
|
||||
c111 Harmony 525 Remote
|
||||
@ -3060,6 +3062,7 @@
|
||||
c532 Unifying Receiver
|
||||
c534 Unifying Receiver
|
||||
c537 Cordless Mouse Receiver
|
||||
c539 Cordless Mouse Receiver
|
||||
c53a PowerPlay Wireless Charging System
|
||||
c53d G631 Keyboard
|
||||
c603 3Dconnexion Spacemouse Plus XT
|
||||
@ -19572,10 +19575,11 @@
|
||||
5512 CH341 in EPP/MEM/I2C mode, EPP/I2C adapter
|
||||
5523 CH341 in serial mode, usb to serial port converter
|
||||
5584 CH341 in parallel mode, usb to printer port converter
|
||||
7522 CH340 serial converter
|
||||
7523 CH340 serial converter
|
||||
752d CH345 MIDI adapter
|
||||
7584 CH340S
|
||||
e008 HID-based serial adapater
|
||||
e008 HID-based serial adapter
|
||||
1a89 Dynalith Systems Co., Ltd.
|
||||
1a8b SGS Taiwan Ltd.
|
||||
1a8d BandRich, Inc.
|
||||
@ -20338,7 +20342,7 @@
|
||||
6052 APB Team Robotic Development Board
|
||||
6053 Darkgame Controller
|
||||
6054 Satlab/AAUSAT3 BlueBox
|
||||
6055 RADiuS ER900TRS-02 transciever with SMA Connector
|
||||
6055 RADiuS ER900TRS-02 transceiver with SMA Connector
|
||||
6056 The Glitch
|
||||
6057 OpenPipe MIDI Shield
|
||||
6058 Novena OTG port
|
||||
@ -20475,10 +20479,10 @@
|
||||
60ec Duet 2 WiFi or Duet 2 Ethernet 3D printer control electronics
|
||||
60ed Duet 2 Maestro 3D printer control electronics
|
||||
60ee Duet 3 motion control electronics
|
||||
60f0 UDAD-T1 data aquisition device (boot)
|
||||
60f1 UDAD-T1 data aquisition device
|
||||
60f2 UDAD-T2 data aquisition device (boot)
|
||||
60f3 UDAD-T2 data aquisition device
|
||||
60f0 UDAD-T1 data acquisition device (boot)
|
||||
60f1 UDAD-T1 data acquisition device
|
||||
60f2 UDAD-T2 data acquisition device (boot)
|
||||
60f3 UDAD-T2 data acquisition device
|
||||
60f4 Uniti ARC motor controller
|
||||
60f5 EightByEight Blinky Badge (DFU)
|
||||
60f6 EightByEight Blinky Badge
|
||||
@ -20494,6 +20498,7 @@
|
||||
6118 Thomson MO5 keyboard
|
||||
6122 Ultimate Hacking Keyboard
|
||||
614c dwtk In-Circuit Emulator
|
||||
614d Generic Display
|
||||
8085 Box0 (box0-v5)
|
||||
cc15 rad1o badge for CCC summer camp 2015
|
||||
1d57 Xenta
|
||||
@ -20511,7 +20516,7 @@
|
||||
ad03 [T3] 2.4GHz and IR Air Mouse Remote Control
|
||||
af01 AUVIO Universal Remote Receiver for PlayStation 3
|
||||
af03 Wireless Receiver
|
||||
fa20 2.4GHz Wireless Reciever (Mini Keyboard & Mouse)
|
||||
fa20 2.4GHz Wireless Receiver (Mini Keyboard & Mouse)
|
||||
1d5b Smartronix, Inc.
|
||||
1d5c Fresco Logic
|
||||
2000 FL2000/FL2000DX VGA/DVI/HDMI Adapter
|
||||
@ -20819,7 +20824,12 @@
|
||||
0001 Wi-Fi Body Scale (WBS01)
|
||||
1fba DERMALOG Identification Systems GmbH
|
||||
1fbd Delphin Technology AG
|
||||
0001 Expert Key - Data aquisition system
|
||||
0001 Expert Key - Data acquisition system
|
||||
0004 MetiOS Device (RNDIS)
|
||||
0005 Loggito
|
||||
0006 LoggitoLab 8 AI-RTD
|
||||
0007 LoggitoLab 8 TC
|
||||
0008 LoggitoLab 4 AI-RTD 4 TC
|
||||
1fc9 NXP Semiconductors
|
||||
0003 LPC1343
|
||||
000c LPC4330FET180 [ARM Cortex M4 + M0] (device firmware upgrade mode)
|
||||
@ -22644,6 +22654,14 @@
|
||||
f190 MSO-19
|
||||
f280 MSO-28
|
||||
f281 MSO-28
|
||||
3197 Katusha
|
||||
1001 M151
|
||||
1002 M250
|
||||
1003 P130
|
||||
1004 M130
|
||||
1101 P247
|
||||
1102 M247
|
||||
1103 M348
|
||||
31c9 BeiJing LanXum Computer Technology Co., Ltd.
|
||||
1001 Printer
|
||||
1301 Black and White Laser Printer
|
||||
@ -23238,7 +23256,12 @@
|
||||
0780 CS780 Microphone Input
|
||||
07d3 BLOB boot loader firmware
|
||||
07dc Bluetooth 4.0* Smart Ready (low energy)
|
||||
0a66 RealSense 3D Camera (Front F200)
|
||||
0aa5 RealSense SR300
|
||||
0ad2 RealSense D410
|
||||
0ad3 RealSense D415
|
||||
0b07 RealSense D435
|
||||
0b64 RealSense L515
|
||||
0dad Cherry MiniatureCard Keyboard
|
||||
1010 AnyPoint(TM) Home Network 10 Mbps Phoneline Adapter
|
||||
110a Bluetooth Controller from (Ericsson P4A)
|
||||
@ -23264,6 +23287,7 @@
|
||||
9303 8x930Hx Hub
|
||||
9500 CE 9500 DVB-T
|
||||
9890 82930 Test Board
|
||||
a36d Host Controller
|
||||
beef SCM Miniature Card Reader/Writer
|
||||
c013 Wireless HID Station
|
||||
dead Galileo
|
||||
@ -23278,7 +23302,6 @@
|
||||
0032 AX210 Bluetooth
|
||||
0716 Modem Flashloader
|
||||
07da Centrino Bluetooth Wireless Transceiver
|
||||
8087 07da Centrino Advanced-N 6235
|
||||
07db Atom C2000 Root Hub
|
||||
07dc Bluetooth wireless interface
|
||||
07eb Oaktrail tablet
|
||||
|
@ -92,7 +92,10 @@
|
||||
url="https://systemd.io/BOOT_LOADER_SPECIFICATION">Boot Loader Specification</ulink>, as well as any
|
||||
other entries discovered or automatically generated by a boot loader implementing the <ulink
|
||||
url="https://systemd.io/BOOT_LOADER_INTERFACE">Boot Loader
|
||||
Interface</ulink>.</para></listitem>
|
||||
Interface</ulink>.</para>
|
||||
|
||||
<para>JSON output may be requested with <option>--json=</option>.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
@ -258,26 +261,64 @@
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><option>--make-machine-id-directory=yes|no</option></term>
|
||||
<listitem><para>Control creation and deletion of the top-level machine ID directory on the file
|
||||
system containing boot loader entries (i.e. beneath the file system returned by the
|
||||
<option>--print-boot-path</option> option, see above) during <option>install</option> and
|
||||
<option>remove</option>, respectively. Defaults to <literal>no</literal>. See
|
||||
<term><option>--make-entry-directory=yes|no</option></term>
|
||||
<listitem><para>Controls creation and deletion of the <ulink
|
||||
url="https://systemd.io/BOOT_LOADER_SPECIFICATION">Boot Loader Specification</ulink> Type #1 entry
|
||||
directory on the file system containing resources such as kernel images and initial RAM disk images
|
||||
during <option>install</option> and <option>remove</option>, respectively. The directory is named
|
||||
after the entry token, as specified with <option>--entry-token=</option> parameter described below,
|
||||
and is placed immediately below the <varname>$BOOT</varname> root directory (i.e. beneath the file
|
||||
system returned by the <option>--print-boot-path</option> option, see above). Defaults to
|
||||
<literal>no</literal>.</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><option>--entry-token=</option></term>
|
||||
|
||||
<listitem><para>Controls how to name and identify boot loader entries for this OS
|
||||
installation. Accepted during <option>install</option>, and takes one of <literal>auto</literal>,
|
||||
<literal>machine-id</literal>, <literal>os-id</literal>, <literal>os-image-id</literal> or an
|
||||
arbitrary string prefixed by <literal>literal:</literal> as argument.</para>
|
||||
|
||||
<para>If set to <option>machine-id</option> the entries are named after the machine ID of the running
|
||||
system (e.g. <literal>b0e793a9baf14b5fa13ecbe84ff637ac</literal>). See
|
||||
<citerefentry><refentrytitle>machine-id</refentrytitle><manvolnum>5</manvolnum></citerefentry> for
|
||||
details about the machine ID concept and file.</para>
|
||||
|
||||
<para>Overriding this may be desirable to hide the machine ID from the (unencrypted) ESP, configure a
|
||||
<citerefentry><refentrytitle>kernel-install</refentrytitle><manvolnum>8</manvolnum></citerefentry>
|
||||
script, or, conversely, commit a transient machine ID.</para>
|
||||
<para>If set to <option>os-id</option> the entries are named after the OS ID of the running system,
|
||||
i.e. the <varname>ID=</varname> field of
|
||||
<citerefentry><refentrytitle>os-release</refentrytitle><manvolnum>5</manvolnum></citerefentry>
|
||||
(e.g. <literal>fedora</literal>). Similar, if set to <option>os-image-id</option> the entries are
|
||||
named after the OS image ID of the running system, i.e. the <varname>IMAGE_ID=</varname> field of
|
||||
<filename>os-release</filename> (e.g. <literal>vendorx-cashier-system</literal>).</para>
|
||||
|
||||
<para>The top-level machine ID directory is useful to allow smooth multi-boot installations: each
|
||||
installed OS instance will have a different machine ID and thus a separate directory to place its
|
||||
boot-time resources in. If this feature is turned off with this option, care needs to be taken that
|
||||
multiple OS instances do not place conflicting files on the shared ESP and Extended Boot Loader
|
||||
Partitions, or that multiple OS instances are not possible.</para></listitem>
|
||||
<para>If set to <option>auto</option> (the default), the <filename>/etc/kernel/entry-token</filename>
|
||||
file will be read if it exists, and the stored value used. Otherwise if the local machine ID is
|
||||
initialized it is used. Otherwise <varname>IMAGE_ID=</varname> from <filename>os-release</filename>
|
||||
will be used, if set. Otherwise, <varname>ID=</varname> from <filename>os-release</filename> will be
|
||||
used, if set.</para>
|
||||
|
||||
<para>Unless set to <literal>machine-id</literal>, or when
|
||||
<option>--make-entry-directory=yes</option> is used the selected token string is written to a file
|
||||
<filename>/etc/kernel/entry-token</filename>, to ensure it will be used for future entries. This file
|
||||
is also read by
|
||||
<citerefentry><refentrytitle>kernel-install</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
|
||||
in order to identify under which name to generate boot loader entries for newly installed kernels, or
|
||||
to determine the entry names for removing old ones.</para>
|
||||
|
||||
<para>Using the machine ID for naming the entries is generally preferable, however there are cases
|
||||
where using the other identifiers is a good option. Specifically: if the identification data that the
|
||||
machine ID entails shall not be stored on the (unencrypted) <varname>$BOOT</varname> partition, or if
|
||||
the ID shall be generated on first boot and is not known when the entries are prepared. Note that
|
||||
using the machine ID has the benefit that multiple parallel installations of the same OS can coexist
|
||||
on the same medium, and they can update their boot loader entries independently. When using another
|
||||
identifier (such as the OS ID or the OS image ID), parallel installations of the same OS would try to
|
||||
use the same entry name. To support parallel installations, the installer must use a different entry
|
||||
token when adding a second installation.</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
<xi:include href="standard-options.xml" xpointer="no-pager"/>
|
||||
<xi:include href="standard-options.xml" xpointer="json" />
|
||||
<xi:include href="standard-options.xml" xpointer="help"/>
|
||||
<xi:include href="standard-options.xml" xpointer="version"/>
|
||||
</variablelist>
|
||||
|
@ -106,21 +106,21 @@
|
||||
| swap.target | | v v |
|
||||
| | v | remote-cryptsetup.target |
|
||||
| | (various low-level (various mounts and | remote-veritysetup.target |
|
||||
| | services: udevd, fsck services...) | | remote-fs.target
|
||||
| | tmpfiles, random | | | /
|
||||
| | seed, sysctl, ...) v | | /
|
||||
| | | local-fs.target | | /
|
||||
| | | | | | /
|
||||
\____|______|_______________ ______|___________/ | /
|
||||
\ / | /
|
||||
v | /
|
||||
sysinit.target | /
|
||||
| | /
|
||||
______________________/|\_____________________ | /
|
||||
/ | | | \ | /
|
||||
| | | | | | /
|
||||
v v | v | | /
|
||||
(various (various | (various | |/
|
||||
| | services: udevd, fsck services...) | | |
|
||||
| | tmpfiles, random | | | remote-fs.target
|
||||
| | seed, sysctl, ...) v | | |
|
||||
| | | local-fs.target | | _____________/
|
||||
| | | | | |/
|
||||
\____|______|_______________ ______|___________/ |
|
||||
\ / |
|
||||
v |
|
||||
sysinit.target |
|
||||
| |
|
||||
______________________/|\_____________________ |
|
||||
/ | | | \ |
|
||||
| | | | | |
|
||||
v v | v | |
|
||||
(various (various | (various | |
|
||||
timers...) paths...) | sockets...) | |
|
||||
| | | | | |
|
||||
v v | v | |
|
||||
|
@ -78,10 +78,10 @@
|
||||
<term><command>capture</command> <arg choice="opt" rep="repeat"><replaceable>SERVICE</replaceable></arg></term>
|
||||
|
||||
<listitem><para>Similar to <command>monitor</command> but
|
||||
writes the output in pcap format (for details, see the <ulink
|
||||
url="https://wiki.wireshark.org/Development/LibpcapFileFormat">Libpcap
|
||||
File Format</ulink> description). Make sure to redirect
|
||||
standard output to a file. Tools like
|
||||
writes the output in pcapng format (for details, see
|
||||
<ulink url="https://github.com/pcapng/pcapng/">
|
||||
PCAP Next Generation (pcapng) Capture File Format</ulink>).
|
||||
Make sure to redirect standard output to a file or pipe. Tools like
|
||||
<citerefentry project='die-net'><refentrytitle>wireshark</refentrytitle><manvolnum>1</manvolnum></citerefentry>
|
||||
may be used to dissect and view the resulting
|
||||
files.</para></listitem>
|
||||
|
@ -90,7 +90,10 @@
|
||||
<citerefentry project='man-pages'><refentrytitle>less</refentrytitle><manvolnum>1</manvolnum></citerefentry> and
|
||||
<citerefentry project='man-pages'><refentrytitle>more</refentrytitle><manvolnum>1</manvolnum></citerefentry>, until one is found. If
|
||||
no pager implementation is discovered no pager is invoked. Setting this environment variable to an empty string
|
||||
or the value <literal>cat</literal> is equivalent to passing <option>--no-pager</option>.</para></listitem>
|
||||
or the value <literal>cat</literal> is equivalent to passing <option>--no-pager</option>.</para>
|
||||
|
||||
<para>Note: if <varname>$SYSTEMD_PAGERSECURE</varname> is not set, <varname>$SYSTEMD_PAGER</varname>
|
||||
(as well as <varname>$PAGER</varname>) will be silently ignored.</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry id='less'>
|
||||
|
@ -85,7 +85,8 @@
|
||||
|
||||
<listitem><para>The maximum size in bytes of a core which will be processed. Core dumps exceeding
|
||||
this size may be stored, but the backtrace will not be generated. Like other sizes in this same
|
||||
config file, the usual suffixes to the base of 1024 are allowed (B, K, M, G, T, P, and E).</para>
|
||||
config file, the usual suffixes to the base of 1024 are allowed (B, K, M, G, T, P, and E). Defaults
|
||||
to 1G on 32bit systems, 32G on 64bit systems.</para>
|
||||
|
||||
<para>Setting <varname>Storage=none</varname> and <varname>ProcessSizeMax=0</varname>
|
||||
disables all coredump handling except for a log entry.</para>
|
||||
@ -96,8 +97,9 @@
|
||||
<term><varname>ExternalSizeMax=</varname></term>
|
||||
<term><varname>JournalSizeMax=</varname></term>
|
||||
|
||||
<listitem><para>The maximum (compressed or uncompressed) size in bytes of a core to be saved. Unit
|
||||
suffixes are allowed just as in <option>ProcessSizeMax=</option>.</para></listitem>
|
||||
<listitem><para>The maximum (compressed or uncompressed) size in bytes of a core to be saved in
|
||||
separate files on disk (default: 1G on 32bit, 32G on 64bit systems) or in the journal (default:
|
||||
10M). Unit suffixes are allowed just as in <option>ProcessSizeMax=</option>.</para></listitem>
|
||||
|
||||
<para><varname>ExternalSizeMax=infinity</varname> sets the core size to unlimited.</para>
|
||||
</varlistentry>
|
||||
|
@ -677,6 +677,14 @@
|
||||
of the current PCR state.</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><option>tpm2-pin=</option></term>
|
||||
|
||||
<listitem><para>Takes a boolean argument, defaults to <literal>false</literal>. Controls whether
|
||||
TPM2 volume unlocking is bound to a PIN in addition to PCRs. Similarly, this option is only useful
|
||||
when TPM2 enrollment metadata is not available.</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><option>token-timeout=</option></term>
|
||||
|
||||
|
42
man/event-quick-child.c
Normal file
42
man/event-quick-child.c
Normal file
@ -0,0 +1,42 @@
|
||||
/* SPDX-License-Identifier: CC0-1.0 */
|
||||
|
||||
#include <assert.h>
|
||||
#include <stdio.h>
|
||||
#include <unistd.h>
|
||||
#include <sd-event.h>
|
||||
|
||||
int main(int argc, char **argv) {
|
||||
pid_t pid = fork();
|
||||
assert(pid >= 0);
|
||||
|
||||
/* SIGCHLD signal must be blocked for sd_event_add_child to work */
|
||||
sigset_t ss;
|
||||
sigemptyset(&ss);
|
||||
sigaddset(&ss, SIGCHLD);
|
||||
sigprocmask(SIG_BLOCK, &ss, NULL);
|
||||
|
||||
if (pid == 0) /* child */
|
||||
sleep(1);
|
||||
|
||||
else { /* parent */
|
||||
sd_event *e = NULL;
|
||||
int r;
|
||||
|
||||
/* Create the default event loop */
|
||||
sd_event_default(&e);
|
||||
assert(e);
|
||||
|
||||
/* We create a floating child event source (attached to 'e').
|
||||
* The default handler will be called with 666 as userdata, which
|
||||
* will become the exit value of the loop. */
|
||||
r = sd_event_add_child(e, NULL, pid, WEXITED, NULL, (void*) 666);
|
||||
assert(r >= 0);
|
||||
|
||||
r = sd_event_loop(e);
|
||||
assert(r == 666);
|
||||
|
||||
sd_event_unref(e);
|
||||
}
|
||||
|
||||
return 0;
|
||||
}
|
@ -84,13 +84,8 @@
|
||||
<term><option>-f</option></term>
|
||||
<term><option>--force</option></term>
|
||||
|
||||
<listitem><para>Force immediate halt, power-off, or reboot. When
|
||||
specified once, this results in an immediate but clean shutdown
|
||||
by the system manager. When specified twice, this results in an
|
||||
immediate shutdown without contacting the system manager. See the
|
||||
description of <option>--force</option> in
|
||||
<citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
|
||||
for more details.</para></listitem>
|
||||
<listitem><para>Force immediate halt, power-off, reboot. Do
|
||||
not contact the init system.</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
|
@ -428,6 +428,28 @@
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><varname>systemd.watchdog_pre_sec=</varname></term>
|
||||
|
||||
<listitem>
|
||||
<para>Overrides the watchdog pre-timeout settings otherwise configured with
|
||||
<varname>RuntimeWatchdogPreSec=</varname>. Takes a time value (if no unit is specified, seconds is the
|
||||
implicitly assumed time unit) or the special strings <literal>off</literal> or
|
||||
<literal>default</literal>. For details, see
|
||||
<citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><varname>systemd.watchdog_pretimeout_governor=</varname></term>
|
||||
|
||||
<listitem>
|
||||
<para>Overrides the watchdog pre-timeout settings otherwise configured with
|
||||
<varname>RuntimeWatchdogPreGovernor=</varname>. Takes a string value. For details, see
|
||||
<citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><varname>systemd.cpu_affinity=</varname></term>
|
||||
|
||||
|
@ -39,21 +39,21 @@
|
||||
<filename>/boot/</filename>, <filename>/efi/</filename>, or <filename>/boot/efi/</filename>, see below.
|
||||
</para>
|
||||
|
||||
<para><command>kernel-install</command> will execute the files
|
||||
located in the directory <filename>/usr/lib/kernel/install.d/</filename>
|
||||
and the local administration directory <filename>/etc/kernel/install.d/</filename>.
|
||||
All files are collectively sorted and executed in lexical order, regardless of the directory in
|
||||
which they live. However, files with identical filenames replace each other.
|
||||
Files in <filename>/etc/kernel/install.d/</filename> take precedence over files with the same name
|
||||
in <filename>/usr/lib/kernel/install.d/</filename>. This can be used to override a system-supplied
|
||||
executables with a local file if needed; a symbolic link in <filename>/etc/kernel/install.d/</filename>
|
||||
with the same name as an executable in <filename>/usr/lib/kernel/install.d/</filename>,
|
||||
pointing to <filename>/dev/null</filename>, disables the executable entirely. Executables must have the
|
||||
extension <literal>.install</literal>; other extensions are ignored.</para>
|
||||
<para><command>kernel-install</command> will run the executable files ("plugins") located in the
|
||||
directory <filename>/usr/lib/kernel/install.d/</filename> and the local administration directory
|
||||
<filename>/etc/kernel/install.d/</filename>. All files are collectively sorted and executed in lexical
|
||||
order, regardless of the directory in which they live. However, files with identical filenames replace
|
||||
each other. Files in <filename>/etc/kernel/install.d/</filename> take precedence over files with the
|
||||
same name in <filename>/usr/lib/kernel/install.d/</filename>. This can be used to override a
|
||||
system-supplied executables with a local file if needed; a symbolic link in
|
||||
<filename>/etc/kernel/install.d/</filename> with the same name as an executable in
|
||||
<filename>/usr/lib/kernel/install.d/</filename>, pointing to <filename>/dev/null</filename>, disables the
|
||||
executable entirely. Executables must have the extension <literal>.install</literal>; other extensions
|
||||
are ignored.</para>
|
||||
|
||||
<para>An executable should return <constant>0</constant> on success. It may also
|
||||
return <constant>77</constant> to cause the whole operation to terminate
|
||||
(executables later in lexical order will be skipped).</para>
|
||||
<para>An executable placed in these directories should return <constant>0</constant> on success. It may
|
||||
also return <constant>77</constant> to cause the whole operation to terminate (executables later in
|
||||
lexical order will be skipped).</para>
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
@ -64,37 +64,45 @@
|
||||
<term><command>add <replaceable>KERNEL-VERSION</replaceable> <replaceable>KERNEL-IMAGE</replaceable> [<replaceable>INITRD-FILE</replaceable> ...]</command></term>
|
||||
<listitem>
|
||||
<para>This command expects a kernel version string and a path to a kernel image file as
|
||||
arguments. <command>kernel-install</command> calls the executables from
|
||||
<filename>/usr/lib/kernel/install.d/*.install</filename> and
|
||||
<filename>/etc/kernel/install.d/*.install</filename> with the following arguments:
|
||||
arguments. Optionally, one or more initial RAM disk images may be specified as well (note that
|
||||
plugins might generate additional ones). <command>kernel-install</command> calls the executable
|
||||
files from <filename>/usr/lib/kernel/install.d/*.install</filename> and
|
||||
<filename>/etc/kernel/install.d/*.install</filename> (i.e. the plugins) with the following
|
||||
arguments:</para>
|
||||
|
||||
<programlisting>add <replaceable>KERNEL-VERSION</replaceable> <filename>$BOOT/<replaceable>MACHINE-ID</replaceable>/<replaceable>KERNEL-VERSION</replaceable>/</filename> <replaceable>KERNEL-IMAGE</replaceable> [<replaceable>INITRD-FILE</replaceable> ...]</programlisting>
|
||||
</para>
|
||||
<programlisting>add <replaceable>KERNEL-VERSION</replaceable> <filename>$BOOT/<replaceable>ENTRY-TOKEN</replaceable>/<replaceable>KERNEL-VERSION</replaceable>/</filename> <replaceable>KERNEL-IMAGE</replaceable> [<replaceable>INITRD-FILE</replaceable> ...]</programlisting>
|
||||
|
||||
<para>The third argument directly refers to the path where to place kernel images, initial RAM disk
|
||||
images and other resources for <ulink url="https://systemd.io/BOOT_LOADER_SPECIFICATION">Boot
|
||||
Loader Specification</ulink> Type #1 entries (the "entry directory"). If other boot loader schemes
|
||||
are used the parameter may be ignored. The <replaceable>ENTRY-TOKEN</replaceable> string is
|
||||
typically the machine ID and is supposed to identify the local installation on the system. For
|
||||
details see below.</para>
|
||||
|
||||
<para>Two default plugins execute the following operations in this case:</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem><para><command>kernel-install</command> creates
|
||||
<filename>$BOOT/<replaceable>MACHINE-ID</replaceable>/<replaceable>KERNEL-VERSION</replaceable></filename>,
|
||||
if enabled (see <varname>$KERNEL_INSTALL_LAYOUT=</varname>).</para></listitem>
|
||||
<filename>$BOOT/<replaceable>ENTRY-TOKEN</replaceable>/<replaceable>KERNEL-VERSION</replaceable></filename>,
|
||||
if enabled (see <varname>$KERNEL_INSTALL_LAYOUT</varname>).</para></listitem>
|
||||
|
||||
<listitem><para><filename>50-depmod.install</filename> runs
|
||||
<citerefentry project='man-pages'><refentrytitle>depmod</refentrytitle><manvolnum>8</manvolnum></citerefentry> for the
|
||||
<replaceable>KERNEL-VERSION</replaceable>.</para></listitem>
|
||||
|
||||
<listitem><para><filename>90-loaderentry.install</filename>
|
||||
copies <replaceable>KERNEL-IMAGE</replaceable> to
|
||||
<filename>$BOOT/<replaceable>MACHINE-ID</replaceable>/<replaceable>KERNEL-VERSION</replaceable>/linux</filename>.
|
||||
<listitem><para><filename>90-loaderentry.install</filename> copies
|
||||
<replaceable>KERNEL-IMAGE</replaceable> to
|
||||
<filename>$BOOT/<replaceable>ENTRY-TOKEN</replaceable>/<replaceable>KERNEL-VERSION</replaceable>/linux</filename>.
|
||||
If <replaceable>INITRD-FILE</replaceable>s are provided, it also copies them to
|
||||
<filename>$BOOT/<replaceable>MACHINE-ID</replaceable>/<replaceable>KERNEL_VERSION</replaceable>/<replaceable>INITRD-FILE</replaceable></filename>.
|
||||
<filename>$BOOT/<replaceable>ENTRY-TOKEN</replaceable>/<replaceable>KERNEL_VERSION</replaceable>/<replaceable>INITRD-FILE</replaceable></filename>.
|
||||
It also creates a boot loader entry according to the <ulink
|
||||
url="https://systemd.io/BOOT_LOADER_SPECIFICATION">Boot Loader Specification</ulink> in
|
||||
<filename>$BOOT/loader/entries/<replaceable>MACHINE-ID</replaceable>-<replaceable>KERNEL-VERSION</replaceable>.conf</filename>.
|
||||
url="https://systemd.io/BOOT_LOADER_SPECIFICATION">Boot Loader Specification</ulink> (Type #1) in
|
||||
<filename>$BOOT/loader/entries/<replaceable>ENTRY-TOKEN</replaceable>-<replaceable>KERNEL-VERSION</replaceable>.conf</filename>.
|
||||
The title of the entry is the <replaceable>PRETTY_NAME</replaceable> parameter specified in
|
||||
<filename>/etc/os-release</filename> or <filename>/usr/lib/os-release</filename> (if the former is
|
||||
missing), or "Linux <replaceable>KERNEL-VERSION</replaceable>", if unset.</para>
|
||||
<filename>/etc/os-release</filename> or <filename>/usr/lib/os-release</filename> (if the former
|
||||
is missing), or "Linux <replaceable>KERNEL-VERSION</replaceable>", if unset.</para>
|
||||
|
||||
<para>If <varname>$KERNEL_INSTALL_LAYOUT=</varname> is not "bls", this plugin does nothing.</para></listitem>
|
||||
<para>If <varname>$KERNEL_INSTALL_LAYOUT</varname> is not "bls", this plugin does nothing.</para></listitem>
|
||||
</itemizedlist>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -104,13 +112,13 @@
|
||||
<para>This command expects a kernel version string as single argument. This calls executables from
|
||||
<filename>/usr/lib/kernel/install.d/*.install</filename> and
|
||||
<filename>/etc/kernel/install.d/*.install</filename> with the following arguments:
|
||||
|
||||
<programlisting>remove <replaceable>KERNEL-VERSION</replaceable> <filename>$BOOT/<replaceable>MACHINE-ID</replaceable>/<replaceable>KERNEL-VERSION</replaceable>/</filename></programlisting>
|
||||
</para>
|
||||
|
||||
<para>Afterwards, <command>kernel-install</command> removes the directory
|
||||
<filename>$BOOT/<replaceable>MACHINE-ID</replaceable>/<replaceable>KERNEL-VERSION</replaceable>/</filename>
|
||||
and its contents.</para>
|
||||
<programlisting>remove <replaceable>KERNEL-VERSION</replaceable> <filename>$BOOT/<replaceable>ENTRY-TOKEN</replaceable>/<replaceable>KERNEL-VERSION</replaceable>/</filename></programlisting>
|
||||
|
||||
<para>Afterwards, <command>kernel-install</command> removes the entry directory
|
||||
<filename>$BOOT/<replaceable>ENTRY-TOKEN</replaceable>/<replaceable>KERNEL-VERSION</replaceable>/</filename>
|
||||
and its contents, if it exists.</para>
|
||||
|
||||
<para>Two default plugins execute the following operations in this case:</para>
|
||||
|
||||
@ -118,14 +126,18 @@
|
||||
<listitem><para><filename>50-depmod.install</filename> removes the files generated by <command>depmod</command> for this kernel again.</para></listitem>
|
||||
|
||||
<listitem><para><filename>90-loaderentry.install</filename> removes the file
|
||||
<filename>$BOOT/loader/entries/<replaceable>MACHINE-ID</replaceable>-<replaceable>KERNEL-VERSION</replaceable>.conf</filename>.</para></listitem>
|
||||
|
||||
<listitem><para><command>kernel-install</command> removes
|
||||
<filename>$BOOT/<replaceable>MACHINE-ID</replaceable>/<replaceable>KERNEL-VERSION</replaceable></filename>,
|
||||
if enabled (see <varname>$KERNEL_INSTALL_LAYOUT=</varname>).</para></listitem>
|
||||
<filename>$BOOT/loader/entries/<replaceable>ENTRY-TOKEN</replaceable>-<replaceable>KERNEL-VERSION</replaceable>.conf</filename>.</para></listitem>
|
||||
</itemizedlist>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><command>inspect</command></term>
|
||||
<listitem>
|
||||
<para>Shows the various paths and parameters configured or auto-detected. In particular shows the
|
||||
values of the various <varname>$KERNEL_INSTALL_*</varname> environment variables listed
|
||||
below.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
</variablelist>
|
||||
</refsect1>
|
||||
@ -135,9 +147,9 @@
|
||||
<para>The partition where the kernels and <ulink url="https://systemd.io/BOOT_LOADER_SPECIFICATION">Boot
|
||||
Loader Specification</ulink> snippets are located is called <varname>$BOOT</varname>.
|
||||
<command>kernel-install</command> determines the location of this partition by checking
|
||||
<filename>/efi/</filename>, <filename>/boot/</filename>, and <filename>/boot/efi/</filename>
|
||||
in turn. The first location where <filename>$BOOT/loader/entries/</filename> or
|
||||
<filename>$BOOT/$MACHINE_ID/</filename> exists is used.</para>
|
||||
<filename>/efi/</filename>, <filename>/boot/</filename>, and <filename>/boot/efi/</filename> in turn. The
|
||||
first location where <filename>$BOOT/loader/entries/</filename> or
|
||||
<filename>$BOOT/<replaceable>ENTRY-TOKEN</replaceable>/</filename> exists is used.</para>
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
@ -163,28 +175,57 @@
|
||||
<para>If <option>--verbose</option> is used, <varname>$KERNEL_INSTALL_VERBOSE=1</varname> will be set for
|
||||
the plugins. They may output additional logs in this case.</para>
|
||||
|
||||
<para>If <varname>MACHINE_ID=</varname> is set and not empty, it will be used as <replaceable>MACHINE-ID</replaceable>,
|
||||
overriding any automatic detection attempts. The value must be a valid machine ID (32 hexadecimal characters).</para>
|
||||
<para>If <varname>$MACHINE_ID</varname> is set and not empty when <command>kernel-install</command> is
|
||||
invoked, it will be used as <replaceable>MACHINE-ID</replaceable>, overriding any automatic detection
|
||||
attempts. The value must be a valid machine ID (32 hexadecimal characters).</para>
|
||||
|
||||
<para><varname>KERNEL_INSTALL_MACHINE_ID=</varname> is set for the plugins to the desired <replaceable>MACHINE-ID</replaceable> –
|
||||
either 32 hexadecimal characters or the special value <literal>Default</literal>.</para>
|
||||
<para><varname>KERNEL_INSTALL_BOOT_ROOT=</varname> is set for the plugins to the root directory (mount point, usually) of the hierarchy
|
||||
where boot-loader entries, kernel images, and associated resources should be placed. Can be overridden by setting <varname>BOOT_ROOT=</varname>.</para>
|
||||
<para><varname>$KERNEL_INSTALL_MACHINE_ID</varname> is set for the plugins to the desired
|
||||
<replaceable>MACHINE-ID</replaceable> to use. It's always a 128bit ID, and typically the ID from
|
||||
<filename>/etc/machine-id</filename> or the one passed in via <varname>$MACHINE_ID</varname>. (If no
|
||||
machine ID was specified via these methods it might be generated randomly by
|
||||
<command>kernel-install</command>, in which case it only applies to this invocation.)</para>
|
||||
|
||||
<para><varname>KERNEL_INSTALL_LAYOUT=bls|other|...</varname> specifies the installation layout.
|
||||
Defaults to <option>bls</option> if <filename>$BOOT/<replaceable>MACHINE-ID</replaceable></filename> exists, or <option>other</option> otherwise.
|
||||
Additional layout names may be defined by convention. If a plugin uses a special layout,
|
||||
it's encouraged to declare its own layout name and configure <varname>layout=</varname> in <filename>install.conf</filename> upon initial installation.</para>
|
||||
<para><varname>$KERNEL_INSTALL_ENTRY_TOKEN</varname> is set for the plugins to the desired entry "token"
|
||||
to use. It's an identifier that shall be used to identify the local installation, and is often the
|
||||
machine ID, i.e. same as <varname>$KERNEL_INSTALL_MACHINE_ID</varname>, but might also be a different
|
||||
type of identifier, for example a fixed string or the <varname>ID=</varname>,
|
||||
<varname>IMAGE_ID=</varname> values from <filename>/etc/os-release</filename>. The string passed here
|
||||
will be used to name Boot Loader Specification entries, or the directories the kernel image and initial
|
||||
RAM disk images are placed into. Note that while oftentimes
|
||||
<varname>$KERNEL_INSTALL_ENTRY_TOKEN</varname> and <varname>$KERNEL_INSTALL_MACHINE_ID</varname> are set
|
||||
to the same value, the latter is guaranteed to be a valid 32 character ID in lowercase hexadecimals while
|
||||
the former can be any short string. The entry token to use is read from
|
||||
<filename>/etc/kernel/entry-token</filename>, if it exists. Otherwise a few possible candidates below the
|
||||
<varname>$BOOT</varname> are searched for Boot Loader Specification Type 1 entry directories, and if
|
||||
found the entry token is derived from that. If that is not successful the machine ID is used as
|
||||
fallback.</para>
|
||||
|
||||
<para><varname>$KERNEL_INSTALL_BOOT_ROOT</varname> is set for the plugins to the absolute path of the
|
||||
root directory (mount point, usually) of the hierarchy where boot loader entries, kernel images, and
|
||||
associated resources should be placed. This usually is the path where the XBOOTLDR partition or the ESP
|
||||
(EFI System Partition) are mounted, and also conceptually referred to as <varname>$BOOT</varname>. Can be
|
||||
overridden by setting <varname>$BOOT_ROOT</varname>.</para>
|
||||
|
||||
<para><varname>$KERNEL_INSTALL_LAYOUT=bls|other|...</varname> is set for the plugins to specify the
|
||||
installation layout. Defaults to <option>bls</option> if
|
||||
<filename>$BOOT/<replaceable>ENTRY-TOKEN</replaceable></filename> exists, or <option>other</option>
|
||||
otherwise. Additional layout names may be defined by convention. If a plugin uses a special layout, it's
|
||||
encouraged to declare its own layout name and configure <varname>layout=</varname> in
|
||||
<filename>install.conf</filename> upon initial installation. The following values are currently
|
||||
understood:</para>
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term>bls</term>
|
||||
<listitem>
|
||||
<para>Standard <ulink url="https://systemd.io/BOOT_LOADER_SPECIFICATION">Boot Loader Specification</ulink> layout,
|
||||
compatible with <citerefentry><refentrytitle>systemd-boot</refentrytitle><manvolnum>7</manvolnum></citerefentry>: entries in
|
||||
<filename>$BOOT/loader/entries/<replaceable>MACHINE-ID</replaceable>-<replaceable>KERNEL-VERSION</replaceable>[+<replaceable>TRIES</replaceable>].conf</filename>,
|
||||
kernel and initrds under <filename>$BOOT/<replaceable>MACHINE-ID</replaceable>/<replaceable>KERNEL-VERSION</replaceable>/</filename></para>
|
||||
<para>Provided by <filename>90-loaderentry.install</filename>.</para>
|
||||
<para>Standard <ulink url="https://systemd.io/BOOT_LOADER_SPECIFICATION">Boot Loader
|
||||
Specification</ulink> Type #1 layout, compatible with
|
||||
<citerefentry><refentrytitle>systemd-boot</refentrytitle><manvolnum>7</manvolnum></citerefentry>:
|
||||
entries in
|
||||
<filename>$BOOT/loader/entries/<replaceable>ENTRY-TOKEN</replaceable>-<replaceable>KERNEL-VERSION</replaceable>[+<replaceable>TRIES</replaceable>].conf</filename>,
|
||||
kernel and initrds under
|
||||
<filename>$BOOT/<replaceable>ENTRY-TOKEN</replaceable>/<replaceable>KERNEL-VERSION</replaceable>/</filename></para>
|
||||
<para>Implemented by <filename>90-loaderentry.install</filename>.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
@ -194,6 +235,14 @@
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
|
||||
<para><varname>$KERNEL_INSTALL_INITRD_GENERATOR</varname> is set for plugins to select the initrd
|
||||
generator. This may be configured as <varname>initrd_generator=</varname> in
|
||||
<filename>install.conf</filename>. See below.</para>
|
||||
|
||||
<para><varname>$KERNEL_INSTALL_STAGING_AREA</varname> is set for plugins to a path to a directory.
|
||||
Plugins may drop files in that directory, and they will be installed as part of the loader entry, based
|
||||
on the file name and extension.</para>
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
@ -241,25 +290,21 @@
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>
|
||||
<filename>/etc/machine-id</filename>
|
||||
<filename>/etc/kernel/entry-token</filename>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>The content of this file specifies the machine identification
|
||||
<replaceable>MACHINE-ID</replaceable>. If <filename>/etc/machine-id</filename>
|
||||
cannot be read or is temporary (backed by a file on <constant>tmpfs</constant>),
|
||||
<command>kernel-install</command> will use <literal>Default</literal> instead.</para>
|
||||
<para>If this file exists it is read and used as "entry token" for this system, i.e. is used for
|
||||
naming Boot Loader Specification entries, see
|
||||
<varname>$KERNEL_INSTALL_ENTRY_TOKEN</varname> above for details.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>
|
||||
<filename>/etc/machine-info</filename>
|
||||
<filename>/etc/machine-id</filename>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>If this file contains the <varname>KERNEL_INSTALL_MACHINE_ID</varname> variable,
|
||||
<command>kernel-install</command> will use it as <replaceable>MACHINE-ID</replaceable> instead of
|
||||
the contents of <filename>/etc/machine-id</filename>. If the variable is not found in
|
||||
<filename>/etc/machine-info</filename>, <command>kernel-install</command> will try to save the
|
||||
machine ID it uses to install to <varname>$BOOT</varname> to this file.</para>
|
||||
<para>The content of this file specifies the machine identification
|
||||
<replaceable>MACHINE-ID</replaceable>.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
@ -267,9 +312,9 @@
|
||||
<filename>/etc/os-release</filename>
|
||||
<filename>/usr/lib/os-release</filename>
|
||||
</term>
|
||||
<listitem>
|
||||
<listitem>
|
||||
<para>Read by <filename>90-loaderentry.install</filename>.
|
||||
If available, <varname>PRETTY_NAME</varname> is read from these files and used as the title of the boot menu entry.
|
||||
If available, <varname>PRETTY_NAME=</varname> is read from these files and used as the title of the boot menu entry.
|
||||
Otherwise, <literal>Linux <replaceable>KERNEL-VERSION</replaceable></literal> will be used.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -279,10 +324,10 @@
|
||||
<filename>/etc/kernel/install.conf</filename>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>Configuration options for <command>kernel-install</command>,
|
||||
as a series of <varname>KEY=</varname><replaceable>VALUE</replaceable> assignments,
|
||||
compatible with shell syntax.
|
||||
See the Environment variables section for supported keys.</para>
|
||||
<para>Configuration options for <command>kernel-install</command>, as a series of
|
||||
<varname>KEY=</varname><replaceable>VALUE</replaceable> assignments, compatible with shell
|
||||
syntax. This currently supports two keys: <varname>layout=</varname> and
|
||||
<varname>initrd_generator=</varname>, for details see the Environment variables section above.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
|
@ -23,6 +23,7 @@
|
||||
<refsynopsisdiv>
|
||||
<para><filename><replaceable>ESP</replaceable>/loader/loader.conf</filename>,
|
||||
<filename><replaceable>ESP</replaceable>/loader/entries/*.conf</filename>
|
||||
<filename><replaceable>XBOOTLDR</replaceable>/loader/entries/*.conf</filename>
|
||||
</para>
|
||||
</refsynopsisdiv>
|
||||
|
||||
@ -30,15 +31,19 @@
|
||||
<title>Description</title>
|
||||
|
||||
<para>
|
||||
<citerefentry><refentrytitle>systemd-boot</refentrytitle><manvolnum>7</manvolnum></citerefentry>
|
||||
will read <filename><replaceable>ESP</replaceable>/loader/loader.conf</filename> and any files with the
|
||||
<citerefentry><refentrytitle>systemd-boot</refentrytitle><manvolnum>7</manvolnum></citerefentry> will
|
||||
read <filename><replaceable>ESP</replaceable>/loader/loader.conf</filename>, and any files with the
|
||||
<literal>.conf</literal> extension under
|
||||
<filename><replaceable>ESP</replaceable>/loader/entries/</filename> on the EFI system partition (ESP).
|
||||
<filename><replaceable>ESP</replaceable>/loader/entries/</filename> on the EFI system partition (ESP),
|
||||
and <filename><replaceable>XBOOTLDR</replaceable>/loader/entries/</filename> on the extended boot loader
|
||||
partition (XBOOTLDR) as defined by <ulink url="https://systemd.io/BOOT_LOADER_SPECIFICATION">Boot Loader
|
||||
Specification</ulink>.
|
||||
</para>
|
||||
|
||||
<para>Each configuration file must consist of an option name, followed by
|
||||
whitespace, and the option value. <literal>#</literal> may be used to start
|
||||
a comment line. Empty and comment lines are ignored.</para>
|
||||
<para>Each of these configuration files must consist of series of newline (i.e. ASCII code 10) separated
|
||||
lines, each consisting of an option name, followed by whitespace, and the option
|
||||
value. <literal>#</literal> may be used to start a comment line. Empty and comment lines are ignored. The
|
||||
files use UTF-8 encoding.</para>
|
||||
|
||||
<para>Boolean arguments may be written as
|
||||
<literal>yes</literal>/<literal>y</literal>/<literal>true</literal>/<literal>t</literal>/<literal>on</literal>/<literal>1</literal> or
|
||||
@ -49,7 +54,14 @@
|
||||
<refsect1>
|
||||
<title>Options</title>
|
||||
|
||||
<para>The following configuration options in <filename>loader.conf</filename> are understood:</para>
|
||||
<para>The configuration options supported by
|
||||
<filename><replaceable>ESP</replaceable>/loader/entries/*.conf</filename> and
|
||||
<filename><replaceable>XBOOTLDR</replaceable>/loader/entries/*.conf</filename> files are defined as part
|
||||
of the <ulink url="https://systemd.io/BOOT_LOADER_SPECIFICATION">Boot Loader
|
||||
Specification</ulink>.</para>
|
||||
|
||||
<para>The following configuration are supported by the <filename>loader.conf</filename> configuration
|
||||
file:</para>
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
@ -196,6 +208,38 @@
|
||||
by using the <keycap>f</keycap> key.</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>beep</term>
|
||||
|
||||
<listitem><para>Beep n times when the n-th entry in the boot menu is shown (default disabled).
|
||||
Currently, only x86 is supported, where it uses the PC speaker.</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>reboot-for-bitlocker</term>
|
||||
|
||||
<listitem><para>Caveat: This feature is experimental, and is likely to be changed (or removed in its
|
||||
current form) in a future version of systemd.</para>
|
||||
|
||||
<para>Work around BitLocker requiring a recovery key when the boot loader was
|
||||
updated (disabled by default).</para>
|
||||
|
||||
<para>Try to detect BitLocker encrypted drives along with an active TPM. If both are found
|
||||
and Windows Boot Manager is selected in the boot menu, set the <literal>BootNext</literal>
|
||||
EFI variable and restart the system. The firmware will then start Windows Boot Manager
|
||||
directly, leaving the TPM PCRs in expected states so that Windows can unseal the encryption
|
||||
key. This allows systemd-boot to be updated without having to provide the recovery key for
|
||||
BitLocker drive unlocking.</para>
|
||||
|
||||
<para>Note that the PCRs that Windows uses can be configured with the
|
||||
<literal>Configure TPM platform validation profile for native UEFI firmware configurations</literal>
|
||||
group policy under <literal>Computer Configuration\Administrative Templates\Windows Components\BitLocker Drive Encryption</literal>.
|
||||
When secure boot is enabled, changing this to PCRs <literal>0,2,7,11</literal> should be safe.
|
||||
The TPM key protector needs to be removed and then added back for the PCRs on an already
|
||||
encrypted drive to change. If PCR 4 is not measured, this setting can be disabled to speed
|
||||
up booting into Windows.</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>random-seed-mode</term>
|
||||
|
||||
|
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue
Block a user