Bug 25162

Changing Component to "RPM Packages", because the Installer component is meant for drakx-installer-stage2 bugs ;-)

I'm not sure this is a kernel bug, assigning to the kernel maintainers, but CC'ing barjac

Btw, Jim, did you maybe install the bootloader from a different Mageia install than from the one you were using when updating that kernel?

Component: Installer => RPM Packages
Source RPM: kernel-desktopop-5.1.18-1.mga7-1-1.mga7 => kernel-desktop-5.1.18-1.mga7-1-1.mga7
Summary: ((Installer)) Cannot find a bootloader installed. Only taking care of initrd. => kernel update: Cannot find a bootloader installed. Only taking care of initrd.
CC: (none) => marja11, zen25000

In the other bug you told that drakboot crashed because of missing /boot/EFI

So is /boot/EFI not mounted ?

That would explain this "no bootloader installed"

CC: (none) => tmb

See also: https://bugs.mageia.org/show_bug.cgi?id=25163

I have been pre-empted by Marja & Thomas (thanks)!
I had some basic questions:
- Was the urpmi command to upgrade an M6 system to M7, or just update an M7 system?
- What kernel did it leave you with, and did that boot OK?
- Why the following rpm -i command? Just to get the -devel- version of the kernel, which should have already been at 5.1.18?

CC: (none) => lewyssmith

As a brief history to my problem, I had Mageia 6 installed
and working fine on a first SSDD.  EFI/grub2/gpt. 
Due to many problems trying to dual-boot with Windows 10,
I eventually installed VirtualBox and installed Win10
there, but effects of trying to install Win10 on the first
SSDD may have remained.

For Mageia 7, I chose to install it fresh on a second 
SSDD from a DVD, and that worked.  I could boot into the
5.1.14-desktop kernel or into Mageia 6 that grub2 had found
on the first SSDD.  

I updated to the 5.1.18-desktop, and when I rebooted there
was no indication the 5.1.18 kernel was available.  I could
boot to the 5.1.14 kernel.  I ran and reran update-grub2,
reinstalled the 5.1.18 kernel (--force --replacepkgs
--replacefiles) and eventually tried to recreate the bootloader 
using mcc.  That failed, and in the wake of that I filed
my bug report.


To deal  first with Thomas Backlund's on EFI mounted,

I could boot into 5.1.18 by selecting 5.1.14 and immediately
hitting e for edit, and then changing the 14 to 18 in two places.
After booting into 5.1.18, /boot/EFI was not mounted.  I went 
into mcc and mounted /dev/sda1 on /boot/EFI.  mcc says,

Mount point: /boot/EFI
Device: sda1
Volume label: EFI
UUID: 1D8A-EBD3
Type: vfat (0xba)
Start: sector 4096
Size: 500MB (0% of disk), 1024000 sectors
Cylinder 0 to 63
Formatted
Mounted

but when I clicked on View I got an Error message Failed to
mount partition.  ls -laR /boot/EFI yielded nothing but the 
directory name EFI.  Using mcc I again mounted /dev/sda1 on
/boot/EFI, and quit mcc.  Mcc asked if I wanted to save 
changes and I said yes.  I reloaded mcc, and clicked on View,
but it could not be opened.  ls -laR /boot/EFI however yielded:

[jim@sorrel ~]$ ls -l /boot/EFI
total 16
drwxr-xr-x 2 root root 4096 Oct 24  2016 '$RECYCLE.BIN'/
drwxr-xr-x 3 root root 4096 Oct 28  2016  EFI/
drwxr-xr-x 3 root root 4096 Nov  1  2016  Recovery/
-rwxr-xr-x 1 root root    0 Nov  1  2016  Recovery.txt*
drwxr-xr-x 2 root root 4096 Oct 31  2016 'System Volume Information'/
[jim@sorrel ~]$ cd /boot/EFI
[jim@sorrel EFI]$ ls -l
total 16
drwxr-xr-x 2 root root 4096 Oct 24  2016 '$RECYCLE.BIN'/
drwxr-xr-x 3 root root 4096 Oct 28  2016  EFI/
drwxr-xr-x 3 root root 4096 Nov  1  2016  Recovery/
-rwxr-xr-x 1 root root    0 Nov  1  2016  Recovery.txt*
drwxr-xr-x 2 root root 4096 Oct 31  2016 'System Volume Information'/
[jim@sorrel EFI]$ ls -l EFI
total 4
drwxr-xr-x 2 root root 4096 Oct 28  2016 mageia/
[jim@sorrel EFI]$ ls -laR /boot/EFI
/boot/EFI:
total 24
drwxr-xr-x 6 root root 4096 Dec 31  1969  ./
drwxr-xr-x 5 root root 4096 Jul 20 22:37  ../
drwxr-xr-x 2 root root 4096 Oct 24  2016 '$RECYCLE.BIN'/
drwxr-xr-x 3 root root 4096 Oct 28  2016  EFI/
drwxr-xr-x 3 root root 4096 Nov  1  2016  Recovery/
-rwxr-xr-x 1 root root    0 Nov  1  2016  Recovery.txt*
drwxr-xr-x 2 root root 4096 Oct 31  2016 'System Volume Information'/
'/boot/EFI/$RECYCLE.BIN':
total 12
drwxr-xr-x 2 root root 4096 Oct 24  2016 ./
drwxr-xr-x 6 root root 4096 Dec 31  1969 ../
-rwxr-xr-x 1 root root  129 Oct 24  2016 desktop.ini*
/boot/EFI/EFI:
total 12
drwxr-xr-x 3 root root 4096 Oct 28  2016 ./
drwxr-xr-x 6 root root 4096 Dec 31  1969 ../
drwxr-xr-x 2 root root 4096 Oct 28  2016 mageia/
/boot/EFI/EFI/mageia:
total 132
drwxr-xr-x 2 root root   4096 Oct 28  2016 ./
drwxr-xr-x 3 root root   4096 Oct 28  2016 ../
-rwxr-xr-x 1 root root 125440 Jul 23  2018 grubx64.efi*
/boot/EFI/Recovery:
total 12
drwxr-xr-x 3 root root 4096 Nov  1  2016 ./
drwxr-xr-x 6 root root 4096 Dec 31  1969 ../
drwxr-xr-x 2 root root 4096 Nov  1  2016 Logs/
/boot/EFI/Recovery/Logs:
total 12
drwxr-xr-x 2 root root 4096 Nov  1  2016  ./
drwxr-xr-x 3 root root 4096 Nov  1  2016  ../
-rwxr-xr-x 1 root root   72 Nov  1  2016 'BootUX (1).sqml'*
'/boot/EFI/System Volume Information':
total 12
drwxr-xr-x 2 root root 4096 Oct 31  2016 ./
drwxr-xr-x 6 root root 4096 Dec 31  1969 ../
-rwxr-xr-x 1 root root   76 Oct 24  2016 IndexerVolumeGuid*

Just minutes ago I tried rebooting with a mount entry in /etc/fstab:
UUID=1D8A-EBD3 /boot/EFI vfat defaults 0 0

A text screen came up saying it could not find 
/boot/grub2/themes/maggy/grub2-mageia-default.png
which was a pointer to ../grub2-mageia-default.png.
That file was there but had been changed to a dot file,
//boot/grub2/themes/maggy/.grub2-mageia-default.png
presumably by my attempt to set up a bootloader in 
text mode.

Text choices were offered for  Mageia and Mageia 6.
Mageia 7 was not offered, but when I clicked on Mageia
it offered me the Mageia 7 5.1.14 and 5.1.18 kernels.
I selected the latter and the system booted.

Mcc says /dev/sda1 the EFI partition is mounted, but
when I attempt to View it I get the Error message
Failed to mount partition.

Regarding the update-grub2:
[root@sorrel ~]# update-grub2
Generating grub configuration file ...
Found theme: /boot/grub2/themes/maggy/theme.txt
Found linux image: /boot/vmlinuz-5.1.18-desktop-1.mga7
Found initrd image: /boot/initrd-5.1.18-desktop-1.mga7.img
Found linux image: /boot/vmlinuz-5.1.14-desktop-1.mga7
Found initrd image: /boot/initrd-5.1.14-desktop-1.mga7.img
Found linux image: /boot/vmlinuz-desktop
Found initrd image: /boot/initrd-desktop.img
Jul 22 09:37:21 | DM multipath kernel driver not loaded
Found Mageia 6 (6) on /dev/sda2
done

I do not see how the 5.1.14 kernel should boot but the 5.1.18
kernel not be available.

As failure to find the correct files seems to be the problem,
a detailed description of my disks and partitions follows.

label EFI 500MB is the first partition on a 250GB SSD, followed by
label mageia6 39GB (system partition) and label mageia6home 73GB
(separate partition for my /home/jim == $HOME directory).  gparted 
shows these partitions also have Name efi, mageia5 and mageia5home,
and I think Mageia 5 was the first OS installed but it was wiped out
later (along with space where I attempted to instal Win10,
unsuccessfully).  There are unused 34GB and 73GB partitions on
this first SSD, that at one time were intended for cauldron.

See note on /dev/sda7 grub2 core.img below.

On a second 250GB SSD, the first partition is label mageia7 39GB and
the second label  mageia7home 73GB, with two unused partitions 39GB
and 81GB.  The system has two WD hard drives, one used for music,
genealogical files, and backup files, and the other unused, but 
I think these can be ignored.  gparted does not list Name for any of
these partitions.

All Linux partitions are gpt/ext4 and (with the exception of
/dev/sda7 created by the mageia7 install at some point) 
labeled before use. 

mcc says the 500MB EFI partition is vfat, and gparted says it is
fat32 /boot/EFI with label EFI, with Flags msftdata.  gparted
also found grub2 core.img 100.16 MiB on /dev/sda7 with Flags
bios_grub.  I have no idea whether this was created by installation
of mageia7 or by the recent update to a new kernel. Also, if my
reading of the gparted information is correct, the /dev/sda1 ==
efi == /boot/EFI == label EFI partition is currently mounted and 
is the only partition on the first SSD that is.  The /dev/sda7 ==
grub2 core.img Flags bios_grub (no Name or label) appears to be
physically within /dev/sda1 == efi == /boot/EFI == label EFI, 
which I think was marked as mounted all along.

This brings up the question of whether mounting EFI on 
/boot/EFI in /etc/hosts (done just a few minutes ago) and its 
normal mount mode as an EFI partition are in conflict or somehow 
mounted twice.  Rebooting is possible (though not working properly) 
so the EFI software is available.  Moreover, this had nothing 
to do with the original problem.

Please attach the report.bug.xz file found in /root/drakx in your Mageia 7 filesystem.

CC: (none) => mageia

The report.bug.xz has a date-time stamp of Oct 24  2016, from the time 
when this system was first set up.  I don't think you want this old one.
Only install.log1 shows a recent date-time.  Others are Nov 1 or Oct 24
2016, when Mageia was installed on /dev/sda2 and /dev/sda3, with the
EFI partition /dev/sda1.

(-rw-r--r-- 1 root root  138100 Jul  8 09:26 install.log1).

-rw-r--r-- 1 root root  156524 Oct 24  2016 report.bug.xz

Both of the above are in /root/drakx,  /dev/sdb1.

[root@sorrel drakx]# df -k /root/drakx
Filesystem     1K-blocks    Used Available Use% Mounted on
/dev/sdb1       40054040 8262940  29726716  22% /
[root@sorrel drakx]#

I thought you said you did a fresh install. That looks like an upgrade.

The date on your /boot/EFI/EFI/mageia/grubx64.efi indicates it wasn't created by the installer. The fact that you have a BIOS boot partition makes me suspect you booted the installer DVD in legacy mode, not UEFI mode.

What is the output of

  rpm -qa | grep grub

and

 cat /etc/fstab | grep EFI

when booted into your Mageia 7 system?

[jim@sorrel ~]$ rpm -qa |grep grub
grub2-2.02.0-15.mga7
grub2-efi-2.02.0-15.mga7
grub2-common-2.02.0-15.mga7
grub-doc-0.97-48.1.mga7
grub2-mageia-theme-2.02.0-15.mga7
[jim@sorrel ~]$ cat /etc/fstab |grep EFI
UUID=1D8A-EBD3 /boot/EFI vfat defaults,umask=000 0 0
[jim@sorrel ~]$

Do note that the EFI line from /etc/fstab did not exist until I created
it trying to see if that made a difference, as I described earlier.

WRT the date on grubx64.efi, that I think came from my forced reinstall of the new Mageia 7 kernel, 1.1.18.

It is located in the EFI partition that is the first partition on the first SSDD.  Mageia 6 is installed to the second and third partitions on that SSDD.
Mageia 7 is installed to the first and second partions on the second SSDD.

[jim@sorrel mageia]$ df -k .
Filesystem     1K-blocks  Used Available Use% Mounted on
/dev/sda1         510984   168    510816   1% /boot/EFI
[jim@sorrel mageia]$ pwd
/boot/EFI/EFI/mageia
[jim@sorrel mageia]$ ls -la
total 136
drwxrwxrwx 2 root root   4096 Oct 28  2016 ./
drwxrwxrwx 3 root root   4096 Oct 28  2016 ../
-rwxrwxrwx 1 root root 129024 Jul 22 11:45 grubx64.efi*
[jim@sorrel mageia]$

Had the DVD installed in legacy mode, it would have provided grub executables and files.

[jim@sorrel sbin]$ find /usr/bin -name grub\*
/usr/bin/grub2-mkrelpath
/usr/bin/grub2-mount
/usr/bin/grub2-editenv
/usr/bin/grub2-mklayout
/usr/bin/grub2-kbdcomp
/usr/bin/grub2-syslinux2cfg
/usr/bin/grub2-file
/usr/bin/grub2-mkimage
/usr/bin/grub2-mkfont
/usr/bin/grub2-render-label
/usr/bin/grub2-mkrescue
/usr/bin/grub2-mkpasswd-pbkdf2
/usr/bin/grub2-fstest
/usr/bin/grub2-script-check
/usr/bin/grub2-glue-efi
/usr/bin/grub2-mknetdir
/usr/bin/grub2-mkstandalone
/usr/bin/grub2-menulst2cfg

You have the grub2 package installed. That is only used for legacy (MBR) boot. You have since run drakboot, which is probably why you also have the grub2-efi package installed.

The date on your /boot/EFI/EFI/mageia/grubx64.efi file has changed since comment 4. That suggests you have successfully reinstalled it, now that you have /boot/EFI in your fstab.

[More expert people are looking at this.]

Jim
> I had Mageia 6 installed
> and working fine on a first SSDD.  EFI/grub2/gpt. 
> Due to many problems trying to dual-boot with Windows 10,
It is common to have problems sharing with Windows, but they can usually be overcome quite easily. See:
 https://wiki.mageia.org/en/About_EFI_UEFI

Mageia 7 offers rEFInd for booting, which offers its own boot menu of *what it finds* in the ESP and different disk partitions. It is well worth having.

Worth recapitulating the nub of your problem:
> For Mageia 7, I chose to install it fresh on a second 
> SSDD from a DVD, and that worked.  I could boot into the
> 5.1.14-desktop kernel or into Mageia 6 that grub2 had found
> on the first SSDD.  
> I updated to the 5.1.18-desktop, and when I rebooted there
> was no indication the 5.1.18 kernel was available.  I could
> boot to the 5.1.14 kernel."
To summarise your system, here are simpler methods:
 # gdisk -l /dev/sdx
 # fdisk -l /dev/sdx
where x is a, b etc (you have both); lists all the disc partitions.
 $ cat /etc/fstab
shows what partitions should be mounted at boot, & where.
 $ mount | grep /dev/sd
lists (omitting spurious enries) what actual partitions are mounted & where.
 $ ls -l /boot | grep 5.1.1
shows (omitting other things) what kernels, initrd etc you have, and what are the defaults (->) which should be the most recent. That would be interesting in your case where 18 seems to be ignored.

As far as the ESP is concerned, it should always be mounted on /boot/EFI. If it is not, that is important. Only /boot/EFI/EFI/ matters here:
 /boot/EFI/EFI:
 drwxr-xr-x 2 root root 4096 Oct 28  2016 mageia/
 /boot/EFI/EFI/mageia:
 -rwxr-xr-x 1 root root 125440 Jul 23  2018 grubx64.efi*

Assuming that the partition for /boot/EFI not in /etc/fstab and failure to mount it was the core of the problem, I first put
UUID=1D8A-EBD3 /boot/EFI vfat defaults,umask=000 0 0
in fstab.

With that mounted, I booted and found a way through the terminal text choices offered and found 5.1.18 as a choice.  I booted to that and then ran update-grub2 and dracut -f, and to top things off I moved 
/boot/grub2/themes/.grub2-mageia-default.png to 
/boot/grub2/themes/grub2-mageia-default.png.
I rebooted and then successfully set up my bootloader using mcc, choosing 
GRUB2 with text menu, and the boot options now appear in a gui (as before) that disappears when the machine boots to run level 3.

Not all is working as it should.  When I login, I get 7 lines of auth: messages about my login that I as a user should not see.  That I think is a different problem, though, so I shall halt for now.

Jim
Thank you for your patient experimenting.

It looks from comment 10 as if your system was somewhat mixed up between grub2 (MBR) and grub2-efi. One wonders whether if you made a clean start with Mageia 7, the box in native EFI and *not* compatability mode, these problem would not  arise. Normal default options for the disc partitioning with the ESP on the first disc (it being system-wide) should automatically mount that on /boot/EFI, and it would be in /etc/fstab. Bootloader installation grub2-efi with normal graphical menu should work, and include all installed systems - Windows included.
The fact that you had to add the ESP to /etc/fstab signaled something very wrong.

From comment 12, where you have arrived at a 'working' system, can we close this?
You can re-open it if from a clean native EFI install you hit the same problem; in this case, there were too many manipulations which clouded the issue.
 
> Not all is working as it should.  When I login, I get 7 lines of auth:
> messages about my login that I as a user should not see.  That I think is a
> different problem, though, so I shall halt for now.
Agree this is not normal, but the system is heavily tweaked. If this happens on a clean install, please do raise a bug for it.

I have no clear idea of what to do about the problem I had, but remain concerned.
At the time the new kernel 5.1.18 was installed, only three partitions were involved.  The EFI partition was on the first SSDD with Mageia 6, and / and /home for Mageia 7 were on a second SSDD that had been unused prior to install of Mageia 7.  The EFI partition obviously was accessible, as I was offered the option of the 5.1.14 kernel or Mageia 6 when rebooting.  I could, and did, choose the 5.1.14 kernel in some cases and the machine booted.
How that could be, and the bootloader not be found for the 5.1.18 kernel, I still do not understand.
In time, another kernel will be available, and I can reopen the bug if the problem recurs.
Or should I install the 5.1.18 server kernel and see what happens?
If you think the latter a good idea, please specify any special procedures you wish followed.

Do you have a spare (/) partition on the second SSD to *re-do* the Mageia 7 installation (hence a duplicate) with all other partitions being the same: /home, swap, ESP - the last two being detected & assigned automatically by the installer; choose graphical grub2 for bootloader, and check that the few EFI packages are installed - you see that happening.
This to test whether the ESP is correctly handled, grub2-efi used, and whether after reboot a system update not only pulls in the newer kernel, but shows it in the graphical boot menu.
If you can do this, do one step at a time. Comment 11 gives simple health checks you can do - plus perhaps the grub2 menu file, and the output of
 # ls -l /boot/EFI/EFI/mageia      [to check the EFI bootloader timestamp]
- after the [successful] post-install re-boot;
- then after updating the system [where things went wrong].
Just a thought.

I think I have found the root of the problem.  After backing up the system, I put the Mageia 7 install DVD in sr0, and normal boot options appeared.  I could not get the machine to read the DVD.

I went into the BIOS with F2 (Z170-E LGA 1151 ATX Intel Motherboard) and found the boot priority order had two entries for sr0:

P1: HL-DT-ST DVD RAM GH20NSCO (4241MB)
UEFI: HL-DT-ST DVD RAM GH20NSCO (4241MB)

The first entry was immediately visible in the BIOS boot sequence list, but the second did not appear until I used the down arrow key to find disks available but not appearing in the little window for the list.

It appears Mageia 7 had installed to the mbr.  In my second attempt to install Mageia 7, the bios went first to the DVD but (perhaps due to my tinkering) could not use it and continued on to the SSDD uefi boot, which worked.

When I changed the boot priority order in the BIOS, I could boot with the install dvd in sr0 and it offered me EFI install for Mageia 7.

I have run update-grub2 and dracut -f to incorporate the latest changes, and if all works I will assume this problem is solved.  No more news from me will be good news.

Apologies for my ignorance and the botched BIOS boot order settings.  I have not touched the BIOS since Mageia 6 was installed, so how it worked the past few years is beyond me, but one I am not competent to analyze.

Jim
Thank you for all your research. What you found is the sort of thing I suspected. EFI boxes are best treated as such, always; if they can work in MBR mode, mixing the two is not on. So you followed the true EFI path, with success.
Remember that it is only the most recently installed Mageia (or whatever) whose boot menu will be invoked from EFI booting - but show other installations.

You might one day try installing with rEFInd booting, which dispenses with Grub2.

> I have run update-grub2 and dracut -f to incorporate the latest changes
This I never understood. Any Linux installation with Grub2 will normally result in a boot menu showing all installed systems; and hence access to all of them. Running 'update-grub2' is superfluous - except on 'older' installations if you want them to include 'newer' ones in their boot menu.
Unsure also of the need for dracut, since any kernel installation or update automatically includes that (I think). In years of installing Mageias as part of QA, and updating these systems with new kernels, I have never touched dracut; and only used update-grub2 to bring back to life (from a different system) an unbootable one.

Closing this in the hope you will not need to re-open it.

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