Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Can't Boot EFI Stub After dd to New Hard Drive
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Kernel & Hardware
View previous topic :: View next topic  
Author Message
AustinMatherne
n00b
n00b


Joined: 25 Jul 2012
Posts: 32
Location: Minneapolis, Minnesota, USA

PostPosted: Sun Apr 20, 2014 5:19 am    Post subject: Can't Boot EFI Stub After dd to New Hard Drive Reply with quote

I swapped out an older 256GB SSD with a new (also 256GB) SSD by running:
Code:
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?
Back to top
View user's profile Send private message
khayyam
Advocate
Advocate


Joined: 07 Jun 2012
Posts: 2949

PostPosted: Sun Apr 20, 2014 12:13 pm    Post subject: Re: Can't Boot EFI Stub After dd to New Hard Drive Reply with quote

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
Back to top
View user's profile Send private message
AustinMatherne
n00b
n00b


Joined: 25 Jul 2012
Posts: 32
Location: Minneapolis, Minnesota, USA

PostPosted: Sun Apr 20, 2014 5:21 pm    Post subject: Reply with quote

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

Code:
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.
Back to top
View user's profile Send private message
khayyam
Advocate
Advocate


Joined: 07 Jun 2012
Posts: 2949

PostPosted: Sun Apr 20, 2014 7:43 pm    Post subject: Reply with quote

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

Code:
# 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.

Code:
# 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
Back to top
View user's profile Send private message
Hu
Watchman
Watchman


Joined: 06 Mar 2007
Posts: 9312

PostPosted: Sun Apr 20, 2014 7:52 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
AustinMatherne
n00b
n00b


Joined: 25 Jul 2012
Posts: 32
Location: Minneapolis, Minnesota, USA

PostPosted: Mon Apr 21, 2014 12:00 am    Post subject: Reply with quote

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"?
Back to top
View user's profile Send private message
khayyam
Advocate
Advocate


Joined: 07 Jun 2012
Posts: 2949

PostPosted: Mon Apr 21, 2014 2:39 am    Post subject: Reply with quote

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:

Code:
# 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
Back to top
View user's profile Send private message
Hu
Watchman
Watchman


Joined: 06 Mar 2007
Posts: 9312

PostPosted: Mon Apr 21, 2014 2:55 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
AustinMatherne
n00b
n00b


Joined: 25 Jul 2012
Posts: 32
Location: Minneapolis, Minnesota, USA

PostPosted: Mon Apr 21, 2014 3:05 am    Post subject: Reply with quote

khayyam, from efibootmgr 0.6.0:
Code:
-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.
Back to top
View user's profile Send private message
khayyam
Advocate
Advocate


Joined: 07 Jun 2012
Posts: 2949

PostPosted: Mon Apr 21, 2014 12:17 pm    Post subject: Reply with quote

AustinMatherne wrote:
from efibootmgr 0.6.0:
Code:
-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
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Kernel & Hardware All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum