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.
