Created attachment 11084 [details]
Screenshot of the logging terminal (ctrl-alt-Fsomething)

Created attachment 11085 [details]
Output of journalctl -xb  compressed tar.gz

Created attachment 11086 [details]
Output of lspci -v

Created attachment 11087 [details]
/root/drakx/install compressed tar.gz

Created attachment 11088 [details]
/root/drakx/ddebug compressed tar.gz

Created attachment 11089 [details]
/root/drakx/report.bug.xz

(and yes it was a few days ago; I did not have time to report until now)

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

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

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.

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

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.

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.

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.

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

As it is important, calling more devs

CC: (none) => mageia, rverschelde

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.

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

(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.

Fixed on isos or to be put in errata?

That we'll know when someone tests it...

I was waiting for some message to follow "I'll complete the transition."...

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.

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.

OK. So on upgrading a system using LVM from mga6,
udisks need be uninstalled manually.

Keywords: (none) => FOR_ERRATA7

https://wiki.mageia.org/en/Mageia_7_Errata#LVM_and.2For_LUKS_with_old_udisks

Version: Cauldron => 7
Keywords: FOR_ERRATA7 => IN_ERRATA7
Priority: release_blocker => High

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

perl-Hal-Cdroms has been ported to udisks2 and I have just obsoleted udisks in cauldron.

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
Status: NEW => RESOLVED