# Can't Boot EFI Stub After dd to New Hard Drive

## AustinMatherne

I swapped out an older 256GB SSD with a new (also 256GB) SSD by running:

```
dd if=/dev/sda of=/dev/sde bs=32M
```

I then unplugged /dev/sda and plugged /dev/sde into the cable that /dev/sda was previously hooked up to. I was using EFI stub and I was able to boot back into Gentoo the first time without skipping a beat. However, after the first reboot I can't get back into the system except by booting off a USB stick that contains an identical copy of my kernel. I used efibootmgr to delete and recreate the boot entry, yet when I select it from the boot menu the screen flashes black momentarily before returning to the boot menu.

Anyone know what's going on here?

----------

## khayyam

 *AustinMatherne wrote:*   

> Anyone know what's going on here?

 

AustinMatherne ... I imagine its due to the new disk differing in size slightly (256GB being something of a ball park figure). Does 'gdisk -l /dev/sda' show "Warning! Disk size is smaller than the main header indicates!" (or similar)? If so you may need to "relocate backup data structures to the end of the disk" (in the "experts" menu, the "x" option).

Also, having dd'ed the disk you will have two disks with the same GUID, you can use 'sgdisk --randomize-guids' on the new disk to fix this.

The gptfdisk author (srs5694) is often reading the forum, so he may have have better advice as to how to solve this.

HTH & best ... khay

----------

## AustinMatherne

Thanks for the suggestions, unfortunately gdisk -l doesn't produce a warning.

```
GPT fdisk (gdisk) version 0.8.10

 

Partition table scan:

  MBR: protective

  BSD: not present

  APM: not present

  GPT: present

 

Found valid GPT with protective MBR; using GPT.

Disk /dev/sda: 500118192 sectors, 238.5 GiB

Logical sector size: 512 bytes

Disk identifier (GUID): 243693F9-DBF6-49EA-AD56-5EB0B1124CF8

Partition table holds up to 128 entries

First usable sector is 34, last usable sector is 500118158

Partitions will be aligned on 2048-sector boundaries

Total free space is 2014 sectors (1007.0 KiB)

 

Number  Start (sector)    End (sector)  Size       Code  Name

   1            2048         1050623   512.0 MiB   EF00  EFI System

   2         1050624       483340287   230.0 GiB   8300  Linux filesystem

   3       483340288       500118158   8.0 GiB     8200  Linux swap
```

Edit: Also, the old hard drive that was cloned is no longer in the system.

----------

## khayyam

 *AustinMatherne wrote:*   

> Thanks for the suggestions, unfortunately gdisk -l doesn't produce a warning.

 

AustinMatherne ... you're welcome. The only other possible cause I can think of is that the previous entry in efivars is somehow causing issues ... or perhaps efi is confused as the PARTUUID is reporting something other than whats expected (or something of that nature given the disk was cloned). This is a guess, but it may be worth checking 'blkid' against 'efibootmgr -v' ...

```
# blkid |awk '/EFI/{print $8}'

PARTUUID="a5d32078-64a7-4c13-a0f1-1286c2f6422b"

# efibootmgr -v

BootCurrent: 0000

Timeout: 5 seconds

BootOrder: 0000

Boot0000* rEFInd  HD(1,28,64000,a5d32078-64a7-4c13-a0f1-1286c2f6422b)File(\efi\refind\refind_ia32.efi)
```

You should see something similar, though if you didn't delete the old entry you may have more than one. The thing to check is that that PARTUUID's match. Also, you may want to delete any obsolete entries ... this shouldn't cause it to fail to boot but they are unneeded so you may as well remove them.

```
# efibootmgr --bootnum <NNNN> --delete-bootnum
```

... where '<NNNN>' is the 4 char alphanumeric of the entry. Also, incase you made a typo when previously adding the boot entry, I would check it (or remove and renew) ... just to rule out something obvious.

I've never cloned a disk with GPT/EFI so I'm not sure what issues you might run into, but given it was working with the previous disk my guess that some disparity between efivars and what the disk reports is the cause.

HTH & best ... khay

----------

## Hu

Although not relevant to your immediate problem, I feel I should point out that you should never use dd to copy a drive image onto an SSD, since doing so marks the entire copied area as used.  Using dd to write to a spinning drive is inefficient but otherwise harmless.  Using dd to write to an SSD tells the drive firmware that the entire drive is used, which interferes with wear levelling.

----------

## AustinMatherne

Apparently efibootmgr changed the default location of the kernel from elilo.efi to /EFI/redhat/grub.efi. I renamed and moved my kernel to the new location on /dev/sda1 and everything is working now, I'm not sure how it got screwed up to begin with, but I must have done something during the first boot on the new hard drive unrelated to the new drive. "efibootmgr -v" turned up the issue. The help was much appreciated.

Hu, regarding your comment, is there anything I can do to fix this now?

Edit: Would sending a TRIM signal to the drive informing it which parts aren't in use fix this, such as "fstrim -a"?

----------

## khayyam

 *AustinMatherne wrote:*   

> Apparently efibootmgr changed the default location of the kernel from elilo.efi to /EFI/redhat/grub.efi.

 

AustinMatherne ... '\elilo.efi' is the default if no '--loader' is provided as an arg to efibootmgr, so I'm not sure how it would default to grub.efi. If you need to change this in future then use something like the following:

```
# efibootmgr --create --part 1 --label "something" --loader "\efi\path\to\loader.efi"
```

I generally avoid making any changes to efivars by using rEFInd as the boot manager, it scans the disk and offers any efi executables (including efi_stub kernels if they are suffixed with .efi) as bootable. So, once set no further changes are needed, and updating kernels, and generally managing booting, is much easier.

best ... khay

----------

## Hu

If the device understands TRIM and implements it well, fstrim -a would probably work.  I suggest having a backup of any files on that drive, since some SSDs are known not to handle TRIM very well.  This was mostly a problem with early generation SSDs.

----------

## AustinMatherne

khayyam, from efibootmgr 0.6.0:

```
-l | --loader name     (defaults to \EFI\redhat\grub.efi)
```

I'm not sure what prevented me from booting the first time, but the first thing I tried after I couldn't boot was delete and recreate the entry using nothing but the create flag (efibootmgr -c). Unlike in the past, because I didn't specify a loader name the entry pointed to "\EFI\redhat\grub.efi" instead of "\elilo.efi". I only noticed this after running "efibootmgr -v".

Everything's working now though, so thank you. Also, "fstrim -a" ran and doesn't appear to have destroyed anything.

----------

## khayyam

 *AustinMatherne wrote:*   

> from efibootmgr 0.6.0:
> 
> ```
> -l | --loader name     (defaults to \EFI\redhat\grub.efi)
> ```
> ...

 

AustinMatherne ... ahhh, ok, this isn't the case with =< 0.5.4-r1 (stable). Can't think why intel would be making this distribution specific. The efi specification (written by intel) states that '/efi/boot/boot_{ia32}{x64}.efi is the default loader (though this should be hardcoded in the firmware).

 *AustinMatherne wrote:*   

> I'm not sure what prevented me from booting the first time, but the first thing I tried after I couldn't boot was delete and recreate the entry using nothing but the create flag (efibootmgr -c). Unlike in the past, because I didn't specify a loader name the entry pointed to "\EFI\redhat\grub.efi" instead of "\elilo.efi". I only noticed this after running "efibootmgr -v".

 

yes, I'd avoid using '--create' without args in future :) ... as I said previously, I try not to make any changes to efivars because there have been bugs in efibootmgr (due probably to the fact that though there is a specification vendors have been less than diligent in following it ... Apple being one case in point). 

 *AustinMatherne wrote:*   

> Everything's working now though, so thank you.

 

... again, you're welcome.

best ... khay

----------

