Re: GPT boot, again

2019-07-28 Thread Emmanuel Dreyfus
Emmanuel Dreyfus  wrote:

> - in UEFI mode, bootstrap does not read boot.cfg and while it sees the
> GPT partitions, it is unable to access a RAID that has a GPT inside. It
> can access a RAID that has a disklabel inside, though, but that does not
> help for > 2 TB.

Reading the sources, I find that boot.cfg should be stored in the EFI
partion as /EFI/NetBSD/boot.cfg and ineed if it is at this location, EFI
bootstrap finds it.

I still have the problem with accessing a RAIDframe containing a GPT.
-- 
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
m...@netbsd.org


Re: GPT boot, again

2019-07-27 Thread Emmanuel Dreyfus
Emmanuel Dreyfus  wrote:

> I try to boot NetBSD/Xen from a GPT, with little success.
> 
> I understand NetBSD EFI bootstrap does not support multiboot, so I
> should use BIOS boot.

That poins seems false, I found multiboot code in EFI boot after all.

I made some progress: it seems the BIOS/UEFI has real trouble with the
GPT. Creating a MBR partition overlapping with the PMBR helps a lot:

Partition table:
0: GPT Protective MBR (sysid 238)
start 1, size 4294967295 (2097152 MB, Cyls 0-267349/89/4)
PBR is not bootable: Bad magic number (0x)
1: EFI system partition (sysid 239)
start 34, size 524288 (256 MB, Cyls 0/0/35-32/162/36), Active
2: 
3: 

I did it this way to keep the GPT intact:
dd if=/dev/rwd0d bs=512 count=1 > mbr
fdisk -IafFu1 -s 239/34/524288 mbr
dd if=mbr of=/dev/rwd0d bs=512 count=1

The EFI partition was formatted using
newfs_msdos -F 16 -L efi@wd0 -B /usr/mdec/bootxx_fat16 /dev/rdk0

It contains:
/boot
/boot.cfg
/efi/boot/bootx64.efi

Now the BIOS accepts booting that either in legacy or UEFI mode. However
I face two problems:

- In legacy mode, bootstrap displays two lines of blank (rendered as
underscore on the serial line), then nothing.  I tried FAT 12 with
bootxx_fat12 with the same result.

- in UEFI mode, bootstrap does not read boot.cfg and while it sees the
GPT partitions, it is unable to access a RAID that has a GPT inside. It
can access a RAID that has a disklabel inside, though, but that does not
help for > 2 TB.

disk hd0 mediaId 0 size 5589 GB
  hd0a(EFI System) hd0b(NetBSD RAID) hd0c(NetBSD Swap)


-- 
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
m...@netbsd.org


Re: GPT boot, again

2019-07-25 Thread Dima Veselov



They both point to 1 sector or 64 block. Also, you must have booting 
partition end

lined up too, so it never can be bigger than 2Gb.


I mean 2Tb, but this statement is anyway wrong. However - I have all
booting wedges less than MBR partition, but never succeeded if boot
wedge was bigger than 2Tb, so there may be some problem as well.



Re: GPT boot, again

2019-07-25 Thread Dima Veselov

I installed /boot, ran installboot and gpt biosboot. Here is fdisk
output for the disk:


What flags installboot was used with?


installboot -o console=com0,speed=115200 /dev/rdk2
/usr/mdec/bootxx_ffsv2


Did you installed MBR ever? I always do that separately.



Here is the result:

# dkctl wd2 listwedges
/dev/rwd2d: 3 wedges:
dk3: efi@wd2, 524288 blocks at 34, type: msdos
dk4: raid1@wd2, 11686966381 blocks at 524322, type: raidframe
dk5: swap@wd2, 33554432 blocks at 11687490703, type: swap


Not sure you can do partitioning that way. You have to line up
fake MBR partition and real GPT booting partition, so they match.
In your case MBR partition is started at 1 sector, this is (usually)
64 block. Here we see that you have real booting partition at
524322. Nobody can point BIOS bootcode (MBR actually) to
that address. This how it will work:

[root@gloria kab00m]$ fdisk wd0
.
cylinders: 5814021, heads: 16, sectors/track: 63 (1008 sectors/cylinder)
.
0: GPT Protective MBR (sysid 238)
start 1, size 4294967295 (2097152 MB, Cyls 0-267349/89/4)
PBR is not bootable: Bad magic number (0x)

[root@gloria kab00m]$ dkctl wd0 listwedges
/dev/rwd0d: 5 wedges:
dk0: 5b9ff8df-0892-11e4-b3c8-001731c9c57a, 524288 blocks at 64, type: 
raidframe


They both point to 1 sector or 64 block. Also, you must have booting 
partition end

lined up too, so it never can be bigger than 2Gb.


# installboot -ev NAME=raid1@wd2
File system: /dev/rdk4
Boot options:timeout 5, flags 0, speed 115200, ioaddr 0, console
com0

But I think it does not even reach that stage, since the BIOS just skips
the disk.


Disk may be skipped because MBR corrupted, so you can reinstall
it after lining partitions up.


Re: GPT boot, again

2019-07-25 Thread Emmanuel Dreyfus
 wrote:

> I guess it's on a i386/amd64 arch? Because, if my memory is right, 
> there is the need of the "\x55\xAA" in the two last bytes of the
> first 512b block (the signature) for the BIOS.

Yes, this is amd64. The magic number is there, indeed:

# dd if=/dev/rwd2d bs=512 count=1|hexdump -C|tail -2
1f0        aa55
200




-- 
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
m...@netbsd.org


Re: GPT boot, again

2019-07-25 Thread Martin Husemann
On Thu, Jul 25, 2019 at 05:46:31PM +0200, Emmanuel Dreyfus wrote:
> Martin Husemann  wrote:
> 
> > You may want to use rwd2d instead of rdk2
> 
> What is the rationale? I expect that to destroy the GPT.

There are various architectures that write the boot record to the disk,
not the NetBSD root partition. I can never remember which one needs what,
sorry for the confusion.

But "gpt biosboot" should already handle everything needed at the disk level,
and there is nothing else that the bios should require to recognize the disk
as bootable.

Martin


Re: GPT boot, again

2019-07-25 Thread tlaronde
On Thu, Jul 25, 2019 at 04:20:59PM +0200, Emmanuel Dreyfus wrote:
> Hello
> 
> I try to boot NetBSD/Xen from a GPT, with little success.
> 
> I understand NetBSD EFI bootstrap does not support multiboot, so I
> should use BIOS boot.
> 
> I installed /boot, ran installboot and gpt biosboot. Here is fdisk
> output for the disk:
> 
> Partition table:
> 0: GPT Protective MBR (sysid 238)
> start 1, size 4294967295 (2097152 MB, Cyls 0-267349/89/4), Active
> PBR is not bootable: Bad magic number (0x)
> 1: 
> 2: 
> 3: 
> First active partition: 0
> 
> And if I hexdump the disk block 0, I see the strings of a bootstrap
> present.
> 
> But the BIOS will not consider the disk for booting. I made it the first
> priority, but it just skips to the next one.
> 
> I wonder if "PBR is not bootable: Bad magic number" may be at fault
> here. Any idea?

I guess it's on a i386/amd64 arch? Because, if my memory is right, 
there is the need of the "\x55\xAA" in the two last bytes of the
first 512b block (the signature) for the BIOS.
-- 
Thierry Laronde 
 http://www.kergis.com/
   http://www.sbfa.fr/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C


Re: GPT boot, again

2019-07-25 Thread Emmanuel Dreyfus
Martin Husemann  wrote:

> You may want to use rwd2d instead of rdk2

What is the rationale? I expect that to destroy the GPT.

# installboot -o console=com0,speed=115200 /dev/rwd2d
/usr/mdec/bootxx_ffsv2

And indeed:

# gpt show wd2
start size  index  contents
01 PMBR (active)
1  11721045134 Unused
  11721045135   32 Sec GPT table
  117210451671 Sec GPT header

Fortunately, gpt recover wd2 did its job.

-- 
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
m...@netbsd.org


Re: GPT boot, again

2019-07-25 Thread Martin Husemann
On Thu, Jul 25, 2019 at 05:20:12PM +0200, Emmanuel Dreyfus wrote:
> Dima Veselov  wrote:
> 
> > > I installed /boot, ran installboot and gpt biosboot. Here is fdisk
> > > output for the disk:
> > 
> > What flags installboot was used with?
> 
> installboot -o console=com0,speed=115200 /dev/rdk2
> /usr/mdec/bootxx_ffsv2

You may want to use rwd2d instead of rdk2

Martin


Re: GPT boot, again

2019-07-25 Thread Emmanuel Dreyfus
Dima Veselov  wrote:

> > I installed /boot, ran installboot and gpt biosboot. Here is fdisk
> > output for the disk:
> 
> What flags installboot was used with?

installboot -o console=com0,speed=115200 /dev/rdk2
/usr/mdec/bootxx_ffsv2

Here is the result:

# dkctl wd2 listwedges 
/dev/rwd2d: 3 wedges:
dk3: efi@wd2, 524288 blocks at 34, type: msdos
dk4: raid1@wd2, 11686966381 blocks at 524322, type: raidframe
dk5: swap@wd2, 33554432 blocks at 11687490703, type: swap

# installboot -ev NAME=raid1@wd2
File system: /dev/rdk4
Boot options:timeout 5, flags 0, speed 115200, ioaddr 0, console
com0

But I think it does not even reach that stage, since the BIOS just skips
the disk.


-- 
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
m...@netbsd.org


Re: GPT boot, again

2019-07-25 Thread Dima Veselov

I understand NetBSD EFI bootstrap does not support multiboot, so I
should use BIOS boot.

I installed /boot, ran installboot and gpt biosboot. Here is fdisk
output for the disk:


What flags installboot was used with?


Partition table:
0: GPT Protective MBR (sysid 238)
 start 1, size 4294967295 (2097152 MB, Cyls 0-267349/89/4), Active
 PBR is not bootable: Bad magic number (0x)
1: 
2: 
3: 
First active partition: 0

And if I hexdump the disk block 0, I see the strings of a bootstrap
present.

But the BIOS will not consider the disk for booting. I made it the first
priority, but it just skips to the next one.

I wonder if "PBR is not bootable: Bad magic number" may be at fault
here. Any idea?


It is not a fault. All of them look like yours. It even able not to be 
active.


GPT boot, again

2019-07-25 Thread Emmanuel Dreyfus
Hello

I try to boot NetBSD/Xen from a GPT, with little success.

I understand NetBSD EFI bootstrap does not support multiboot, so I
should use BIOS boot.

I installed /boot, ran installboot and gpt biosboot. Here is fdisk
output for the disk:

Partition table:
0: GPT Protective MBR (sysid 238)
start 1, size 4294967295 (2097152 MB, Cyls 0-267349/89/4), Active
PBR is not bootable: Bad magic number (0x)
1: 
2: 
3: 
First active partition: 0

And if I hexdump the disk block 0, I see the strings of a bootstrap
present.

But the BIOS will not consider the disk for booting. I made it the first
priority, but it just skips to the next one.

I wonder if "PBR is not bootable: Bad magic number" may be at fault
here. Any idea?


-- 
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
m...@netbsd.org