Web lists-archives.com

Re: BIOS Can Not Find Disk




On Mon 04 Dec 2017 at 17:34:52 (-0800), David Christensen wrote:
> On 12/04/17 07:21, David Wright wrote:
> >I recently reformatted a disk thus:
> >
> >puck:                       GPT-style, master
> >
> >Part #  filesys size        code    rôle
> >puck    -       1007KiB             partition tables and alignment space
> >puck01  -       3MiB        EF02    bios-boot for Grub (bios_grub flag)
> >puck02  FAT32   496MiB      EF00    EFI (boot flag)
> >puck03  ext2    500MiB      8300    /boot (unencrypted)
> >…
> 
> Your console session is incomplete -- you did not copy/paste your command.

That isn't a console session, it's taken from the File (in the MI5/FBI
sense) that I keep on each significant piece of hardware that I have.
"Puck" is what's written in magic marker on the drive.
"Part #" is the filesystem LABEL where there is such a thing,
otherwise it's a human label by which to refer to it (as I did
when I wrote puck01 later in the post).
"code" is the abbreviated code of the type used by gdisk.
"rôle" is the use that the area/partition is put to, written
in human language.

I don't know of a command that can print out a line like
puck    -       1007KiB             partition tables and alignment space
which is why I write it into the file myself.

> >which gdisk shows as
> >
> >Number  Start (sector)    End (sector)  Size       Code  Name
> >    1            2048            8191   3.0 MiB     EF02  BIOS boot partition
> >    2            8192         1023999   496.0 MiB   EF00  EFI System
> >    3         1024000         2047999   500.0 MiB   8300  Linux filesystem
> >…
> 
> As above; but at least you dropped a clue, "gdisk".

That *is* a copy/paste. I didn't think the command relevant: my
question is about the absence of this sort of partition in the
disk that you formatted:

    1            2048            8191   3.0 MiB     EF02  BIOS boot partition

I was under the impression (correct me if this is wrong) that Grub
put its 1st stage in the first sector along with the "fake" MBR
partition table, and the 2nd stage into the BIOS boot partition
which is an area that nothing else takes any interest in.

AFAICT (again, correct me if this is wrong) your disk has nowhere
for Grub to place its 2nd stage, so it fails. Perhaps that's what you
were deliberately trying to show?

> >Is the absence of a partition like puck01 on your disk a significant
> >factor in your failure to install grub?
> >ie where's grub going to place itself?
> 
> I initially let d-i/partman automagically partition the SSD, looked
> at the table it generated, and saw a ESP partition, a swap
> partition, and a root partition.  I then wipe the first and last
> megabyte, created the GPT partition with parted, and then proceeded
> with the complex disk layout I really wanted.  Unfortunately,
> debian-9.1.0-amd64-xfce-CD-1 d-i blew up trying to install GRUB, so
> I don't know where GRUB ends up when UEFI firmware and GPT
> partitioning is done correctly.  That's why I plan to try again with
> the simplest automagic partitioning and see what happens.

I don't know anything about UEFI firmware. I'm only just inheriting
a UEFI laptop with W10 on it and hope to split a partition for linux,
but I've only booted linux from a USB stick just to have a poke about.

The OP/Subject line says "BIOS Can Not Find Disk" so I'm posting info
from a BIOS computer booting from a SATA GPT disk. I installed stretch
onto it from a USB stick. Here's the full output from gdisk if you
think it helps:

✂ ✂ ✂ ✂ ✂ ✂ ✂ ✂ ✂ ✂

GPT fdisk (gdisk) version 0.8.10

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.

Disk /dev/sdb: 156250000 sectors, 74.5 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 3443D1C7-75D1-44BB-B438-18F912FEC2DA
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 156249966
Partitions will be aligned on 2048-sector boundaries
Total free space is 2014 sectors (1007.0 KiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048            8191   3.0 MiB     EF02  BIOS boot partition
   2            8192         1023999   496.0 MiB   EF00  EFI System
   3         1024000         2047999   500.0 MiB   8300  Linux filesystem
   4         2048000        79140863   36.8 GiB    8300  Linux filesystem
   5        79140864       156249966   36.8 GiB    8300  Linux filesystem

✂ ✂ ✂ ✂ ✂ ✂ ✂ ✂ ✂ ✂

And here is how it boots, as seen by bootinfoscript:

✂ ✂ ✂ ✂ ✂ ✂ ✂ ✂ ✂ ✂

                  Boot Info Script 0.61      [1 April 2012]


============================= Boot Info Summary: ===============================

 => Grub2 (v1.99) is installed in the MBR of /dev/sda and looks at sector 2048 
    of the same hard drive for core.img, but core.img can not be found at this 
    location.
 => Grub2 (v1.99) is installed in the MBR of /dev/sdb and looks at sector 2048 
    of the same hard drive for core.img. core.img is at this location and 
    looks in partition 85 for .

sda1: __________________________________________________________________________

    File system:       crypto_LUKS
    Boot sector type:  Unknown
    Boot sector info: 

sdb1: __________________________________________________________________________

    File system:       BIOS Boot partition
    Boot sector type:  Grub2's core.img
    Boot sector info: 

sdb2: __________________________________________________________________________

    File system:       
    Boot sector type:  -
    Boot sector info: 
    Mounting failed:   mount: unknown filesystem type ''

sdb3: __________________________________________________________________________

    File system:       ext2
    Boot sector type:  -
    Boot sector info: 
    Operating System:  
    Boot files:        /grub/grub.cfg

sdb4: __________________________________________________________________________

    File system:       crypto_LUKS
    Boot sector type:  Unknown
    Boot sector info: 

sdb5: __________________________________________________________________________

    File system:       crypto_LUKS
    Boot sector type:  Unknown
    Boot sector info: 

============================ Drive/Partition Info: =============================

Drive: sda _____________________________________________________________________
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: gpt

Partition  Boot  Start Sector    End Sector  # of Sectors  Id System

/dev/sda1                   1   976,773,167   976,773,167  ee GPT


GUID Partition Table detected.

Partition    Start Sector    End Sector  # of Sectors System
/dev/sda1           2,048   976,771,071   976,769,024 Data partition (Linux)

Drive: sdb _____________________________________________________________________
Disk /dev/sdb: 74.5 GiB, 80000000000 bytes, 156250000 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: gpt

Partition  Boot  Start Sector    End Sector  # of Sectors  Id System

/dev/sdb1                   1   156,249,999   156,249,999  ee GPT


GUID Partition Table detected.

Partition    Start Sector    End Sector  # of Sectors System
/dev/sdb1           2,048         8,191         6,144 BIOS Boot partition
/dev/sdb2           8,192     1,023,999     1,015,808 EFI System partition
/dev/sdb3       1,024,000     2,047,999     1,024,000 Data partition (Linux)
/dev/sdb4       2,048,000    79,140,863    77,092,864 Data partition (Linux)
/dev/sdb5      79,140,864   156,249,966    77,109,103 Data partition (Linux)

✂ ✂ ✂ ✂ ✂ ✂ ✂ ✂ ✂ ✂

As you can see, the 2nd stage of Grub is at the first sector of
/dev/sdb1, or what I called "puck01".

I haven't tried installing Debian on a GPT disk without having
(a) a protective MBR for the 1st stage and (b) a BIOS Boot
partition for the 2nd stage, so I don't know how or whether
it objects.

I haven't pieced together the info from the OP into a coherent
narrative. (There are too many bits like "Yes, that was made possible
by "fdisk -t dos /dev/sda" and it's been reverted.") So I can't
suggest a way of fixing their problem. I don't know how fascist
their BIOS is. This 2006 Dell doesn't seem to bother about
boot flags.

All I can say is that there doesn't seem to be much point in
formatting a GPT disk without including (i) a protective MBR,
(ii) a BIOS Boot partition and (iii) an EFI System partition.
(i) and (ii) give you backward compatibility, and (iii) gives
you future-proofing. As you can see, I haven't yet bothered
to format (iii) as I was more concerned with getting LUKS right.
One day, I might get my hands on a UEFI desktop.

Cheers,
David.