Re: Fw: Fw: Grub cannot see my new hard drive
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.
Reply to: