You are not logged in.
Hello!
I've used Arch before, in fact I'm using Arch on my desktop right now, and I have used it on my laptop on an external drive. However due to a failed drive I have to reinstall it for my laptop on to a replacement drive. I'm not truly experienced with Arch, but I've messed around with it.
So my platform is a laptop, specifically an HP Spectre x360. I have Windows on the main hard drive, and I am trying to install Arch to an external USB hard drive.
My problem is that GRUB will not boot. I have installed GRUB to an EFI partition, and I have run grub-mkconfig (and it is outputting to the EFI partition). However, my problem is that for some reason, when trying to boot from GRUB, I am spat out to the GRUB command line with no error message. Using "ls", I managed to figure out that when I am on a live CD, my Windows hard drive is /dev/sda, and my external hard drive is /dev/sdb. Normally, these are mapped to (hd0) (hd1) respectively. However, it seems that from the GRUB command line, it is flipped; that is, my Windows hard drive (/dev/sda) is being mapped to (hd1), whereas my external hard drive (/dev/sdb) is mapping to (hd0). Looking at my GRUB config (the one generated by grub-mkconfig), it seems that it is expecting the external hard drive to be (hd1):
menuentry 'Arch Linux' --class arch --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-<HD UUID>' {
savedefault
load_video
set gfxpayload=keep
insmod gzio
insmod part_gpt
insmod ext2
set root='hd1,gpt3' ###### Notice this line as well as the line 2 below
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-ieee1275='ieee1275/ (null)/sas/disk@0,gpt3' --hint-bios=hd1,gpt3 --hint-efi=hd1,gpt3 --hint-baremetal=ahci1,gpt3 <HD UUID>
else
search --no-floppy --fs-uuid --set=root <HD UUID>
fi
echo 'Loading Linux linux ...'
linux /boot/vmlinuz-linux root=UUID=<HD UUID> rw quiet
echo 'Loading initial ramdisk ...'
initrd /boot/intel-ucode.img /boot/initramfs-linux.img
}Just to be clear, I am NOT being dropped into grub-rescue. It is just that the menu entries seem to fail for some reason and I am sent into the command line. I COULD just modify the generated config file, but that's generally a bad idea, since any GRUB update could regenerate the config file and make my system unusable again.
My intuition is that if I can get the external hard drive to be (hd1), then all will work out. Is there a way to assign the hard drive to that? Or maybe I'm way off base and there's another solution?
I've tried searching for any combination of related words but I've yet to stumble on an answer. Any help would be appreciated, and if there's any more information that you all need, I can provide.
Thank you in advance!
Last edited by Spykill (2019-01-27 17:47:14)
Offline
Welcome to the Arch Linux forums.
This is why we strongly suggest you not use device names. The order in which they are instantiated is undefined, hence their names can change.
Use UUIDs. [edit: or partUUIDs] They are immutable.
https://wiki.archlinux.org/index.php/Pe … ng#by-uuid
Last edited by ewaller (2019-01-26 15:14:40)
Nothing is too wonderful to be true, if it be consistent with the laws of nature -- Michael Faraday
The shortest way to ruin a country is to give power to demagogues.— Dionysius of Halicarnassus
---
How to Ask Questions the Smart Way
Offline
Welcome to the Arch Linux forums.
This is why we strongly suggest you not use device names. The order in which they are instantiated is undefined, hence their names can change.
Use UUIDs. [edit: or partUUIDs] They are immutable.
https://wiki.archlinux.org/index.php/Pe … ng#by-uuid
Thank you for the response! I have indeed seen this page, but I'm not really sure how to take advantage of it. Like should I be mounting using a UUID, or is there a command I should be using with grub-mkconfig to force it to use UUIDs? Or possibly something else entirely. I will try reinstalling GRUB when mounting by device name, but I don't really see how that would change it, since the problem seems to be that grub-mkconfig refers to the drive as hd1, as opposed to /dev/sdb.
Edit: I tried reinstalling GRUB and re-configuring with the partitions mounted using UUIDs and no change. grub-mkconfig still writes the drive as (hd1)
Last edited by Spykill (2019-01-26 17:13:21)
Offline
grub-mkconfig sucks horribly, and I strongly suggest using my WIP rewrite: https://wiki.archlinux.org/index.php/Us … om_scratch
That being said, what little I see of your grub.cfg implies that the set root=hd1 nonsense should always be immediately overwritten by search --no-floppy --fs-uuid --set=root <HD UUID>
But it depends on what else is being done elsewhere, so who knows.
For context, this is my entire grub.cfg (and I know why every single character in it is there):
set timeout=1
set default=0
set btrfsroot=53731b6e-8cce-467c-bf07-be1b04207846
cmdline="root=UUID=$btrfsroot rw"
menuentry "Arch Linux" {
linux /boot/vmlinuz-linux $cmdline
initrd /boot/intel-ucode.img /boot/initramfs-linux.img
}
menuentry "Arch Linux Fallback" {
linux /boot/vmlinuz-linux $cmdline
initrd /boot/intel-ucode.img /boot/initramfs-linux-fallback.img
}Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline
Thank you both for your help, but my problem is solved!
So when I change the order of my USBs, it actually changes the order of the drives in Arch. Plugging in my live cd to one port and my hard drive to another port leads to one configuration, let's say the live cd is /dev/sdb and the drive is /dev/sdc. Swapping the USB ports led to the letters swapping, so the live cd becomes /dev/sdc and the drive becomes /dev/sdb. When I installed Arch, I accidentally had the live cd as /dev/sdb. When I tried running Arch from the drive, I guess it was "looking" for /dev/sdc in some way, but since there were only 2 drives, it wasn't finding it.
TL;DR In any case, I just completely reinstalled Arch onto my external drive, ensuring that it was labelled as /dev/sdb, by exchanging the ports that my live CD and my external drive used.
Offline
As mentioned and implied in the responses you've been given, this isn't really a solution because this order isn't guaranteed, even if you remain in your current USB ports, chances are that udev might initialize one or the other first, which is why you should be using UUIDs and not /dev/sdX in any configuration where you have to accurately access the correct disk.
Offline