[Bug 1854981] Re: system doesn't properly boot as expected if /usr is on its own LV
Eric Desrochers
eric.desrochers at canonical.com
Tue Dec 3 19:50:30 UTC 2019
** 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
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, 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
More information about the foundations-bugs
mailing list