On 02/12/2020 05:08, George Koehler wrote:
On Wed, 2 Dec 2020 01:59:00 +0100
Noth <nothingn...@citycable.ch> wrote:
Disk: sd0 Usable LBA: 34 to 4000797326 [4000797360 Sectors]
#: type [ start: size ]
------------------------------------------------------------------------
0: EFI Sys [ 2048: 389120 ]
1: e3c9e316-0b5c-4db8-817d-f92df00215ae [ 391168: 262144 ]
2: FAT12 [ 653312: 1071679488 ]
3: 516e7cba-6ecf-11d6-8ff8-00022d09712b [ 1072332800: 3905536 ]
4: Linux files* [ 1076238336: 2692558848 ]
5: OpenBSD [ 3768797184: 195311616 ]
6: Win Recovery [ 3964108800: 2027520 ]
7: Win Recovery [ 3966136320: 31772672 ]
8: Win Recovery [ 3997911040: 2885632 ]
OpenBSD offset 3768797184 is about 1797G. I believe that our EFI
bootloader works only if OpenBSD partition 'a' is in the first 1024G
of the drive. Back in January 2020, I suspected that a daddr32_t
would overflow in /sys/arch/amd64/stand/efiboot/efidev.c, see
https://marc.info/?l=openbsd-bugs&m=158007879212894&w=2
I have no drives larger than 1024G, so I have no way to reproduce the
problem. --George
Ah that would make sense. I'll try redoing the setup with the OpenBSD
slice moved to just behind the main Windows one, that'll put it in
within the first 1024Gb.
Cheers,
Noth
