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

bodge99 · 07-29-2019, 02:28 PM

Hi,

I tried every combination, "straight" GPT, GPT with BIOS partition and a couple of "home brew" hybrids that I used to use to get around certain BIOS bugs on older kit. Most of this stuff has been relegated to the spares bin now as I've replaced stuff with newer kit. I never did get round to disassembling the BIOS though.. Ho hum..

Bodge99

Shadow_7 · 07-30-2019, 04:23 AM

Quote:

Originally Posted by tofino_surfer

Also if you read the first post the OP has a 4TB external drive so they need to use GPT.

Not technically true. They could format it DOS, ...but... they'd only be able to use the first 2TB of space. And even that's not technically true as they could dd all the live long day to the 2TB of space not in the DOS partition table. Although not that useful for most folks.

I suspect a BIOS/UEFI issue. Grub can boot gpt drives. But the bios may not be able to load grub from anything other than DOS partitioned drives. I have a few (relatively modern) computers that exhibit this behavior. Which is why I almost always use small USB sticks and format them DOS for my linux OSes. Which I then mount other drives including GPT formatted ones from and use. I don't need my OS drive to be 4TB. 32GB suffices in most cases. Anything more and I put /home/ or something under /home/ on another drive and mount it before that user logs in.

bodge99 · 07-30-2019, 09:46 AM

Hi.

I agree with tofino_surfer. This is not a GPT/MBR problem. This is a Grub problem due to the lack of an xhci module for USB3 support.

My understanding is that some UEFI firmwares would directly support either embedded or expansion card USB3 (or both). I also understand that UEFI firmware support varies considerably across differing hardware. i.e. the same USB3 expansion card ("pure" xhci) will be supported on some motherboards but not on others.
Support can also differ between legacy and UEFI modes on the same board.

I'll only state that "something" is true if I've proved it myself on my hardware. Even then I'll give the caveat that I am talking about my kit only.. although in most cases what works with my stuff should work elsewhere (as long as I'm not relying on UEFI functionality etc.).

What I have seen and can categorically state as fact is that some UEFI firmwares are very poor quality indeed.
I've spent some time reverse engineering some 32bit UEFI tablet firmwares with a view to replacing them with 64bit versions. I ended up viewing the original firmware code quality as barely alpha quality. I still don't understand how code of this quality was ever released.

Bodge99

tofino_surfer · 07-30-2019, 10:28 AM

Quote:

I suspect a BIOS/UEFI issue. Grub can boot gpt drives. But the bios may not be able to load grub from anything other than DOS partitioned drives.

You haven't read the first post in this thread. The OP has never installed grub on the GPT drive. They are using the same grub installation on their main sda drive in the computer itself, that boots Ubuntu. They booted into Ubuntu and ran update-grub which calls os-prober which detected the MX Linux installation on the external drive.

Quote:

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
}

Their main internal drive sda has the grub installation. Due to lack of xhci support grub2 can't find and read the root partition with the given UUID. The grub bootloader has already been loaded into memory through the sda installation.

Quote:

Not technically true. They could format it DOS, ...but... they'd only be able to use the first 2TB of space.

Who would do this and waste half of the disk space for which they paid ? At worst they could copy the kernels and initrds from the external drive to sda in the Ubuntu partition, boot from there, and then simply mount the / partition on the USB3 drive as well as /home and others.

colorpurple21859 · 07-30-2019, 10:39 AM

With it booting from super-grub, I still think a grub-module needs to be loaded. Plug the drive in the usb2 port, at the ubuntu grub prompt

Code:

insmod part_gpt
insmod usb
insmode ehci
ls

see if the usb drive partitions are listed.
If the usb drive partitions are still not seen, and they are from the grub prompt of super-grub

Code:

set pager=1
lsmod

take note of the loaded modules from ubuntu grub-prompt compared to super-grub grub-prompt

Quote:

At worst they could copy the kernels and initrds from the external drive to sda in the Ubuntu partition,

And/ or if there is room create a boot partition for the external drive on the internal drive and mount to /boot on the external drive.

business_kid · 07-31-2019, 03:10 PM

Strewth! 49 posts! Still nobody's got him booting. No wonder he's giving it a rest. (post 42)

Booting off a 4TB usb drive is one of those catch-22 things on pcs, isn't it? You can boot a usb disk (from the pc bios) but that just boots the first block. That means you boot, say /dev/sdb, but not /dev/sdb1, or not lilo or grub. If you divide the disk, the boot pukes on the partition table.

You need modules to read usb, but before you can stick in a module, you need a kernel, & initrd or module tree - catch 22. Better folks than I have flattened their heads off that particular brick wall.

I would make a common boot on the internal disk, with all kernels, and an initrd & System.map for each, and put all kernels there, and specify the usb UUID for the drive. That should work, unless efi gets in the way. Without the drive, those options wouldn't be valid. Then he can have as many ultra-slow loading distros as he fancies, and remember to take a weekend away any time he runs e2fsck.

bodge99 · 07-31-2019, 03:52 PM

Hi,

I hope you'll agree that some of us here recognise the exact problem.. The newer ("pure" xhci) USB3 hardware is only supported by the kernel (when started) or by UEFI firmware, possibly not in Legacy mode and possibly not with USB3 expansion cards.

I'd say your thinking is perfectly valid and is close to what I'm proposing.. Some folk reading this would see how to proceed from here (on a practical level, altering the boot loader configs, placing kernels et. al. etc.). Some folk who are newer to Linux may find a more complete solution more helpful.
There is nothing more discouraging to a new Linux user than finding that their (possibly newer) kit doesn't work properly without significant help from the good folk on forums such as this one.

I personally like solving problems.. this is what kick-started my interest in Linux originally. Linux gives me the tools to do this. If I can give a generic solution that is applicable to other folks problems then I'm more than happy.

I've ordered a USB3 expansion card. I'm going to experiment with this card in a few computers to prove my idea for a more general solution that will be easily applied to any working system.

Bodge99

tofino_surfer · 07-31-2019, 04:04 PM

Quote:

Booting off a 4TB usb drive is one of those catch-22 things on pcs, isn't it? You can boot a usb disk (from the pc bios) but that just boots the first block. That means you boot, say /dev/sdb, but not /dev/sdb1, or not lilo or grub. If you divide the disk, the boot pukes on the partition table.

You still haven't read or understood the posts in this thread. The OP isn't actually booting from this external USB drive as they never installed Grub on this drive. They are booting from the Ubuntu grub.cfg on their main internal drive. os-prober detected this installation. Read the first post and my post #49. Grub is loading from the internal drive and trying to access the kernel and initrd on the USB3 drive. However since grub2 has no xhci support it can't find the USB3 disk.

Also you don't seem to understand how legacy BIOS works. It doesn't understand any type of partition table. On a GPT drive the grub2 second stage core.img file is placed in a 1 MB BIOS Boot partition which is pointed to by the first stage in the protective MBR. Once core.img is loaded into memory grub takes over. Grub2 can understand GPT and MBR partition tables so grub has no problems with partitions.

Quote:

You need modules to read usb, but before you can stick in a module, you need a kernel, & initrd or module tree - catch 22. Better folks than I have flattened their heads off that particular brick wall.

You are confusing Linux kernel modules with grub2 modules. Grub2 has a module for ehci used for USB2. Grub2 should be capable of booting off of USB2.

Terry Coats · 07-31-2019, 09:42 PM

Supergrubdisk will boot the MX Linux system on the /dev/sdb1
gpt 4 terabyte drive. It boots it while plugged into an USB
3.0 port. I can't figure out what parameters it is using
to do so because supergrubdisk hides them in variables instead
of the actual values. It tells what is happening but the
info flys by so fast on the screen I cannot read it. If I
could figure out how to redirect that info to a file I
would do so.So, i know it is possible to make this work as
supergrubdisk is doing it but doesn't show me how. As for
now when I want to use the systems on the gpt drive I guess
I'll use supergrubdisk when I need it but I'd still like to
know why grub's "grub-mkconfig" doesn't write a grub.cfg
for that is useful for that gpt drive.
Thanks, all.

Shadow_7 · 08-01-2019, 09:32 AM

There's various grub things. grub-rescue to create el torito images for optical discs. update-grub to create a grub.cfg for your current environment. I'll often use that (in a chroot) to create the grub.cfg and boot that grub.cfg from another grub disc (and different grub.cfg). Via the configfile option in the "c"ommand mode of grub.

I suspect that your supergrubdisk is NOT gpt formated.

# blkid

Which is why it works for you.

Long ago (pre-2006) I had a laptop that would not boot from USB. But I used a grub optical disc to boot the USB and that worked fine for me for at least a year. It was an old laptop and the fan wasn't working for at least a year, if not three years. It worked fine for email, game guides, and other simple things. Eventually it got hot enough to influence the stability of the USB ports, and was no longer reliable enough to bother trying.

tofino_surfer · 08-01-2019, 11:54 AM

Quote:

I suspect that your supergrubdisk is NOT gpt formated.

It is a bootable .iso file just like any OS .iso file. There is no reason to suspect anything. You can easily look at the contents of the supergrubdisk .iso by simply mounting it with mount -t iso9660 or by simply calling mount with the .iso file name and a mountpoint as mount can usually figure out the filesystem.

This is what the OP should do to find out what this disk is doing and how it is successfully booting USB3 ports. I did this once. This rescue disk is filled with scripts in the grub2 scripting language.

Quote:

Which is why it works for you.

This is quite nonsensical. Are you saying that GPT disks can't be booted from USB ? Legacy BIOS can't tell the difference between MBR and GPT.

Quote:

Long ago (pre-2006) I had a laptop that would not boot from USB. But I used a grub optical disc to boot the USB and that worked fine for me for at least a year.

There is a very simple explanation for this. Older computers can't boot from USB as the BIOS didn't support this yet. The optical disc was IDE or SATA. The grub on this disk had usb and ehci drivers and so could boot from USB2 ports.

Terry Coats · 08-01-2019, 03:03 PM

Quote:

Originally Posted by tofino_surfer

It is a bootable .iso file just like any OS .iso file. There is no reason to suspect anything. You can easily look at the contents of the supergrubdisk .iso by simply mounting it with mount -t iso.

This is what the OP should do to find out what this disk is doing and how it is successfully booting USB3 ports. I did this once. This rescue disk is filled with scripts in the grub2 scripting language.

This is quite nonsensical. Are you saying that GPT disks can't be booted from USB ? Legacy BIOS can't tell the difference between MBR and GPT.

There is a very simple explanation for this. Older computers can't boot from USB as the BIOS didn't support this yet. The optical disc was IDE or SATA. The grub on this disk had usb and ehci drivers and so could boot from USB2 ports.

Thanks for the tip. I'll get around to looking at the scripts on the supergrubdisk.

Shadow_7 · 08-01-2019, 04:05 PM

Quote:

Originally Posted by tofino_surfer

This is quite nonsensical. Are you saying that GPT disks can't be booted from USB ? Legacy BIOS can't tell the difference between MBR and GPT.

They can on SOME hardware and SOME implementations of UEFI. But not all. And for some implementations that depends on settings. Like Secure Boot ON/OFF, or LSM/Legacy ON/OFF. In the case of my HP laptops, I have to delete known keys for Secure boot and legacy to even be change-able in a way that persists between boots / reboots. The only black or white is that it WORKS or it DOES NOT. The details of which are relatively insignificant. And in the case of GPT, it "MIGHT".

bodge99 · 08-09-2019, 07:43 AM

Hi,

My USB3 pci-e card arrived last week and I've been playing around with it..

My initial thoughts i.e. booting an external device from this USB3 card works.. mostly..

Testing hardware: 3 legacy/MBR machines, 4 UEFI machines (2 running in legacy/mbr mode and 2 in UEFI/GPT mode.). A Linux Mint 19.1 installation has been placed on an SSD drive in a USB caddy.

As expected, Grub doesn't see the the USB3 card at all on a cold boot with any machine. Grub does see the card on one UEFI machine when warm booted.

Copying the kernel & initrd from the USB3 external drive Mint installation to a separate directory on the main machine and using a modified grub.cfg works mostly as expected on two of the legacy machines and two of the UEFI ones (one in legacy mode and one UEFI). Some of the UEFI firmware detects anything on the USB3 ports and alters the firmware hardware detection order. This then affects what Grub sees on a warm boot. These are on Slackware machines so I'll retry when I've converted the fstab's to use UUID's.

One of the UEFI machines doesn't want to work with the USB3 card at all.. I'll view this as "work in progress".

I'll continue experimenting when I've got a little spare time..

Bodge99

tofino_surfer · 08-09-2019, 11:43 PM

Quote:

They can on SOME hardware and SOME implementations of UEFI. But not all. And for some implementations that depends on settings. Like Secure Boot ON/OFF, or LSM/Legacy ON/OFF. In the case of my HP laptops, I have to delete known keys for Secure boot and legacy to even be change-able in a way that persists between boots / reboots. The only black or white is that it WORKS or it DOES NOT. The details of which are relatively insignificant. And in the case of GPT, it "MIGHT".

These comments have virtually nothing to do with the OPs problem in this thread. The OP is using legacy BIOS so all of the comments about Secure Boot and keys are irrelevant. The issue is booting from an external USB3 port and grub's non-support of the xhci protocol.