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

Re: changing from BIOS to GPT



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.


Reply to: