Bug 28426

Please attach /root/drakx/report.bug.xz from the M8 root partition.

CC: (none) => mageia

Hi, thanks reporting this.

We are waiting for your /root/drakx/report.bug.xz file.

CC: (none) => ouaurelien
Keywords: (none) => NEEDINFO
Source RPM: (none) => drakx-installer-stage2-18.45-1.mga8

Created attachment 12389 [details]
bug.report.xz

Martin,
In install.sh, grub2-install has no target drive parameter which IIRC should be there in the case of legacy bios.

It's a while since I was regularly involved with grub2, but that's all I notice looking at the above report.

Barry

CC: (none) => zen25000

It's actually a UEFI BIOS, so the install.sh is correct. I can't spot anything obviously wrong in the installer logs.

Herman, if you can switch back to the M8 bootloader, boot into M8 and run

  grub2-editenv list

What does that show?

saved_entry=gnulinux-advanced-d4d0fdcc-db47-4921-b364-3a0e9ae106f1>gnulinux-5.10.16-desktop-1.mga8-advanced-d4d0fdcc-db47-4921-b364-3a0e9ae106f1
boot_success=0
This is the second boot after getting back in the status where there is no grub menu showing. Does that matter or did you want the really first one after enforcing this situation?

(In reply to Martin Whitaker from comment #5)
> It's actually a UEFI BIOS, so the install.sh is correct. I can't spot
> anything obviously wrong in the installer logs.

I was looking at line 3 of the original post.

@Herman, no, that shows what I wanted - even though it doesn't help. The grub.cfg file tests if boot_success = 1, and sets the boot timeout to 0 if so. I wondered if that was what you were seeing, but I guess not.

There were no changes to drakboot or grub2 between the 17-Feb and 22-Feb ISOs. The only change to the installer was in the artwork. So I really don't know what else to suggest here.

(if you just wanted a working system, I'd suggest using rEFInd instead of GRUB2, but that won't help explain what went wrong here)

@Barry on Comment 7
Sorry to have you put on the wrong foot: it is definitely a UEFI machine.

I tried to reproduce this on my Asus tablet, which has the same CPU as Herman's machine, but a different brand of 32-bit UEFI BIOS, but it did not show this fault.

Herman, do you still have the USB stick you used to do the install? If so, can we just confirm it's not a bad copy. To do that, as root

  dd if=/dev/sdX bs=1k count=4393770 | md5sum

substituting sdX with the actual device your USB stick appears as. The result should be

  ade337db66b90e5307fc8bc6bba4a3ca  -

# dd if=/dev/sde bs=1k count=4393770 | md5sum
4393770+0 records gelezen (read)
4393770+0 records geschreven (written)
4499220480 bytes (4,5 GB, 4,2 GiB) copied, 355,883 s, 12,6 MB/s
ade337db66b90e5307fc8bc6bba4a3ca  -

Hi Herman,
I would really recommend that you try https://wiki.mageia.org/en/User_talk:Barjac It takes only a few minutes to set up and has been in use here for over 5 years. Keeps all systems totally isolated.
Barry

UEFI system:
Is the NVRAM ticklish? Joking aside, this reminds me that Ubuntu and his flavors share the same "Ubuntu" directory for /boot/EFI/ubuntu and leads to one take precedence if you update on Kubuntu, and next time you update on Xubuntu... Sometimes you get Kubuntu loading, sometimes you get Xubuntu as default entry...

So, Mageia 7 and 8 share the same name "Mageia" in /boot/EFI/ directory... this can lead to on such issue. That is strange is that a M8 installation was already done according to

(In reply to Martin Whitaker from comment #8)
> @Herman, no, that shows what I wanted - even though it doesn't help. The
> grub.cfg file tests if boot_success = 1, and sets the boot timeout to 0 if
> so. I wondered if that was what you were seeing, but I guess not.
> 
> There were no changes to drakboot or grub2 between the 17-Feb and 22-Feb
> ISOs. The only change to the installer was in the artwork. So I really don't
> know what else to suggest here.
> 
> (if you just wanted a working system, I'd suggest using rEFInd instead of
> GRUB2, but that won't help explain what went wrong here)

Better to use rEFInd in this case...

Source RPM: drakx-installer-stage2-18.45-1.mga8 => drakx-installer-stage2-18.45-1.mga8.src.rpm
Keywords: NEEDINFO => (none)

It is nice to see BarryJ here. That script is a tour de force.

But Herman's problem...
> Installation seems to work OK. Rebooting does not show the grub menu
> but boots directly to the M8 installation
This is totally weird, not seeing the Grub2 menu. I cannot imagine how that could be by-passed, whichever installation (M7 or M8) gets shown.
It is often useful in such problems to see what is what:
 # gdisk -l /dev/sd...
 # efibootmgr
 # efibootmgr -v
 # tree /boot/EFI/              [but trim the rEFInd & Windows bits]
 # ls -l /boot/EFI/EFI/mageia   [shows when the Mageia Grub2 b/l was done]
But all that is too late.

> Ubuntu and his flavors share the same "Ubuntu" directory for /boot/EFI/ubuntu
> and leads to one take precedence if you update on Kubuntu, and next time you
> update on Xubuntu... Sometimes you get Kubuntu loading, sometimes you get
> Xubuntu as default entry...
> Mageia 7 and 8 share the same name "Mageia" in /boot/EFI/ directory...
[/boot/EFI/EFI/]
= same problem. The most recent kernel update takes the boot. See
https://wiki.mageia.org/en/About_EFI_UEFI#Multi-booting_.26_EFI_Boot_Managers
"Multiple instances of a distribution"

For EFI, just use rEFInd. Once it is installed and *always* booted, you can wave goodbye to Grub2. It does not need any NVRAM entry other than for itself, no bootloaders in /boot/efi/EFI/ other than itself (but offers those it finds). It offers to boot (directly, with Linux stub) all systems it finds on the disc. It pays to label each filesystem e.g. MAGEIA7 because this gets shown.

I seriously think for M9 we should abandon Grub2 for EFI systems. We get bugs for it.

Unfortunately rEFInd is not the answer here, as Herman's machine has a 32-bit UEFI BIOS, rEFInd doesn't support mixed-mode boot, and from bug 27484 we know that Herman can't install a 32-bit system.

Something is causing GRUB to time out instantly, but from the config files shown in the installer log, I can't see what that could be - we have the line

  GRUB_TIMEOUT=10

in /etc/defaults/grub

@ Martin
Where did you get that it is a 32-bit UEFI, I've never noticed something like that looking into it????

@ Lewis
Well, it is not too late, I can always get back to the "faulty condition" by running drakboot in the M8 system. If you think it is usefull, say so, I'll have a look at it tomorrow.

@ Herman,

In the dmidecode section of the report.bug.xz it says

BIOS Information
        Vendor: Phoenix Technologies Ltd.
        Version: 1.00.12.MN IA32

IA32 indicates it's 32-bit. Also the installer has chosen to install the 32-bit grub2-efi-2.04.0-29.mga8.i586 package.

You can confirm it by

  cat /sys/firmware/efi/fw_platform_size

If you do decide to have another attempt, try adding the line

  set timeout=10

to the end of /boot/grub2/grub.cfg, just to be sure that the timeout is set correctly.

@ Lewis
# gdisk -l /dev/mmcblk1p1
GPT fdisk (gdisk) version 1.0.6

Warning: Partition table header claims that the size of partition table
entries is 0 bytes, but this program  supports only 128-byte entries.
Adjusting accordingly, but partition table may be garbage.
Warning: Partition table header claims that the size of partition table
entries is 3145784 bytes, but this program  supports only 128-byte entries.
Adjusting accordingly, but partition table may be garbage.
Partition table scan:
  MBR: MBR only
  BSD: not present
  APM: not present
  GPT: not present


***************************************************************
Found invalid GPT and valid MBR; converting MBR to GPT format
in memory. 
***************************************************************

Disk /dev/mmcblk1p1: 1021986 sectors, 499.0 MiB
Sector size (logical/physical): 512/512 bytes
Disk identifier (GUID): 4C70AB29-5EFF-4EFD-AC05-E85B31C63486
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 1021952
Partitions will be aligned on 2048-sector boundaries
Total free space is 1021919 sectors (499.0 MiB)

Number  Start (sector)    End (sector)  Size       Code  Name

# efibootmgr
BootCurrent: 0001
Timeout: 2 seconds
BootOrder: 0001,0000,0013,0014,0015,0016,0017
Boot0000* Windows Boot Manager
Boot0001* mageia
Boot0010  Setup
Boot0011  Boot Menu
Boot0012  Diagnostic Splash
Boot0013* USB HDD:
Boot0014* eMMC Card0:
Boot0015* Internal Shell
Boot0016* USB CD:
Boot0017* USB FDD:
Boot0018* CD-ROM:

# efibootmgr -v
BootCurrent: 0001
Timeout: 2 seconds
BootOrder: 0001,0000,0013,0014,0015,0016,0017
Boot0000* Windows Boot Manager	HD(1,GPT,cfb14ee0-9db2-4b01-ad18-e4547d424ab6,0x800,0x32000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}...5................
Boot0001* mageia	HD(1,GPT,8e5b974f-8fd8-477a-a3f3-fffc574edc8f,0x800,0xf9822)/File(\EFI\mageia\grubia32.efi)
Boot0010  Setup	FvFile(721c8b66-426c-4e86-8e99-3457c46ab0b9)
Boot0011  Boot Menu	FvFile(86488440-41bb-42c7-93ac-450fbf7766bf)
Boot0012  Diagnostic Splash	FvFile(a7d8d9a6-6ab0-4aeb-ad9d-163e59a7a380)
Boot0013* USB HDD:	VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,33e821aaaf33bc4789bd419f88c50803)
Boot0014* eMMC Card0:	VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,80145304018780439c84491cbd8274fb00)
Boot0015* Internal Shell	FvFile(c57ad6b7-0515-40a8-9d21-551652854e37)
Boot0016* USB CD:	VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,86701296aa5a7848b66cd49dd3ba6a55)
Boot0017* USB FDD:	VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,6ff015a28830b543a8b8641009461e49)
Boot0018* CD-ROM:	VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,be9d0102e211f3489efa0b983c96839b)

# tree /boot/EFI/
/boot/EFI/
└── EFI
    ├── BOOT
    └── mageia
        ├── grub.efi
        └── grubia32.efi

3 directories, 2 files
# ls -l /boot/EFI/EFI/mageia
total 208
-rwxrwxrwx 1 root root 106496 Mar  3 16:39 grub.efi*
-rwxrwxrwx 1 root root 106496 Mar  3 16:39 grubia32.efi*

@ Martin
Confirm it is 32.
Your last suggestion was understood as inserting this statement on the very last line of the /boot/grub2/grub.cfg file, right?
Well, it didn't have any effect at all. After running drakboot with "probe foreign OS" on in M8, the system boots straight into M8. I see the menu entries in the file /boot/grub2/grub.cfg, but on booting nada, null, niente, niks.

(In reply to Herman Viaene from comment #20)
> Your last suggestion was understood as inserting this statement on the very
> last line of the /boot/grub2/grub.cfg file, right?

Yes. To have an effect, you need to do that after running drakboot (because /boot/grub2/grub.cfg is rewritten by drakboot).

That's what I did. I was wondering whether this statement would do any good in the commands list in drakboot. I let it as it was, let drakboot do what I usually does here, then checked th grubcfg file for the menu entries and added the statement. No effect on the M8 boot at all.
had to run the M7 Rescue again to get the proper grub again.

(In reply to Martin Whitaker from comment #15)
> Unfortunately rEFInd is not the answer here, as Herman's machine has a
> 32-bit UEFI BIOS, rEFInd doesn't support mixed-mode boot
Another 64-bit box with 32-bit EFI? Pains. Thanks for this info about rEFInd, important to know. So 32-bit EFI needs Grub2, gloom. I merely repeated your c8!

Thanks for the command outputs, Herman, even though they have not helped. The identical sizes of:
-rwxrwxrwx 1 root root 106496 Mar  3 16:39 grub.efi*
-rwxrwxrwx 1 root root 106496 Mar  3 16:39 grubia32.efi*
look suspicous. Martin?

I am puzzled why this 64-bit apparently EFI system has "legacy BIOS" and an MBR disc (if that is what it is). No wonder gdisk was upset; this would have been more appropriate:
 # fdisk -l /dev/mmcblk1p1
but that is academic.

> Found with M8 Ci of 22/2, not on the one of 17/2.
> There is a M7 installation present , and a M8 from the 17/2 "final".
> This had multiboot with grub flawlessly up to now.
Are we drifting away from this important fact?
Martin said "There were no changes to drakboot or grub2 between the 17-Feb and 22-Feb ISOs", but *something* must have changed. Perhaps an unconscious difference in the installation of the two. It is common to see "Nothing has changed" then after a lot of painful diagnosis, there is always something, somewhere.

Have you tried (you may have, in which case sorry), for example, from either running Mageia,
either # update-grub2 ; or if that does not help,  # grub2-install

CC: (none) => lewyssmith

(In reply to Lewis Smith from comment #23)
> I am puzzled why this 64-bit apparently EFI system has "legacy BIOS" and an
> MBR disc (if that is what it is). No wonder gdisk was upset; this would have

Despite a lot of public misinformation, efi does not require gpt and gpt
does not require efi.

efi firmware should work with either gpt or mbr partitioned drives. Same with
bios firmware systems as well as uefi firmware running in either uefi mode or
bios legacy emulation mode. There are some faulty uefi systems where this is
not true and gpt is required, but the systems that follow the uefi standards
do support mbr partitioning.

The system will appear as legacy bios in a uefi firmware system if Compatibility
Support Module (CSM) has been activated in the uefi setup.

CC: (none) => davidwhodgins

Bogus UEFI?

(In reply to Dave Hodgins from comment #24)
> (In reply to Lewis Smith from comment #23)
> Despite a lot of public misinformation, efi does not require gpt and gpt
> does not require efi.
This I knew: https://wiki.mageia.org/en/About_EFI_UEFI
"GPT is independent of EFI. Some EFI systems require GPT (or they'll automatically switch to CSM mode). Other EFI systems are ok with MBR partition tables."

(In reply to Aurelien Oudelet from comment #25)
> Bogus UEFI?
This does not explain the *change* Herman suffered in comment 0.

@Herman
Where are you with this?
Have you been able to get into either M7 or M8 system and run 'update-grub2' or 'grub2-install'?

Run update-grub2 on M7 and that picked up the M8  installation. Rebooted and, choose M8 and niw editing from there.
So this workaround seems to do the trick.

Thanks for the feedback.
Can we close this?

Yeah. Closing as works for me. Feel free to reopen if a way to reproduce it
for others can be found using only Mageia tools to create the issue.

Resolution: (none) => WORKSFORME
Status: NEEDINFO => RESOLVED