Description of problem: grub2-mkrescue still searches /boot/grub for grub.cfg this makes it hard (thought not impossible) to create a Mageia based rescue disk with mkrescue as the default in Mageia is /boot/grub2 Version-Release number of selected component (if applicable): How reproducible: Create a rescue disk using mkrescue and you'll end up with both a grub and a grub2 folder in boot.
Created attachment 10087 [details] Fix hard coded /boot/grub values to be /boot/grub2
Assigning to barjac, who is the de facto maintainer of grub2, even if he prefers to not be the official maintainer. CC'ing the Base System maintainers because I feel tempted to count grub2 as a Base System package, because for 99,9% of the users, if grub2 doesn't work nothing will.
Keywords: (none) => PATCHCC: (none) => basesystem, marja11Assignee: bugsquad => zen25000
Well, that's the default bootloader for all mga6/7 installations, so yes that's a base pkg nowadays...
CC: (none) => thierry.vignaud
Hi Jeremiah, Thanks for your work on the patch, it did not apply after the hundreds of others that we carry, but after manually re-diffing I have a working build. However, I started wondering why I had never hit this problem myself and looked at an old script of mine here: https://wiki.mageia.org/en/User:Barjac About half way down there is: grub2-mkrescue -o grub2-boot.iso grub2-boot/ which prompted me to look at the man page. From man grub2-mkrescue: grub-mkrescue [-o | --output=FILE] [--modules=MODULES] [--install-modules=MODULES] [--themes=THEMES] [--fonts=FONTS] [--locales=LOCALES] [--compress[=no,xz,gz,lzo]] [-d | --directory=DIR] [--grub-mkimage=FILE] [--rom-directory=DIR] [--xorriso=FILE] [--grub-glue-efi=FILE] [--grub-render-label=FILE] [--label-font=FILE] [--label-color=COLOR] [--label-bgcolor=FILE] [--product-name=STRING] [--product-version=STRING] [--sparc-boot] [--arcs-boot] It is very unlikely that anyone would run grub2-mkrescue without reading the man page and using some parameters, which is probably why this has never been reported before. This is not really a bug IMHO so I am tempted to leave this as per upstream and close as WONTFIX. Any other opinions?
Please point out what you mean? There's no option in the source to change the dir. Also it's hardcoded to search for the grub.cfg in /boot/grub options won't change that. If you look at the ISO it generates, everything is in /boot/grub which is unexpected behavior if the rest of your tools install in grub2 then for consistency sake all should. It's an easy enough patch. If scripts are written to generate and manipulate ISOs then this tool will always be the odd one out. I don't care as much because I follow your svn and upstream fairly closely, I also generate a dozen or so cauldron builds a day and have my own package building system, so if I have to build and patch grub myself that's fine. Just thought others may run into this eventually and inconsistencies make engineering a tad more difficult.
If the created rescue disk boots the system then it's job is done and exactly where it puts it's own files is immaterial, but I guess there may be situations where this could be inconvenient, so I take your point. On reading your opening sentence in the first comment in this report I thought you were referring to where the program was looking for it's input. I agree it's a simple patch but it will still need maintaining when upstream sources change. Ideally this should be handled upstream when --program-transform-name=s,grub,%{name}, is passed to configure. I'm happy to push this but should we be changing the lines that only refer to sparc and mips etc. as I don't think they affect us?
Sorry about not being clear.. You are correct it is immaterial.. Ideally this is an upstream issue. The true fix is not hardcoding a value but allowing it to be user defined. Some distros still use /boot/grub as they have dropped 0.97 usage altogether. So the patch here could only be applied at the distro level. However, as you stated this is imatterial and is the patch worth the trouble.. most likely not for you guys. I'll go ahead and close this out. This is really because I am to lazy to figure out how to add it as a user defined option and submit it to grub.. I am by no means a C guy. However, I should figure this out and see if I can get something at least submitted upstream before I bother you guys about it. I'll just keep making my grub builds in the mean time.
Closing this out since it is grub, a base package, and the trouble of fixing wouldn't be worth the risk for most.
Resolution: (none) => WONTFIXStatus: NEW => RESOLVED
Tools shipped in Mageia should match the Mageia install layout, so yes, that patch should be applied...
Status: RESOLVED => REOPENEDCC: (none) => tmbResolution: WONTFIX => (none)
Created attachment 10093 [details] Updated
Attachment 10087 is obsolete: 0 => 1
Created attachment 10094 [details] Patch to have mkrescue write to grub2 I went ahead and updated it so it would apply cleanly. I am applying it after the mga patches in the spec file.
Attachment 10093 is obsolete: 0 => 1
I have built rpms for i586 https://copr-be.cloud.fedoraproject.org/results/jmiahman/Unity-Linux/mageia-cauldron-i586/00742356-grub2/ and x86_64 in copr, I don't have access to BS yet.. :) https://copr-be.cloud.fedoraproject.org/results/jmiahman/Unity-Linux/mageia-cauldron-x86_64/00742356-grub2/ Was able to generate an ISO with it :)
Created attachment 10095 [details] Patch to have mkrescue write to grub2
Attachment 10094 is obsolete: 0 => 1
Jeremiah, Your patch leaves line 264 unchanged - is this intentional? After applying patch: fprintf (load_cfg_f, "set prefix=(${root})/boot/grub\n");
N.B. I am applying after ALL other patches.
Same question about line 630 which was also in your first patch. "/boot/grub", sa, sysarea_img,
Yup I missed those in this latest diff sorry :(
Created attachment 10096 [details] Patch to have mkrescue write to grub2
Attachment 10095 is obsolete: 0 => 1
Created attachment 10097 [details] Patch to have mkrescue write to grub2 Rediffed so it would apply cleanly in spec file.
Attachment 10096 is obsolete: 0 => 1
Hmm.. well I guessed that and rebuilt with those added, but I'm trying to do a quick test and hitting errors. Do you have an example usage of grub2-mkrescue that works with this patch? [baz@localhost ~]$ grub2-mkrescue -o grub.iso GNU xorriso 1.4.8 : RockRidge filesystem manipulator, libburnia project. Drive current: -outdev 'stdio:grub.iso' Media current: stdio file, overwriteable Media status : is blank Media summary: 0 sessions, 0 data blocks, 0 data, 22.1g free Added to ISO image: directory '/'='/tmp/grub.GD5wNA' xorriso : UPDATE : 560 files added in 1 seconds xorriso : FAILURE : Cannot find in ISO image: -boot_image ... bin_path='/boot/grub2/i386-pc/eltorito.img' xorriso : UPDATE : 560 files added in 1 seconds xorriso : aborting : -abort_on 'FAILURE' encountered 'FAILURE' This looks as though it's looking for i386-pc modules on my efi system (I do have grub2 installed as well as grub2-efi in order to try to show up any issues with not having them conflict)
Sure you're not missing the change on line 500?
No - all looks identical to your latest. Rebuilding with your latest anyway and will then test with grub2 uninstalled as well.
hmmm doesn't seem to be [root@unity-linux live]# grub2-mkrescue -o test.iso GNU xorriso 1.4.8 : RockRidge filesystem manipulator, libburnia project. Drive current: -outdev 'stdio:test.iso' Media current: stdio file, overwriteable Media status : is blank Media summary: 0 sessions, 0 data blocks, 0 data, 837m free Added to ISO image: directory '/'='/tmp/grub.FcNJiH' xorriso : UPDATE : 322 files added in 1 seconds xorriso : UPDATE : 322 files added in 1 seconds xorriso : NOTE : Copying to System Area: 512 bytes from file '/usr/lib/grub/i386-pc/boot_hybrid.img' ISO image produced: 4690 sectors Written to medium : 4690 sectors at LBA 0 Writing to 'stdio:test.iso' completed successfully.
[root@unity-linux live]# grub2-mkrescue -o test.iso GNU xorriso 1.4.8 : RockRidge filesystem manipulator, libburnia project. Drive current: -outdev 'stdio:test.iso' Media current: stdio file, overwriteable Media status : is blank Media summary: 0 sessions, 0 data blocks, 0 data, 829m free Added to ISO image: directory '/'='/tmp/grub.PBAH4B' xorriso : UPDATE : 322 files added in 1 seconds xorriso : UPDATE : 322 files added in 1 seconds xorriso : NOTE : Copying to System Area: 512 bytes from file '/usr/lib/grub/i386-pc/boot_hybrid.img' ISO image produced: 4690 sectors Written to medium : 4690 sectors at LBA 0 Writing to 'stdio:test.iso' completed successfully. [root@unity-linux live]# mount -o loop test.iso /mnt/ mount: /mnt: WARNING: device write-protected, mounted read-only. [root@unity-linux live]# ls /mnt/bo boot/ boot.catalog [root@unity-linux live]# ls /mnt/boot grub2/ [root@unity-linux live]#
Interesting. I rebuilt using the patch above (which compared exactly with mine except for minor line number differences) and now there is no error. Strange. With grub2 installed it produces a larger hybrid image which contains both sets of modules: [baz@localhost ~]$ grub2-mkrescue -o grub.iso GNU xorriso 1.4.8 : RockRidge filesystem manipulator, libburnia project. Drive current: -outdev 'stdio:grub.iso' Media current: stdio file, overwriteable Media status : is blank Media summary: 0 sessions, 0 data blocks, 0 data, 22.1g free Added to ISO image: directory '/'='/tmp/grub.nXcEIb' xorriso : UPDATE : 560 files added in 1 seconds xorriso : UPDATE : 560 files added in 1 seconds xorriso : NOTE : Copying to System Area: 512 bytes from file '/usr/lib/grub/i386-pc/boot_hybrid.img' ISO image produced: 5561 sectors Written to medium : 5561 sectors at LBA 0 Writing to 'stdio:grub.iso' completed successfully. With grub2 removed the iso only contains the efi modules: [baz@localhost ~]$ grub2-mkrescue -o grub.iso GNU xorriso 1.4.8 : RockRidge filesystem manipulator, libburnia project. Drive current: -outdev 'stdio:grub.iso' Media current: stdio file, overwriteable Media status : is blank Media summary: 0 sessions, 0 data blocks, 0 data, 22.1g free Added to ISO image: directory '/'='/tmp/grub.LEVnag' xorriso : UPDATE : 283 files added in 1 seconds xorriso : UPDATE : 283 files added in 1 seconds ISO image produced: 4432 sectors Written to medium : 4432 sectors at LBA 0 Writing to 'stdio:grub.iso' completed successfully. [baz@localhost ~]$ No sign of boot/grub so this looks OK now. Thanks for your help with this Jeremiah, I will push it to Cauldron.
Closing as fixed Submitted to Cauldron: http://svnweb.mageia.org/packages?view=revision&revision=1219973
Resolution: (none) => FIXEDStatus: REOPENED => RESOLVED
Created attachment 10100 [details] Patch to have mkrescue write to grub2 dir Not so fast.. deeper testing was needed. One more patch is needed.. please test :) I have a working ISO that boots up, but I would like to have someone else have the same great experience.
Attachment 10097 is obsolete: 0 => 1
Re-opening then.
Resolution: FIXED => (none)Status: RESOLVED => REOPENED
(In reply to Jeremiah Summers from comment #27) but I would like to have someone > else have the same great experience. Updated patch and pushed to cauldron. Please test.
Created attachment 10112 [details] Screenshot of boot ISO with grub2 release 6 mkrescue changes
Works good here, created an ISO (attached screen shot above) using my build system for Unity (that uses mkrescue) and everything looks good. First and foremost it boots and secondly everything on the ISO that has to do with grub gets placed in /boot/grub2
Closing out
Status: REOPENED => RESOLVEDResolution: (none) => FIXED