For the record, I did not ass-u-me the new disk was blank. I verified it was blank as soon as it was installed and I booted the system. Thanks for the heads up for anyone else reading this though.

Added: This is a bit of a tangent from the original post we should probably take elsewhere. That said, if your "dead" or used disk has sensitive data on it then have it run through a disk shredder, or otherwise destroy it to the point it is unreadable. If you need to return a defective disk for a replacement, consider not doing that and just buy another new disk and destroy the defective one. These are the only ways to be sure your data on that disk does not escape your control.

This is a brand new disk, just taken out of the factory packaging this past weekend. It was completely blank when I added it as a PV then created the VG for the first time and attempted to create the first logical volume on it using the same LVM steps at the CLI I have used hundreds of times in my job as a Unix / Linux administrator at a regional ISP. Since then I have removed all the LVM data and started from a completely blank disk more than once now. There was nothing on the disk to confuse LVM from the start.

I once overheard one of the LAN admins in our company complaining loudly about a supposedly new disk not being blank (about half of the people in the canteen could hear him). He had spent several hours trying to add the disk to a Novell Netware server and could not get it to work. Eventually he removed all the old disks from the server and booted it with just the new supposedly blank disk in it and it came up as another company's server!

So don't assume a new disk is always blank. Or that a disk you send back as faulty (or part of a faulty system) won't end up being sold to a random customer. Always wipe anything that might be sensitive first.

You don't mention whether(/that?) you also re-created the block device (major:minor = 254:5) as /dev/dm-5?

The block device was created "automagically" when I used lvcreate with the -Zn switch. Only the symlinks had to be created that first time. I am now happily running with /home, /var, and swap on the new WD 1 TB disk.

Added: All -Zn does is tell lvcreate to not attempt to zero the new device.

Note, this is not novice friendly. If you, dear reader, are a novice, do not blindly follow my steps. Try to figure out what I did and why first.

There is nothing special with LVM on Devuan. It works fine on my machines. Mostly created while installing the system.

Here are three links to HowTo's:
https://tldp.org/HOWTO/LVM-HOWTO/
https://linuxhandbook.com/lvm-guide/
https://www.howtoforge.com/linux_lvm

The first I have used a lot.

I have already been through all the guides, mate. This problem with lvcreate AFTER INSTALLATION is not addressed in any of them. As you can see above, I found a workaround.

Here are three links to HowTo's:
https://tldp.org/HOWTO/LVM-HOWTO/
https://linuxhandbook.com/lvm-guide/
https://www.howtoforge.com/linux_lvm

The first I have used a lot.

Using the "-Zn" switch worked to partially create what I needed. These steps got my new logical var created and ready to use:

[ROOT@devuan-nuc ~] # lvcreate -Zn -n var -L 20g devuan-nuc-vg2
  WARNING: Logical volume devuan-nuc-vg2/var not zeroed.
  Logical volume "var" created.

Then I ran vgscan --mknodes, but that did not create the symlink in /dev/mapper as I was expecting:

[ROOT@devuan-nuc ~] # ls -l /dev/mapper/
total 0
crw------- 1 root root  10, 236 Aug 30 13:28 control
brw-rw---- 1 root disk 254,   5 Aug 31 11:10 devuan--nuc--vg2-var      <<<--- yeah, no.
lrwxrwxrwx 1 root root        7 Aug 30 05:28 devuan--nuc--vg-home -> ../dm-4
lrwxrwxrwx 1 root root        7 Aug 30 05:28 devuan--nuc--vg-root -> ../dm-0
lrwxrwxrwx 1 root root        7 Aug 30 05:28 devuan--nuc--vg-swap_1 -> ../dm-2
lrwxrwxrwx 1 root root        7 Aug 30 05:28 devuan--nuc--vg-tmp -> ../dm-3
lrwxrwxrwx 1 root root        7 Aug 30 05:28 devuan--nuc--vg-var -> ../dm-1

I removed that file with rm /dev/mapper/devuan--nuc--vg2-var, and created the symlink by hand with:

[ROOT@devuan-nuc ~] # cd /dev/mapper/
[ROOT@devuan-nuc mapper] # ln -s ../dm-5 devuan--nuc--vg2-var

Then I made the filesystem on the logical volume:

[ROOT@devuan-nuc mapper] # mkfs.ext4 /dev/devuan-nuc-vg2/var 
mke2fs 1.46.2 (28-Feb-2021)
Discarding device blocks: done                            
Creating filesystem with 5242880 4k blocks and 1310720 inodes
Filesystem UUID: e46a61e4-c322-4d45-8d26-31386bd47efb
Superblock backups stored on blocks: 
	32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
	4096000

Allocating group tables: done                            
Writing inode tables: done                            
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done 

Now I will make a mount point, mount the sucker, add that to /etc/fstab, and see if this all survives a reboot or not.

Yet those are used when logical volumes are made using the Devuan installer. Weird.

[ROOT@devuan-nuc ~] # ls -dl /dev/devuan-nuc-vg*
drwxr-xr-x 2 root root 140 Aug 30 05:28 /dev/devuan-nuc-vg

[ROOT@devuan-nuc ~] # ls -l /dev/devuan-nuc-vg*
total 0
lrwxrwxrwx 1 root root 7 Aug 30 05:28 home -> ../dm-4
lrwxrwxrwx 1 root root 7 Aug 30 05:28 root -> ../dm-0
lrwxrwxrwx 1 root root 7 Aug 30 05:28 swap_1 -> ../dm-2
lrwxrwxrwx 1 root root 7 Aug 30 05:28 tmp -> ../dm-3
lrwxrwxrwx 1 root root 7 Aug 30 05:28 var -> ../dm-1

[ROOT@devuan-nuc ~] # ls -l /dev/dm*
brw-rw---- 1 root disk 254, 0 Aug 30 13:28 /dev/dm-0
brw-rw---- 1 root disk 254, 1 Aug 30 13:28 /dev/dm-1
brw-rw---- 1 root disk 254, 2 Aug 30 13:28 /dev/dm-2
brw-rw---- 1 root disk 254, 3 Aug 30 13:28 /dev/dm-3
brw-rw---- 1 root disk 254, 4 Aug 30 13:28 /dev/dm-4

There should be a /dev/devuan-nuc-vg2 directory for the new volume group. It seems there should also be a /dev/dm-5(?) created when I make the new logical volume. I have never had to create any of that stuff by hand, but if needed, I will do it. Anyone here know the proper method to get those created?

Added: Obviously I can create the directory and symlinks "by hand" with mkdir and ln. My main concern is getting the dm-? disk files created correctly.

This is my home system. I cannot copy files from the work systems to my home, nor vice versa, for diff without breaking company security rules. Besides, I am on vacation from work which is why I have time to work on my home setup. Not gonna login to work just for this. Someone would notice, and I would get pinged for workthing.

I can take a gander at the work systems when I am back at work next week to see if I can find a difference with my eyeball-mark-I.

If there is a difference between Devuan/Debian and those other OS types, it might be a difference in the lvm.conf files. Perhaps you can diff those between systems?

[ROOT@devuan-nuc ~] # vgs
  VG             #PV #LV #SN Attr   VSize    VFree  
  devuan-nuc-vg    1   5   0 wz--n- <222.59g  12.00m
  devuan-nuc-vg2   1   0   0 wz--n-  931.51g 931.51

Why are both showing up as on PV 1? There are TWO physical disks:

[ROOT@devuan-nuc ~] # pvs
  PV         VG             Fmt  Attr PSize    PFree  
  /dev/sda3  devuan-nuc-vg  lvm2 a--  <222.59g  12.00m
  /dev/sdb   devuan-nuc-vg2 lvm2 a--   931.51g 931.51g

Or am I misreading that? At this point I am fairly confused.

This is a brand new disk, just taken out of the factory packaging this past weekend. It was completely blank when I added it as a PV then created the VG for the first time and attempted to create the first logical volume on it using the same LVM steps at the CLI I have used hundreds of times in my job as a Unix / Linux administrator at a regional ISP. Since then I have removed all the LVM data and started from a completely blank disk more than once now. There was nothing on the disk to confuse LVM from the start.

That said, my company uses primarily Red Hat / CentOS (ICK!). So I suspect there is a difference between those and Devuan / Debian that I am missing.