system-pstore do not move dumps to /var/lib/systemd/pstore/ #18540
Labels
Comments
agraf
pushed a commit
to agraf/systemd
that referenced
this issue
Jun 9, 2022
The systemd-pstore service takes pstore files on boot and transfers them to disk. It only does it once on boot and only if it finds any. The typical location of the pstore on modern systems is the UEFI variable store. Most distributions ship with CONFIG_EFI_VARS_PSTORE=m. That means, the UEFI variable store is only available on boot after the respective module is loaded. In most situations, the pstore service gets loaded before the UEFI pstore, so we don't get to transfer logs. Instead, they accumulate, filling up the pstore over time, potentially breaking the UEFI variable store. Let's add a dependency on the kernel module to ensure we only scan for pstate after we can actually see pstate. Because pstore may be implemented through a variety of different backends and pulling pstore data is not time critical, let's just defer the service start until all module loading has settled. Fixes systemd#18540
agraf
pushed a commit
to agraf/systemd
that referenced
this issue
Jun 10, 2022
The systemd-pstore service takes pstore files on boot and transfers them to disk. It only does it once on boot and only if it finds any. The typical location of the pstore on modern systems is the UEFI variable store. Most distributions ship with CONFIG_EFI_VARS_PSTORE=m. That means, the UEFI variable store is only available on boot after the respective module is loaded. In most situations, the pstore service gets loaded before the UEFI pstore, so we don't get to transfer logs. Instead, they accumulate, filling up the pstore over time, potentially breaking the UEFI variable store. Let's add a service dependency on any kernel module that can provide a pstore to ensure we only scan for pstate after we can actually see pstate. I have seen live occurences of systems breaking because we did not erase the pstates and ran out of UEFI nvram space. Fixes systemd#18540
yuwata
pushed a commit
that referenced
this issue
Jun 14, 2022
The systemd-pstore service takes pstore files on boot and transfers them to disk. It only does it once on boot and only if it finds any. The typical location of the pstore on modern systems is the UEFI variable store. Most distributions ship with CONFIG_EFI_VARS_PSTORE=m. That means, the UEFI variable store is only available on boot after the respective module is loaded. In most situations, the pstore service gets loaded before the UEFI pstore, so we don't get to transfer logs. Instead, they accumulate, filling up the pstore over time, potentially breaking the UEFI variable store. Let's add a service dependency on any kernel module that can provide a pstore to ensure we only scan for pstate after we can actually see pstate. I have seen live occurences of systems breaking because we did not erase the pstates and ran out of UEFI nvram space. Fixes #18540
fbuihuu
pushed a commit
to openSUSE/systemd
that referenced
this issue
Jul 19, 2022
The systemd-pstore service takes pstore files on boot and transfers them to disk. It only does it once on boot and only if it finds any. The typical location of the pstore on modern systems is the UEFI variable store. Most distributions ship with CONFIG_EFI_VARS_PSTORE=m. That means, the UEFI variable store is only available on boot after the respective module is loaded. In most situations, the pstore service gets loaded before the UEFI pstore, so we don't get to transfer logs. Instead, they accumulate, filling up the pstore over time, potentially breaking the UEFI variable store. Let's add a service dependency on any kernel module that can provide a pstore to ensure we only scan for pstate after we can actually see pstate. I have seen live occurences of systems breaking because we did not erase the pstates and ran out of UEFI nvram space. Fixes systemd/systemd#18540 (cherry picked from commit 70e74a5)
enr0n
added a commit
to enr0n/systemd
that referenced
this issue
Sep 7, 2022
Commit 70e74a5 ("pstore: Run after modules are loaded") added After= and Wants= entries for all known kernel modules providing a pstore. While adding these dependencies on systems where one of the modules is not present, or not configured, should not have a real affect on the system, it can produce annoying error messages in the kernel log, e.g. "mtd device must be supplied (device name is empty)" when the mtdpstore module is not configured correctly. Since dependencies cannot be removed with drop-ins, if a distro wants to remove some of these modules from systemd-pstore.service, they need to patch units/systemd-pstore.service.in. On the other hand, if they want to append to the dependencies this can be done by shipping a drop-in. Since the original intent of the previous commit was to fix [1], which only requires the efi_pstore module, remove all other kernel module dependencies from systemd-pstore.service, and let distros ship drop-ins to add dependencies if needed. [1] systemd#18540
enr0n
added a commit
to enr0n/systemd
that referenced
this issue
Sep 7, 2022
Commit 70e74a5 ("pstore: Run after modules are loaded") added After= and Wants= entries for all known kernel modules providing a pstore. While adding these dependencies on systems where one of the modules is not present, or not configured, should not have a real affect on the system, it can produce annoying error messages in the kernel log. E.g. "mtd device must be supplied (device name is empty)" when the mtdpstore module is not configured correctly. Since dependencies cannot be removed with drop-ins, if a distro wants to remove some of these modules from systemd-pstore.service, they need to patch units/systemd-pstore.service.in. On the other hand, if they want to append to the dependencies this can be done by shipping a drop-in. Since the original intent of the previous commit was to fix [1], which only requires the efi_pstore module, remove all other kernel module dependencies from systemd-pstore.service, and let distros ship drop-ins to add dependencies if needed. [1] systemd#18540
enr0n
added a commit
to enr0n/systemd
that referenced
this issue
Sep 13, 2022
Commit 70e74a5 ("pstore: Run after modules are loaded") added After= and Wants= entries for all known kernel modules providing a pstore. While adding these dependencies on systems where one of the modules is not present, or not configured, should not have a real affect on the system, it can produce annoying error messages in the kernel log. E.g. "mtd device must be supplied (device name is empty)" when the mtdpstore module is not configured correctly. Since dependencies cannot be removed with drop-ins, if a distro wants to remove some of these modules from systemd-pstore.service, they need to patch units/systemd-pstore.service.in. On the other hand, if they want to append to the dependencies this can be done by shipping a drop-in. Since the original intent of the previous commit was to fix [1], which only requires the efi_pstore module, remove all other kernel module dependencies from systemd-pstore.service, and let distros ship drop-ins to add dependencies if needed. [1] systemd#18540
yuwata
pushed a commit
that referenced
this issue
Sep 13, 2022
Commit 70e74a5 ("pstore: Run after modules are loaded") added After= and Wants= entries for all known kernel modules providing a pstore. While adding these dependencies on systems where one of the modules is not present, or not configured, should not have a real affect on the system, it can produce annoying error messages in the kernel log. E.g. "mtd device must be supplied (device name is empty)" when the mtdpstore module is not configured correctly. Since dependencies cannot be removed with drop-ins, if a distro wants to remove some of these modules from systemd-pstore.service, they need to patch units/systemd-pstore.service.in. On the other hand, if they want to append to the dependencies this can be done by shipping a drop-in. Since the original intent of the previous commit was to fix [1], which only requires the efi_pstore module, remove all other kernel module dependencies from systemd-pstore.service, and let distros ship drop-ins to add dependencies if needed. [1] #18540
fbuihuu
pushed a commit
to openSUSE/systemd
that referenced
this issue
Oct 21, 2022
Commit 70e74a5 ("pstore: Run after modules are loaded") added After= and Wants= entries for all known kernel modules providing a pstore. While adding these dependencies on systems where one of the modules is not present, or not configured, should not have a real affect on the system, it can produce annoying error messages in the kernel log. E.g. "mtd device must be supplied (device name is empty)" when the mtdpstore module is not configured correctly. Since dependencies cannot be removed with drop-ins, if a distro wants to remove some of these modules from systemd-pstore.service, they need to patch units/systemd-pstore.service.in. On the other hand, if they want to append to the dependencies this can be done by shipping a drop-in. Since the original intent of the previous commit was to fix [1], which only requires the efi_pstore module, remove all other kernel module dependencies from systemd-pstore.service, and let distros ship drop-ins to add dependencies if needed. [1] systemd/systemd#18540 (cherry picked from commit 8b8bd62)
nmeyerhans
pushed a commit
to nmeyerhans/systemd-stable
that referenced
this issue
Oct 26, 2022
The systemd-pstore service takes pstore files on boot and transfers them to disk. It only does it once on boot and only if it finds any. The typical location of the pstore on modern systems is the UEFI variable store. Most distributions ship with CONFIG_EFI_VARS_PSTORE=m. That means, the UEFI variable store is only available on boot after the respective module is loaded. In most situations, the pstore service gets loaded before the UEFI pstore, so we don't get to transfer logs. Instead, they accumulate, filling up the pstore over time, potentially breaking the UEFI variable store. Let's add a service dependency on any kernel module that can provide a pstore to ensure we only scan for pstate after we can actually see pstate. I have seen live occurences of systems breaking because we did not erase the pstates and ran out of UEFI nvram space. Fixes systemd/systemd#18540 (cherry picked from commit 70e74a5)
nmeyerhans
pushed a commit
to nmeyerhans/systemd-stable
that referenced
this issue
Oct 26, 2022
Commit 70e74a5 ("pstore: Run after modules are loaded") added After= and Wants= entries for all known kernel modules providing a pstore. While adding these dependencies on systems where one of the modules is not present, or not configured, should not have a real affect on the system, it can produce annoying error messages in the kernel log. E.g. "mtd device must be supplied (device name is empty)" when the mtdpstore module is not configured correctly. Since dependencies cannot be removed with drop-ins, if a distro wants to remove some of these modules from systemd-pstore.service, they need to patch units/systemd-pstore.service.in. On the other hand, if they want to append to the dependencies this can be done by shipping a drop-in. Since the original intent of the previous commit was to fix [1], which only requires the efi_pstore module, remove all other kernel module dependencies from systemd-pstore.service, and let distros ship drop-ins to add dependencies if needed. [1] systemd/systemd#18540 (cherry picked from commit 8b8bd62)
fbuihuu
pushed a commit
to openSUSE/systemd
that referenced
this issue
Nov 3, 2022
The systemd-pstore service takes pstore files on boot and transfers them to disk. It only does it once on boot and only if it finds any. The typical location of the pstore on modern systems is the UEFI variable store. Most distributions ship with CONFIG_EFI_VARS_PSTORE=m. That means, the UEFI variable store is only available on boot after the respective module is loaded. In most situations, the pstore service gets loaded before the UEFI pstore, so we don't get to transfer logs. Instead, they accumulate, filling up the pstore over time, potentially breaking the UEFI variable store. Let's add a service dependency on any kernel module that can provide a pstore to ensure we only scan for pstate after we can actually see pstate. I have seen live occurences of systems breaking because we did not erase the pstates and ran out of UEFI nvram space. Fixes systemd/systemd#18540 (cherry picked from commit 70e74a5)
fbuihuu
pushed a commit
to openSUSE/systemd
that referenced
this issue
Nov 3, 2022
Commit 70e74a5 ("pstore: Run after modules are loaded") added After= and Wants= entries for all known kernel modules providing a pstore. While adding these dependencies on systems where one of the modules is not present, or not configured, should not have a real affect on the system, it can produce annoying error messages in the kernel log. E.g. "mtd device must be supplied (device name is empty)" when the mtdpstore module is not configured correctly. Since dependencies cannot be removed with drop-ins, if a distro wants to remove some of these modules from systemd-pstore.service, they need to patch units/systemd-pstore.service.in. On the other hand, if they want to append to the dependencies this can be done by shipping a drop-in. Since the original intent of the previous commit was to fix [1], which only requires the efi_pstore module, remove all other kernel module dependencies from systemd-pstore.service, and let distros ship drop-ins to add dependencies if needed. [1] systemd/systemd#18540 (cherry picked from commit 8b8bd62)
keszybz
pushed a commit
to systemd/systemd-stable
that referenced
this issue
Nov 3, 2022
The systemd-pstore service takes pstore files on boot and transfers them to disk. It only does it once on boot and only if it finds any. The typical location of the pstore on modern systems is the UEFI variable store. Most distributions ship with CONFIG_EFI_VARS_PSTORE=m. That means, the UEFI variable store is only available on boot after the respective module is loaded. In most situations, the pstore service gets loaded before the UEFI pstore, so we don't get to transfer logs. Instead, they accumulate, filling up the pstore over time, potentially breaking the UEFI variable store. Let's add a service dependency on any kernel module that can provide a pstore to ensure we only scan for pstate after we can actually see pstate. I have seen live occurences of systems breaking because we did not erase the pstates and ran out of UEFI nvram space. Fixes systemd/systemd#18540 (cherry picked from commit 70e74a5)
keszybz
pushed a commit
to systemd/systemd-stable
that referenced
this issue
Nov 3, 2022
Commit 70e74a5 ("pstore: Run after modules are loaded") added After= and Wants= entries for all known kernel modules providing a pstore. While adding these dependencies on systems where one of the modules is not present, or not configured, should not have a real affect on the system, it can produce annoying error messages in the kernel log. E.g. "mtd device must be supplied (device name is empty)" when the mtdpstore module is not configured correctly. Since dependencies cannot be removed with drop-ins, if a distro wants to remove some of these modules from systemd-pstore.service, they need to patch units/systemd-pstore.service.in. On the other hand, if they want to append to the dependencies this can be done by shipping a drop-in. Since the original intent of the previous commit was to fix [1], which only requires the efi_pstore module, remove all other kernel module dependencies from systemd-pstore.service, and let distros ship drop-ins to add dependencies if needed. [1] systemd/systemd#18540 (cherry picked from commit 8b8bd62)
dtardon
pushed a commit
to dtardon/systemd-rhel8
that referenced
this issue
Jan 30, 2023
The systemd-pstore service takes pstore files on boot and transfers them to disk. It only does it once on boot and only if it finds any. The typical location of the pstore on modern systems is the UEFI variable store. Most distributions ship with CONFIG_EFI_VARS_PSTORE=m. That means, the UEFI variable store is only available on boot after the respective module is loaded. In most situations, the pstore service gets loaded before the UEFI pstore, so we don't get to transfer logs. Instead, they accumulate, filling up the pstore over time, potentially breaking the UEFI variable store. Let's add a service dependency on any kernel module that can provide a pstore to ensure we only scan for pstate after we can actually see pstate. I have seen live occurences of systems breaking because we did not erase the pstates and ran out of UEFI nvram space. Fixes systemd/systemd#18540 (cherry picked from commit 70e74a5997ae2ce7ba72a74ac949c3b2dad1a1d6) Related: #2158832
dtardon
pushed a commit
to dtardon/systemd-rhel8
that referenced
this issue
Jan 30, 2023
Commit 70e74a5997 ("pstore: Run after modules are loaded") added After=
and Wants= entries for all known kernel modules providing a pstore.
While adding these dependencies on systems where one of the modules is
not present, or not configured, should not have a real affect on the
system, it can produce annoying error messages in the kernel log. E.g.
"mtd device must be supplied (device name is empty)" when the mtdpstore
module is not configured correctly.
Since dependencies cannot be removed with drop-ins, if a distro wants to
remove some of these modules from systemd-pstore.service, they need to
patch units/systemd-pstore.service.in. On the other hand, if they want
to append to the dependencies this can be done by shipping a drop-in.
Since the original intent of the previous commit was to fix [1], which
only requires the efi_pstore module, remove all other kernel module
dependencies from systemd-pstore.service, and let distros ship drop-ins
to add dependencies if needed.
[1] systemd/systemd#18540
(cherry picked from commit 8b8bd621e1d16808678fc3afed257df1fa03a281)
Related: #2158832
systemd-rhel-bot
pushed a commit
to redhat-plumbers/systemd-rhel8
that referenced
this issue
Feb 27, 2023
The systemd-pstore service takes pstore files on boot and transfers them to disk. It only does it once on boot and only if it finds any. The typical location of the pstore on modern systems is the UEFI variable store. Most distributions ship with CONFIG_EFI_VARS_PSTORE=m. That means, the UEFI variable store is only available on boot after the respective module is loaded. In most situations, the pstore service gets loaded before the UEFI pstore, so we don't get to transfer logs. Instead, they accumulate, filling up the pstore over time, potentially breaking the UEFI variable store. Let's add a service dependency on any kernel module that can provide a pstore to ensure we only scan for pstate after we can actually see pstate. I have seen live occurences of systems breaking because we did not erase the pstates and ran out of UEFI nvram space. Fixes systemd/systemd#18540 (cherry picked from commit 70e74a5997ae2ce7ba72a74ac949c3b2dad1a1d6) Related: #2158832
systemd-rhel-bot
pushed a commit
to redhat-plumbers/systemd-rhel8
that referenced
this issue
Feb 27, 2023
Commit 70e74a5997 ("pstore: Run after modules are loaded") added After=
and Wants= entries for all known kernel modules providing a pstore.
While adding these dependencies on systems where one of the modules is
not present, or not configured, should not have a real affect on the
system, it can produce annoying error messages in the kernel log. E.g.
"mtd device must be supplied (device name is empty)" when the mtdpstore
module is not configured correctly.
Since dependencies cannot be removed with drop-ins, if a distro wants to
remove some of these modules from systemd-pstore.service, they need to
patch units/systemd-pstore.service.in. On the other hand, if they want
to append to the dependencies this can be done by shipping a drop-in.
Since the original intent of the previous commit was to fix [1], which
only requires the efi_pstore module, remove all other kernel module
dependencies from systemd-pstore.service, and let distros ship drop-ins
to add dependencies if needed.
[1] systemd/systemd#18540
(cherry picked from commit 8b8bd621e1d16808678fc3afed257df1fa03a281)
Related: #2158832
dtardon
pushed a commit
to dtardon/systemd-rhel8
that referenced
this issue
Apr 12, 2023
The systemd-pstore service takes pstore files on boot and transfers them to disk. It only does it once on boot and only if it finds any. The typical location of the pstore on modern systems is the UEFI variable store. Most distributions ship with CONFIG_EFI_VARS_PSTORE=m. That means, the UEFI variable store is only available on boot after the respective module is loaded. In most situations, the pstore service gets loaded before the UEFI pstore, so we don't get to transfer logs. Instead, they accumulate, filling up the pstore over time, potentially breaking the UEFI variable store. Let's add a service dependency on any kernel module that can provide a pstore to ensure we only scan for pstate after we can actually see pstate. I have seen live occurences of systems breaking because we did not erase the pstates and ran out of UEFI nvram space. Fixes systemd/systemd#18540 (cherry picked from commit 70e74a5997ae2ce7ba72a74ac949c3b2dad1a1d6) Related: #2186176
dtardon
pushed a commit
to dtardon/systemd-rhel8
that referenced
this issue
Apr 12, 2023
Commit 70e74a5997 ("pstore: Run after modules are loaded") added After=
and Wants= entries for all known kernel modules providing a pstore.
While adding these dependencies on systems where one of the modules is
not present, or not configured, should not have a real affect on the
system, it can produce annoying error messages in the kernel log. E.g.
"mtd device must be supplied (device name is empty)" when the mtdpstore
module is not configured correctly.
Since dependencies cannot be removed with drop-ins, if a distro wants to
remove some of these modules from systemd-pstore.service, they need to
patch units/systemd-pstore.service.in. On the other hand, if they want
to append to the dependencies this can be done by shipping a drop-in.
Since the original intent of the previous commit was to fix [1], which
only requires the efi_pstore module, remove all other kernel module
dependencies from systemd-pstore.service, and let distros ship drop-ins
to add dependencies if needed.
[1] systemd/systemd#18540
(cherry picked from commit 8b8bd621e1d16808678fc3afed257df1fa03a281)
Related: #2186176
dtardon
pushed a commit
to dtardon/systemd-rhel8
that referenced
this issue
Apr 12, 2023
The systemd-pstore service takes pstore files on boot and transfers them to disk. It only does it once on boot and only if it finds any. The typical location of the pstore on modern systems is the UEFI variable store. Most distributions ship with CONFIG_EFI_VARS_PSTORE=m. That means, the UEFI variable store is only available on boot after the respective module is loaded. In most situations, the pstore service gets loaded before the UEFI pstore, so we don't get to transfer logs. Instead, they accumulate, filling up the pstore over time, potentially breaking the UEFI variable store. Let's add a service dependency on any kernel module that can provide a pstore to ensure we only scan for pstate after we can actually see pstate. I have seen live occurences of systems breaking because we did not erase the pstates and ran out of UEFI nvram space. Fixes systemd/systemd#18540 (cherry picked from commit 70e74a5997ae2ce7ba72a74ac949c3b2dad1a1d6) Related: #2186177
dtardon
pushed a commit
to dtardon/systemd-rhel8
that referenced
this issue
Apr 12, 2023
Commit 70e74a5997 ("pstore: Run after modules are loaded") added After=
and Wants= entries for all known kernel modules providing a pstore.
While adding these dependencies on systems where one of the modules is
not present, or not configured, should not have a real affect on the
system, it can produce annoying error messages in the kernel log. E.g.
"mtd device must be supplied (device name is empty)" when the mtdpstore
module is not configured correctly.
Since dependencies cannot be removed with drop-ins, if a distro wants to
remove some of these modules from systemd-pstore.service, they need to
patch units/systemd-pstore.service.in. On the other hand, if they want
to append to the dependencies this can be done by shipping a drop-in.
Since the original intent of the previous commit was to fix [1], which
only requires the efi_pstore module, remove all other kernel module
dependencies from systemd-pstore.service, and let distros ship drop-ins
to add dependencies if needed.
[1] systemd/systemd#18540
(cherry picked from commit 8b8bd621e1d16808678fc3afed257df1fa03a281)
Related: #2186177
jamacku
pushed a commit
to redhat-plumbers/systemd-rhel8
that referenced
this issue
Apr 20, 2023
The systemd-pstore service takes pstore files on boot and transfers them to disk. It only does it once on boot and only if it finds any. The typical location of the pstore on modern systems is the UEFI variable store. Most distributions ship with CONFIG_EFI_VARS_PSTORE=m. That means, the UEFI variable store is only available on boot after the respective module is loaded. In most situations, the pstore service gets loaded before the UEFI pstore, so we don't get to transfer logs. Instead, they accumulate, filling up the pstore over time, potentially breaking the UEFI variable store. Let's add a service dependency on any kernel module that can provide a pstore to ensure we only scan for pstate after we can actually see pstate. I have seen live occurences of systems breaking because we did not erase the pstates and ran out of UEFI nvram space. Fixes systemd/systemd#18540 (cherry picked from commit 70e74a5997ae2ce7ba72a74ac949c3b2dad1a1d6) Related: #2186176
jamacku
pushed a commit
to redhat-plumbers/systemd-rhel8
that referenced
this issue
Apr 20, 2023
Commit 70e74a5997 ("pstore: Run after modules are loaded") added After=
and Wants= entries for all known kernel modules providing a pstore.
While adding these dependencies on systems where one of the modules is
not present, or not configured, should not have a real affect on the
system, it can produce annoying error messages in the kernel log. E.g.
"mtd device must be supplied (device name is empty)" when the mtdpstore
module is not configured correctly.
Since dependencies cannot be removed with drop-ins, if a distro wants to
remove some of these modules from systemd-pstore.service, they need to
patch units/systemd-pstore.service.in. On the other hand, if they want
to append to the dependencies this can be done by shipping a drop-in.
Since the original intent of the previous commit was to fix [1], which
only requires the efi_pstore module, remove all other kernel module
dependencies from systemd-pstore.service, and let distros ship drop-ins
to add dependencies if needed.
[1] systemd/systemd#18540
(cherry picked from commit 8b8bd621e1d16808678fc3afed257df1fa03a281)
Related: #2186176
jamacku
pushed a commit
to redhat-plumbers/systemd-rhel8
that referenced
this issue
Apr 20, 2023
The systemd-pstore service takes pstore files on boot and transfers them to disk. It only does it once on boot and only if it finds any. The typical location of the pstore on modern systems is the UEFI variable store. Most distributions ship with CONFIG_EFI_VARS_PSTORE=m. That means, the UEFI variable store is only available on boot after the respective module is loaded. In most situations, the pstore service gets loaded before the UEFI pstore, so we don't get to transfer logs. Instead, they accumulate, filling up the pstore over time, potentially breaking the UEFI variable store. Let's add a service dependency on any kernel module that can provide a pstore to ensure we only scan for pstate after we can actually see pstate. I have seen live occurences of systems breaking because we did not erase the pstates and ran out of UEFI nvram space. Fixes systemd/systemd#18540 (cherry picked from commit 70e74a5997ae2ce7ba72a74ac949c3b2dad1a1d6) Related: #2186177
jamacku
pushed a commit
to redhat-plumbers/systemd-rhel8
that referenced
this issue
Apr 20, 2023
Commit 70e74a5997 ("pstore: Run after modules are loaded") added After=
and Wants= entries for all known kernel modules providing a pstore.
While adding these dependencies on systems where one of the modules is
not present, or not configured, should not have a real affect on the
system, it can produce annoying error messages in the kernel log. E.g.
"mtd device must be supplied (device name is empty)" when the mtdpstore
module is not configured correctly.
Since dependencies cannot be removed with drop-ins, if a distro wants to
remove some of these modules from systemd-pstore.service, they need to
patch units/systemd-pstore.service.in. On the other hand, if they want
to append to the dependencies this can be done by shipping a drop-in.
Since the original intent of the previous commit was to fix [1], which
only requires the efi_pstore module, remove all other kernel module
dependencies from systemd-pstore.service, and let distros ship drop-ins
to add dependencies if needed.
[1] systemd/systemd#18540
(cherry picked from commit 8b8bd621e1d16808678fc3afed257df1fa03a281)
Related: #2186177
11 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
systemd version the issue has been seen with
Used distribution
Linux kernel version used (
uname -a)CPU architecture issue was seen on
Expected behaviour you didn't see
Unexpected behaviour you saw
Steps to reproduce the problem
Additional program output to the terminal or log subsystem illustrating the issue
After kernel crash and reboot dump files not moved to /var/lib/systemd/pstore
I think systemd-pstore start before load efi_pstore kernel module and mount /sys/fs/pstore, and this time /sys/fs/pstore/ is empty.
systemd-pstore should requires on load kernel module
After add to service:
work fine, dump files moved to /var/lib/systemd/pstore.
The text was updated successfully, but these errors were encountered: