initramfs.debug_DISCO

** Attachment added: "initramfs.debug_DISCO"
   
https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1854981/+attachment/5309607/+files/initramfs.debug

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to lvm2 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, most likely because of the
  grub parameter that specifies it "root=/dev/mapper/ubuntu-vg-ubuntu--
  lv"

  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, 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

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

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1854981/+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