Bug 294326 - glabel.8: Document conditions where (automatic) labeled devices aren't created
Summary: glabel.8: Document conditions where (automatic) labeled devices aren't created
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 16.0-CURRENT
Hardware: Any Any
: --- Affects Some People
Assignee: freebsd-bugs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2026-04-08 09:31 UTC by Michael Osipov
Modified: 2026-04-08 18:58 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Osipov freebsd_committer freebsd_triage 2026-04-08 09:31:18 UTC
I wanted to make use of automatical disk labels /dev/diskid/ for ZFS and failed. Consider the follwing configuration:
root@deblndw013x:~
# camcontrol inquiry da0
pass0: <HP RAID 1(1+0) OK> Fixed Direct Access SPC-3 SCSI device
pass0: Serial Number 50014380147AB8F0
pass0: 135.168MB/s transfers, Command Queueing Enabled
root@deblndw013x:~
# camcontrol inquiry da1
pass1: <HP RAID 5 OK> Fixed Direct Access SPC-3 SCSI device
pass1: Serial Number 50014380147AB8F0
pass1: 135.168MB/s transfers, Command Queueing Enabled
root@deblndw013x:~
# camcontrol inquiry da2
pass2: <HP RAID 1(1+0) OK> Fixed Direct Access SPC-3 SCSI device
pass2: Serial Number 50014380147AB8F0
pass2: 135.168MB/s transfers, Command Queueing Enabled

Note: Please don't ask why it is RAID, the controller firmware does not support HBA mode.

As you can see the S/N is identical for all three VDs (see also https://www.claudiokuenzler.com/blog/413/freebsd-cciss-hp-smart-array-raid-wrong-disk-numbering-labeling). Whether this is a firmware bug in the controller or in ciss(4) I don't know, but this can happens with GPT labels and other automatic labels.

I ended up with only one labeled device. dmesg didn't show a WARNING/ERROR nothing. Looking into sys/geom/label/g_label.c I see g_label_create() three conditions:
* Label invalid. Not documented what characters are permissive.
* Label too long. 64 chars including prefix and null byte.
* Label already exists, first wins. My case.

I believe that they should be part of the manpage especially for the automatically created labeled devices.
Comment 1 Michael Osipov freebsd_committer freebsd_triage 2026-04-08 09:31:56 UTC
ziaee, this might be interesting for you from a documentation PoV.
Comment 2 Alexander Ziaee freebsd_committer freebsd_triage 2026-04-08 18:32:18 UTC
Hard agree. Thanks for tagging me. We really need mention of this in CAVEATS. Can you write a patch?
Comment 3 Michael Osipov freebsd_committer freebsd_triage 2026-04-08 18:58:51 UTC
Yet something else: Looking at disk(4) there is:
/usr/include/sys/disk.h:#define DISK_IDENT_SIZE 256
but g_label_create() uses "char name[64]". While I am not an expect on the subsystems, but isn't that a contradiction?

Sample:
#include <sys/types.h>
#include <sys/ioctl.h>
#include <sys/disk.h>

#include <err.h>
#include <errno.h>
#include <fcntl.h>
#include <stdio.h>
#include <string.h>
#include <unistd.h>

int
main(int argc, char *argv[])
{
    int fd;
    char ident[DISK_IDENT_SIZE];

    if (argc != 2) {
        fprintf(stderr, "Usage: %s <device>\n", argv[0]);
        return 1;
    }

    fd = open(argv[1], O_RDONLY);
    if (fd < 0)
        err(1, "open(%s)", argv[1]);

    memset(ident, 0, sizeof(ident));

    if (ioctl(fd, DIOCGIDENT, ident) < 0)
        err(1, "ioctl(DIOCGIDENT)");

    printf("Device: %s\nIdent : %s\n", argv[1], ident);

    close(fd);
    return 0;
}

root@deblndw013x:~
# ./a.out /dev/da0
Device: /dev/da0
Ident : 50014380147AB8F0
root@deblndw013x:~
# ./a.out /dev/da1
Device: /dev/da1
Ident : 50014380147AB8F0
root@deblndw013x:~
# ./a.out /dev/da2
Device: /dev/da2
Ident : 50014380147AB8F0
root@deblndw013x:~

So if this value can be longer than 64 chars the sample code would print it and likely "camcontrol identify"/"diskinfo -s", but glabel would refuse to create it?