On Tue, Aug 25, 2015 at 3:18 PM, Stéphan Gorget <[email protected]> wrote: > Hello, > > I tried to chainload grub-legacy from grub2
As always, use of grub legacy is discouraged, and upstream grub legacy never even had [U]EFI support, but chainloading other UEFI based loaders should generally work, so continuing to the problem you're having... > using efi. I have the > following setup > > (ahci0,gpt1) - vfat - just the efi file at that place : > /efi/redhat/grub.efi (/boot/efi) > (ahci0,gpt2) - ext* - kernel and grub > (/boot) > (ahci0,gpt3) - ext* - Linux FS > (/) > > I noticed that none of the device is detected as efidisk and they all > have the device id GRUB_DISK_DEVICE_ATA_ID, furthermore when I put > debug=all I can clearly see that it does not use the efidisk code > path. Which means that you have ahci.mod loaded. Why? Unless you need to bypass your boot firmware's disk access functions due to bugs in your boot firmware, you probably don't want to be using ahci.mod. > > I define root and prefix and try to chainload the grub.efi. However > whatever I do it end up saying "Not a valid root device". (ahci0) is not a valid device for the purposes of chainloading; Chainloading requires a device the boot firmware understands. > BTW > chainloading on the same setup but on BIOS works just fine, even > though I know it's a different story. While chainloading after using ahci.mod on BIOS based systems may work sometimes, I don't think it's a good idea. The reason that grub disables biosdisk access after loading ahci.mod is for safety. Having the firmware try to access a drive after its state has been altered by grub (which most firmware will not expect as bootloaders generally can't do this) could be unsafe. I don't know enough about the problem to say for sure, but it might even be that grub should be modified to not allow chainloading after direct disk access on BIOS based systems. > > I also know I can just start the kernel from there and it works but I > would rather chainload. I can also just bail out and leave the boot > order fallback to disk, but I would like to avoid that also. > To put into context the grub2-git-version I am testing from is loaded > via network on an ipv6-only network and I want to use grub2 to replace > any pxe/ipxe/gpxe in order to simplify the decision making to just > boot local or start an imaging process. For preparing a netboot image you should be using either grub-mknetdir or grub-mkstandalone. Using grub-mkimage manually is strongly discouraged as users usually get it wrong. I mention this because direct use of grub-mkimage by users who aren't also grub developers is the primary reason that we see users accidentally loading ahci.mod when they didn't intend to. Baking all modules into the grub core is a *bad* idea, and will lead to other problems beyond the one you've described above. -- Jordan Uggla (Jordan_U on irc.freenode.net) _______________________________________________ Help-grub mailing list [email protected] https://lists.gnu.org/mailman/listinfo/help-grub
