On Tue, Nov 15, 2022 at 11:25:15PM +0100, Joel Carnat wrote:
> Le 13/11/2022 ?? 09:31, Otto Moerbeek a ??crit??:
> > On Sun, Nov 13, 2022 at 09:24:53AM +0100, Otto Moerbeek wrote:
> >
> > > On Sat, Nov 12, 2022 at 09:59:00PM +0100, Patrick Wildt wrote:
> > >
> > > > Am Sat, Nov 05, 2022 at 04:03:50PM +0100 schrieb Joel Carnat:
> > > > > Hi,
> > > > >
> > > > > I have installed OpenBSD 7.2 on a 14TB SATA disk using my ODROID HC4.
> > > > >
> > > > > During installation, I was not able to use the whole disk size
> > > > > although I selected "whole" and "auto partionning". The installer
> > > > > seemed
> > > > > to recognized only about 2TB.
> > > > >
> > > > > dmesg says:
> > > > > sd0 at scsibus0 targ 0 lun 0: <ATA, WDC WD140EFGX-68, 85.0>
> > > > > naa.5000cca28fd7d301
> > > > > sd0: 13351936MB, 512 bytes/sector, 27344764928 sectors
> > > > >
> > > > > but after rebooting on the installed system, the disk layout was the
> > > > > following:
> > > > >
> > > > > # fdisk sd0
> > > > > Disk: sd0 geometry: 32960/511/255 [4294852800 Sectors]
> > > > > Offset: 0 Signature: 0xAA55
> > > > > Starting Ending LBA Info:
> > > > > #: id C H S - C H S [ start: size ]
> > > > > -------------------------------------------------------------------------------
> > > > > *0: 0C 0 128 129 - 0 257 1 [ 32768: 32768 ]
> > > > > Win95 FAT32L
> > > > > 1: 00 0 0 0 - 0 0 0 [ 0: 0 ]
> > > > > unused
> > > > > 2: 00 0 0 0 - 0 0 0 [ 0: 0 ]
> > > > > unused
> > > > > 3: A6 0 257 2 - 32959 510 255 [ 65536: 4294787264 ]
> > > > > OpenBSD
> > > > >
> > > > > Using disklabel, I could "correct" the disk usage and reformat the
> > > > > last
> > > > > partition to get full disk space.
> > > > > sd0> l
> > > > > # /dev/rsd0c:
> > > > > type: SCSI
> > > > > disk: SCSI disk
> > > > > label: WDC WD140EFGX-68
> > > > > duid: b9ce90e6ba9fedcd
> > > > > flags:
> > > > > bytes/sector: 512
> > > > > sectors/track: 255
> > > > > tracks/cylinder: 511
> > > > > sectors/cylinder: 130305
> > > > > cylinders: 209852
> > > > > total sectors: 27344764928
> > > > > boundstart: 65536
> > > > > boundend: 4294852800
> > > > >
> > > > > sd0> b
> > > > > Starting sector: [65536]
> > > > > Size ('*' for entire disk): [4294787264] *
> > > > >
> > > > > sd0*> l
> > > > > # /dev/rsd0c:
> > > > > type: SCSI
> > > > > disk: SCSI disk
> > > > > label: WDC WD140EFGX-68
> > > > > duid: b9ce90e6ba9fedcd
> > > > > flags:
> > > > > bytes/sector: 512
> > > > > sectors/track: 255
> > > > > tracks/cylinder: 511
> > > > > sectors/cylinder: 130305
> > > > > cylinders: 209852
> > > > > total sectors: 27344764928
> > > > > boundstart: 65536
> > > > > boundend: 27344764928
> > > > >
> > > > > sd0> p g
> > > > > OpenBSD area: 65536-27344764928; size: 13039.0G; free: 10991.1G
> > > > > # size offset fstype [fsize bsize cpg]
> > > > > a: 1.0G 65536 4.2BSD 2048 16384 12960 # /
> > > > > b: 4.0G 2162688 swap #
> > > > > none
> > > > > c: 13039.0G 0 unused
> > > > > d: 4.0G 10540448 4.2BSD 2048 16384 12960 #
> > > > > /tmp
> > > > > e: 11.5G 18929024 4.2BSD 2048 16384 12960 #
> > > > > /var
> > > > > f: 30.0G 43024544 4.2BSD 2048 16384 12960 #
> > > > > /usr
> > > > > g: 1.0G 105939104 4.2BSD 2048 16384 12960 #
> > > > > /usr/X11R6
> > > > > h: 20.0G 108036256 4.2BSD 2048 16384 12960 #
> > > > > /usr/local
> > > > > i: 0.0G 32768 MSDOS
> > > > > j: 300.0G 149979328 4.2BSD 4096 32768 26062 #
> > > > > /home
> > > > > k: 4.0G 779223872 4.2BSD 2048 16384 12960 #
> > > > > /var/www
> > > > > l: 1672.3G 787693696 4.2BSD 8192 65536 52270 #
> > > > > /data
> > > > > sd0> c l
> > > > > Partition l is currently 3507159040 sectors in size, and can have a
> > > > > maximum
> > > > > size of 26557071232 sectors.
> > > > > size: [3507159040] *
> > > > > sd0*> p g
> > > > > OpenBSD area: 65536-27344764928; size: 13039.0G; free: 0.0G
> > > > > # size offset fstype [fsize bsize cpg]
> > > > > a: 1.0G 65536 4.2BSD 2048 16384 12960 # /
> > > > > b: 4.0G 2162688 swap #
> > > > > none
> > > > > c: 13039.0G 0 unused
> > > > > d: 4.0G 10540448 4.2BSD 2048 16384 12960 #
> > > > > /tmp
> > > > > e: 11.5G 18929024 4.2BSD 2048 16384 12960 #
> > > > > /var
> > > > > f: 30.0G 43024544 4.2BSD 2048 16384 12960 #
> > > > > /usr
> > > > > g: 1.0G 105939104 4.2BSD 2048 16384 12960 #
> > > > > /usr/X11R6
> > > > > h: 20.0G 108036256 4.2BSD 2048 16384 12960 #
> > > > > /usr/local
> > > > > i: 0.0G 32768 MSDOS
> > > > > j: 300.0G 149979328 4.2BSD 4096 32768 26062 #
> > > > > /home
> > > > > k: 4.0G 779223872 4.2BSD 2048 16384 12960 #
> > > > > /var/www
> > > > > l: 12663.4G 787693696 4.2BSD 8192 65536 52270 #
> > > > > /data
> > > > > sd0*>
> > > > >
> > > > > The questions are :
> > > > > - is this an expected behaviour from the installer?
> > > > > - shall the disklabel correction rather be done during installation?
> > > > > - is this a issue when fdisk and disklabel disagree about the number
> > > > > of
> > > > > sectors?
> > > > >
> > > > > Thank you,
> > > > > Joel C.
> > > > >
> > > >
> > > > I'm not certain, but I believe the installer is using MBR partition
> > > > table, and my guess is that an MBR partition table can't cover that
> > > > space? It's just a guess though.
> > > >
> > >
> > > MBRs cannot cover more thann 2TB indeed, and you can use the b command
> > > in disklabel to extend the OpenSBD part of the disk, as demonstrated.
> > >
> > > For autolayout that does not matter much, as the max sizes of the
> > > partitions fit well in 2TB.
> >
> > And if needed, you can do it during install by choosing to edit the
> > default layout, and use the b command and then the R command to resize
> > any partition you want.
> >
> > Especially the R command is nice, as it will move the remaining
> > partitions to avoid gaps if you shrink one in the middle or shrink
> > the last one if you extend one and there is no room left.
> >
> > -Otto
> >
>
> Ok, thanks!
>
> So I plugged a blank 6TB in the HC4 and did a few install testings.
>
> Indeed, using "whole" and "edit auto layout" can be done during installation
> and leads to a bootable system. But I end up in the same configuration as
> the 16TB one : an MBR configuration with fdisk not matching what disklabel
> says.
That is no suprise, MBR can't handle larger than 2TB. The disk bounds
in the label override.
>
> Then I went to interrupt the installer, install a GPT configuration ("fdisk
> -gy -b 960 sd0") and return to the installer. Then, using "whole" and "edit
> auto layout", disklabel was aware of the real size of the disk and I could
> add/resize partition using 'c' and 'a' ; as in amd64. In the end, the system
> also boots and I end up with a coherent fdisk / disklabel sectors number:
> # fdisk sd0
> Disk: sd0 Usable LBA: 34 to 11721045134 [11721045168 Sectors]
> #: type [ start: size ]
> ------------------------------------------------------------------------
> 0: EFI Sys [ 64: 32768 ]
> 1: OpenBSD [ 32832: 11721012303 ]
>
> # disklabel -pg sd0
> # /dev/rsd0c:
> type: SCSI
> disk: SCSI disk
> label: WDC WD60EFRX-68L
> duid: 5b6d700ce4baa7c8
> flags:
> bytes/sector: 512
> sectors/track: 255
> tracks/cylinder: 511
> sectors/cylinder: 130305
> cylinders: 89950
> total sectors: 11721045168 # total bytes: 5589.0G
> boundstart: 32832
> boundend: 11721045135
>
> 16 partitions:
> # size offset fstype [fsize bsize cpg]
> a: 1.0G 32832 4.2BSD 2048 16384 12960 # /
> b: 4.0G 2129984 swap # none
> c: 5589.0G 0 unused
> d: 4.0G 10507744 4.2BSD 2048 16384 12960 # /tmp
> e: 11.5G 18896320 4.2BSD 2048 16384 12960 # /var
> f: 30.0G 42991840 4.2BSD 2048 16384 12960 # /usr
> g: 1.0G 105906400 4.2BSD 2048 16384 12960 # /usr/X11R6
> h: 20.0G 108003552 4.2BSD 2048 16384 12960 # /usr/local
> i: 0.0G 64 MSDOS
> j: 3.0G 149946592 4.2BSD 2048 16384 12960 # /usr/src
> k: 6.0G 156238048 4.2BSD 2048 16384 12960 # /usr/obj
> l: 300.0G 168820992 4.2BSD 4096 32768 26062 # /home
> m: 2048.0G 797966592 4.2BSD 8192 65536 52270 # /var/www
> n: 3160.5G 5092970880 4.2BSD 8192 65536 52270 # /data
>
>
> So it seems both MBR and GPT works. Does it seem safer to run the GPT
> installation or is the MBR + disklabel tweak a safe configuration?
It should be safe. I have been doing MBR based installs on large disks
for a long time. But these days, GPT might be better supported if you
have modern hardware.
-Otto
