Description of problem: Gnome Live installation [direct from boot menu] ends with a screen about the [EFI] bootloader. Clicking 'finish' does so almost immediately, rather than the more usual 10m wait on my system. Re-booting either via the EFI boot menu 'mageia' entry (re NVRAM), or rEFInd 'mageia' entry (re the ESP) shows that the EFI bootloader was not installed. Cannot get into the installed system, but instead the most recent previously installed Mageia. Whether this is specific to the Gnome Live, or all Lives, I know not. If somebody else confirms the problem for a different Live, please edit the bug title to remove 'Gnome'. Version-Release number of selected component (if applicable): Re the Gnome Live 7beta1 ISO dated Sun Dec 2 23:21:13 CET 2018 How reproducible: I did it once only! You have to go through the entire installation to hit the problem. But I might do it all again to see whether it was spurious. Steps to Reproduce: 1. Install the system all the way. 2. Re-boot (via NVRAM or ESP) and see where you end up .
Hi Lewis, Please use a Live DVD in live mode to mount the root partition of the install that fails to boot. There's a directory with a very long hexadecimal name in /that/partition's/var/log/journal/ please run, as root, journalctl -D /path/into/that/hexadecimal/directory/ > journal.txt and then attach journal.txt to this bug report. (Compress the journal with "xz journal.txt" if it's too large to attach.)
Keywords: (none) => 7beta1, NEEDINFOAssignee: bugsquad => isobuildCC: (none) => marja11
Created attachment 10539 [details] File as requested in comment 1 In reply to previous comment. Thanks for the detailed instructions. I did not understand all you said about working from a Live ISO in Live mode. In this case, the ISO did *not* boot into Live mode; see the PAD. From another working system on the same box, I simply mounted the unbootable Gnome installation (partition 14) and got directly to the file you cited: # mount -t ext4 /dev/sda14 /mnt After poking around to see the lay of the land: # ls -l /mnt/var/log/journal/ drwxr-sr-x 2 root systemd-journal 4096 Dec 6 10:33 84820759a51844229dc3bca132cd2f99/ # journalctl -D /mnt/var/log/journal/ > /tmp/journal.txt # ls -l /tmp/journal.txt -rw-r--r-- 1 root root 574968 Rha 8 16:19 /tmp/journal.txt tmp]# xz journal.txt tmp]# ls -l -rw-r--r-- 1 root root 42536 Rha 8 16:19 journal.txt.xz # umount /mnt Hope this is what you wanted. I shall now try chrooting into it to see whether I can make it bootable!
Poking around the unbootable Gnome Live installation, I discover that it lacks the EFI boot tools. Only 'efibootmgr' is there. I cross-checked a few names that came to mind with a normal system. *Missing* were (at least), as shown by 'whereis' or 'ls' on the *valid* system, absent in the failed one: - grub: /usr/lib/grub /etc/grub.d /usr/share/grub - grub2-install: /usr/sbin/grub2-install /usr/share/man/man8/grub2-install.8.xz - update-grub: /usr/bin/update-grub - grub2: /usr/share/info/grub2.info.xz # ls /usr/lib/grub* x86_64-efi/ I think the efi packages installation was skipped.
Looking at the log, the installer has chosen to use rEFInd, not GRUB2. That shouldn't happen unless you specifically request it, so I'll have to look into that. Did you have rEFInd already installed in the ESP on that machine?
CC: (none) => mageia
(In reply to Martin Whitaker from comment #4) > Did you have rEFInd already installed in the ESP on that machine? Yes; but *very* old. I remember a question about it, but did not want the installer messing around with it, so said 'no' to installing it. I have messed around a lot with the baulked system, and am at last using it. Chroot'd into it, I installed 'grub2-common' and 'grub2-efi'. 'grub2-mageia' was not available, so the boot menu is scarcely legible character. I followed my own advice in https://wiki.mageia.org/en/About_EFI_UEFI section "Putting the two together" re 'grub2-install' & 'efibootmgr', but it is clearly iffy re the--bootloader-id, -L and -l (shown 'mageia') parameters. Wanting to call the system GNOME, I ended up with two identical VRAM entries (one now deleted) which worked from the EFI boot menu. But I think the system did not show in rEFInd despite: /boot/EFI/EFI/GNOME/grubx64.efi I must look into this: I know from experience that rEFInd finds whatever is in the ESP. I would not mind knowing how our installers go about it.
I did not say all above. After my efforts with 'grub2-install' & 'efibootmgr', it booted to the grub prompt. I then chroot'ed from another system, ran 'update-grub', and *that* eventually booted OK. PS I needed to mount the ESP for the grub installation to work.
(In reply to Lewis Smith from comment #5) > (In reply to Martin Whitaker from comment #4) > > Did you have rEFInd already installed in the ESP on that machine? > Yes; but *very* old. I remember a question about it, but did not want the > installer messing around with it, so said 'no' to installing it. At that point you had already passed the screen where you can choose which bootloader to use. If an existing rEFInd installation is detected, the default should have been not to reinstall it. IIRC, you never used the ability of rEFInd to boot Linux directly. If you choose rEFInd in drakboot, it assumes you do want to do that - if not, you should select GRUB2. BTW, one of the advantages of using rEFInd without GRUB2 is that it avoids the 10min delay. The intention is that during a clean install, the default selection is always GRUB2, but one of the fixes I made during testing got missed, so currently, if rEFInd is found in the ESP, it will be the default. This should be fixed when we next build ISOs. > I have messed around a lot with the baulked system, and am at last using it. > Chroot'd into it, I installed 'grub2-common' and 'grub2-efi'. 'grub2-mageia' > was not available, so the boot menu is scarcely legible character. The package you want is grub2-mageia-theme. That is in the local repo on the Live ISOs, so should have been available. You could have tried running drakboot in the chroot to change the bootloader. Although a bit painful to use, it should work in text mode.
Keywords: NEEDINFO => (none)Assignee: isobuild => mageia
(In reply to Martin Whitaker from comment #7) > At that point you had already passed the screen where you can choose which > bootloader to use. > If an existing rEFInd installation is detected, the default should have been > not to reinstall it. This is my first tangle with rEFInd on Mageia, so honestly I do not yet know how to choose & what to expect. What you say helps. This is a major new thingy. > IIRC, you never used the ability of rEFInd to boot Linux directly. If you > choose rEFInd in drakboot, it assumes you do want to do that - if not, you > should select GRUB2. True, I have no idea how this works: Linux 'stubs'?. If so, are these integral with the kernel, or put into the ESP? I assumed (perhaps wrongly) that rEFInd scans the ESP. If it indeed lists only what it actually finds in disc partitions, then the ESP becomes irrelevant for Grub2 booting. In fact I recently cleaned out my ESP of sub-directories for a few obsolete Linux's, although they *remain on disc*. My old version of rEFInd does not list them, so *is* tied to the ESP. > BTW, one of the advantages of using rEFInd without > GRUB2 is that it avoids the 10min delay. Interesting... > The package you want is grub2-mageia-theme. That is in the local repo on the > Live ISOs, so should have been available. Thanks. I had searched a working system for essential Grub2 thingies, did not unearth this one. Presumably if I install it, and update-grub, the menu will become graphical. But let sleeping dogs...
(In reply to Lewis Smith from comment #8) > This is my first tangle with rEFInd on Mageia, so honestly I do not yet know > how to choose & what to expect. What you say helps. This is a major new > thingy. Yes. I need to write something up on the Wiki, but so much to do, so little time... The Linux stub bootloader is integral to the kernel. If configured so (and by default it is), rEFInd will scan all partitions it can, looking for Linux kernels with the stub bootloader enabled, and present them in the boot menu. However, it can only do this if it has a driver for the filesystem - look in /boot/EFI/EFI/refind/drivers_x64 to see what you have installed. The only built-in driver is for FAT.
MGA7 beta 2.2 Gnome Live start February This installed (no reference to rEFInd, leaving Grub2 default) & re-booted without problems, so I am closing this bug. Thanks for improvement.
Resolution: (none) => FIXEDStatus: NEW => RESOLVED