On Mon, Jul 25, 2022 at 4:00 PM Lukas Märdian <1982...@bugs.launchpad.net>
wrote:

> Alfonso, would this also affect Focal (Ubuntu Core 20), after this patch
> is shipped to that series via SRU (as it happened on Jammy already)?
>
> https://git.launchpad.net/~ubuntu-core-
> dev/ubuntu/+source/systemd/commit/?h=ubuntu-
> focal&id=6e60756f2079d6408abdb967127a1d9b9a0eba8c
>
> Do we need to include this fix for Focal too, before uploading the next
> Focal SRU?
>

Although the bug was reported for UC22, if the patch causing the problem is
in focal I would say that yes, probably it would be needed to backport it
there.


>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1982462
>
> Title:
>   Some modprobe loading services requested by the pstore service fail
>
> Status in systemd package in Ubuntu:
>   In Progress
> Status in systemd source package in Jammy:
>   Triaged
> Status in systemd source package in Kinetic:
>   In Progress
>
> Bug description:
>   [Impact]
>
>   It has been detected that some modprobe services fail on UC22 after
>   the jammy upgrade  249.11-0ubuntu3.4:
>
>   $ systemctl --system --no-ask-password --no-pager list-units
> --state=failed
>   Failed units:
>     UNIT                             LOAD   ACTIVE SUB    DESCRIPTION
>   ● modprobe@chromeos_pstore.service loaded failed failed Load Kernel
> Module chromeos_pstore
>   ● modprobe@efi_pstore.service      loaded failed failed Load Kernel
> Module efi_pstore
>   ● modprobe@mtdpstore.service       loaded failed failed Load Kernel
> Module mtdpstore
>   ● modprobe@pstore_blk.service      loaded failed failed Load Kernel
> Module pstore_blk
>   ● modprobe@pstore_zone.service     loaded failed failed Load Kernel
> Module pstore_zone
>   ● modprobe@ramoops.service         loaded failed failed Load Kernel
> Module ramoops
>
>   This happens because of some changes to systemd-pstore.service that
>   now has:
>
>   After=modprobe@efi_pstore.service modprobe@mtdpstore.service
> modprobe@chromeos_pstore.service modprobe@ramoops.service
> modprobe@pstore_zone.service modprobe@pstore_blk.service
>   Wants=modprobe@efi_pstore.service modprobe@mtdpstore.service
> modprobe@chromeos_pstore.service modprobe@ramoops.service
> modprobe@pstore_zone.service modprobe@pstore_blk.service
>
>   This causes too many tries of the modprobe services, that fail in the
>   end with
>
>   Jul 20 09:02:39 ubuntu systemd[1]: modprobe@chromeos_pstore.service:
>   Start request repeated too quickly.
>
>   Although we have seen this only on UC22, it potentially can affect
>   classic systems as well, as systemd-pstore.service is re-tried there a
>   few times too. See https://github.com/snapcore/core-base/issues/72 for
>   more details.
>
>   A fix for this is available upstream:
>
> https://github.com/systemd/systemd/commit/9625350e5381a68c1179ae4581e7586c206663e1
>
>   [Test Plan]
>
>   Start the device and check that there is no modprobe-pstore related
>   failed service. This is racy, so a few tries will be needed to make
>   sure things are fine.
>
>   [Where problems could occur]
>
>   The modprobe services are usually dependencies from other services, so
>   it should be fine if the retry behavior is controlled by those other
>   services. Risk should be small. If something goes wrong we might see a
>   lot of restarts for these services.
>
>   [Other Info]
>
>   Testing should happen on UC22 too.
>
> To manage notifications about this bug go to:
>
> https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1982462/+subscriptions
>
>

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1982462

Title:
  Some modprobe loading services requested by the pstore service fail

Status in systemd package in Ubuntu:
  In Progress
Status in systemd source package in Jammy:
  Triaged
Status in systemd source package in Kinetic:
  In Progress

Bug description:
  [Impact]

  It has been detected that some modprobe services fail on UC22 after
  the jammy upgrade  249.11-0ubuntu3.4:

  $ systemctl --system --no-ask-password --no-pager list-units --state=failed
  Failed units:
    UNIT                             LOAD   ACTIVE SUB    DESCRIPTION
  ● modprobe@chromeos_pstore.service loaded failed failed Load Kernel Module 
chromeos_pstore
  ● modprobe@efi_pstore.service      loaded failed failed Load Kernel Module 
efi_pstore
  ● modprobe@mtdpstore.service       loaded failed failed Load Kernel Module 
mtdpstore
  ● modprobe@pstore_blk.service      loaded failed failed Load Kernel Module 
pstore_blk
  ● modprobe@pstore_zone.service     loaded failed failed Load Kernel Module 
pstore_zone
  ● modprobe@ramoops.service         loaded failed failed Load Kernel Module 
ramoops

  This happens because of some changes to systemd-pstore.service that
  now has:

  After=modprobe@efi_pstore.service modprobe@mtdpstore.service 
modprobe@chromeos_pstore.service modprobe@ramoops.service 
modprobe@pstore_zone.service modprobe@pstore_blk.service
  Wants=modprobe@efi_pstore.service modprobe@mtdpstore.service 
modprobe@chromeos_pstore.service modprobe@ramoops.service 
modprobe@pstore_zone.service modprobe@pstore_blk.service

  This causes too many tries of the modprobe services, that fail in the
  end with

  Jul 20 09:02:39 ubuntu systemd[1]: modprobe@chromeos_pstore.service:
  Start request repeated too quickly.

  Although we have seen this only on UC22, it potentially can affect
  classic systems as well, as systemd-pstore.service is re-tried there a
  few times too. See https://github.com/snapcore/core-base/issues/72 for
  more details.

  A fix for this is available upstream:
  
https://github.com/systemd/systemd/commit/9625350e5381a68c1179ae4581e7586c206663e1

  [Test Plan]

  Start the device and check that there is no modprobe-pstore related
  failed service. This is racy, so a few tries will be needed to make
  sure things are fine.

  [Where problems could occur]

  The modprobe services are usually dependencies from other services, so
  it should be fine if the retry behavior is controlled by those other
  services. Risk should be small. If something goes wrong we might see a
  lot of restarts for these services.

  [Other Info]

  Testing should happen on UC22 too.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1982462/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to     : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

Reply via email to