group.of.nepali.translators team mailing list archive

[Eric Desrochers <eric.desrochers@xxxxxxxxxxxxx>]

** Changed in: lvm2 (Ubuntu Xenial)
       Status: New => Won't Fix

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
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:
  Won't Fix
Status in lvm2 package in Ubuntu:
  Fix Released
Status in initramfs-tools source package in Xenial:
  Won't Fix
Status in lvm2 source package in Xenial:
  Won't Fix
Status in initramfs-tools source package in Bionic:
  Won't Fix
Status in lvm2 source package in Bionic:
  Confirmed
Status in initramfs-tools source package in Disco:
  Won't Fix
Status in lvm2 source package in Disco:
  Confirmed

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