[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Chainload grub2 to grub-legacy on ahci / efi.

From: Jordan Uggla
Subject: Re: Chainload grub2 to grub-legacy on ahci / efi.
Date: Tue, 25 Aug 2015 19:01:46 -0700

On Tue, Aug 25, 2015 at 3:18 PM, Stéphan Gorget <address@hidden> 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

> 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.

> 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]