Bug 28111

Summary:	install to eMMC device, bootup stalls due to incorrect partition information
Product:	Mageia	Reporter:	Ben McMonagle <westel>
Component:	Installer	Assignee:	Kernel and Drivers maintainers <kernel>
Status:	RESOLVED FIXED	QA Contact:
Severity:	normal
Priority:	Normal	CC:	davidwhodgins, mageia, thierry.vignaud
Version:	Cauldron
Target Milestone:	---
Hardware:	i586
OS:	Linux
Whiteboard:
Source RPM:		CVE:
Status comment:	fixed in git
Attachments:	install report journal of failed boot

Description Ben McMonagle 2021-01-16 05:00:12 CET

Description of problem: UEFI install of LXDE from 32 CI.iso onto existing partitions and rebooted. bootup stalled with a timeout for mounting partitions.
unit is dual boot with Windows 10


Version-Release number of selected component (if applicable):
ISO:  Mageia-8-rc-i586.iso
DATE: Wed 13 Jan 2021 11:27:14 PM CET

How reproducible:


Steps to Reproduce:
1.install a desktop from above .iso onto emmc device
2.reboot and wait for timeout
3.

Comment 1 Ben McMonagle 2021-01-16 05:03:55 CET

Created attachment 12219 [details]
install report

Comment 2 Ben McMonagle 2021-01-16 05:09:36 CET

Created attachment 12220 [details]
journal of failed boot

Comment 3 Ben McMonagle 2021-01-16 05:37:48 CET

oops

install was from :
ISO Name: Mageia-8-rc-x86_64
DATE.txt: Wed 13 Jan 2021 11:31:41 PM CET

Comment 4 Dave Hodgins 2021-01-16 10:21:19 CET

dev-mmcblk1p2.device: Job dev-mmcblk1p2.device/start timed out.

Either it's a hardware problem or a kernel problem.

CC: (none) => davidwhodgins
Assignee: bugsquad => kernel

Comment 5 Martin Whitaker 2021-01-18 20:59:11 CET

It's a random device enumeration problem. When the installer ran, the EMMC device was /dev/mmcblk1. When the boot failed. it was mmcblk2. As there's only one MMC device present, I don't know why that happens.

However, what I think's really wrong here is that the installer is writing device names into /etc/fstab instead of UUIDs. Does anyone know if there's a reason why MMC devices (and, looking on my system, NVME devices) are treated differently, or is it just that drakx hasn't caught up with the modern world?

For reference, the drakx function that decides whether to use a UUID instead of a device name is in devices.pm:

sub should_prefer_UUID {
    my ($dev) = @_;
    $dev =~ /^((?:[hsv]|xv)d)/;
}

CC: (none) => mageia, thierry.vignaud

Comment 6 Thomas Backlund 2021-01-18 21:46:50 CET

(In reply to Martin Whitaker from comment #5)
> It's a random device enumeration problem. When the installer ran, the EMMC
> device was /dev/mmcblk1. When the boot failed. it was mmcblk2. As there's
> only one MMC device present, I don't know why that happens.
> 
> However, what I think's really wrong here is that the installer is writing
> device names into /etc/fstab instead of UUIDs. Does anyone know if there's a
> reason why MMC devices (and, looking on my system, NVME devices) are treated
> differently, or is it just that drakx hasn't caught up with the modern world?
> 

I'd say it is this, and the lack of hw to test on...
 
> For reference, the drakx function that decides whether to use a UUID instead
> of a device name is in devices.pm:
> 
> sub should_prefer_UUID {
>     my ($dev) = @_;
>     $dev =~ /^((?:[hsv]|xv)d)/;
> }

That also misseas  nvme devices so we should extend it before RC is released so we can revert for final if the fallout is too big (or go for second RC)

Comment 7 Ben McMonagle 2021-01-18 21:50:32 CET

it appears that the issue is *more* prevalent for  me if I reuse the existing partitions and  format them.

If I remove the existing ext4 & swap partitions,  then auto allocate the new free space, the problem appears to be mitigated.

Comment 8 Martin Whitaker 2021-01-20 00:01:41 CET

I've modified the should_prefer_UUID() routine to include both mmcblk and nvme device and verified it works locally.

Status comment: (none) => fixed in git

Comment 9 Ben McMonagle 2021-02-21 03:20:05 CET

good for me

Status: NEW => RESOLVED
Resolution: (none) => FIXED