Nothing seems good enough. Do you want a picture? I'm not typing all of that in on my tablet. Let's just let it go. I'm working on understanding grub. I'm going to boot from a USB flash drive.
name=Matthew%20Campbell&email=trenix25%40pm.me -------- Original Message -------- On Jul 3, 2020, 7:37 AM, David Wright wrote: > On Thu 02 Jul 2020 at 21:17:57 (+0000), Matthew Campbell wrote: >> On Jul 2, 2020, 1:08 PM, David Wright wrote: >> > On Thu 02 Jul 2020 at 08:12:00 (+0000), Matthew Campbell wrote: >> >> On Jul 1, 2020, 7:50 PM, David Wright wrote: >> >> > On Wed 17 Jun 2020 at 05:14:22 (+0000), Matthew Campbell wrote: >> >> >> […] >> >> >> I booted from a USB 2.0 flash drive into Grub2. >> >> >> […] >> >> >> /dev/sdb is the new 4 TB Toshiba External USB 3.0 hard drive. >> >> >> […] >> >> >> The hard drive, /dev/sdb, always responds faster than the USB flash >> >> >> drives so it is always /dev/sdb. >> >> >> >> >> >> Now Debian Linux is running on my new hard drive using /dev/sdb1 as >> >> >> the root partition. >> > […] >> >> The 4 TB hard drive uses a GPT type partition table, not an MBR type >> >> table, which is why the computer can't see it. It can't make sense of GPT >> >> tables. >> > >> > If your computer can't make sense of GPT tables, how are you able to >> > run Debian Linux from its first partition? >> > >> > I think what you might be trying to say is that you haven't managed to >> > boot from a GPT disk connected by USB. But if you can boot with Grub >> > from an MBR stick, that suggests that something is missing on your >> > GPT disk. >> > >> > Have you tried to install Grub on your 4TB disk? What did it say? >> > Were there any error messages. >> > >> > How is this disk partitioned? Did you do it, or is it just as it >> > was bought? I'll give you an example of how I have system disks >> > partitioned. You don't necessarily have to follow it, but it might >> > help you to deal with yours. >> > >> > --✄-------- >> > […] >> > --✄-------- >> > >> > This drive is inside a 2000-built PC. (It can't boot from any sort of >> > USB device.) The second partition table shows the protective MBR, >> > which contains the Grub code for the PC to boot from. >> > >> > The first partition table is the GPT one. Partitions 4 and 5 are >> > for root filesystems, one for stretch and one for buster. When >> > bullseye is released, I'll most likely overwrite the stretch one. >> > Partition 3 is for swap, and 6 is for /home. Both these are encrypted >> > in different ways. >> > >> > That leaves the more interesting ones. Partition 2 is to enable the >> > drive to be used to boot an EFI system, and is obviously unused by >> > this PC. (I could "borrow" it for more swap, but the PC only has >> > 500MB memory, so probably pointless for the tasks it does.) >> > >> > Partition 1 is where Grub puts the Second Stage code that it requires >> > to read the disk partition table and filesystems, so that it can find >> > grub.cfg, the kernel and initrd. On a "real" MBR disk, there is >> > typically plenty of room between the partition table and the first >> > partition for this code, but on a GPT disk, that space is where >> > the partition table itself resides; so Grub has to find somewhere >> > else. That's what partition 1 is for. >> > >> > My *guess* is that your Grub is booting ok, but has no (or little) >> > Second Stage code to determine anything about the drives beyond >> > their existence, so you just get the Grub prompt. >> > >> > Note that it's not important where Grub puts its code, only that >> > there is some space somewhere. On this laptop, my BIOS Boot >> > partition is sda9, because BIOS booting was late to the party >> > on what was bought as a Windows/EFI/GPT machine. > >> The computer's startup/settings menu does not detect the 4 TB drive so it >> does not list it as a bootable device. > > Yes, I have no idea what criteria it uses to display devices, > nor whether it can display more than one device, nor whether > the connection type matters, and so on. > >> I cannot boot from the 4 TB drive. > > We gathered that, hence the thread. > >> It gives me an error saying that it cannot find the file system UUID >> (whatever code for /dev/sdb1) > > I have no idea what UUID values it's looking for, nor what you have > available. Were you to try the method I suggested earlier, you > wouldn't have to worry about all that stuff. It just gets in the way > at this stage. You know what partitions should be present as you've > just looked at them with Grub's ls. > >> when grub starts from /dev/sda. > > A fortnight ago, you said that you reconfigured Grub to boot > the 4TB drive. We have no idea what that reconfiguration looked > like, what was found by probing, nor whether it's correct. > >> It then gets confused and supports nothing. > > Metaphors like that communicate nothing at all to me. > >> fdisk does not offer an option to make /dev/sdb1 bootable/active. > > Eh? /dev/sdb1 is your Linux root filesystem on a GPT disk. The only > boot flag for GPT is on the EFI System partition, which can't also > be in /dev/sdb1. You need to run fdisk -t dos /dev/sdX so that > fdisk doesn't use the wrong partition table. (IIRC you can't do it > if you switch into MBR mode in fdisk.) I presume you didn't. That's > why it's important to know what you did, not what you think you did > and what you believe to be true. > >> I used 17 different partitions on /dev/sdb, the first of which starts 1 MiB >> in. > > Sure. So I presume you have 4096-byte sectors and the first partition > starts at 256? You know exactly how my disk is partitioned. I have > almost no idea about yours. I'm tired of guessing, and posing > questions that try to take into account all possibilities so that > vague answers might reveal something. > > Cheers, > David.
