[Bug 1982486] Re: update-motd-fsck-at-reboot: exclude nbd devices

Dan Watkins 1982486 at bugs.launchpad.net
Wed Jul 27 14:44:25 UTC 2022


I would also like this fix in jammy (as would the SRU team, if I'm
fixing it in focal!): given a `jammy` branch doesn't yet exist, I'm not
sure how best to proceed with that.

** Description changed:

+ [Impact]
+ 
+ * update-motd-fsck-at-reboot will block shutdown if a broken NBD device
+ is present in the system when it executes.  In some configurations (e.g.
+ when sudo authorisation is provided via sssd, which stops before this
+ task completes), this can result in a hard power cycle being required to
+ return a machine to service.
+ 
+ * Users with NBD devices will erroneously see them reported as devices
+ that will be fsck'd at next boot.
+ 
+ [Test Plan]
+ 
+ * Get a QEMU image containing an ext4 partition (e.g. https://cloud-images.ubuntu.com/releases/focal/release/ubuntu-20.04-server-cloudimg-amd64.img)
+ * `qemu-nbd -c /dev/nbd0 <that image>`
+ * `mount /dev/nbd0p2 /mnt` (partition number may vary depending on your image)
+ * Execute `update-motd-fsck-at-reboot`
+ * Observe NBD device not included
+ 
+ [Where problems could occur]
+ 
+ If the one-line fix is incorrect, users may not receive notification of
+ fsck'ing that is going to happen, which they may rely on.
+ 
+ [Original Report]
+ 
  I've ended up in a situation where a machine's /dev/nbd* devices are in
  a broken state: the easiest way for me to fix this is to reboot the
  system.  However, the reboot is blocked by update-motd-fsck-at-reboot
  trying to run dumpe2fs against one of the broken partitions:
  
  $ ps faux
  ...
  root      191396  0.0  0.2  37864  8672 ?        Ss   12:37   0:00 sshd: dwatkins [priv]
  root      191421  0.0  0.0   2608   480 ?        S    12:37   0:00  \_ sh -c /usr/bin/env -i PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin run-parts --ls
  root      191422  0.0  0.0   2496   508 ?        S    12:37   0:00      \_ run-parts --lsbsysinit /etc/update-motd.d
  root      191455  0.0  0.0   2608  1748 ?        S    12:37   0:00          \_ /bin/sh /usr/lib/update-notifier/update-motd-fsck-at-reboot
  root      191483  0.0  0.0   3480   944 ?        D    12:37   0:00              \_ dumpe2fs -h /dev/nbd0p2
  ...
  
  These NBD devices will not be present after a reboot, so I think the
  script would probably be more correct if it omitted operating on these
  devices.

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to update-notifier in Ubuntu.
https://bugs.launchpad.net/bugs/1982486

Title:
  update-motd-fsck-at-reboot: exclude nbd devices

Status in update-notifier package in Ubuntu:
  In Progress

Bug description:
  [Impact]

  * update-motd-fsck-at-reboot will block shutdown if a broken NBD
  device is present in the system when it executes.  In some
  configurations (e.g. when sudo authorisation is provided via sssd,
  which stops before this task completes), this can result in a hard
  power cycle being required to return a machine to service.

  * Users with NBD devices will erroneously see them reported as devices
  that will be fsck'd at next boot.

  [Test Plan]

  * Get a QEMU image containing an ext4 partition (e.g. https://cloud-images.ubuntu.com/releases/focal/release/ubuntu-20.04-server-cloudimg-amd64.img)
  * `qemu-nbd -c /dev/nbd0 <that image>`
  * `mount /dev/nbd0p2 /mnt` (partition number may vary depending on your image)
  * Execute `update-motd-fsck-at-reboot`
  * Observe NBD device not included

  [Where problems could occur]

  If the one-line fix is incorrect, users may not receive notification
  of fsck'ing that is going to happen, which they may rely on.

  [Original Report]

  I've ended up in a situation where a machine's /dev/nbd* devices are
  in a broken state: the easiest way for me to fix this is to reboot the
  system.  However, the reboot is blocked by update-motd-fsck-at-reboot
  trying to run dumpe2fs against one of the broken partitions:

  $ ps faux
  ...
  root      191396  0.0  0.2  37864  8672 ?        Ss   12:37   0:00 sshd: dwatkins [priv]
  root      191421  0.0  0.0   2608   480 ?        S    12:37   0:00  \_ sh -c /usr/bin/env -i PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin run-parts --ls
  root      191422  0.0  0.0   2496   508 ?        S    12:37   0:00      \_ run-parts --lsbsysinit /etc/update-motd.d
  root      191455  0.0  0.0   2608  1748 ?        S    12:37   0:00          \_ /bin/sh /usr/lib/update-notifier/update-motd-fsck-at-reboot
  root      191483  0.0  0.0   3480   944 ?        D    12:37   0:00              \_ dumpe2fs -h /dev/nbd0p2
  ...

  These NBD devices will not be present after a reboot, so I think the
  script would probably be more correct if it omitted operating on these
  devices.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/update-notifier/+bug/1982486/+subscriptions




More information about the foundations-bugs mailing list