Grub2 installed from Mageia 5 creates entries for Mageia 4, but refers to /boot/vmlinuz-desktop in the partition for Mageia 5, not the Mageia 4 partition. These entries are created by os-prober. Workaround: set root=UUID=... to the good value in /boot/grub2/grub.cfg But when I have an update (kernel update ?), the entry is overwritten with the wrong entry. Context : 1 harddrive /dev/sda GPT formatted Installed: Windows 8 on /dev/sda4 Mageia 4 / on /dev/sda5 Mageia 5 / on /dev/sda12 ============== fdisk -l Disk /dev/sda: 931,5 GiB, 1000204886016 bytes, 1953525168 sectors Unités : secteur de 1 à 512 = 512 octets Taille de secteur (logique / physique) : 512 octets / 4096 octets taille d'E/S (minimale / optimale) : 4096 octets / 4096 octets Type d'étiquette de disque : gpt Identifiant de disque : 9A13EFB0-8399-47AB-9A7F-6783192DFC82 Périphérique Début Fin Taille Type /dev/sda1 2048 206847 100M EFI System /dev/sda2 206848 2050047 900M Windows recovery environment /dev/sda3 2050048 2312191 128M Microsoft reserved /dev/sda4 2312192 783718399 372,6G Microsoft basic data /dev/sda5 783718400 851290111 32,2G Microsoft basic data /dev/sda6 1911560192 1953523711 20G Windows recovery environment /dev/sda7 851290112 867674111 7,8G Microsoft basic data /dev/sda8 867674112 1802762239 445,9G Microsoft basic data /dev/sda9 1802762240 1819146239 7,8G Microsoft basic data /dev/sda10 1819146240 1819498495 172M Microsoft basic data /dev/sda11 1819498496 1820112895 300M Linux filesystem /dev/sda12 1820112896 1852831743 15,6G Linux filesystem /dev/sda13 1852831744 1911560191 28G Linux filesystem Disk /dev/mapper/crypt_sda9: 7,8 GiB, 8386510848 bytes, 16379904 sectors Unités : secteur de 1 à 512 = 512 octets Taille de secteur (logique / physique) : 512 octets / 4096 octets taille d'E/S (minimale / optimale) : 4096 octets / 4096 octets ================== I modified the entry: linux /boot/vmlinuz-desktop root=UUID=98da39dc-4acb-44be-8572-8f4c867b2a0e ro splash quiet resume=UUID=b3b19c7a-dc3e-40e7-b726-753452ad8577 to linux /boot/vmlinuz-desktop root=UUID=879f6a8c-16e6-452a-a114-308d6781b7b0 ro splash quiet resume=UUID=b3b19c7a-dc3e-40e7-b726-753452ad8577 in menuentry 'Mageia 4 (4) (sur /dev/sda5)' --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-simple-879f6a8c-16e6-452a-a114-308d6781b7b0' { In the grub.cfg I join, I have only edited the entry above cited. The submenuentry are not altered and are as generated by os-prober/grub2-mkconfig. Reproducible: Steps to Reproduce:
Created attachment 5968 [details] The working grub.cfg
Attachment 5968 mime type: application/octet-stream => message/textCC: (none) => zen25000
Attachment 5968 mime type: message/text => text/plain
Interesting... Out of curiosity does this produce any output when run in Mageia 5? su cd /etc egrep -r "Mageia release 4|Mageia 4" Just wondering if there is some left-over from Mga4 in your Mga5 that's confusing os-prober. Was it an upgrade? I have many mga/3/4/5 installations that os-prober has never confused, however I don't have any GPT disks. And what's the output of: su os-prober
egrep give nothing. The installation is new, not an upgrade. os-prober gives: Microsoft/Boot/bootmgfw.efi:Windows Boot Manager:Windows /dev/sda5:Mageia 4 (4):Mageia:linux
Source RPM: (none) => os-prober-1.64-7.mga5
Created attachment 5970 [details] Result of bootinfoscript
Could you revert to os-prober-1.64-7 (urpmi --downgrade os-prober) as 1.65 seems to have introduced another issue - 'linuxefi' and 'initrdefi' have appeared in some entries and we don't use either. After downgrading please run bootinfoscript again and attach. Don't obsolete the old RESULTS.txt from 1.65 yet as it may be useful. Thanks.
Priority: Normal => release_blockerBlocks: (none) => 14069
I don't see the bug issue in the sdb12/boot/grub2/grub.cfg that is in the RESULTS.txt. Where did you see the error that you reported on irc? Did you manually edit grub.cfg after installing os-prober-1.65 before running bootinfoscript? I do see strange entries in the Advanced section for Mga4. Does sda5/boot/grub/menu.lst exist? It's not found by bootinfoscript but please check. If it does it will be parsed by os-prober which may explain those odd entries.
Created attachment 5983 [details] Output of bootinfoscript with os-prober1.64-7 After downgrading to 1.64-7
(In reply to Barry Jackson from comment #6) > I don't see the bug issue in the sdb12/boot/grub2/grub.cfg that is in the > RESULTS.txt. > Where did you see the error that you reported on irc? > Did you manually edit grub.cfg after installing os-prober-1.65 before > running bootinfoscript? Yes, I did, because if not, I cann't reboot my main system. > > I do see strange entries in the Advanced section for Mga4. Does > sda5/boot/grub/menu.lst exist? No it doesn't exist. I have only menu.lst.example > It's not found by bootinfoscript but please > check. If it does it will be parsed by os-prober which may explain those odd > entries.
In the first result.txt, you can see that the two last entries in submenu have: root=UUID=98da39dc-4acb-44be-8572-8f4c867b2a0e which is erroneous and was for the main entry for Mageia 4, before I correct that. After downgrade, I see that the Mageia 4 entries disappear. Thus I regenerated it, and yet is the new result.
Created attachment 5984 [details] Output of bootinfoscript with os-prober1.64-7, after relaunch
(In reply to papoteur from comment #9) > In the first result.txt, you can see that the two last entries in submenu > have: > root=UUID=98da39dc-4acb-44be-8572-8f4c867b2a0e > which is erroneous and was for the main entry for Mageia 4, before I correct > that. OK > > After downgrade, I see that the Mageia 4 entries disappear. Thus I > regenerated it, and yet is the new result. OMG Obviously os-prober ran, as it found windows, so why did it miss Mga4 completely? :\ That looks like another issue.
OK I now see the issue more clearly. I was confused when I saw the linuxefi in the first RESULTS.txt, but I failed to realize that this WAS normal in Mga4 and I was seeing it only in the Mga4 generated grub.cfg, so that was a non-issue. So to summarize: The errors we are seeing in 1.64-7 are still there in 1.65 This only seems to affect you at present or maybe only GPT/EFI installations. I have never tried to set up GPT/EFI in a VM but I think this may be the next step in order to try to reproduce. WDYT?
Perhaps this bug is related? 15250
Created attachment 5997 [details] RESULTS.text from an EFI VM install of Mga4, and 2x Mga5 I have managed to install Mga4.1 alongside two installations of Mga5 in an EFI VM on three virtual disks. I cannot currently get Mga4.1 to boot in this setup, but the other two Mga5 installations do boot OK and both produce what appear to be valid grub.cfg entries for the Mga4 system. Attached is the RESULTS.txt from the system on sda2. Ignore the mention of grub legacy in the MBR of sda - I accidentally ran grub-install... instead of grub2-install... during the nightmare of installing all this. Verdict so far is that I cannot reproduce this bug - unless anyone can see something wrong with the attached. :\ One thing that has emerged is that grub2-install fails to update the efi boot order list because the list exists, running efibootmgr -O before grub2-install removes the error.
(In reply to papoteur from comment #13) > Perhaps this bug is related? > 15250 I don't think so.
(In reply to Barry Jackson from comment #14) > Created attachment 5997 [details] > RESULTS.text from an EFI VM install of Mga4, and 2x Mga5 > > I have managed to install Mga4.1 alongside two installations of Mga5 in an > EFI VM on three virtual disks. > I cannot currently get Mga4.1 to boot in this setup, but the other two Mga5 > installations do boot OK and both produce what appear to be valid grub.cfg > entries for the Mga4 system. > Attached is the RESULTS.txt from the system on sda2. Ignore the mention of > grub legacy in the MBR of sda - I accidentally ran grub-install... instead > of grub2-install... during the nightmare of installing all this. > > Verdict so far is that I cannot reproduce this bug - unless anyone can see > something wrong with the attached. :\ Entry for Mageia 5 on sdb1 seems correct. The difference with my installation : I have also W8. And all partitions are on the same device. Is there a debug mode for os-prober?
(In reply to papoteur from comment #16) > The difference with my installation : I have also W8. And all partitions are > on the same device. Yes I wondered about testing with one device, but it's very time consuming and I really don't have much time at the moment due to real life ;) > Is there a debug mode for os-prober? Yes, however it's designed to integrate with a custom logger tool in Debian. I managed to debug it in the past by commenting out a line (or part of) near the end of the main os-prober script: ) 9>&1 | logger 1>&- # fd_logger IIRC I chopped off the pipe (and maybe used set -x) but it's a while ago and I don't recall the detail. I do remember adding heaps of echo's to output vars at various stages. I hope that helps ;)
OK I now have a *fully working* EFI VM install of Mga5 and Mga4.1 on sda, with another Mga5 on sdb. I have one ESP on sda. After the Mga4.1 install (from Live) I booted Mga5 (on sda) and ran the following in order to make the Mga5 grub2 install on sda the controlling grub2: efibootmgr -O grub2-install /dev/sda update-grub All grub2 menu options boot correctly. :) If it ain't broke I can't even try to fix it :\
I investigate the problem and found what I consider as a bug: The problem is not in os-prober itself which correctly found two entries: Microsoft/Boot/bootmgfw.efi:Windows Boot Manager:Windows /dev/sda5:Mageia 4 (4):Mageia:linux but in /etc/grub.d/30_osprober The wrong line is written here: I have in line 237 cat << EOF linux ${LKERNEL} ${LPARAMS} EOF LKERNEL is the entry as written in the grub2 entry found on DEVICE but LKERNEL refers to a kernel which can point to another partition. In my case, it refers to the Mageia 5 on /dev/sda12 Thus the menuentry want to point to Mageia 4 on sda5 but use an entry which is for Mageia 5 on sda12. The entries worked in /etc/grub.d/30_osprober come from linux-boot-prober, which surprisingly doesn't list the Mageia 4 (sda5) entries: linux-boot-prober /dev/sda5 /dev/sda5:/dev/sda5:Mageia 5 (5) (on /dev/sda12):/boot/vmlinuz-desktop:/boot/initrd-desktop.img:root=UUID=98da39dc-4acb-44be-8572-8f4c867b2a0e ro splash quiet resume=UUID=b3b19c7a-dc3e-40e7-b726-753452ad8577 /dev/sda5:/dev/sda5:Mageia (on /dev/sda12):/boot/vmlinuz-desktop:/boot/initrd-desktop.img:root=UUID=98da39dc-4acb-44be-8572-8f4c867b2a0e ro splash quiet resume=UUID=b3b19c7a-dc3e-40e7-b726-753452ad8577 /dev/sda5:/dev/sda5:Mageia, with Linux desktop (sur /dev/sda12):/boot/vmlinuz-desktop:/boot/initrd-desktop.img:root=UUID=98da39dc-4acb-44be-8572-8f4c867b2a0e ro splash quiet resume=UUID=b3b19c7a-dc3e-40e7-b726-753452ad8577
Created attachment 6066 [details] linux-boot-prober output in VM for comparison
@papoteur Please test with os-prober-1.65-1.mga5 in cauldron core/updates_testing. It has 4 Fedora patches which were not applied when you tested it previously from my repo. Thanks, Barry
(In reply to Barry Jackson from comment #21) > @papoteur > Please test with os-prober-1.65-1.mga5 in cauldron core/updates_testing. > It has 4 Fedora patches which were not applied when you tested it previously > from my repo. > > Thanks, > Barry Hi Barry, I just tested with os-prober-1.65-1.mga5 It is a good solution. Entries generated work directly, I don't need to edit them to boot my Mageia 4. :) Thanks for your job !
Status: NEW => RESOLVEDResolution: (none) => FIXED
Great :) So as you closed the bug I assume this also fixed the mixed UUIDs as well as the Mindows issue?
Ah yes, I forgotten that I have a Windows. The entry is good too. I never reported problem with it.
On my Mageia 4, I installed os-prober-1.65-2.mga5. I run grub2-install. After the reboot, I get the grub2 menu, with a first entry to "Mageia" which starts Mageia 4, a second line for "More entries for Mageia", an entry "Windows Boot Manager" which starts Windows 8.1, and to lines for "Mageia 5 (sur sda12)". I have also a last "Windows" line which comes form /etc/grub.d/40_custom. Thus, all is fine. Papoteur
Great, many thanks for testing. I will push os-prober-1.65 to 4/updates_testing.