Grub can't boot a gpt external USB drive. Tells me device not found.

Terry Coats · 07-24-2019, 04:57 AM

I bought a new external USB disk drive to put various
distros on to play with and try out. I didn't think about
what I was buying because Linux usually handles anything.
It turned out to be a gpt drive, something I've never had
to deal with before. It's a 4 terabyte drive. Here's what
my linuxfromscratch-8.3 says it is:

Code:

terry [ ~ ]$lsusb
...........
0bc2:331a Seagate RSS LLC
...........

I did some reading up on it and partitioned it into 5
partitions. 4 that I formatted into ext4 and a smaller
100 megabyte partition in case I needed some boot stuff.
Here's what fdisk shows on the drive:

Code:

 Disk /dev/sdb: 3.7 TiB, 4000787029504 bytes, 7814037167 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: E79FD96E-32F6-41B9-9471-36742AB20DE6

Device          Start        End    Sectors   Size Type
/dev/sdb1      206848 1953509375 1953302528 931.4G Linux root (x86)
/dev/sdb2  1953509376 3907016703 1953507328 931.5G Linux filesystem
/dev/sdb3  3907016704 5860524031 1953507328 931.5G Linux filesystem
/dev/sdb4  5860524032 7814035455 1953511424 931.5G Linux filesystem
/dev/sdb5        2048     206847     204800   100M BIOS boot

Partition table entries are not in disk order.

sdb1 thru sdb4 work just fine for reading and writing data.
I installed a distro on sdb1, MX Linux to try out. No problems
there as far as I could tell. It seemed to install fine from
the dvd. Here's what /boot on the drive shows:

Code:

terry [ ~ ]$ ls /mnt/gpt1/boot
total 64220
drwxr-xr-x  3 root root     4096 May 17 14:35 .
drwxr-xr-x 22 root root     4096 Jul 22 11:52 ..
-rw-r--r--  1 root root   206241 May 15 16:29 config-4.19.0-5-amd64
drwxr-xr-x  3 root root     4096 May 11 16:09 grub
-rw-r--r--  1 root root 56631262 May 17 14:35 initrd.img-4.19.0-5-amd64
-rw-r--r--  1 root root   182704 Jun 25  2015 memtest86+.bin
-rw-r--r--  1 root root   184840 Jun 25  2015 memtest86+_multiboot.bin
-rw-r--r--  1 root root  3304239 May 15 16:29 System.map-4.19.0-5-amd64
-rw-r--r--  1 root root  5228416 May 15 16:29 vmlinuz-4.19.0-5-amd64

Everything necessary seems to be there.
I do the grub2 stuff from my Ubuntu system
on sda1 because that's where this current incarnation
of various Linux distros started.
From Ubuntu I ran "update-grub" so it could pick up the
new MX Linux distro and add it to the menu of bootable
systems. It saw the MX I installed to sdb1 and added it
to the grub menu. Here's what it says is there:

Code:

menuentry 'MX 18.3 Continuum (18.3) (on /dev/sdb1)' --class mx --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-simple-1d88c0e8-9d75-4832-896c-3a06cdbc795a' {
        insmod part_gpt
        insmod ext2
        insmod usb
        set root='hd1,gpt1'
        if [ x$feature_platform_search_hint = xy ]; then
          search --no-floppy --fs-uuid --set=root --hint-bios=hd1,gpt1 --hint-efi=hd1,gpt1 --hint-baremetal=ahci1,gpt1  1d88c0e8-9d75-4832-896c-3a06cdbc795a
        else
          search --no-floppy --fs-uuid --set=root 1d88c0e8-9d75-4832-896c-3a06cdbc795a
        fi
        linux /boot/vmlinuz-4.19.0-5-amd64 root=/dev/sdb1
        initrd /boot/initrd.img-4.19.0-5-amd64
}
submenu 'Advanced options for MX 18.3 Continuum (18.3) (on /dev/sdb1)' $menuentry_id_option 'osprober-gnulinux-advanced-1d88c0e8-9d75-4832-896c-3a06cdbc795a' {
        menuentry 'MX 18.3 Continuum (18.3) (on /dev/sdb1)' --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-/boot/vmlinuz-4.19.0-5-amd64--1d88c0e8-9d75-4832-896c-3a06cdbc795a' {
                insmod part_gpt
                insmod ext2
                insmod usb
                set root='hd1,gpt1'
                if [ x$feature_platform_search_hint = xy ]; then
                  search --no-floppy --fs-uuid --set=root --hint-bios=hd1,gpt1 --hint-efi=hd1,gpt1 --hint-baremetal=ahci1,gpt1  1d88c0e8-9d75-4832-896c-3a06cdbc795a
                else
                  search --no-floppy --fs-uuid --set=root 1d88c0e8-9d75-4832-896c-3a06cdbc795a
                fi
                linux /boot/vmlinuz-4.19.0-5-amd64 root=/dev/sdb1
                initrd /boot/initrd.img-4.19.0-5-amd64
        }
}

The problem is when I try to boot this selection from the
grub boot menu I am told that the device is not found and
it refers to the uuid 1d88c0e8-9d75-4832-896c-3a06cdbc795a.
I don't understand. When "update-grub" was run it certainly
saw this uuid because it wrote it in grub.cfg.I also get
messages that the partition is not found and "kernel must be loaded first"
I suspect this is related to the fact that the disk is
gpt and needs some special magic but I don't know.
I'm fairly knowledgeable with Linux having used it for
years but this one has me stumped. Can anyone help?

syg00 · 07-24-2019, 05:12 AM

gpt disks need a partition for the boot code to be installed into. For BIOS you need a BIOS_BOOT partition rather than using the "spare" sectors after the MBR.
For UEFI, you need a EFI partition for the loader code.

colorpurple21859 · 07-24-2019, 05:24 AM

Grub maybe switching the boot order when the usb drive is plugged, where the usb is hd0 and the internal drive is hd1. My system does this when a usb is plugged in and that is where the search uuid stuff comes into play in the grub menus. Maybe changing set root=(hd1,1) to set root=(hd0,1) will work.
use blkid /dev/sdb to check the uuids of the usb partitions.

Terry Coats · 07-24-2019, 07:11 AM

Quote:

Originally Posted by syg00

gpt disks need a partition for the boot code to be installed into. For BIOS you need a BIOS_BOOT partition rather than using the "spare" sectors after the MBR.
For UEFI, you need a EFI partition for the loader code.

partition 5 is marked bios boot

Code:

/dev/sdb5        2048     206847     204800   100M BIOS boot

If grub isn't writing anything there I don't know how to make it.

BW-userx · 07-24-2019, 07:23 AM

if you are going to boot a usb OS, I'd suggest you install your grub on that drive as well, no matter if it is UEFI or MBR. that way all you got a do is point your BIOS to that drive and its grub will do the rest.

Just keep in mind when you update your grub it is going to pick up every OS that it knows and add it to its listings as well.

Terry Coats · 07-24-2019, 07:23 AM

Quote:

Originally Posted by colorpurple21859

Grub maybe switching the boot order when the usb drive is plugged, where the usb is hd0 and the internal drive is hd1. My system does this when a usb is plugged in and that is where the search uuid stuff comes into play in the grub menus. Maybe changing set root=(hd1,1) to set root=(hd0,1) will work.
use blkid /dev/sdb to check the uuids of the usb partitions.

The drive's uuid never changes. I've checked many times
and the partition always remains hd1,1

colorpurple21859 · 07-24-2019, 10:27 AM

what I was suggesting was at the grub menu when you first boot, press e to edit the mx menu entry and change to root=(hd0,1), to see if that works.
post the output of

Code:

sudo blkid /dev/sdb

Terry Coats · 07-24-2019, 12:46 PM

Quote:

Originally Posted by colorpurple21859

what I was suggesting was at the grub menu when you first boot, press e to edit the mx menu entry and change to root=(hd0,1), to see if that works.
post the output of

Code:

sudo blkid /dev/sdb

root=(hd0,1) gives the same error message device not found.

Code:

terry [ ~ ]$ sudo blkid /dev/sdb
/dev/sdb: PTUUID="e79fd96e-32f6-41b9-9471-36742ab20de6" PTTYPE="gpt"

colorpurple21859 · 07-24-2019, 02:12 PM

try: set root=(hd0) or (hd1)
and or search --no-floppy --fs-uuid --set=root 1d88c0e8-9d75-4832-896c-3a06cdbc795a
to

Code:

search --no-floppy --fs-uuid --set= e79fd96e-32f6-41b9-9471-36742ab20de6

Terry Coats · 07-24-2019, 06:31 PM

Quote:

Originally Posted by colorpurple21859

try: set root=(hd0) or (hd1)
and or search --no-floppy --fs-uuid --set=root 1d88c0e8-9d75-4832-896c-3a06cdbc795a
to

Code:

search --no-floppy --fs-uuid --set= e79fd96e-32f6-41b9-9471-36742ab20de6

I tried those suggestions. Still get device not found error
message. Grub boot seems to not see the hardware in the first place,
let alone the file systems on it. Which doesn't make sense to me
because all the tools for looking at devices see the drive and
its partitions.

colorpurple21859 · 07-24-2019, 08:30 PM

at the grub menu press c for a grub prompt then

Code:

ls

This will give a list of drives and partitions that grub sees. If the usb isn't seen either there is some grub module that needs to loaded at the grub menu, or there is a setting in your bios that needs to be changed.

syg00 · 07-24-2019, 11:12 PM

Quote:

Originally Posted by Terry Coats

partition 5 is marked bios boot

- how'd I miss that ...

Quote:

If grub isn't writing anything there I don't know how to make it.

Let's see what the output of bootinfoscript is - a variant of it may even be in Ubuntu repos.

tofino_surfer · 07-25-2019, 02:55 PM

You should probably load the ehci host controller interface module manually in the grub entries.

insmod ehci

xhci is used for USB3.0 but doesn't appear to be supported by grub2 yet. The ehci interface is older but many motherboards have a ehci compatibility mode for xhci controllers. Unfortunately many new motherboards are xhci only meaning there isn't any grub support.

Quote:

gpt disks need a partition for the boot code to be installed into. For BIOS you need a BIOS_BOOT partition rather than using the "spare" sectors after the MBR
For UEFI, you need a EFI partition for the loader code.

This is only if you are actually booting from the disk. The OP is trying to boot from grub on sda. sdb in this case is just another disk. It doesn't need to have grub installed on it. If you have multiple disks you only need grub2 to be installed on one of them as grub2 can read partitions on other disks by searching for the UUID.

Quote:

I do the grub2 stuff from my Ubuntu system on sda1 because that's where this current incarnation of various Linux distros started. From Ubuntu I ran "update-grub" so it could pick up the new MX Linux distro and add it to the menu of bootable systems. It saw the MX I installed to sdb1 and added it to the grub menu.

tofino_surfer · 07-25-2019, 06:33 PM

The following page explains the grub2 (lack of) support for xhci and USB3.0

https://unix.stackexchange.com/quest...ie-card/323080

Linux itself has had xhci support for quite some time. My Gigabyte Z68 MB is from 2011 with xhci USB3.0 controllers

Code:

$ lspci -k
05:00.0 USB controller: Etron Technology, Inc. EJ168 USB 3.0 Host Controller (rev 01)
        Subsystem: Gigabyte Technology Co., Ltd Device 5007
        Kernel driver in use: xhci_hcd
06:00.0 USB controller: Etron Technology, Inc. EJ168 USB 3.0 Host Controller (rev 01)
        Subsystem: Gigabyte Technology Co., Ltd Device 5007
        Kernel driver in use: xhci_hcd

However grub2 has not yet developed xhci support after many years and was relying on ehci controllers in a sort of compatibility mode created to support older OS such as Windows 7. If the OP has a new xhci only MB they would have to try using the firmware's own drivers.

tofino_surfer · 07-25-2019, 07:23 PM

Quote:

The problem is when I try to boot this selection from the grub boot menu I am told that the device is not found and it refers to the uuid 1d88c0e8-9d75-4832-896c-3a06cdbc795a. I don't understand. When "update-grub" was run it certainly saw this uuid because it wrote it in grub.cfg.

This is very easy to explain. Linux itself has no problems with xhci and USB3. "update-grub" and os-prober run in Linux on Ubuntu. However at boot time it is the grub2 bootloader's capability of interfacing with the xhci controller that matters. If you have an older motherboard that has an ehci compatibility controller then putting insmod ehci in the stanza may solve your problem. If you have a newer xhci-only motherboard then you will have great difficulty.

There is a large difference between the grub2 configuration tools which run on Linux and the grub2 bootloader itself. Linux has xhci support. Grub2 does not.

The following is quite wrong. /dev/sdb is the drive itself.

Code:

$ sudo blkid /dev/sdb
/dev/sdb: PTUUID="e79fd96e-32f6-41b9-9471-36742ab20de6" PTTYPE="gpt"

search --no-floppy --fs-uuid --set= e79fd96e-32f6-41b9-9471-36742ab20de6

PTUUID is the Partition Table UUID. There is no filesystem in the partition table.

MX Linux is on /dev/sdb1

Code:

menuentry 'MX 18.3 Continuum (18.3) (on /dev/sdb1)'
...
set root='hd1,gpt1'
search --no-floppy --fs-uuid --set=root 1d88c0e8-9d75-4832-896c-3a06cdbc795a

It was right the first time. Grub can't find this partition at boot time as it doesn't have the low level module for the host controller interface.

Quote:

It turned out to be a gpt drive, something I've never had to deal with before. It's a 4 terabyte drive.

Your problems have nothing to do with the type of partition table on this drive. If you bought a smaller 2TB USB3 drive and formatted it with MBR partitions you would still have the same problems. You never mentioned that it is USB3 so I am assuming anything this large and new would be USB3. USB3 uses xhci controllers. It is the grub2 support of xhci that is the issue.