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

Re: changing from BIOS to GPT



On 06/06/15 01:32 PM, Lisi Reisz wrote:
On Saturday 06 June 2015 16:21:38 Gary Dale wrote:
On 06/06/15 05:28 AM, Lisi Reisz wrote:
On Saturday 06 June 2015 04:51:58 Gary Dale wrote:
On 05/06/15 03:22 PM, Arno Schuring wrote:
Hi,

Date: Fri, 5 Jun 2015 14:45:04 -0400
    From: garydale@torfree.net

       > I have a computer that was set up with an the older style
       > partition table and wanted to convert it to GPT. Since the first
       > partition

started

       > at 2048, I figured this wouldn't be a problem. Just use gdisk to

write a

       > new partition table after stealing some space from swap for an

EFI boot

       > partition. Then reconfigure grub...

       "reconfigure grub" in this case meant uninstalling grub-pc and
installing grub-efi, right? And
       that EFI boot partition is mounted on /boot/EFI, is formatted as
FAT32, and has the correct
       partition type (EF01 in gdisk iirc)?

No actually. I never uninstalled grub-pc. The machine seemed to have
grub-efi-amd64 all along. What I meant was the more mundane update-grub
sequence. Also, I've been using EF02 as the gpt partition type for the
efi partition. So far I've never had a problem with that.

       > [..] created new Linux and Swap partitions that I
       > installed Jessie to. These were extended partitions that gdisk

converted

       > to primary (it displays them as primary but with the original

numbers).

       There's no such thing as primary/extended/logical partitions with
GPT.

I know. I was just explaining that they were not originally primary
partitions, in case that made any difference.

       > Now I don't even to get a grub rescue prompt. I've tried
       > reinstalling grub in a chroot after booting with system rescue
       > cd but that didn't work. I've reinstalled grub to /dev/sda but
       > again without success. Update-grub sees the partitions but
       > doesn't give me a bootable

system.

       > BTW: Grub is the grub-efi-amd64 package.
       >
       > At one point I did get it to boot after using F12 to bring up a
       > boot menu and booting from the first HD, but I haven't been able
       > to

repeat that.

       That probably wouldn't have worked anyway, as EFI doesn't "boot
from HD". That "boot from
       HD" option probably tried a legacy boot. Instead, EFI relies on a
list of bootloaders that's stored
       in nvram. You can use efibootmgr to query or modify this list.
However, that gives you a nice
       chicken-and-egg problem.

I'm not sure why it worked once and, after it did work once, why it
didn't work after that. efibootmgr doesn't want to tell me anything
other than it doesn't work in this mode when I boot using system rescue
cd. I'm also confused as to how grub-efi-amd64 came to be installed. I
don't recall installing it at any point along the process. I thought
perhaps it was what the Jessie installer put in place when I originally
installed Jessie.

       Modifying the efi boot list can only be done through efi system
calls, and the efi system calls
       are only available if your system is booted in EFI mode to begin
with. See
http://blog.uncooperative.org/blog/2014/02/06/the-efi-system-partition/
for a description
       of the boot process.

       There is a default efi bootloader, it should be located as
/boot/efi/efi/boot/bootx64.efi
       assuming your ESP is mounted correctly (see above). Grub is
probably installed as grubx64.efi,
       you may want to copy the grub efi loader to this default location
and try again.

I'll give that a try in the morning. However I'm puzzled as to why this
is happening. I looked at my regular workstation which also uses a gpt
partitioned disk and it uses grub-pc to boot. However trying to use
grub-pc on the other machine also failed to boot.

I would have expected an install of grub to leave the machine in a
bootable state. However purging grub then installing it fresh doesn't
seem to do that, whether I'm talking about regular or efi.

This leads me to ask "exactly when do I need grub-efi as opposed to
grub-pc?" Prior to this problem, I'd never even considered that there
would be a different grub. Since the workstation I'm using to write this
reply on uses both grub-pc and gpt, what triggers the need for grub-efi?


       If that fails, your next attempt at fixing this would be to find a
copy of shellx64.efi on the 'net.
       It's a part of Intel's EFI SDK, but easily available as a separate
download (eek! downloading
       unsigned binaries from random sites). If you put it in the root of
the ESP (i.e. /boot/efi/shellx64.efi),
       your firmware/bios may offer you a separate option to boot this
shell instead. Note the use of
       "may", there is no standard for this.

       That shell pretty much behaves as a dos prompt with tab
completion, you can try to start
       grubx64 from there. That's pretty all the pointers I can give you.
The process above is how
       I converted one of my machines from legacy to efi boot. Be
prepared for a lot of reading, trialing,
       and erroring. Best of luck, Arno

Thanks Arno. Not sure what happened to your reply but it took some doing
to separate your bits from my original post. Hopefully this gets through
in better shape.  :)
Have you tried running os-prober?

Lisi
That would only help if the problem was grub not finding anything. It
finds the correct OSs but fails to actually get to the point that it can
display what it's found.
Might not os-prober get them to the point of display?  I though it put things
in the GRUB menu, in addituion to finding them.

Lisi

Lisi

The problem is that the grub boot loader doesn't appear to be executing. The grub menu looks fine on the HD, but grub itself doesn't even get to the point of failing.


Reply to: