Re: kern/59761: dmsetup broken in 10.1 with default GENERIC kernel

["Mike Edwards via gnats" <gnats-admin%NetBSD.org@localhost>]

The following reply was made to PR kern/59761; it has been noted by GNATS.

From: Mike Edwards <mike%mobile.mirkwood.net@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: kern-bug-people%netbsd.org@localhost, gnats-admin%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost, 
	medwards-netbsd%mirkwood.net@localhost
Subject: Re: kern/59761: dmsetup broken in 10.1 with default GENERIC kernel
Date: Mon, 17 Nov 2025 00:28:46 +0000

 Confirmed - if I shut down the VM, mount it's fs on the Linux Xen
 host, and mknod the control file from there, it's created correctly,
 and now dmsetup -vv ls works:
 [ksh] root@netbsd02# dmsetup -vv ls
 Ioctl type  version --- flags 4
 Ioctl type  names --- flags 4
 No devices found
 
 I suppose it'll do as a workaround right now, but the inability to
 create the node from the running netbsd VM is a bit odd.  Perhaps an
 issue with using ext2 for /?
 
 On Sun, Nov 16, 2025 at 11:35=E2=80=AFPM Mike Edwards via gnats
 <gnats-admin%netbsd.org@localhost> wrote:
 >
 > The following reply was made to PR kern/59761; it has been noted by GNATS=
 .
 >
 > From: Mike Edwards <mike%mobile.mirkwood.net@localhost>
 > To: gnats-bugs%netbsd.org@localhost
 > Cc:
 > Subject: Re: kern/59761: dmsetup broken in 10.1 with default GENERIC kern=
 el
 > Date: Sun, 16 Nov 2025 23:32:32 +0000
 >
 >  Ok, well, that's funny - there's a bug here, but it's not the one I
 >  thought it was!
 >
 >  Then again, there's still something odd:
 >  [ksh] root@netbsd02# ls -al
 >  total 48
 >  drwxr-xr-x   2 root  wheel      4096 Nov 16 18:19 .
 >  drwxr-xr-x  11 root  wheel     45056 Nov 12 22:03 ..
 >  crw-rw----   1 root  operator   0, 0 Nov 16 18:19 control
 >  [ksh] root@netbsd02# rm control
 >  [ksh] root@netbsd02# ls -al
 >  total 48
 >  drwxr-xr-x   2 root  wheel   4096 Nov 16 18:21 .
 >  drwxr-xr-x  11 root  wheel  45056 Nov 12 22:03 ..
 >  [ksh] root@netbsd02# mknod -m 660 -u root -g operator control c 194 0
 >  [ksh] root@netbsd02# ls -al
 >  total 48
 >  drwxr-xr-x   2 root  wheel      4096 Nov 16 18:21 .
 >  drwxr-xr-x  11 root  wheel     45056 Nov 12 22:03 ..
 >  crw-rw----   1 root  operator   0, 0 Nov 16 18:21 control
 >  [ksh] root@netbsd02#
 >
 >  Perhaps unusually, I'm using ext2fs here, as it makes it easier to
 >  mount the vm on the host if needed (Xen dom0 is currently Linux).
 >  Other nodes in the top-level /dev seem to have correct numbering,
 >  though I'm finding if I try to create a new copy of one of those nodes
 >  with mknod, it likewise creates a device with address 0, 0.
 >
 >  If I recall correctly, a script running on the Linux host created the
 >  nodes in /dev initially, so that may explain why those nodes have
 >  correct numbering, but the inability to create a node with anything
 >  but 0, 0 on the running vm is a bit on the strange side.
 >
 >  On Sun, Nov 16, 2025 at 10:45=3DE2=3D80=3DAFPM Michael van Elst via gnat=
 s
 >  <gnats-admin%netbsd.org@localhost> wrote:
 >  >
 >  > The following reply was made to PR kern/59761; it has been noted by GN=
 ATS=3D
 >  .
 >  >
 >  > From: mlelstv%serpens.de@localhost (Michael van Elst)
 >  > To: gnats-bugs%netbsd.org@localhost
 >  > Cc:
 >  > Subject: Re: kern/59761: dmsetup broken in 10.1 with default GENERIC k=
 ern=3D
 >  el
 >  > Date: Sun, 16 Nov 2025 22:43:34 -0000 (UTC)
 >  >
 >  >  gnats-admin%NetBSD.org@localhost ("Mike Edwards via gnats") writes:
 >  >
 >  >  > [ksh] root@netbsd02# ls -ld /dev/mapper/control
 >  >  > crw-rw----  1 root  operator  0, 0 Nov 15 19:50 /dev/mapper/control
 >  >  >
 >  >  > 0,0?  Oddly, dmsetup doesn't agree with ls here:
 >  >
 >  >  0, 0 would be "console". Something is wrong in your /dev directory.
 >  >
 >  >
 >  >  > Why would ls report 0,0, and dmsetup 33,176?
 >  >
 >  >  The source reveals utter stupidity:
 >  >
 >  >          if (major && buf.st_rdev !=3D3D MKDEV(major, minor)) {
 >  >                  log_verbose("%s: Wrong device number: (%u, %u) instea=
 d o=3D
 >  f "
 >  >                              "(%u, %u)", control,
 >  >                              MAJOR(buf.st_mode), MINOR(buf.st_mode),
 >  >                              major, minor);
 >  >  ...
 >  >
 >  >  The check is correct, but then it prints bits from buf.st_mode instea=
 d
 >  >  of buf.st_rdev.
 >  >
 >  >
 >