Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #223568 > unrolled thread

Re: Grub cannot see my new hard drive

Back to article view | Back to linux.debian.user

Contents

  Re: Grub cannot see my new hard drive Matthew Campbell <trenix25@pm.me> - 2020-06-17 07:20 +0200
    Re: Grub cannot see my new hard drive deloptes <deloptes@gmail.com> - 2020-06-17 08:50 +0200
      Re: Fw: Grub cannot see my new hard drive deloptes <deloptes@gmail.com> - 2020-06-18 07:00 +0200
    Re: Grub cannot see my new hard drive David Wright <deblis@lionunicorn.co.uk> - 2020-07-02 05:00 +0200
      Fw: Grub cannot see my new hard drive Matthew Campbell <trenix25@pm.me> - 2020-07-02 10:20 +0200
        Re: Fw: Grub cannot see my new hard drive "Thomas Schmitt" <scdbackup@gmx.net> - 2020-07-02 11:20 +0200
        Re: Fw: Grub cannot see my new hard drive David Christensen <dpchrist@holgerdanske.com> - 2020-07-02 21:00 +0200
          Fw: Fw: Grub cannot see my new hard drive Matthew Campbell <trenix25@pm.me> - 2020-07-02 23:20 +0200
        Re: Fw: Grub cannot see my new hard drive David Wright <deblis@lionunicorn.co.uk> - 2020-07-02 22:10 +0200
          Fw: Fw: Grub cannot see my new hard drive Matthew Campbell <trenix25@pm.me> - 2020-07-02 23:20 +0200
            Re: Fw: Fw: Grub cannot see my new hard drive David Wright <deblis@lionunicorn.co.uk> - 2020-07-03 16:40 +0200
              Fw: Fw: Fw: Grub cannot see my new hard drive Matthew Campbell <trenix25@pm.me> - 2020-07-03 19:30 +0200
                Re: Fw: Fw: Fw: Grub cannot see my new hard drive deloptes <deloptes@gmail.com> - 2020-07-03 21:10 +0200
                  Re: Grub cannot see my new hard drive David Wright <deblis@lionunicorn.co.uk> - 2020-07-04 04:00 +0200
                    Re: Grub cannot see my new hard drive deloptes <deloptes@gmail.com> - 2020-07-04 08:00 +0200
                      Re: Grub cannot see my new hard drive "Thomas Schmitt" <scdbackup@gmx.net> - 2020-07-04 09:00 +0200
                        Re: Grub cannot see my new hard drive deloptes <deloptes@gmail.com> - 2020-07-04 09:10 +0200

#223568 — Re: Grub cannot see my new hard drive

[Multipart message — attachments visible in raw view] — view raw

I'm starting a fresh thread for this.

I booted from a USB 2.0 flash drive into Grub2. Then I asked Grub for a command prompt. Then I issued the following three commands:

grub> linux (hd2,msdos1)/vmlinuz root=/dev/sdb1 ro
grub> initrd (hd2,msdos1)/initrd.img
grub> boot

/dev/sda is the internal hard drive in the laptop computer.
/dev/sdb is the new 4 TB Toshiba External USB 3.0 hard drive.

/dev/sdc and /dev/sdd are currently USB 2.0 flash drives with an ext4 file system on the first and only partition. Both use a DOS MBR partition table that sets the first partition as active/bootable.

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. I need to set up a separate USB flash drive to do all of this by default so I don't have to do all of this work every time the computer boots up. I also need to install Grub2 on the backup USB flash drive so I can use it to boot my system if something goes wrong and the first USB flash drive that I just used gets screwed up as well.

name=Matthew%20Campbell&email=trenix25%40pm.me

[toc] | [next] | [standalone]

#223571

[Multipart message — attachments visible in raw view] — view raw

Matthew Campbell wrote:

> Now Debian Linux is running on my new hard drive using /dev/sdb1 as the
> root partition. I need to set up a separate USB flash drive to do all of
> this by default so I don't have to do all of this work every time the
> computer boots up. I also need to install Grub2 on the backup USB flash
> drive so I can use it to boot my system if something goes wrong and the
> first USB flash drive that I just used gets screwed up as well.

you better find out how to install properly grub2. I suggest using UUIDs -
it will save you a lot of troubles - especially on removable devices.

I attach here my notes regarding GPT and removable or not removable disks -
I hope it helps.

[toc] | [prev] | [next] | [standalone]

#223615

Matthew Campbell wrote:

> My computer cannot see a GPT partition table. I've had to use a dos MBR
> partition table on my USB flash drives. I mount my file systems as
> read-only first so I can check them after booting before remounting them
> read-write.

I am sorry to say it, but you are not able to understand.

[toc] | [prev] | [next] | [standalone]

#224278

On Wed 17 Jun 2020 at 05:14:22 (+0000), Matthew Campbell wrote:
> 
> I booted from a USB 2.0 flash drive into Grub2. Then I asked Grub for a command prompt. Then I issued the following three commands:
> 
> grub> linux (hd2,msdos1)/vmlinuz root=/dev/sdb1 ro
> grub> initrd (hd2,msdos1)/initrd.img
> grub> boot
> 
> /dev/sda is the internal hard drive in the laptop computer.
> /dev/sdb is the new 4 TB Toshiba External USB 3.0 hard drive.
> 
> /dev/sdc and /dev/sdd are currently USB 2.0 flash drives with an ext4 file system on the first and only partition. Both use a DOS MBR partition table that sets the first partition as active/bootable.
> 
> 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. I need to set up a separate USB flash drive to do all of this by default so I don't have to do all of this work every time the computer boots up. I also need to install Grub2 on the backup USB flash drive so I can use it to boot my system if something goes wrong and the first USB flash drive that I just used gets screwed up as well.

Perhaps it would be simpler to use a more generic approach.
You could try installing the package grub-rescue-pc, which
contains within /usr/lib/grub-rescue/:

-rw-r--r-- 1 root root 5021696 Jun 25  2019 grub-rescue-cdrom.iso
-rw-r--r-- 1 root root 1255424 Jun 25  2019 grub-rescue-floppy.img
lrwxrwxrwx 1 root root      21 Jun 25  2019 grub-rescue-usb.img -> grub-rescue-cdrom.iso

(The exact sizes may differ according to amd64/i386 architecture.)
I copy the ISO file onto any old USB stick that's past its prime.

If that stick boots successfully, you should type:

c       for a grub prompt.
ls      to list the drives and partitions that grub can see.
ESC     to exit from the prompt.
e       to edit grub.cfg.
Change  set root=(hd0,msdos1)
to the appropriate (drive,partition) from the ls output, eg (hd1,gpt4).
Change  root=/dev/sda1
to the appropriate partition, eg sda4.
F10     to boot.
Grub uses the links in your root filesystem to find the appropriate
vmlinuz and initrd.img. (You might need hd2 and sdb1 for the first
partition on the second disk.)

Your system should now be running from the hard drive specified.

As you want to streamline this, it makes sense to change those two
lines on the stick, as appropriate. I tried this out by making a
local copy of the original grub-rescue-cdrom.iso and editing it with
emacs. I searched for the string "For boot" to get to the right place,
and edited as above. gpt4 is shorter than msdos1, so I added a couple
of spaces after the ). This makes it easier to compare the original
and the copy by typing
$ vbindiff your-copy.iso /usr/lib/grub-rescue/grub-rescue-cdrom.iso
and pressing Enter. The differences will show up in red.

(If you don't have vbindiff, just install the package vbindiff.)

Copy the modified ISO onto the stick, boot it, and press e as above.
If the menu looks correct, press F10 to boot. Next time you boot
from the stick, just pressing Return will be enough.

When the USB stick gets ropy, just copy your ISO to another one.

I didn't bother to investigate why emacs added a harmless linefeed
to the end of the edited ISO.

I'm surprised that you appear to have an MBR partition table on
the 4TB drive (hd2,msdos1). Is that right or have I misunderstood
something?

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#224288

[Multipart message — attachments visible in raw view] — view raw

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. It is a Toshiba Satellite laptop. Satellite P105-S6187, model number PSPAAU-01L00S. I just ordered new memory for it yesterday. At the moment one memory card is sitting on top of it with the cover removed. I'll be putting it back together in a moment. It was factory preloaded with Windows Vistsa.

name=Matthew%20Campbell&email=trenix25%40pm.me

-------- Original Message --------
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. Then I asked Grub for a command prompt. Then I issued the following three commands:
>>
>> grub> linux (hd2,msdos1)/vmlinuz root=/dev/sdb1 ro
>> grub> initrd (hd2,msdos1)/initrd.img
>> grub> boot
>>
>> /dev/sda is the internal hard drive in the laptop computer.
>> /dev/sdb is the new 4 TB Toshiba External USB 3.0 hard drive.
>>
>> /dev/sdc and /dev/sdd are currently USB 2.0 flash drives with an ext4 file system on the first and only partition. Both use a DOS MBR partition table that sets the first partition as active/bootable.
>>
>> 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. I need to set up a separate USB flash drive to do all of this by default so I don't have to do all of this work every time the computer boots up. I also need to install Grub2 on the backup USB flash drive so I can use it to boot my system if something goes wrong and the first USB flash drive that I just used gets screwed up as well.
>
> Perhaps it would be simpler to use a more generic approach.
> You could try installing the package grub-rescue-pc, which
> contains within /usr/lib/grub-rescue/:
>
> -rw-r--r-- 1 root root 5021696 Jun 25 2019 grub-rescue-cdrom.iso
> -rw-r--r-- 1 root root 1255424 Jun 25 2019 grub-rescue-floppy.img
> lrwxrwxrwx 1 root root 21 Jun 25 2019 grub-rescue-usb.img -> grub-rescue-cdrom.iso
>
> (The exact sizes may differ according to amd64/i386 architecture.)
> I copy the ISO file onto any old USB stick that's past its prime.
>
> If that stick boots successfully, you should type:
>
> c for a grub prompt.
> ls to list the drives and partitions that grub can see.
> ESC to exit from the prompt.
> e to edit grub.cfg.
> Change set root=(hd0,msdos1)
> to the appropriate (drive,partition) from the ls output, eg (hd1,gpt4).
> Change root=/dev/sda1
> to the appropriate partition, eg sda4.
> F10 to boot.
> Grub uses the links in your root filesystem to find the appropriate
> vmlinuz and initrd.img. (You might need hd2 and sdb1 for the first
> partition on the second disk.)
>
> Your system should now be running from the hard drive specified.
>
> As you want to streamline this, it makes sense to change those two
> lines on the stick, as appropriate. I tried this out by making a
> local copy of the original grub-rescue-cdrom.iso and editing it with
> emacs. I searched for the string "For boot" to get to the right place,
> and edited as above. gpt4 is shorter than msdos1, so I added a couple
> of spaces after the ). This makes it easier to compare the original
> and the copy by typing
> $ vbindiff your-copy.iso /usr/lib/grub-rescue/grub-rescue-cdrom.iso
> and pressing Enter. The differences will show up in red.
>
> (If you don't have vbindiff, just install the package vbindiff.)
>
> Copy the modified ISO onto the stick, boot it, and press e as above.
> If the menu looks correct, press F10 to boot. Next time you boot
> from the stick, just pressing Return will be enough.
>
> When the USB stick gets ropy, just copy your ISO to another one.
>
> I didn't bother to investigate why emacs added a harmless linefeed
> to the end of the edited ISO.
>
> I'm surprised that you appear to have an MBR partition table on
> the 4TB drive (hd2,msdos1). Is that right or have I misunderstood
> something?
>
> Cheers,
> David.

[toc] | [prev] | [next] | [standalone]

#224290

Hi,

Matthew Campbell wrote:
> 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.

Not knowing what's actually causing your problem, i have to doubt this
theory.

If the machine's firmware has no clue of GPT but of MBR partition tables,
then it would accept the "protective" partition of type 0xee in the MBR
partition table which announces the presence of GPT. (That's a legacy
precaution of GPT.)

Further, if the firmware does not know about GPT, it cannot be EFI.
Since Google reports that Toshiba P105-S6187 uses an Intel Core 2 processor,
i would then expect the firmware to be PC-BIOS.
PC-BIOS does not rely on partitions or offer a INT call to interpret a
partition table.

So it's up to the booted software to interpret partition tables and to
represent them as storage devices.
This software is supposed to be GRUB, which should be able to recognize
GPT if module part_gpt ist installed.

So i wonder: Does your GRUB configuration enable part_gpt ?
I read in the web and in Debian ISOs the line

  insmod part_gpt


Have a nice day :)

Thomas

[toc] | [prev] | [next] | [standalone]

#224299

On 2020-07-02 01:12, Matthew Campbell wrote:
> 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. It is a Toshiba Satellite laptop. Satellite P105-S6187, model number PSPAAU-01L00S. I just ordered new memory for it yesterday. At the moment one memory card is sitting on top of it with the cover removed. I'll be putting it back together in a moment. It was factory preloaded with Windows Vistsa.

I still think the best answer is to disconnect the external drives, use 
the Debian Installer rescue shell to zero-fill the internal drive, and 
install Debian on the internal drive.


David

[toc] | [prev] | [next] | [standalone]

#224307

[Multipart message — attachments visible in raw view] — view raw

For the last time, the internal hard drive will not be erased. Windows will stay on it. It will not be used for Linux. It is a really old hard drive that could fail at any moment. Linux has been and will remain installed on the external 4 TB hard drive.

name=Matthew%20Campbell&email=trenix25%40pm.me

-------- Original Message --------
On Jul 2, 2020, 11:50 AM, David Christensen wrote:

> On 2020-07-02 01:12, Matthew Campbell wrote:
>> 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. It is a Toshiba Satellite laptop. Satellite P105-S6187, model number PSPAAU-01L00S. I just ordered new memory for it yesterday. At the moment one memory card is sitting on top of it with the cover removed. I'll be putting it back together in a moment. It was factory preloaded with Windows Vistsa.
>
> I still think the best answer is to disconnect the external drives, use
> the Debian Installer rescue shell to zero-fill the internal drive, and
> install Debian on the internal drive.
>
> David

[toc] | [prev] | [next] | [standalone]

#224303

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.

--✄--------

# fdisk /dev/sda

Welcome to fdisk (util-linux 2.33.1).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.

Command (m for help): p
Disk /dev/sda: 465.8 GiB, 500107862016 bytes, 976773168 sectors
Disk model: ST3500641A      
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: A519207D-4D17-4727-A35D-55B72A0CB95B

Device         Start       End   Sectors   Size Type
/dev/sda1       2048      8191      6144     3M BIOS boot
/dev/sda2       8192   1023999   1015808   496M EFI System
/dev/sda3    1024000   2047999   1024000   500M Linux swap
/dev/sda4    2048000  63487999  61440000  29.3G Linux filesystem
/dev/sda5   63488000 124927999  61440000  29.3G Linux filesystem
/dev/sda6  124928000 976773119 851845120 406.2G Linux filesystem

Command (m for help): M
Entering protective/hybrid MBR disklabel.

Command (m for help): p
Disk /dev/sda: 465.8 GiB, 500107862016 bytes, 976773168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00000000

Device     Boot Start       End   Sectors   Size Id Type
/dev/sda1           1 976773167 976773167 465.8G ee GPT

Command (m for help): q

# 

--✄--------

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.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#224306

[Multipart message — attachments visible in raw view] — view raw

The computer's startup/settings menu does not detect the 4 TB drive so it does not list it as a bootable device. I cannot boot from the 4 TB drive. It gives me an error saying that it cannot find the file system UUID (whatever code for /dev/sdb1) when grub starts from /dev/sda. It then gets confused and supports nothing. fdisk does not offer an option to make /dev/sdb1 bootable/active. I used 17 different partitions on /dev/sdb, the first of which starts 1 MiB in.

name=Matthew%20Campbell&email=trenix25%40pm.me

-------- Original Message --------
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.
>
> --✄--------
>
> # fdisk /dev/sda
>
> Welcome to fdisk (util-linux 2.33.1).
> Changes will remain in memory only, until you decide to write them.
> Be careful before using the write command.
>
> Command (m for help): p
> Disk /dev/sda: 465.8 GiB, 500107862016 bytes, 976773168 sectors
> Disk model: ST3500641A
> Units: sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 512 bytes
> Disklabel type: gpt
> Disk identifier: A519207D-4D17-4727-A35D-55B72A0CB95B
>
> Device Start End Sectors Size Type
> /dev/sda1 2048 8191 6144 3M BIOS boot
> /dev/sda2 8192 1023999 1015808 496M EFI System
> /dev/sda3 1024000 2047999 1024000 500M Linux swap
> /dev/sda4 2048000 63487999 61440000 29.3G Linux filesystem
> /dev/sda5 63488000 124927999 61440000 29.3G Linux filesystem
> /dev/sda6 124928000 976773119 851845120 406.2G Linux filesystem
>
> Command (m for help): M
> Entering protective/hybrid MBR disklabel.
>
> Command (m for help): p
> Disk /dev/sda: 465.8 GiB, 500107862016 bytes, 976773168 sectors
> Units: sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 512 bytes
> Disklabel type: dos
> Disk identifier: 0x00000000
>
> Device Boot Start End Sectors Size Id Type
> /dev/sda1 1 976773167 976773167 465.8G ee GPT
>
> Command (m for help): q
>
> #
>
> --✄--------
>
> 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.
>
> Cheers,
> David.

[toc] | [prev] | [next] | [standalone]

#224315

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.

[toc] | [prev] | [next] | [standalone]

#224320

[Multipart message — attachments visible in raw view] — view raw

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.

[toc] | [prev] | [next] | [standalone]

#224330

Matthew Campbell wrote:

> 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.

When I want to boot from the USB drive with GPT configured I first make sure
the bios can understand GPT and then select "One Time Boot" (F12 after
power on / reboot )

I already lost the track here, but I wonder why it should be that hard for
you. I have 5 PCs around (1 server, 2 desktops and 2 notebooks) - all of
them do it the same way. Only difference is the One Time Boot key, because
it is bios specific.

If I were you I would try with USB stick of reasonable size i.e. 8-256GB
with GPT. If it does not work on the small USB with GPT - the problem seems
to be GPT.
If you can boot with GPT from the USB stick, you can repeat the
configuration on the 4TB and try the same procedure. If it fails it is
because of the 4TB disk.

Somebody mentioned grub could handle GPT. My experience (and debian
documentation) says it can handle it, if and only if it is installed from
GPT enabled machine. It is not possible to install grub on a disk for GPT
from non GPT booted machine. If my knowledge is outdated, please update me.

https://wiki.debian.org/UEFI#Booting_from_removable_media

[toc] | [prev] | [next] | [standalone]

#224339

On Fri 03 Jul 2020 at 21:04:44 (+0200), deloptes wrote:
> Matthew Campbell wrote:
> 
> > Nothing seems good enough. Do you want a picture? I'm not typing all of
> > that in on my tablet.

Some people post pictures to appropriate sites when it's not possible
to copy the text (eg, in the BIOS, running Grub, etc.) but most of
my questions can be answered with files that are still readable after
the system is up and running. They should be transferrable to a system
running an email client.

> > Let's just let it go. I'm working on understanding
> > grub. I'm going to boot from a USB flash drive.

Fair enough. That's why I'm posting examples of methods that work,
which might help in your understanding.

> When I want to boot from the USB drive with GPT configured I first make sure
> the bios can understand GPT and then select "One Time Boot" (F12 after
> power on / reboot )
> 
> I already lost the track here, but I wonder why it should be that hard for
> you. I have 5 PCs around (1 server, 2 desktops and 2 notebooks) - all of
> them do it the same way. Only difference is the One Time Boot key, because
> it is bios specific.
> 
> If I were you I would try with USB stick of reasonable size i.e. 8-256GB
> with GPT. If it does not work on the small USB with GPT - the problem seems
> to be GPT.
> If you can boot with GPT from the USB stick, you can repeat the
> configuration on the 4TB and try the same procedure. If it fails it is
> because of the 4TB disk.
> 
> Somebody mentioned grub could handle GPT. My experience (and debian
> documentation) says it can handle it, if and only if it is installed from
> GPT enabled machine. It is not possible to install grub on a disk for GPT
> from non GPT booted machine. If my knowledge is outdated, please update me.
> 
> https://wiki.debian.org/UEFI#Booting_from_removable_media

I think that giving this reference confirms that you are using "GPT"
to refer to two completely different things: the partitioning of the
disk, and the UEFI method of booting. This is confusing.

The OP has described a problem with a ~2006 laptop which, as far as
I can understand it, involves GPT devices (as well as MBR ones),
and *BIOS* booting.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#224342

David Wright wrote:

> The OP has described a problem with a ~2006 laptop which, as far as
> I can understand it, involves GPT devices (as well as MBR ones),
> and *BIOS* booting.
> 

I am not sure if grub can boot off GPT without UEFI. I honestly never
thought of this. For me both go hand in hand. The GPT  is part of the UEFI
specs (https://en.wikipedia.org/wiki/GUID_Partition_Table).

And thank you for bringing the context to my memory. Regarding support in
windows look at the tables of the WIKI link at the end of the page. It says
it requires UEFI to boot in all versions of windows 64 except server, while
on 32 it does not support booting at all around those years 2001-2009 (up
to win7).
And the note: "MBR takes precedence in hybrid configuration."
It might be that to boot off from the drive, OP would need to setup UEFI and
disable MBR boot completely.

regards

PS: Sorry but I was just thinking of trying to add a turbo on 1920 car :)

[toc] | [prev] | [next] | [standalone]

#224343

Hi,

deloptes wrote:
> I am not sure if grub can boot off GPT without UEFI.

That's the use case of the GRUB BIOS boot partition with Type GUID
21686148-6449-6e6f-744e656564454649.
See "GPT" section in
  https://www.gnu.org/software/grub/manual/grub/html_node/BIOS-installation.html

It is necessary with GPT because the GPT header block occupies room where
GRUB would classically store follow-up code for the code in the MBR.


> The GPT  is part of the UEFI specs

Which is very friendly of Intel, because with GPT we don't need to look at
Wikipedia for technical specifications.

But, as said previously, old PC-BIOS does not care for partitions.
GRUB does. Normally it can handle partition tables if the necessary GRUB
modules are loaded. For GPT: insmod part_gpt


Have a nice day :)

Thomas

[toc] | [prev] | [next] | [standalone]

#224344

Thomas Schmitt wrote:

> But, as said previously, old PC-BIOS does not care for partitions.
> GRUB does. Normally it can handle partition tables if the necessary GRUB
> modules are loaded. For GPT: insmod part_gpt

Thank you Thomas, I now understand this use case.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web