DragonFly master change about s0 (compatibility slice)

[Autumn Jolitz]

Hi Aaron,

First off, I’m very pleased you were able to identify the commit that removed support.

What I encountered shouldn’t fully mean that we can’t remove s0 compatibility — I feel it means that we need some method of identifying and fixing the errant drive in question. I couldn’t migrate to master (or any successive release) because I had no way to remedy the issue on the new kernel/userland.

Ideally, an offline utility that would move HAMMER/UFS/et al forwards enough to create the missing MBR or GPT mappings along with a dmesg saying “Hey! I don’t see a partition map on $device! If this is a real drive and you relied on s0 compatibility, why don’t you run $utility to fix it?”

Removing compatibility hacks is something I’ll always be supportive of *provided we have a way to fix/migrate in-situ*.

I’m just happy I had the presence of mind to keep a prebuilt userland/kernel staged so I could rapidly reinstall the working version without waiting for a 2 hour compile.

Autumn

> On Mar 2, 2026, at 10:27 PM, Aaron LI <aly at aaronly.me> wrote:
> 
> On 3/3/26 1:49 PM, Aaron LI wrote:
>>> On 3/3/26 11:32 AM, Autumn Jolitz wrote:
>>> 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.
>> Yes.  I indeed made a change to the s0 (compatibility slice) support in commit 8cf8601ebae6a54f01fe9a7aed045832fc6a903b [1]. With that commit, a disk without MBR or GPT is ignored by kernel, instead of assuming there is the compatibility slice (s0) covering the whole disk.  A later commit (f687b277b90809ae7df59f012ba2c7312b608545 [2]) only made a special case for vn(4) disk because that's actually used by our nrelease framework.
>> So one must format a disk with either MBR or GPT before using.
>> For MBR-formatted disks, slices start from 1 (i.e., s1, s2, s3, s4).
>> For GPT-formatted disks, slices start from 0 (e.g., s0, s1, ...).
>> [1] kernel: Don't siliently ignore EINVAL from mbrinit() and gptinit()
>> https://gitweb.dragonflybsd.org/dragonfly.git/ commitdiff/8cf8601ebae6a54f01fe9a7aed045832fc6a903b
>> [2] kernel: Add DSO_NOMBR flag to allow VN(4) disks to have no MBR
>> https://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/ f687b277b90809ae7df59f012ba2c7312b608545
>>> 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]
>> With the updated master, kernel will not automatically create the s0 compatibility slice for an unformatted disk (i.e., no MBR or GPT).
>> By the way, I would never invoke 'newfs' on a disk (e.g., da0) rather than on a slice/partition (e.g., da0s0, da0s1), although the old behavior would make 'da0' == 'da0s0' in that case.
>>> - 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.
> 
> Hi Autumn,
> 
> After another think, I agree with you and the above change will indeed cause trouble for such rare users: the filesystem previously created directly on an unformatted disk would disappear and unusable on the new master kernel, and there is no empty space at the disk beginning to create a MBR for migration.
> 
> I'll recheck the code to restore the s0 compatibility slice support later.
> 
> Thank you for the detailed report.
> 
> Cheers,
> Aaron