[Bug 1854981] Re: system doesn't properly boot as expected if /usr is on its own LV

Wed Dec 4 00:43:31 UTC 2019

I wonder if this behaviour is not observe in Eoan because it is the
first Ubuntu release introducing the removal of lvmetad[0] (starting
v2_03_00) in favour of 'event_activation'[1] (starting v2_03_03) in
lvm2.

Seems like a lot happened between lvm2 found in disco and eoan in term
of development in the activation area.

[0]
e6be10ffd man: remove scattered lvmetad references
cbee4d3d8 man pvscan: replace lvmetad text
1c0b02e36 man: remove lvmetad
81ca0cb16 Remove init scripts related to clvm and lvmetad
07d2794a1 tests: remove lvmetad variation
b070c14a8 tests: drop lvmetad parts of system_id test
3bcc6c7e6 tests: drop lvmetad bits
97506a7e2 build: Remove lvmetad leftovers
bf4be8066 spec: Remove lvmetad
63ec42f42 tests: remove lvmetad tests
117160b27 Remove lvmetad

[1]
commit 4b5d6de86b3fd3a06b913708e477b603627c8614
Author: David Teigland <teigland at redhat.com>
Date:   Mon Nov 26 12:49:39 2018 -0600

    pvscan systemd service for event based activation

    The pvscan systemd service for autoactivation was
    mistakenly dropped along with the lvmetad related
    services.

    The activation generator program now looks at the new
    lvm.conf setting "event_activation" (default 1) to
    switch between event activation and direct activation.

    Previously, the old use_lvmetad setting was used to
    switch between event and direct activation.
----

commit fc482406ec4e0607a9d7335ac927c64b361cad1c
Author: Zdenek Kabelac <zkabelac at redhat.com>
Date:   Thu Nov 29 23:08:05 2018 +0100

    make: generate config update
----

conf/example.conf.in:
        # Configuration option global/event_activation.
        # Activate LVs based on system-generated device events.
        # When a device appears on the system, a system-generated event runs
        # the pvscan command to activate LVs if the new PV completes the VG.
        # Use auto_activation_volume_list to select which LVs should be
        # activated from these events (the default is all.)
        # When event_activation is disabled, the system will generally run
        # a direct activation command to activate LVs in complete VGs.
        event_activation = 1

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

Title:
  system doesn't properly boot as expected if /usr is on its own LV

Status in initramfs-tools package in Ubuntu:
  New
Status in lvm2 package in Ubuntu:
  New

Bug description:
  Only the lv for root volume get activated, because of the grub
  parameter that specifies/enforce it "root=/dev/mapper/ubuntu-vg-ubuntu
  --lv"

  http://man7.org/linux/man-pages/man7/bootparam.7.html
  'root=...'
                This argument tells the kernel what device is to be used as
                the root filesystem while booting.

  If one add a separate LV for /usr, the system will go straight to
  initramfs prompt failling to mount /usr.

  At initramfs prompt, we notice that 'lv-usr' status is 'NOT
  available'.

  Performing 'lvm vgchange -ay' at initramfs prompt workaround the
  problem and allow one to successfully boot.

  Adding 'debug' parameter, we clearly we see /root being detected and mounted:
  initramfs.debug:
  => + mount -r -t ext4 /dev/mapper/ubuntu--vg-ubuntu--lv /root
  => + mountroot_status=0
  + [ ]
  + log_end_msg
  + _log_msg done.\n
  + [ n = y ]
  + printf done.\n
  done.
  + read_fstab_entry /usr
  + found=1
  + [ -f /root/etc/fstab ]
  + read MNT_FSNAME MNT_DIR MNT_TYPE MNT_OPTS MNT_FREQ MNT_PASS MNT_JUNK
  + [ / = /usr ]
  + read MNT_FSNAME MNT_DIR MNT_TYPE MNT_OPTS MNT_FREQ MNT_PASS MNT_JUNK
  + [ /usr = /usr ]
  + [ -n ]
  + found=0
  + break 2
  + return 0
  + log_begin_msg Mounting /usr file system
  + _log_msg Begin: Mounting /usr file system ...

  then the code read /etc/fstab and specifically search for /usr (most
  likely because of the /usr binary merged) and try to mount if if
  found.

  initramfs-tools:init
  271 maybe_break mount
  272 log_begin_msg "Mounting root file system"
  273 # Always load local and nfs (since these might be needed for /etc or
  274 # /usr, irrespective of the boot script used to mount the rootfs).
  275 . /scripts/local
  276 . /scripts/nfs
  277 . /scripts/${BOOT}
  278 parse_numeric "${ROOT}"
  279 maybe_break mountroot
  280 mount_top
  281 mount_premount
  282 mountroot
  283 log_end_msg
  284
  => 285 if read_fstab_entry /usr; then
  => 286 log_begin_msg "Mounting /usr file system"
  => 287 mountfs /usr
  => 288 log_end_msg
  => 289 fi

  In this case, /usr is present in /etc/fstab but the logical volume is
  not available, so it is mounting a filesystem without his backend
  device, thus goes straight to the initramfs prompt because /usr
  couldn't be mounted.

  It clearly seems to be an 'auto-activation' issue at boot.

  For other such as /home, /var, it's not a big deal cause they can be
  activated later on in the process and they are (I haven't check but I
  guess systemd or systemd unit/generator is taking care of it at some
  point), but /usr is a important piece to have mounted before the pivot
  since it contains most of the crucial binary, especially that nowadays
  /sbin, /bin, and /lib are pointing to /usr:

  lrwxrwxrwx   1 root root         10 Aug 26 13:51 libx32 -> usr/libx32
  lrwxrwxrwx   1 root root          9 Aug 26 13:51 lib64 -> usr/lib64
  lrwxrwxrwx   1 root root          9 Aug 26 13:51 lib32 -> usr/lib32
  lrwxrwxrwx   1 root root          7 Aug 26 13:51 lib -> usr/lib
  lrwxrwxrwx   1 root root          7 Aug 26 13:51 bin -> usr/bin
  lrwxrwxrwx   1 root root          8 Aug 26 13:51 sbin -> usr/sbin

  NOTE:

  * That doesn't affect /usr found in /etc/fstab on its separate
  partition when no LVM involve (e.g. /dev/vdb /usr ext4 ....). It only
  cause issue when /usr is in a LVM context.

  * I was able to reproduce on Bionic and Disco so far.
  Eoan doesn't seem to exhibit the situation so far in my testing.

  * While certain release such as Bionic, Xenial doesn't come implicitly
  with the /usr merge approach. One can install package 'usrmerge' and
  convert their system /usr merged. I don't think removing the
  read_fstable_entry for /usr is an option here, as some user could
  potentially decide to convert their system with 'usrmerge' pkg.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1854981/+subscriptions