** Description changed: - 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" + 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 ... + 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 + 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. + + + 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.
-- 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, 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, 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. 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
