Swapping hard drives results in being unable to boot
up vote
0
down vote
favorite
I have a laptop that I installed Arch on, so far so good. After getting things set up just the way I wanted them and using it for a few days, I decided to experiment a little and install SteamOS. Since I didn't want to mess up my Arch install, and I happened to have a spare 2.5" drive flying around, I just popped the old drive out and put the blank one in. After playing around with SteamOS for a while I swapped the drives back, but now Arch won't boot.
I did not change any BIOS settings. Entering the UEFI boot device selection does not show the HD with Arch installed unless there is another bootable device present (a flash drive with the arch install media in my case), in which case you can manually select the EFI file for GRUB on the HD and boot into Arch normally.
Why would swapping drives suddenly render the old drive unbootable? How do I repair it?
EDIT: After doing the USB stick hack to make the UEFI let me select a file to boot manually, efibootmgr reports the following:
BootCurrent: 003D
Timeout: 0 seconds
BootOrder: 2001,2002,2003
Boot0000* USB Hard Drive (UEFI) - SanDisk Cruzer
Boot2001* USB Drive (UEFI)
Boot2002* Internal CD/DVD ROM Drive (UEFI)
Boot3000* Internal Hard Disk or Solid State Disk
Boot3001* Internal Hard Disk or Solid State Disk
Boot3002* Internal Hard Disk or Solid State Disk
Boot3003* Internal Hard Disk or Solid State Disk
For obvious reasons I can't show the output without the USB hack. The UEFI manger (accessed by pressing F9 during boot in my case) simply does not show the HD as an option unless there is another bootable device available.
boot uefi
asked Nov 27 at 19:42
Milo Christiansen
1013
|
show 3 more comments
up vote
0
down vote
favorite
I have a laptop that I installed Arch on, so far so good. After getting things set up just the way I wanted them and using it for a few days, I decided to experiment a little and install SteamOS. Since I didn't want to mess up my Arch install, and I happened to have a spare 2.5" drive flying around, I just popped the old drive out and put the blank one in. After playing around with SteamOS for a while I swapped the drives back, but now Arch won't boot.
I did not change any BIOS settings. Entering the UEFI boot device selection does not show the HD with Arch installed unless there is another bootable device present (a flash drive with the arch install media in my case), in which case you can manually select the EFI file for GRUB on the HD and boot into Arch normally.
Why would swapping drives suddenly render the old drive unbootable? How do I repair it?
EDIT: After doing the USB stick hack to make the UEFI let me select a file to boot manually, efibootmgr reports the following:
BootCurrent: 003D
Timeout: 0 seconds
BootOrder: 2001,2002,2003
Boot0000* USB Hard Drive (UEFI) - SanDisk Cruzer
Boot2001* USB Drive (UEFI)
Boot2002* Internal CD/DVD ROM Drive (UEFI)
Boot3000* Internal Hard Disk or Solid State Disk
Boot3001* Internal Hard Disk or Solid State Disk
Boot3002* Internal Hard Disk or Solid State Disk
Boot3003* Internal Hard Disk or Solid State Disk
For obvious reasons I can't show the output without the USB hack. The UEFI manger (accessed by pressing F9 during boot in my case) simply does not show the HD as an option unless there is another bootable device available.
boot uefi
asked Nov 27 at 19:42
Milo Christiansen
1013
wiki.archlinux.org/index.php/Persistent_block_device_naming
– jasonwryan
Nov 27 at 19:43
1
That doesn't explain why the UEFI BIOS doesn't identify the HD as bootable.
– Milo Christiansen
Nov 27 at 19:46
Furthermore, that link seemingly doesn't apply at all, as there is only one device in the system and it is mounted properly when I do manage to hack it into booting. This is a BIOS issue of some sort.
– Milo Christiansen
Nov 27 at 19:56
The device names can change randomly - so it does apply. Post the output ofefibootmgr.
– jasonwryan
Nov 27 at 20:03
Added the info requested.
– Milo Christiansen
Nov 27 at 20:18
|
show 3 more comments
up vote
0
down vote
favorite
up vote
0
down vote
favorite
I have a laptop that I installed Arch on, so far so good. After getting things set up just the way I wanted them and using it for a few days, I decided to experiment a little and install SteamOS. Since I didn't want to mess up my Arch install, and I happened to have a spare 2.5" drive flying around, I just popped the old drive out and put the blank one in. After playing around with SteamOS for a while I swapped the drives back, but now Arch won't boot.
I did not change any BIOS settings. Entering the UEFI boot device selection does not show the HD with Arch installed unless there is another bootable device present (a flash drive with the arch install media in my case), in which case you can manually select the EFI file for GRUB on the HD and boot into Arch normally.
Why would swapping drives suddenly render the old drive unbootable? How do I repair it?
EDIT: After doing the USB stick hack to make the UEFI let me select a file to boot manually, efibootmgr reports the following:
BootCurrent: 003D
Timeout: 0 seconds
BootOrder: 2001,2002,2003
Boot0000* USB Hard Drive (UEFI) - SanDisk Cruzer
Boot2001* USB Drive (UEFI)
Boot2002* Internal CD/DVD ROM Drive (UEFI)
Boot3000* Internal Hard Disk or Solid State Disk
Boot3001* Internal Hard Disk or Solid State Disk
Boot3002* Internal Hard Disk or Solid State Disk
Boot3003* Internal Hard Disk or Solid State Disk
For obvious reasons I can't show the output without the USB hack. The UEFI manger (accessed by pressing F9 during boot in my case) simply does not show the HD as an option unless there is another bootable device available.
boot uefi
asked Nov 27 at 19:42
Milo Christiansen
1013
I have a laptop that I installed Arch on, so far so good. After getting things set up just the way I wanted them and using it for a few days, I decided to experiment a little and install SteamOS. Since I didn't want to mess up my Arch install, and I happened to have a spare 2.5" drive flying around, I just popped the old drive out and put the blank one in. After playing around with SteamOS for a while I swapped the drives back, but now Arch won't boot.
I did not change any BIOS settings. Entering the UEFI boot device selection does not show the HD with Arch installed unless there is another bootable device present (a flash drive with the arch install media in my case), in which case you can manually select the EFI file for GRUB on the HD and boot into Arch normally.
Why would swapping drives suddenly render the old drive unbootable? How do I repair it?
EDIT: After doing the USB stick hack to make the UEFI let me select a file to boot manually, efibootmgr reports the following:
BootCurrent: 003D
Timeout: 0 seconds
BootOrder: 2001,2002,2003
Boot0000* USB Hard Drive (UEFI) - SanDisk Cruzer
Boot2001* USB Drive (UEFI)
Boot2002* Internal CD/DVD ROM Drive (UEFI)
Boot3000* Internal Hard Disk or Solid State Disk
Boot3001* Internal Hard Disk or Solid State Disk
Boot3002* Internal Hard Disk or Solid State Disk
Boot3003* Internal Hard Disk or Solid State Disk
For obvious reasons I can't show the output without the USB hack. The UEFI manger (accessed by pressing F9 during boot in my case) simply does not show the HD as an option unless there is another bootable device available.
boot uefi
boot uefi
asked Nov 27 at 19:42
Milo Christiansen
1013
asked Nov 27 at 19:42
Milo Christiansen
1013
edited Nov 27 at 20:17
asked Nov 27 at 19:42
Milo Christiansen
1013
asked Nov 27 at 19:42
Milo Christiansen
1013
asked Nov 27 at 19:42
Milo Christiansen
1013
1013
wiki.archlinux.org/index.php/Persistent_block_device_naming
– jasonwryan
Nov 27 at 19:43
1
That doesn't explain why the UEFI BIOS doesn't identify the HD as bootable.
– Milo Christiansen
Nov 27 at 19:46
Furthermore, that link seemingly doesn't apply at all, as there is only one device in the system and it is mounted properly when I do manage to hack it into booting. This is a BIOS issue of some sort.
– Milo Christiansen
Nov 27 at 19:56
The device names can change randomly - so it does apply. Post the output ofefibootmgr.
– jasonwryan
Nov 27 at 20:03
Added the info requested.
– Milo Christiansen
Nov 27 at 20:18
|
show 3 more comments
wiki.archlinux.org/index.php/Persistent_block_device_naming
– jasonwryan
Nov 27 at 19:43
1
That doesn't explain why the UEFI BIOS doesn't identify the HD as bootable.
– Milo Christiansen
Nov 27 at 19:46
Furthermore, that link seemingly doesn't apply at all, as there is only one device in the system and it is mounted properly when I do manage to hack it into booting. This is a BIOS issue of some sort.
– Milo Christiansen
Nov 27 at 19:56
The device names can change randomly - so it does apply. Post the output ofefibootmgr.
– jasonwryan
Nov 27 at 20:03
Added the info requested.
– Milo Christiansen
Nov 27 at 20:18
wiki.archlinux.org/index.php/Persistent_block_device_naming
– jasonwryan
Nov 27 at 19:43
wiki.archlinux.org/index.php/Persistent_block_device_naming
– jasonwryan
Nov 27 at 19:43
1
1
That doesn't explain why the UEFI BIOS doesn't identify the HD as bootable.
– Milo Christiansen
Nov 27 at 19:46
That doesn't explain why the UEFI BIOS doesn't identify the HD as bootable.
– Milo Christiansen
Nov 27 at 19:46
Furthermore, that link seemingly doesn't apply at all, as there is only one device in the system and it is mounted properly when I do manage to hack it into booting. This is a BIOS issue of some sort.
– Milo Christiansen
Nov 27 at 19:56
Furthermore, that link seemingly doesn't apply at all, as there is only one device in the system and it is mounted properly when I do manage to hack it into booting. This is a BIOS issue of some sort.
– Milo Christiansen
Nov 27 at 19:56
The device names can change randomly - so it does apply. Post the output of
efibootmgr.– jasonwryan
Nov 27 at 20:03
The device names can change randomly - so it does apply. Post the output of
efibootmgr.– jasonwryan
Nov 27 at 20:03
Added the info requested.
– Milo Christiansen
Nov 27 at 20:18
Added the info requested.
– Milo Christiansen
Nov 27 at 20:18
|
show 3 more comments
1 Answer
1
active
oldest
votes
up vote
1
down vote
Turns out I should have used --removable when I installed GRUB if I wanted to be able to swap hard drives. Following the directions at the Arch wiki and renaming my bootloader fixed it right up.
I don't really know why it worked in any great detail, or at least not enough to explain it in a coherent manner. It makes sense, but I would rather not make a fool of myself trying to articulate it.
I'm pretty sure there is a way to fix the BIOS so it knows where the bootloader is, but I don't know how to do that.
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
1
down vote
Turns out I should have used --removable when I installed GRUB if I wanted to be able to swap hard drives. Following the directions at the Arch wiki and renaming my bootloader fixed it right up.
I don't really know why it worked in any great detail, or at least not enough to explain it in a coherent manner. It makes sense, but I would rather not make a fool of myself trying to articulate it.
I'm pretty sure there is a way to fix the BIOS so it knows where the bootloader is, but I don't know how to do that.
add a comment |
up vote
1
down vote
Turns out I should have used --removable when I installed GRUB if I wanted to be able to swap hard drives. Following the directions at the Arch wiki and renaming my bootloader fixed it right up.
I don't really know why it worked in any great detail, or at least not enough to explain it in a coherent manner. It makes sense, but I would rather not make a fool of myself trying to articulate it.
I'm pretty sure there is a way to fix the BIOS so it knows where the bootloader is, but I don't know how to do that.
add a comment |
up vote
1
down vote
up vote
1
down vote
Turns out I should have used --removable when I installed GRUB if I wanted to be able to swap hard drives. Following the directions at the Arch wiki and renaming my bootloader fixed it right up.
I don't really know why it worked in any great detail, or at least not enough to explain it in a coherent manner. It makes sense, but I would rather not make a fool of myself trying to articulate it.
I'm pretty sure there is a way to fix the BIOS so it knows where the bootloader is, but I don't know how to do that.
Turns out I should have used --removable when I installed GRUB if I wanted to be able to swap hard drives. Following the directions at the Arch wiki and renaming my bootloader fixed it right up.
I don't really know why it worked in any great detail, or at least not enough to explain it in a coherent manner. It makes sense, but I would rather not make a fool of myself trying to articulate it.
I'm pretty sure there is a way to fix the BIOS so it knows where the bootloader is, but I don't know how to do that.
answered Nov 27 at 22:01
community wiki
Milo Christiansen
add a comment |
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f484501%2fswapping-hard-drives-results-in-being-unable-to-boot%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
wiki.archlinux.org/index.php/Persistent_block_device_naming
– jasonwryan
Nov 27 at 19:43
1
That doesn't explain why the UEFI BIOS doesn't identify the HD as bootable.
– Milo Christiansen
Nov 27 at 19:46
Furthermore, that link seemingly doesn't apply at all, as there is only one device in the system and it is mounted properly when I do manage to hack it into booting. This is a BIOS issue of some sort.
– Milo Christiansen
Nov 27 at 19:56
The device names can change randomly - so it does apply. Post the output of
efibootmgr.– jasonwryan
Nov 27 at 20:03
Added the info requested.
– Milo Christiansen
Nov 27 at 20:18