Built Python 3.14 Dragonfly 6.4
Autumn Jolitz
autumn.jolitz at gmail.com
Mon Mar 2 19:32:52 PST 2026
Yep, it was what I suspected. There is a bug in the latest master (as of 2f464f7b29ef0068fcf089f37306a0fded066771) — when encountering an MBR partition map caused by calling `newfs_hammer` on a device like `/dev/serno/WWZAEENJ`, the kernel will not recognize the partition map and think the drives are unformatted. Release 6.4 however recognizes those drives just fine.
Context:
- I have four 8TB SATA drives mounted using hammer pls-mirror-stream between each pair
- three of them have an MBR created via calling `newfs_hammer /dev/serno/WWZAEENJ` (i.e. either on the device or on .s0 of the device)
- Example MBR drive: /dev/serno/WWZAEENJ [1]
- one of them has a GPT layout (via `gpt create`/`gpt add -i 0 -t hammer`)
- Example GPT drive: /dev/serno/WWZABTRY [2]
An install-all of master will fail to show on boot /dev/serno/WWZAEENJ.s0 (MBR) but does show (and mount successfully!) /dev/serno/WWZABTRY.s0 (GPT)
By comparison, an install-all of DragonFly_RELEASE_6_4 shows and mounts both MBR and GPT drives successfully.
In any case, I’m going to migrate my mirrors to GPT partition headers, but this is a real bug that others could encounter.
Side note, MAKEOBJDIRPREFIX did not behave as I expected for `build-all` as in it didn’t work. I expected to be able to specify something like `/usr/obj/{master_buildroot,rel64_buildroot}` and have it put all those messy compilation artifacts for a build (idea being to build-all for both current and destination branches and then rollback quickly with a git switch/make flag). I had to settle for null mounting my desired obj store over /usr/obj/usr but it worked enough to allow me to rollback quickly.
Autumn
[1] Example of MBR fdisk drive:
nyx:~$ fdisk /dev/serno/WWZAEENJ
******* Working on device /dev/serno/WWZAEENJ *******
parameters extracted from device are:
cylinders=972801 heads=255 sectors/track=63 (16065 blks/cyl)
Figures below won't work with BIOS for partitions not in cyl 1
parameters to be used for BIOS calculations are:
cylinders=972801 heads=255 sectors/track=63 (16065 blks/cyl)
fdisk: invalid fdisk partition table found
Warning: Ending logical block > 2TB, using max value
Media sector size is 512
Warning: BIOS sector numbering starts with sector 1
Information from DOS bootblock is:
The data for partition 1 is:
<UNUSED>
The data for partition 2 is:
<UNUSED>
The data for partition 3 is:
<UNUSED>
The data for partition 4 is:
sysid 108,(DragonFly BSD)
start 63, size 4294967295 (2097151 Meg), flag 80 (active)
beg: cyl 0/ head 1/ sector 1;
end: cyl 0/ head 0/ sector 62
[2] Example of GPT partition drive:
nyx:~$ sudo gpt show /dev/serno/WWZABTRY
Disk /dev/serno/WWZABTRY: 7452GB (15628053168 512-byte sectors)
Start Sectors Size Index Contents
0 1 512B - PMBR
1 1 512B - Pri GPT header
2 32 16.0KB - Pri GPT table
34 2014 1007KB - Unused
2048 15628050432 7452GB 0 GPT part - DragonFly HAMMER
15628052480 655 328KB - Unused
15628053135 32 16.0KB - Sec GPT table
15628053167 1 512B - Sec GPT header
> On Mar 2, 2026, at 12:26 PM, Autumn Jolitz <autumn.jolitz at gmail.com> wrote:
>
> Okay. I’d like to make a dport when I’ve got some insight into why my last attempt to go to master failed.
>
> Since then, I’ve reimaged one of my HAMMER drives to a GPT layout (instead of the results of a raw `newfs_hammer /dev/serno/WWZABTRY` which wrote an fdisk label for a 8tib partition — `fdisk` on the other fdisk formatted drives complains about it being an invalid label as the end offset exceeds 2TiB lol). I think this is the likely issue as my hammer2 GPT root drive worked fine but couldn’t recognize the partition map for the MBR formatted hammer drives. I’m only able to do this because I’ve PFS mirroring between my data drives so rebuilding one is doable.
>
> If I can get a master userland/kernel built, then a reboot with the new kernel will reveal if it really is that (as opposed to something else breaking which would be worse and requiring help from a developer to gather WTF is wrong…)
>
> I bumped my src to latest master today - it added two commits.
>
> However I’m getting a build failure. I’m going to try the following steps to see if I can get an actionable *something*.
>
> 1. Remove MAKEOBJDIRPREFIX, try build
> 2. Reset master to HEAD~2, try build
>
> Autumn
>
> Build failure 1:
> $ sudo -H git -C /usr/src switch master
> $ sudo -H git -C /usr/src pull
> $ sudo -H git -C /usr/src rev-parse HEAD
> 447e693def340f0816784a1567986dda486bb2f9
> $ sudo -H cp /usr/src/sys/config/X86_64_GENERIC /usr/src/sys/config/NYX
> $ sudo -H make -C /usr/src MAKEOBJDIRPREFIX=/usr/obj/master KERNCONF=NYX build-all
> … /snip
> --- grep_stub.c ---
> make[6]: don't know how to make /usr/src/gnu/usr.bin/grep/libgreputils/libgreputils.a. Stop
>
> make[6]: stopped making "exe" in /usr/src/initrd/rescue
> *** Error code 2
>
>
>>
>> On Mar 1, 2026, at 2:17 PM, Aaron LI <aly at aaronly.me> wrote:
>>
>>
>>
>>> On Mar 2, 2026, at 04:08, Autumn Jolitz <autumn.jolitz at gmail.com> wrote:
>>>
>>> I was able to compile Python 3.14 just now. It took some finagling.
>>>
>>> I’ve added a patch for getting process memory usage.
>>
>> Cool. I suggest you open a PR to https://github.com/DragonFlyBSD/DeltaPorts to include it. Or best submit to the upstream :)
>>
>>> I would have liked to do this on dragonfly/master instead of dragonfly/6_4_RELEASE but the latest kernel doesn’t seem to recognize disklabels for MBR formatted SATA drives.
>>
>> What was the error? Could you provide the steps to reproduce it? It would be a serious problem and I’ll have to look into it.
>>
>> Thank you.
>>
>> Aaron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dragonflybsd.org/pipermail/users/attachments/20260302/160e1e57/attachment-0001.htm>
More information about the Users
mailing list