| View previous topic :: View next topic |
| Author |
Message |
AustinMatherne
n00b
Joined: 25 Jul 2012
Posts: 32
Location: Minneapolis, Minnesota, USA
|
 Posted: Sun Apr 20, 2014 5:19 am Post subject: Can't Boot EFI Stub After dd to New Hard Drive |
 |
|
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 |
|
 |
khayyam
Watchman
Joined: 07 Jun 2012
Posts: 6227
Location: Room 101
|
| Posted: Sun Apr 20, 2014 12:13 pm Post subject: Re: Can't Boot EFI Stub After dd to New Hard Drive |
|
|
| 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 |
|
|
AustinMatherne
n00b
Joined: 25 Jul 2012
Posts: 32
Location: Minneapolis, Minnesota, USA
|
| Posted: Sun Apr 20, 2014 5:21 pm Post subject: |
|
|
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 |
|
|
khayyam
Watchman
Joined: 07 Jun 2012
Posts: 6227
Location: Room 101
|
| Posted: Sun Apr 20, 2014 7:43 pm Post subject: |
|
|
| 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 |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 23071
|
| Posted: Sun Apr 20, 2014 7:52 pm Post subject: |
|
|
| 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 |
|
|
AustinMatherne
n00b
Joined: 25 Jul 2012
Posts: 32
Location: Minneapolis, Minnesota, USA
|
| Posted: Mon Apr 21, 2014 12:00 am Post subject: |
|
|
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 |
|
|
khayyam
Watchman
Joined: 07 Jun 2012
Posts: 6227
Location: Room 101
|
| Posted: Mon Apr 21, 2014 2:39 am Post subject: |
|
|
| 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 |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 23071
|
| Posted: Mon Apr 21, 2014 2:55 am Post subject: |
|
|
| 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 |
|
|
AustinMatherne
n00b
Joined: 25 Jul 2012
Posts: 32
Location: Minneapolis, Minnesota, USA
|
| Posted: Mon Apr 21, 2014 3:05 am Post subject: |
|
|
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 |
|
|
khayyam
Watchman
Joined: 07 Jun 2012
Posts: 6227
Location: Room 101
|
| Posted: Mon Apr 21, 2014 12:17 pm Post subject: |
|
|
| 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 |
|
|
|
Kernel & Hardware
