[Touch-packages] [Bug 1854981] Re: system doesn't properly boot as expected if /usr is on its own LV
This bug was fixed in the package lvm2 - 2.02.176-4.1ubuntu3.18.04.2
---
lvm2 (2.02.176-4.1ubuntu3.18.04.2) bionic; urgency=medium
* d/p/fix-auto-activation-at-boot.patch: (LP: #1854981)
Allow LV auto-activation (e.g. /usr on it's separate LV)
-- Eric Desrochers Thu, 05 Dec 2019
15:15:56 +
** Changed in: lvm2 (Ubuntu Bionic)
Status: Fix Committed => Fix Released
** Changed in: lvm2 (Ubuntu Disco)
Status: Fix Committed => Fix Released
--
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:
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:
Fix Released
Status in initramfs-tools source package in Bionic:
Won't Fix
Status in lvm2 source package in Bionic:
Fix Released
Status in initramfs-tools source package in Disco:
Won't Fix
Status in lvm2 source package in Disco:
Fix Released
Bug description:
[Impact]
In summary, the problem is a LVM 'auto-activation' issue. Basically the LVM
activation doesn't occurs during the boot process (except for LVM root
partition) and since /usr is an important component before the 'pivot'[0], the
init inside the initramfs space tries to mount /usr. If /usr is a LVM volume
then it will try to mount it while its backend device is not activated yet (due
to the actual auto-activation issue), thus the mounting will fails and bring
the user to the initramfs prompt for debugging.
Workaround:
At the initramfs prompt: lvm vgchange -ay and then 'ctrl-d' to resume the
boot process.
[Test Case]
- Install Bionic or Disco
- Create a VG with /usr on its on LV
- Complete the installation
- At reboot the system will be stuck at mounting /usr file system
Extra notes:
Since this problem is ONLY related to LVM activation. If one create a non-LVM
/usr separate partition, everything will work as expected.
Other separate LVM (e.g. /home, /var/, /srv) if on its own separate
LVM volume will not be activate either, but since they don't need to
be mounted in the initramfs space, it's not a problem, they can be
activated later on (after the pivot) by systemd.
So the only combination possible is when /usr is on its separate LV
only.
[Regression potential]
I don't foresee any regression, the fix will instruct udev rule to
pvscan activate volume based on their major/minor number if LVM is
scanned.
+RUN+="(LVM_EXEC)/lvm pvscan --cache --activate ay --major $major
--minor $minor", ENV{LVM_SCANNED}="1"
The current situation doesn't auto-activate at all.
One downside, for users who will see this fixed, will still experience
the situation in standard ISO, since I'm afraid Disco won't produces
new ISO. (it is not recommended to do new disco installs anyway since
it's going EOL shortly) One would need to rely on the mini.iso for
fetching the latest lvm2 package in the archive.
IIRC Bionic will have a new point release somewhere in Feb 2020 but
until then one would need to rely on the mini.iso for fetching the
latest lvm2 package in the archive as well.
or use the workaround in the [Impact] section and then apt-get dist-
upgrade in order to get the latest lvm2.
[Other information]
This problem only exhibit in Bionic and Disco.
Xenial and Eoan and late didn't exhibit the situation.
https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/
https://wiki.debian.org/UsrMerge
[Original 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
+
[Touch-packages] [Bug 1854981] Re: system doesn't properly boot as expected if /usr is on its own LV
This bug was fixed in the package lvm2 - 2.02.176-4.1ubuntu4.2
---
lvm2 (2.02.176-4.1ubuntu4.2) disco; urgency=medium
* d/p/fix-auto-activation-at-boot.patch: (LP: #1854981)
Allow LV auto-activation (e.g. /usr on it's separate LV)
-- Eric Desrochers Thu, 05 Dec 2019
13:13:18 +
--
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:
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:
Fix Released
Status in initramfs-tools source package in Bionic:
Won't Fix
Status in lvm2 source package in Bionic:
Fix Released
Status in initramfs-tools source package in Disco:
Won't Fix
Status in lvm2 source package in Disco:
Fix Released
Bug description:
[Impact]
In summary, the problem is a LVM 'auto-activation' issue. Basically the LVM
activation doesn't occurs during the boot process (except for LVM root
partition) and since /usr is an important component before the 'pivot'[0], the
init inside the initramfs space tries to mount /usr. If /usr is a LVM volume
then it will try to mount it while its backend device is not activated yet (due
to the actual auto-activation issue), thus the mounting will fails and bring
the user to the initramfs prompt for debugging.
Workaround:
At the initramfs prompt: lvm vgchange -ay and then 'ctrl-d' to resume the
boot process.
[Test Case]
- Install Bionic or Disco
- Create a VG with /usr on its on LV
- Complete the installation
- At reboot the system will be stuck at mounting /usr file system
Extra notes:
Since this problem is ONLY related to LVM activation. If one create a non-LVM
/usr separate partition, everything will work as expected.
Other separate LVM (e.g. /home, /var/, /srv) if on its own separate
LVM volume will not be activate either, but since they don't need to
be mounted in the initramfs space, it's not a problem, they can be
activated later on (after the pivot) by systemd.
So the only combination possible is when /usr is on its separate LV
only.
[Regression potential]
I don't foresee any regression, the fix will instruct udev rule to
pvscan activate volume based on their major/minor number if LVM is
scanned.
+RUN+="(LVM_EXEC)/lvm pvscan --cache --activate ay --major $major
--minor $minor", ENV{LVM_SCANNED}="1"
The current situation doesn't auto-activate at all.
One downside, for users who will see this fixed, will still experience
the situation in standard ISO, since I'm afraid Disco won't produces
new ISO. (it is not recommended to do new disco installs anyway since
it's going EOL shortly) One would need to rely on the mini.iso for
fetching the latest lvm2 package in the archive.
IIRC Bionic will have a new point release somewhere in Feb 2020 but
until then one would need to rely on the mini.iso for fetching the
latest lvm2 package in the archive as well.
or use the workaround in the [Impact] section and then apt-get dist-
upgrade in order to get the latest lvm2.
[Other information]
This problem only exhibit in Bionic and Disco.
Xenial and Eoan and late didn't exhibit the situation.
https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/
https://wiki.debian.org/UsrMerge
[Original 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
[Touch-packages] [Bug 1854981] Re: system doesn't properly boot as expected if /usr is on its own LV
[VERIFICATION DISCO]
I have installed Disco, layout /usr on it's on LV, and at reboot same
problem as describe in the impact section. Server stuck in trying to
mount /usr due to lack of LVM activation.
At the initramfs prompt, I ran 'lvm vgchange -ay' to boot properly. I
installed the disco-proposed package of lvm2[0], reboot the system and
everything boot fine. The udev rule fix does the work correctly.
[0] dpkg -l
ii liblvm2app2.2:amd64 2.02.176-4.1ubuntu4.2
amd64LVM2 application library
ii liblvm2cmd2.02:amd64 2.02.176-4.1ubuntu4.2
amd64LVM2 command library
ii lvm2 2.02.176-4.1ubuntu4.2
amd64Linux Logical Volume Manager
ubuntu
Additionally, as stated in comment #13, the autopkgtest failure can be
ignored as they are unrelated to this SRU.
** Tags removed: verification-needed-disco
** Tags added: verification-done-disco
--
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:
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:
Fix Released
Status in initramfs-tools source package in Bionic:
Won't Fix
Status in lvm2 source package in Bionic:
Fix Committed
Status in initramfs-tools source package in Disco:
Won't Fix
Status in lvm2 source package in Disco:
Fix Committed
Bug description:
[Impact]
In summary, the problem is a LVM 'auto-activation' issue. Basically the LVM
activation doesn't occurs during the boot process (except for LVM root
partition) and since /usr is an important component before the 'pivot'[0], the
init inside the initramfs space tries to mount /usr. If /usr is a LVM volume
then it will try to mount it while its backend device is not activated yet (due
to the actual auto-activation issue), thus the mounting will fails and bring
the user to the initramfs prompt for debugging.
Workaround:
At the initramfs prompt: lvm vgchange -ay and then 'ctrl-d' to resume the
boot process.
[Test Case]
- Install Bionic or Disco
- Create a VG with /usr on its on LV
- Complete the installation
- At reboot the system will be stuck at mounting /usr file system
Extra notes:
Since this problem is ONLY related to LVM activation. If one create a non-LVM
/usr separate partition, everything will work as expected.
Other separate LVM (e.g. /home, /var/, /srv) if on its own separate
LVM volume will not be activate either, but since they don't need to
be mounted in the initramfs space, it's not a problem, they can be
activated later on (after the pivot) by systemd.
So the only combination possible is when /usr is on its separate LV
only.
[Regression potential]
I don't foresee any regression, the fix will instruct udev rule to
pvscan activate volume based on their major/minor number if LVM is
scanned.
+RUN+="(LVM_EXEC)/lvm pvscan --cache --activate ay --major $major
--minor $minor", ENV{LVM_SCANNED}="1"
The current situation doesn't auto-activate at all.
One downside, for users who will see this fixed, will still experience
the situation in standard ISO, since I'm afraid Disco won't produces
new ISO. (it is not recommended to do new disco installs anyway since
it's going EOL shortly) One would need to rely on the mini.iso for
fetching the latest lvm2 package in the archive.
IIRC Bionic will have a new point release somewhere in Feb 2020 but
until then one would need to rely on the mini.iso for fetching the
latest lvm2 package in the archive as well.
or use the workaround in the [Impact] section and then apt-get dist-
upgrade in order to get the latest lvm2.
[Other information]
This problem only exhibit in Bionic and Disco.
Xenial and Eoan and late didn't exhibit the situation.
https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/
https://wiki.debian.org/UsrMerge
[Original 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
[Touch-packages] [Bug 1854981] Re: system doesn't properly boot as expected if /usr is on its own LV
I have restart the autopkgtest and they all passes BUT the disco cinder
ones.
Looking at the failure, it's not related to this current SRU, and it
seems to be a recurrent failing pattern:
autopkgtest [04:07:34]: test cinder-daemons: [---
2019-12-06 04:07:37.800 12844 WARNING oslo_db.sqlalchemy.engines [-] URL
mysql://cinder:***@localhost/cinder does not contain a '+drivername' portion,
and will make use of a default driver. A full dbname+drivername:// protocol is
recommended. For MySQL, it is strongly recommended that mysql+pymysql:// be
specified for maximum service compatibility[00m
2019-12-06 04:07:37.803 12844 CRITICAL cinder [-] Unhandled error:
ModuleNotFoundError: No module named 'MySQLdb'
2019-12-06 04:07:37.803 12844 ERROR cinder Traceback (most recent call last):
..
2019-12-06 04:07:37.803 12844 ERROR cinder File
"/usr/lib/python3/dist-packages/sqlalchemy/dialects/mysql/mysqldb.py", line
102, in dbapi
2019-12-06 04:07:37.803 12844 ERROR cinder return __import__('MySQLdb')
2019-12-06 04:07:37.803 12844 ERROR cinder ModuleNotFoundError: No module named
'MySQLdb'
2019-12-06 04:07:37.803 12844 ERROR cinder [00m
autopkgtest [04:07:38]: test cinder-daemons: ---]
autopkgtest [04:07:39]: test cinder-daemons: - - - - - - - - - - results - - -
- - - - - - -
cinder-daemons FAIL non-zero exit status 1
Please ignore the following disco failures:
Regression in autopkgtest for cinder (ppc64el): test log
Regression in autopkgtest for cinder (s390x): test log
Regression in autopkgtest for cinder (amd64): test log
Regression in autopkgtest for cinder (arm64): test log
Regression in autopkgtest for cinder (i386): test log
Regression in autopkgtest for cinder (armhf): test log
Its failing because it can't find the MySQLdb module which is unrelated
to the current LVM2 SRU.
--
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:
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:
Fix Released
Status in initramfs-tools source package in Bionic:
Won't Fix
Status in lvm2 source package in Bionic:
Fix Committed
Status in initramfs-tools source package in Disco:
Won't Fix
Status in lvm2 source package in Disco:
Fix Committed
Bug description:
[Impact]
In summary, the problem is a LVM 'auto-activation' issue. Basically the LVM
activation doesn't occurs during the boot process (except for LVM root
partition) and since /usr is an important component before the 'pivot'[0], the
init inside the initramfs space tries to mount /usr. If /usr is a LVM volume
then it will try to mount it while its backend device is not activated yet (due
to the actual auto-activation issue), thus the mounting will fails and bring
the user to the initramfs prompt for debugging.
Workaround:
At the initramfs prompt: lvm vgchange -ay and then 'ctrl-d' to resume the
boot process.
[Test Case]
- Install Bionic or Disco
- Create a VG with /usr on its on LV
- Complete the installation
- At reboot the system will be stuck at mounting /usr file system
Extra notes:
Since this problem is ONLY related to LVM activation. If one create a non-LVM
/usr separate partition, everything will work as expected.
Other separate LVM (e.g. /home, /var/, /srv) if on its own separate
LVM volume will not be activate either, but since they don't need to
be mounted in the initramfs space, it's not a problem, they can be
activated later on (after the pivot) by systemd.
So the only combination possible is when /usr is on its separate LV
only.
[Regression potential]
I don't foresee any regression, the fix will instruct udev rule to
pvscan activate volume based on their major/minor number if LVM is
scanned.
+RUN+="(LVM_EXEC)/lvm pvscan --cache --activate ay --major $major
--minor $minor", ENV{LVM_SCANNED}="1"
The current situation doesn't auto-activate at all.
One downside, for users who will see this fixed, will still experience
the situation in standard ISO, since I'm afraid Disco won't produces
new ISO. (it is not recommended to do new disco installs anyway since
it's going EOL shortly) One would need to rely on the mini.iso for
fetching the latest lvm2 package in the archive.
IIRC Bionic will have a new point release somewhere in Feb 2020 but
until then one would need to rely on the mini.iso for fetching the
latest lvm2 package in the archive as well.
or use the workaround in the [Impact] section and then apt-get dist-
upgrade in order to get the latest lvm2.
[Other information]
This problem only exhibit in Bionic and Disco.
Xenial and Eoan and late didn't exhibit the
[Touch-packages] [Bug 1854981] Re: system doesn't properly boot as expected if /usr is on its own LV
I have restart the autopkgtest and they all passes BUT the disco cinder
ones.
Looking at the failure, it's not related to this current SRU, and it
seems to be a recurrent failing pattern:
autopkgtest [04:07:34]: test cinder-daemons: [---
2019-12-06 04:07:37.800 12844 WARNING oslo_db.sqlalchemy.engines [-] URL
mysql://cinder:***@localhost/cinder does not contain a '+drivername' portion,
and will make use of a default driver. A full dbname+drivername:// protocol is
recommended. For MySQL, it is strongly recommended that mysql+pymysql:// be
specified for maximum service compatibility[00m
2019-12-06 04:07:37.803 12844 CRITICAL cinder [-] Unhandled error:
ModuleNotFoundError: No module named 'MySQLdb'
2019-12-06 04:07:37.803 12844 ERROR cinder Traceback (most recent call last):
..
2019-12-06 04:07:37.803 12844 ERROR cinder File
"/usr/lib/python3/dist-packages/sqlalchemy/dialects/mysql/mysqldb.py", line
102, in dbapi
2019-12-06 04:07:37.803 12844 ERROR cinder return __import__('MySQLdb')
2019-12-06 04:07:37.803 12844 ERROR cinder ModuleNotFoundError: No module named
'MySQLdb'
2019-12-06 04:07:37.803 12844 ERROR cinder [00m
autopkgtest [04:07:38]: test cinder-daemons: ---]
autopkgtest [04:07:39]: test cinder-daemons: - - - - - - - - - - results - - -
- - - - - - -
cinder-daemons FAIL non-zero exit status 1
Please ignore the following disco failures:
Regression in autopkgtest for cinder (ppc64el): test log
Regression in autopkgtest for cinder (s390x): test log
Regression in autopkgtest for cinder (amd64): test log
Regression in autopkgtest for cinder (arm64): test log
Regression in autopkgtest for cinder (i386): test log
Regression in autopkgtest for cinder (armhf): test log
--
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:
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:
Fix Released
Status in initramfs-tools source package in Bionic:
Won't Fix
Status in lvm2 source package in Bionic:
Fix Committed
Status in initramfs-tools source package in Disco:
Won't Fix
Status in lvm2 source package in Disco:
Fix Committed
Bug description:
[Impact]
In summary, the problem is a LVM 'auto-activation' issue. Basically the LVM
activation doesn't occurs during the boot process (except for LVM root
partition) and since /usr is an important component before the 'pivot'[0], the
init inside the initramfs space tries to mount /usr. If /usr is a LVM volume
then it will try to mount it while its backend device is not activated yet (due
to the actual auto-activation issue), thus the mounting will fails and bring
the user to the initramfs prompt for debugging.
Workaround:
At the initramfs prompt: lvm vgchange -ay and then 'ctrl-d' to resume the
boot process.
[Test Case]
- Install Bionic or Disco
- Create a VG with /usr on its on LV
- Complete the installation
- At reboot the system will be stuck at mounting /usr file system
Extra notes:
Since this problem is ONLY related to LVM activation. If one create a non-LVM
/usr separate partition, everything will work as expected.
Other separate LVM (e.g. /home, /var/, /srv) if on its own separate
LVM volume will not be activate either, but since they don't need to
be mounted in the initramfs space, it's not a problem, they can be
activated later on (after the pivot) by systemd.
So the only combination possible is when /usr is on its separate LV
only.
[Regression potential]
I don't foresee any regression, the fix will instruct udev rule to
pvscan activate volume based on their major/minor number if LVM is
scanned.
+RUN+="(LVM_EXEC)/lvm pvscan --cache --activate ay --major $major
--minor $minor", ENV{LVM_SCANNED}="1"
The current situation doesn't auto-activate at all.
One downside, for users who will see this fixed, will still experience
the situation in standard ISO, since I'm afraid Disco won't produces
new ISO. (it is not recommended to do new disco installs anyway since
it's going EOL shortly) One would need to rely on the mini.iso for
fetching the latest lvm2 package in the archive.
IIRC Bionic will have a new point release somewhere in Feb 2020 but
until then one would need to rely on the mini.iso for fetching the
latest lvm2 package in the archive as well.
or use the workaround in the [Impact] section and then apt-get dist-
upgrade in order to get the latest lvm2.
[Other information]
This problem only exhibit in Bionic and Disco.
Xenial and Eoan and late didn't exhibit the situation.
[Touch-packages] [Bug 1854981] Re: system doesn't properly boot as expected if /usr is on its own LV
[VERIFICATION BIONIC]
I have installed Bionic, layout /usr on it's on LV, and at reboot same
problem as describe in the impact section. Server stuck in trying to
mount /usr due to lack of LVM activation.
At the initramfs prompt, I ran 'lvm vgchange -ay' to boot properly. I
installed the bionic-proposed package of lvm2[0], reboot the system and
everything boot fine. The udev rule fix does the work correctly.
[0] dpkg -l
ii liblvm2app2.2:amd64 2.02.176-4.1ubuntu3.18.04.2
amd64LVM2 application library
ii liblvm2cmd2.02:amd64 2.02.176-4.1ubuntu3.18.04.2
amd64LVM2 command library
ii lvm2 2.02.176-4.1ubuntu3.18.04.2
amd64Linux Logical Volume Manage
** Tags removed: verification-needed-bionic
** Tags added: verification-done-bionic
--
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:
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:
Fix Released
Status in initramfs-tools source package in Bionic:
Won't Fix
Status in lvm2 source package in Bionic:
Fix Committed
Status in initramfs-tools source package in Disco:
Won't Fix
Status in lvm2 source package in Disco:
Fix Committed
Bug description:
[Impact]
In summary, the problem is a LVM 'auto-activation' issue. Basically the LVM
activation doesn't occurs during the boot process (except for LVM root
partition) and since /usr is an important component before the 'pivot'[0], the
init inside the initramfs space tries to mount /usr. If /usr is a LVM volume
then it will try to mount it while its backend device is not activated yet (due
to the actual auto-activation issue), thus the mounting will fails and bring
the user to the initramfs prompt for debugging.
Workaround:
At the initramfs prompt: lvm vgchange -ay and then 'ctrl-d' to resume the
boot process.
[Test Case]
- Install Bionic or Disco
- Create a VG with /usr on its on LV
- Complete the installation
- At reboot the system will be stuck at mounting /usr file system
Extra notes:
Since this problem is ONLY related to LVM activation. If one create a non-LVM
/usr separate partition, everything will work as expected.
Other separate LVM (e.g. /home, /var/, /srv) if on its own separate
LVM volume will not be activate either, but since they don't need to
be mounted in the initramfs space, it's not a problem, they can be
activated later on (after the pivot) by systemd.
So the only combination possible is when /usr is on its separate LV
only.
[Regression potential]
I don't foresee any regression, the fix will instruct udev rule to
pvscan activate volume based on their major/minor number if LVM is
scanned.
+RUN+="(LVM_EXEC)/lvm pvscan --cache --activate ay --major $major
--minor $minor", ENV{LVM_SCANNED}="1"
The current situation doesn't auto-activate at all.
One downside, for users who will see this fixed, will still experience
the situation in standard ISO, since I'm afraid Disco won't produces
new ISO. (it is not recommended to do new disco installs anyway since
it's going EOL shortly) One would need to rely on the mini.iso for
fetching the latest lvm2 package in the archive.
IIRC Bionic will have a new point release somewhere in Feb 2020 but
until then one would need to rely on the mini.iso for fetching the
latest lvm2 package in the archive as well.
or use the workaround in the [Impact] section and then apt-get dist-
upgrade in order to get the latest lvm2.
[Other information]
This problem only exhibit in Bionic and Disco.
Xenial and Eoan and late didn't exhibit the situation.
https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/
https://wiki.debian.org/UsrMerge
[Original 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
[Touch-packages] [Bug 1854981] Re: system doesn't properly boot as expected if /usr is on its own LV
** Description changed:
[Impact]
In summary, the problem is a LVM 'auto-activation' issue. Basically the LVM
activation doesn't occurs during the boot process (except for LVM root
partition) and since /usr is an important component before the 'pivot'[0], the
init inside the initramfs space tries to mount /usr. If /usr is a LVM volume
then it will try to mount it while its backend device is not activated yet (due
to the actual auto-activation issue), thus the mounting will fails and bring
the user to the initramfs prompt for debugging.
Workaround:
At the initramfs prompt: lvm vgchange -ay and then 'ctrl-d' to resume the
boot process.
[Test Case]
- Install Bionic or Disco
- Create a VG with /usr on its on LV
- Complete the installation
- At reboot the system will be stuck at mounting /usr file system
Extra notes:
Since this problem is ONLY related to LVM activation. If one create a non-LVM
/usr separate partition, everything will work as expected.
Other separate LVM (e.g. /home, /var/, /srv) if on its own separate LVM
volume will not be activate either, but since they don't need to be
mounted in the initramfs space, it's not a problem, they can be
activated later on (after the pivot) by systemd.
So the only combination possible is when /usr is on its separate LV
only.
[Regression potential]
I don't foresee any regression, the fix will instruct udev rule to
pvscan activate volume based on their major/minor number if LVM is
scanned.
+RUN+="(LVM_EXEC)/lvm pvscan --cache --activate ay --major $major
--minor $minor", ENV{LVM_SCANNED}="1"
The current situation doesn't auto-activate at all.
- One downside, user will see this fixed, will still experience the
- situation in standard ISO, since I'm afraid there is no more point
- release for Bionic and Disco.
+ One downside, for users who will see this fixed, will still experience
+ the situation in standard ISO, since I'm afraid there is no more point
+ release for Disco. (it is not recommended to do new disco installs
+ anyway since it's going EOL shortly) One would need to rely on the
+ mini.iso for fetching the latest lvm2 package in the archive.
- So one would need to rely on the mini.iso for fetching the latest lvm2
- package in the archive.
+ IIRC Bionic will have a new point release somewhere in Feb 2020 but
+ until then one would need to rely on the mini.iso for fetching the
+ latest lvm2 package in the archive as well.
or use the workaround in the [Impact] section and then apt-get dist-
upgrade in order to get the latest lvm2.
[Other information]
This problem only exhibit in Bionic and Disco.
Xenial and Eoan and late didn't exhibit the situation.
https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/
https://wiki.debian.org/UsrMerge
[Original 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
[Touch-packages] [Bug 1854981] Re: system doesn't properly boot as expected if /usr is on its own LV
Hello Eric, or anyone else affected,
Accepted lvm2 into disco-proposed. The package will build now and be
available at
https://launchpad.net/ubuntu/+source/lvm2/2.02.176-4.1ubuntu4.2 in a few
hours, and then in the -proposed repository.
Please help us by testing this new package. See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed. Your feedback will aid us getting this
update out to other Ubuntu users.
If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested and change the tag from
verification-needed-disco to verification-done-disco. If it does not fix
the bug for you, please add a comment stating that, and change the tag
to verification-failed-disco. In either case, without details of your
testing we will not be able to proceed.
Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in
advance for helping!
N.B. The updated package will be released to -updates after the bug(s)
fixed by this package have been verified and the package has been in
-proposed for a minimum of 7 days.
** Changed in: lvm2 (Ubuntu Disco)
Status: In Progress => Fix Committed
** Tags added: verification-needed verification-needed-disco
** Changed in: lvm2 (Ubuntu Bionic)
Status: In Progress => Fix Committed
** Tags added: verification-needed-bionic
--
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:
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:
Fix Released
Status in initramfs-tools source package in Bionic:
Won't Fix
Status in lvm2 source package in Bionic:
Fix Committed
Status in initramfs-tools source package in Disco:
Won't Fix
Status in lvm2 source package in Disco:
Fix Committed
Bug description:
[Impact]
In summary, the problem is a LVM 'auto-activation' issue. Basically the LVM
activation doesn't occurs during the boot process (except for LVM root
partition) and since /usr is an important component before the 'pivot'[0], the
init inside the initramfs space tries to mount /usr. If /usr is a LVM volume
then it will try to mount it while its backend device is not activated yet (due
to the actual auto-activation issue), thus the mounting will fails and bring
the user to the initramfs prompt for debugging.
Workaround:
At the initramfs prompt: lvm vgchange -ay and then 'ctrl-d' to resume the
boot process.
[Test Case]
- Install Bionic or Disco
- Create a VG with /usr on its on LV
- Complete the installation
- At reboot the system will be stuck at mounting /usr file system
Extra notes:
Since this problem is ONLY related to LVM activation. If one create a non-LVM
/usr separate partition, everything will work as expected.
Other separate LVM (e.g. /home, /var/, /srv) if on its own separate
LVM volume will not be activate either, but since they don't need to
be mounted in the initramfs space, it's not a problem, they can be
activated later on (after the pivot) by systemd.
So the only combination possible is when /usr is on its separate LV
only.
[Regression potential]
I don't foresee any regression, the fix will instruct udev rule to
pvscan activate volume based on their major/minor number if LVM is
scanned.
+RUN+="(LVM_EXEC)/lvm pvscan --cache --activate ay --major $major
--minor $minor", ENV{LVM_SCANNED}="1"
The current situation doesn't auto-activate at all.
One downside, for users who will see this fixed, will still experience
the situation in standard ISO, since I'm afraid Disco won't produces
new ISO. (it is not recommended to do new disco installs anyway since
it's going EOL shortly) One would need to rely on the mini.iso for
fetching the latest lvm2 package in the archive.
IIRC Bionic will have a new point release somewhere in Feb 2020 but
until then one would need to rely on the mini.iso for fetching the
latest lvm2 package in the archive as well.
or use the workaround in the [Impact] section and then apt-get dist-
upgrade in order to get the latest lvm2.
[Other information]
This problem only exhibit in Bionic and Disco.
Xenial and Eoan and late didn't exhibit the situation.
https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/
https://wiki.debian.org/UsrMerge
[Original 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=...'
[Touch-packages] [Bug 1854981] Re: system doesn't properly boot as expected if /usr is on its own LV
** Changed in: lvm2 (Ubuntu Xenial)
Status: Won't Fix => Fix Released
--
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:
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:
Fix Released
Status in initramfs-tools source package in Bionic:
Won't Fix
Status in lvm2 source package in Bionic:
In Progress
Status in initramfs-tools source package in Disco:
Won't Fix
Status in lvm2 source package in Disco:
In Progress
Bug description:
[Impact]
In summary, the problem is a LVM 'auto-activation' issue. Basically the LVM
activation doesn't occurs during the boot process (except for LVM root
partition) and since /usr is an important component before the 'pivot'[0], the
init inside the initramfs space tries to mount /usr. If /usr is a LVM volume
then it will try to mount it while its backend device is not activated yet (due
to the actual auto-activation issue), thus the mounting will fails and bring
the user to the initramfs prompt for debugging.
Workaround:
At the initramfs prompt: lvm vgchange -ay and then 'ctrl-d' to resume the
boot process.
[Test Case]
- Install Bionic or Disco
- Create a VG with /usr on its on LV
- Complete the installation
- At reboot the system will be stuck at mounting /usr file system
Extra notes:
Since this problem is ONLY related to LVM activation. If one create a non-LVM
/usr separate partition, everything will work as expected.
Other separate LVM (e.g. /home, /var/, /srv) if on its own separate
LVM volume will not be activate either, but since they don't need to
be mounted in the initramfs space, it's not a problem, they can be
activated later on (after the pivot) by systemd.
So the only combination possible is when /usr is on its separate LV
only.
[Regression potential]
I don't foresee any regression, the fix will instruct udev rule to
pvscan activate volume based on their major/minor number if LVM is
scanned.
+RUN+="(LVM_EXEC)/lvm pvscan --cache --activate ay --major $major
--minor $minor", ENV{LVM_SCANNED}="1"
The current situation doesn't auto-activate at all.
One downside, user will see this fixed, will still experience the
situation in standard ISO, since I'm afraid there is no more point
release for Bionic and Disco.
So one would need to rely on the mini.iso for fetching the latest lvm2
package in the archive.
or use the workaround in the [Impact] section and then apt-get dist-
upgrade in order to get the latest lvm2.
[Other information]
This problem only exhibit in Bionic and Disco.
Xenial and Eoan and late didn't exhibit the situation.
https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/
https://wiki.debian.org/UsrMerge
[Original 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
[Touch-packages] [Bug 1854981] Re: system doesn't properly boot as expected if /usr is on its own LV
** Description changed:
[Impact]
In summary, the problem is a LVM 'auto-activation' issue. Basically the LVM
activation doesn't occurs during the boot process (except for LVM root
partition) and since /usr is an important component before the 'pivot'[0], the
init inside the initramfs space tries to mount /usr. If /usr is a LVM volume
then it will try to mount it while its backend device is not activated yet (due
to the actual auto-activation issue), thus the mounting will fails and bring
the user to the initramfs prompt for debugging.
Workaround:
At the initramfs prompt: lvm vgchange -ay and then 'ctrl-d' to resume the
boot process.
[Test Case]
- Install Bionic or Disco
- Create a VG with /usr on its on LV
- Complete the installation
- At reboot the system will be stuck at mounting /usr file system
Extra notes:
Since this problem is ONLY related to LVM activation. If one create a non-LVM
/usr separate partition, everything will work as expected.
Other separate LVM (e.g. /home, /var/, /srv) if on its own separate LVM
volume will not be activate either, but since they don't need to be
mounted in the initramfs space, it's not a problem, they can be
activated later on (after the pivot) by systemd.
So the only combination possible is when /usr is on its separate LV
only.
[Regression potential]
I don't foresee any regression, the fix will instruct udev rule to
pvscan activate volume based on their major/minor number if LVM is
scanned.
+RUN+="(LVM_EXEC)/lvm pvscan --cache --activate ay --major $major
--minor $minor", ENV{LVM_SCANNED}="1"
The current situation doesn't auto-activate at all.
One downside, user will see this fixed, will still experience the
situation in standard ISO, since I'm afraid there is no more point
release for Bionic and Disco.
So one would need to rely on the mini.iso for fetching the latest lvm2
package in the archive.
or use the workaround in the [Impact] section and then apt-get dist-
upgrade in order to get the latest lvm2.
[Other information]
This problem only exhibit in Bionic and Disco.
+ Xenial and Eoan and late didn't exhibit the situation.
https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/
https://wiki.debian.org/UsrMerge
[Original 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
[Touch-packages] [Bug 1854981] Re: system doesn't properly boot as expected if /usr is on its own LV
Uploaded in B/D. Waiting for SRU team verification team to approve and
allow packages to start building in -proposed.
- Eric
--
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:
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:
In Progress
Status in initramfs-tools source package in Disco:
Won't Fix
Status in lvm2 source package in Disco:
In Progress
Bug description:
[Impact]
In summary, the problem is a LVM 'auto-activation' issue. Basically the LVM
activation doesn't occurs during the boot process (except for LVM root
partition) and since /usr is an important component before the 'pivot'[0], the
init inside the initramfs space tries to mount /usr. If /usr is a LVM volume
then it will try to mount it while its backend device is not activated yet (due
to the actual auto-activation issue), thus the mounting will fails and bring
the user to the initramfs prompt for debugging.
Workaround:
At the initramfs prompt: lvm vgchange -ay and then 'ctrl-d' to resume the
boot process.
[Test Case]
- Install Bionic or Disco
- Create a VG with /usr on its on LV
- Complete the installation
- At reboot the system will be stuck at mounting /usr file system
Extra notes:
Since this problem is ONLY related to LVM activation. If one create a non-LVM
/usr separate partition, everything will work as expected.
Other separate LVM (e.g. /home, /var/, /srv) if on its own separate
LVM volume will not be activate either, but since they don't need to
be mounted in the initramfs space, it's not a problem, they can be
activated later on (after the pivot) by systemd.
So the only combination possible is when /usr is on its separate LV
only.
[Regression potential]
I don't foresee any regression, the fix will instruct udev rule to
pvscan activate volume based on their major/minor number if LVM is
scanned.
+RUN+="(LVM_EXEC)/lvm pvscan --cache --activate ay --major $major
--minor $minor", ENV{LVM_SCANNED}="1"
The current situation doesn't auto-activate at all.
One downside, user will see this fixed, will still experience the
situation in standard ISO, since I'm afraid there is no more point
release for Bionic and Disco.
So one would need to rely on the mini.iso for fetching the latest lvm2
package in the archive.
or use the workaround in the [Impact] section and then apt-get dist-
upgrade in order to get the latest lvm2.
[Other information]
This problem only exhibit in Bionic and Disco.
https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/
https://wiki.debian.org/UsrMerge
[Original 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
[Touch-packages] [Bug 1854981] Re: system doesn't properly boot as expected if /usr is on its own LV
** Changed in: lvm2 (Ubuntu Bionic)
Status: Confirmed => In Progress
** Changed in: lvm2 (Ubuntu Disco)
Status: Confirmed => In Progress
** Changed in: lvm2 (Ubuntu Disco)
Assignee: (unassigned) => Eric Desrochers (slashd)
** Changed in: lvm2 (Ubuntu Bionic)
Assignee: (unassigned) => Eric Desrochers (slashd)
--
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:
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:
In Progress
Status in initramfs-tools source package in Disco:
Won't Fix
Status in lvm2 source package in Disco:
In Progress
Bug description:
[Impact]
In summary, the problem is a LVM 'auto-activation' issue. Basically the LVM
activation doesn't occurs during the boot process (except for LVM root
partition) and since /usr is an important component before the 'pivot'[0], the
init inside the initramfs space tries to mount /usr. If /usr is a LVM volume
then it will try to mount it while its backend device is not activated yet (due
to the actual auto-activation issue), thus the mounting will fails and bring
the user to the initramfs prompt for debugging.
Workaround:
At the initramfs prompt: lvm vgchange -ay and then 'ctrl-d' to resume the
boot process.
[Test Case]
- Install Bionic or Disco
- Create a VG with /usr on its on LV
- Complete the installation
- At reboot the system will be stuck at mounting /usr file system
Extra notes:
Since this problem is ONLY related to LVM activation. If one create a non-LVM
/usr separate partition, everything will work as expected.
Other separate LVM (e.g. /home, /var/, /srv) if on its own separate
LVM volume will not be activate either, but since they don't need to
be mounted in the initramfs space, it's not a problem, they can be
activated later on (after the pivot) by systemd.
So the only combination possible is when /usr is on its separate LV
only.
[Regression potential]
I don't foresee any regression, the fix will instruct udev rule to
pvscan activate volume based on their major/minor number if LVM is
scanned.
+RUN+="(LVM_EXEC)/lvm pvscan --cache --activate ay --major $major
--minor $minor", ENV{LVM_SCANNED}="1"
The current situation doesn't auto-activate at all.
One downside, user will see this fixed, will still experience the
situation in standard ISO, since I'm afraid there is no more point
release for Bionic and Disco.
So one would need to rely on the mini.iso for fetching the latest lvm2
package in the archive.
or use the workaround in the [Impact] section and then apt-get dist-
upgrade in order to get the latest lvm2.
[Other information]
This problem only exhibit in Bionic and Disco.
https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/
https://wiki.debian.org/UsrMerge
[Original 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
[Touch-packages] [Bug 1854981] Re: system doesn't properly boot as expected if /usr is on its own LV
** Description changed:
+ ## DRAFT in progress ##
+
+ [Impact]
+ In summary, the problem is a LVM 'auto-activation' issue. Basically the LVM
activation doesn't occurs during the boot process (except for LVM root
partition) and since /usr is an important component before the 'pivot'[0], the
init inside the initramfs space tries to mount /usr. If /usr is a LVM volume
then it will try to mount it while its backend device is not activated yet (due
to the actual auto-activation issue), thus the mounting will fails and bring
the user to the initramfs prompt for debugging.
+
+ Workaround:
+ At the initramfs prompt: lvm vgchange -ay and then 'ctrl-d' to resume the
boot process.
+
+ [Test Case]
+
+ - Install Bionic or Disco
+ - Create a VG with /usr on its on LV
+ - Complete the installation
+ - At reboot the system will be stuck at mounting /usr file system
+
+ Extra notes:
+ Since this problem is ONLY related to LVM activation. If one create a non-LVM
/usr separate partition, everything will work as expected.
+
+
+ Other separate LVM (e.g. /home, /var/, /srv) if on its own separate LVM
volume will not be activate either, but since they don't need to be mounted in
the initramfs space, it's not a problem, they can be activated later on (after
the pivot) by systemd.
+
+ So the only combination possible is when /usr is on its separate LV
+ only.
+
+ [Regression potential]
+
+ I don't foresee any regression, the fix will instruct udev rule to
+ pvscan activate volume based on their major/minor number if LVM is
+ scanned.
+
+ +RUN+="(LVM_EXEC)/lvm pvscan --cache --activate ay --major $major
+ --minor $minor", ENV{LVM_SCANNED}="1"
+
+ The current situation doesn't auto-activate at all.
+
+ One downside, user will see this fixed, will still experience the
+ situation in standard ISO, since I'm afraid there is no more point
+ release for Bionic and Disco.
+
+ So one would need to rely on the mini.iso for fetching the latest lvm2
+ package in the archive.
+
+ or use the workaround in the [Impact] section and then apt-get dist-upgrade
in order to get the latest lvm2.
+
+
+ [Original 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
[Touch-packages] [Bug 1854981] Re: system doesn't properly boot as expected if /usr is on its own LV
** Changed in: lvm2 (Ubuntu Xenial)
Status: New => Won't Fix
--
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:
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
--
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
[Touch-packages] [Bug 1854981] Re: system doesn't properly boot as expected if /usr is on its own LV
** Also affects: lvm2 (Ubuntu Bionic)
Importance: Undecided
Status: New
** Also affects: initramfs-tools (Ubuntu Bionic)
Importance: Undecided
Status: New
** Also affects: lvm2 (Ubuntu Disco)
Importance: Undecided
Status: New
** Also affects: initramfs-tools (Ubuntu Disco)
Importance: Undecided
Status: New
** Also affects: lvm2 (Ubuntu Xenial)
Importance: Undecided
Status: New
** Also affects: initramfs-tools (Ubuntu Xenial)
Importance: Undecided
Status: New
** Changed in: initramfs-tools (Ubuntu Disco)
Status: New => Won't Fix
** Changed in: initramfs-tools (Ubuntu Bionic)
Status: New => Won't Fix
** Changed in: initramfs-tools (Ubuntu Xenial)
Status: New => Won't Fix
** Changed in: initramfs-tools (Ubuntu)
Status: New => Won't Fix
** Changed in: lvm2 (Ubuntu)
Status: New => Fix Released
** Changed in: lvm2 (Ubuntu Disco)
Status: New => Confirmed
** Changed in: lvm2 (Ubuntu Bionic)
Status: New => Confirmed
** Changed in: lvm2 (Ubuntu Bionic)
Importance: Undecided => Medium
** Changed in: lvm2 (Ubuntu Disco)
Importance: Undecided => Medium
** Changed in: lvm2 (Ubuntu)
Importance: High => Undecided
--
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:
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 ->
[Touch-packages] [Bug 1854981] Re: system doesn't properly boot as expected if /usr is on its own LV
The problem seems to come from "/udev/69-dm-lvm-metad.rules.in".
Still investigating, stay tuned.
--
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 (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
--
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
[Touch-packages] [Bug 1854981] Re: system doesn't properly boot as expected if /usr is on its own LV
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
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
Date: Thu Nov 29 23:08:05 2018 +0100
make: generate config update
conf/example.conf.in:
- # Configuration option global/use_lvmetad.
- # This setting is no longer used.
- use_lvmetad = 0
+ # 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
- # Configuration option global/lvmetad_update_wait_time.
- # This setting is no longer used.
--
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
[Touch-packages] [Bug 1854981] Re: system doesn't properly boot as expected if /usr is on its own LV
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
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
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
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 (I haven't check but I
guess systemd or
[Touch-packages] [Bug 1854981] Re: system doesn't properly boot as expected if /usr is on its own LV
** Description changed:
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 user merge approach, one can install package 'usrmerge' and
+ make 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.
** Description changed:
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
[Touch-packages] [Bug 1854981] Re: system doesn't properly boot as expected if /usr is on its own LV
** Description changed:
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:
+ 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.
--
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
+
[Touch-packages] [Bug 1854981] Re: system doesn't properly boot as expected if /usr is on its own LV
** Changed in: lvm2 (Ubuntu)
Importance: Undecided => High
** Changed in: initramfs-tools (Ubuntu)
Importance: Undecided => High
** Description changed:
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.
+ 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
- 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.
+
+ * 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.
--
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
[Touch-packages] [Bug 1854981] Re: system doesn't properly boot as expected if /usr is on its own LV
** 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
[Touch-packages] [Bug 1854981] Re: system doesn't properly boot as expected if /usr is on its own LV
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
[Touch-packages] [Bug 1854981] Re: system doesn't properly boot as expected if /usr is on its own LV
For context about the /usr merge:
https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/
https://wiki.debian.org/UsrMerge
--
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
