Bug 28835

Summary: drakboot crashed when using MCC to configure the bootloader to be able to select a different kernel at boot
Product: Mageia Reporter: Rob Teng <r.teng>
Component: RPM PackagesAssignee: Mageia Bug Squad <bugsquad>
Status: RESOLVED INVALID QA Contact:
Severity: normal    
Priority: Normal CC: mageia, ouaurelien
Version: 8   
Target Milestone: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Source RPM: drakxtools-18.45-1.mga8 CVE:
Status comment:

Description Rob Teng 2021-04-24 11:26:57 CEST
The "drakboot" program crashed. Drakbug-18.45 caught it.

I was using the MCC Boot setup to be able to select another than the default kernel at boot time, since after updating to Mageia 8 I'm having trouble with 
sleep/S3 which crashes every second or third time, requiring a hard reset to get the system up again. My system is fully up to date right now.

The boot loader still mentions Mageia 6 on the EFI front page (not sure if it will live / work after this drakboot crash though, fingers crossed), 
and upon choosing "advanced" it mentions Mageia 7.
In the Mageia 7 sub menu, it has all kinds of older kernels on the list, which are no longer installed. 
I think I didn't see any of the currently installed kernels, but the default works.

grub2-install failed: Installing for x86_64-efi platform.
grub2-install: error: cannot find EFI directory.
	...propagated at /usr/lib/libDrakX/any.pm line 278.
	...propagated at /usr/libexec/drakboot line 49.
Perl's trace:
drakbug::bug_handler() called from /usr/libexec/drakboot:49

Theme name: Adwaita
Kernel version = 5.10.30-desktop-1.mga8
Distribution=Mageia release 8 (Official) for x86_64
CPU=AMD A10-7800 Radeon R7, 12 Compute Cores 4C+8G
Comment 1 Rob Teng 2021-04-24 11:36:19 CEST
I'm being silly, I haven't had to mess with linux / Mageia internals for such a long time, and forgot how things went. I used MCC/Diskdrake to mount the EFI partition, and reran the bootloader setup. This time, it didn't throw any error. I also didn't see any dangerous output on the Konsole from where I started MCC.
Fingers crossed!

I do think that the system should have been smart enough to find and mount that EFI partition, so in that sense this bug is real.
Comment 2 Aurelien Oudelet 2021-04-24 11:47:49 CEST
(In reply to Rob Teng from comment #1)
> I'm being silly, I haven't had to mess with linux / Mageia internals for

> I do think that the system should have been smart enough to find and mount
> that EFI partition, so in that sense this bug is real.

Humans can do silly things ;)


On new installations, the EFI partition is ALWAYS mounted on /boot/EFI and a symlink /boot/efi should point to /boot/EFI

So, check that your EFI System partition is listed in /etc/fstab ?

CC: (none) => ouaurelien

Comment 3 Rob Teng 2021-04-27 08:25:35 CEST
My fstab has this:

# Entry for /dev/sda2 :
UUID=3B49-0320 /boot/EFI vfat umask=000,noauto,iocharset=utf8 0 0

So due to the noauto, it had to be actively mounted. I don't know if that is a remains of Mageia 6 or if I did it myself on purpose. In the latter case, as you said, humans can do silly things...
Comment 4 Aurelien Oudelet 2021-04-27 09:21:19 CEST
(In reply to Rob Teng from comment #3)
> My fstab has this:
> 
> # Entry for /dev/sda2 :
> UUID=3B49-0320 /boot/EFI vfat umask=000,noauto,iocharset=utf8 0 0
> 
> So due to the noauto, it had to be actively mounted. I don't know if that is
> a remains of Mageia 6 or if I did it myself on purpose. In the latter case,
> as you said, humans can do silly things...

Adding Martin for advice. I don't remember if Mageia 6 installer did this or not.
But Mageia 7 and 8 do not add "noauto" mount option.
So, no, please remove it.

CC: (none) => mageia

Comment 5 Martin Whitaker 2021-04-28 00:20:26 CEST
My advice is always to use rEFInd, not GRUB ;-)

But more seriously, looking at the drakx history, adding noauto was bug 15627, which was fixed before Mageia 5 was released. So if this system was installed from a beta release of Mageia 5, that would account for it.
Comment 6 Rob Teng 2021-04-29 16:08:18 CEST
Two things: it may well be from the Mageia 5 days.
I do remember the "noauto" catching my eye, but from a security standpoint, I thought that was actually fine.

Second thing: booting works. 
So that is fine, which also means this report can soon be closed.
There will be a new one, because I didn't want to (re-)boot, just wake-up from S3/sleep/Suspend-to-RAM, but Plasma, and then some, crashed. Strangely, keyboard num-lock and caps-lock didn't respond anymore, but the mouse still worked and I could even ssh into the machine. I'll need some time to check the logs.
To be continued elsewhere...
Comment 7 Aurelien Oudelet 2021-04-30 10:14:56 CEST
(In reply to Martin Whitaker from comment #5)
> My advice is always to use rEFInd, not GRUB ;-)
> 
> But more seriously, looking at the drakx history, adding noauto was bug
> 15627, which was fixed before Mageia 5 was released. So if this system was
> installed from a beta release of Mageia 5, that would account for it.

(In reply to Rob Teng from comment #6)
> Two things: it may well be from the Mageia 5 days.
> I do remember the "noauto" catching my eye, but from a security standpoint,
> I thought that was actually fine.
> 
> Second thing: booting works. 
> So that is fine, which also means this report can soon be closed.
> There will be a new one, because I didn't want to (re-)boot, just wake-up
> from S3/sleep/Suspend-to-RAM, but Plasma, and then some, crashed. Strangely,
> keyboard num-lock and caps-lock didn't respond anymore, but the mouse still
> worked and I could even ssh into the machine. I'll need some time to check
> the logs.
> To be continued elsewhere...

'noauto' should be removed from your /etc/fstab ESP line.

Closing.

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