Bug 24949 - LVM based install -> boot fail mounting home; enter shell mode where Ctrl-D boots it up OK
Summary: LVM based install -> boot fail mounting home; enter shell mode where Ctrl-D b...
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: 7
Hardware: All Linux
Priority: High critical
Target Milestone: ---
Assignee: Mageia tools maintainers
QA Contact:
Keywords: IN_ERRATA7
Depends on:
Reported: 2019-06-13 23:15 CEST by Morgan Leijström
Modified: 2020-09-20 09:45 CEST (History)
5 users (show)

See Also:
Source RPM:
Status comment:

Screenshot of the logging terminal (ctrl-alt-Fsomething) (120.99 KB, image/jpeg)
2019-06-13 23:23 CEST, Morgan Leijström
Output of journalctl -xb compressed tar.gz (35.11 KB, application/gzip)
2019-06-13 23:32 CEST, Morgan Leijström
Output of lspci -v (12.26 KB, text/plain)
2019-06-13 23:32 CEST, Morgan Leijström
/root/drakx/install compressed tar.gz (32.66 KB, application/gzip)
2019-06-13 23:33 CEST, Morgan Leijström
/root/drakx/ddebug compressed tar.gz (271.20 KB, application/gzip)
2019-06-13 23:34 CEST, Morgan Leijström
/root/drakx/report.bug.xz (181.59 KB, application/x-xz)
2019-06-13 23:36 CEST, Morgan Leijström

Description Morgan Leijström 2019-06-13 23:15:51 CEST
Version: Fresh install of 7RC1 classic 64 bit

Machine: on Thinkpad T400 with SSD.

Steps to reproduce:
Default install plasma except manual partitioning; one small unused partition marked as BIOS boot, as requested by installer, then a few LVM pv to build up one vg, and in that I created /, /home, swap.

Description of problem:
During boot it stops at the bubbling cauldron until it times out and drops to debug shell.

There Press control-D and it boots and works OK. (did not try hibernation)

How reproducible: Every boot

I will attach logs.
Comment 1 Morgan Leijström 2019-06-13 23:23:31 CEST
Created attachment 11084 [details]
Screenshot of the logging terminal (ctrl-alt-Fsomething)
Comment 2 Morgan Leijström 2019-06-13 23:32:03 CEST
Created attachment 11085 [details]
Output of journalctl -xb  compressed tar.gz
Comment 3 Morgan Leijström 2019-06-13 23:32:37 CEST
Created attachment 11086 [details]
Output of lspci -v
Comment 4 Morgan Leijström 2019-06-13 23:33:53 CEST
Created attachment 11087 [details]
/root/drakx/install compressed tar.gz
Comment 5 Morgan Leijström 2019-06-13 23:34:52 CEST
Created attachment 11088 [details]
/root/drakx/ddebug compressed tar.gz
Comment 6 Morgan Leijström 2019-06-13 23:36:22 CEST
Created attachment 11089 [details]
Comment 7 Morgan Leijström 2019-06-13 23:37:13 CEST
(and yes it was a few days ago; I did not have time to report until now)
Comment 8 Morgan Leijström 2019-06-13 23:47:19 CEST
Excerpt from boot log:

-- A start job for unit home.mount has finished with a failure.
-- The job identifier is 53 and the job result is dependency.
jun 10 02:22:10 KajsasMusikLaptop systemd[1]: Dependency failed for Local File Systems.
-- Subject: A start job for unit local-fs.target has failed
-- Defined-By: systemd

Hm, wonder if this deserves a release blocker status?

If not, then at least a note in errata.

tmb, i think systemd and LVM is your table?

CC: (none) => tmb

Morgan Leijström 2019-06-13 23:48:57 CEST

Summary: LVM based install -> boot fails with useless timeout; Ctrl-D and it boots up OK => LVM based install -> boot fail mounting home; enter shell mode where Ctrl-D boots it up OK

Comment 9 Dave Hodgins 2019-06-14 16:49:48 CEST
Been a while since I used lvm, but doesn't /boot have to be on a non lvm
partition so that the kernel and initrd can be read and the pv/lv then
activated? IIRC, I kept /boot on an ext4 partition. Note that /boot is not
the same as the bios boot partition. They are separate partitions.

CC: (none) => davidwhodgins

Comment 10 Morgan Leijström 2019-06-14 16:55:52 CEST
AFAIK it is supposed to work to boot on LVM since some years, as long as it is not encrypted.  And i have done that on mga6 or if it was 5.

And it seem to basically work in this case too, i think the boot process is just trying to do something in the wrong order, waiting for wrong name, or something like that.

Because when it times out I just hit Ctrl-D and it continue the boot successfully.
Comment 11 Dave Hodgins 2019-06-14 23:06:57 CEST
Just tested a mageia 7 install with encrypted / and no separate /boot, and
while the install appears to work on reboot it drops to a grub rescue prompt.

Adcording to https://wiki.mageia.org/en/Archive:Hard_disk_partioning_for_beginners
an unencrypted /boot is required.

From /usr/lib/libDrakX/fsedit.pm ...
    if ($mntpoint eq "/" && (isLUKS($part) || isRawLUKS($part)) && !fs::get::has_mntpoint("/boot", $all_hds)) {
        cdie N("You've selected an encrypted partition as root (/).
No bootloader is able to handle this without a /boot partition.
Please be sure to add a separate /boot partition");

So it is supposed to be ensuring a separate unencrypted /boot. The bug is that
diskdrake is failing to detect that there isn't one. If it is supposed to
be grub2 asking for the passphrase to decrypt the lvm physical volume, that
is failing.

Priority: Normal => release_blocker
Severity: major => critical
Assignee: bugsquad => mageiatools

Comment 12 Dave Hodgins 2019-06-15 01:55:49 CEST
Tried with an encrypted root (no separate /boot), not in lvm, and it does
display the error message from comment 11.

So it looks like the separate unencrypted /boot is needed, and this bug is
about diskdrake failing to prevent using an encrypted root (/) without a
separate /boot, when using lvm with the entire volume group encrypted.
Comment 13 Dave Hodgins 2019-06-15 02:08:57 CEST
It looks like an unencrypted /boot is still required. If grub2 is
capable of handling the situation where /boot is not separate, our
installer is not currently capable of setting it up properly.
Is the installer expected to setup grub2 to handle an encrypted /boot?
If not, I'll downgrade the priority of the bug, and add an item to
the errata, rather then hold up the release for this problem.
Comment 14 Morgan Leijström 2019-06-15 02:18:28 CEST
I think you should open a separate bug about the issue with encryption.

This bug per comment 0 is without any encryption; only LVM.
System is supposed to be able to boot with / in LVM without a separate /boot outside LVM.
It have worked before and it almost works now.
It is a regression.
Comment 15 PC LX 2019-06-15 13:24:51 CEST
It is possible to install and boot Mageia 6 with an encrypted /boot and / inside LVM.

My current workstation setup is as follows:
sda -> sda1 -> LUKS -> LVM -> LV/SWAP + LV/BTRFS

The BTRFS filesystem has both /, /boot, /usr, /home, etc. There are also sda[2,3,4], sdb, sdc, and more LVs but the above is what's relevant for Mageia 6 boot and system.

Thus if Mageia 7 does not allow a unencrypted /boot or /boot inside LVM, then there is a regression.

CC: (none) => mageia

Comment 16 Morgan Leijström 2019-06-16 15:21:33 CEST
As it is important, calling more devs

CC: (none) => mageia, rverschelde

Comment 17 Martin Whitaker 2019-06-16 18:53:27 CEST
I can work around this bug by commenting out the line

ENV{ID_FS_TYPE}=="LVM2_member", TEST=="/lib/udev/udisks-lvm-pv-export", IMPORT{program}="udisks-lvm-pv-export $env{ID_FS_UUID}"

in /usr/lib/udev/rules.d/80-udisks.rules, or by uninstalling the udisks package.

I don't know why we still install udisks - everything I read says it is obsolete and replaced by udisks2, which we also install.
Comment 18 Thomas Backlund 2019-06-17 18:11:55 CEST
It's perl-Hal-Cdroms that pulls in udisks, so I dropped that from meta-task

But I see draklive-install also has deps on it
Comment 19 Martin Whitaker 2019-06-17 19:56:29 CEST
(In reply to Thomas Backlund from comment #18)
> It's perl-Hal-Cdroms that pulls in udisks, so I dropped that from meta-task
> But I see draklive-install also has deps on it

I changed draklive-install to detect and use udisks2 if available a while ago. I'll complete the transition.
Comment 20 Morgan Leijström 2019-06-23 11:19:15 CEST
Fixed on isos or to be put in errata?
Comment 21 Thomas Backlund 2019-06-23 11:31:06 CEST
That we'll know when someone tests it...
Comment 22 Morgan Leijström 2019-06-23 11:45:26 CEST
I was waiting for some message to follow "I'll complete the transition."...
Comment 23 Morgan Leijström 2019-06-23 15:18:31 CEST
I confirm removing udisks fixes the problem on the same mga7 earlier in this thread which had the problem also after updates last hour.
And yes it pulls away perl-Hal-Cdroms with it.
Comment 24 Martin Whitaker 2019-06-23 22:13:20 CEST
Fixed on ISOs for new installs. For upgrades, users will need to remove udisks themselves (preferably before they upgrade) unless we can obsolete udisks.

I did look at trying to migrate perl-Hal-Cdroms to udisks2, but when I tried the example script that uses it (given by perldoc), it doesn't work even now, so porting it seems futile. As far as I can tell, it is there to automount CDROMs when urpmi tries to access them, but most DEs take care of that themselves.
Comment 25 Morgan Leijström 2019-06-23 22:19:32 CEST
OK. So on upgrading a system using LVM from mga6,
udisks need be uninstalled manually.

Keywords: (none) => FOR_ERRATA7

Comment 26 Morgan Leijström 2019-06-28 17:51:26 CEST

Version: Cauldron => 7
Priority: release_blocker => High

Comment 27 Aurelien Oudelet 2020-09-19 18:08:44 CEST
This is High priority bug for a good reason.

Making Mageia even better than ever is best direction.
In order to do right thing, this bug should be examined and fixed as soon as possible.

Packagers, please make the status to Assigned when you are working on this.
Feel free to reassign the bug if bad-triaged. Also, if bug is old, please close it.

On October 1st 2020, we will drop priority to normal.
Comment 28 Martin Whitaker 2020-09-20 00:39:29 CEST
perl-Hal-Cdroms has been ported to udisks2 and I have just obsoleted udisks in cauldron.
Comment 29 Martin Whitaker 2020-09-20 09:45:40 CEST
As we don't drop packages from stable releases, and it only affects upgrades from Mageia 6 (which most people should have done by now), and it's in the Mageia 7 errata, closing.

Resolution: (none) => FIXED

Note You need to log in before you can comment on or make changes to this bug.