> Le 16 nov. 2022 à 08:48, Otto Moerbeek <o...@drijf.net> a écrit :
>
> 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.
Ok. Thanks a lot!
