Solved How does the creation of /dev/diskid/?

R

Rolio43

Hi, I have two computers that have the variable kern.geom.label.disk_ident.enable=1

zpool does not display the same thing:
Code: 
$ zpool status
  pool: zroot
 state: ONLINE
  scan: resilvered 344G in 00:33:14 with 0 errors on Fri Mar  7 15:36:05 2025
config:

    NAME                               STATE     READ WRITE CKSUM
    zroot                              ONLINE       0     0     0
      mirror-0                         ONLINE       0     0     0
        diskid/DISK-S5RPNF0TB23259Yp3  ONLINE       0     0     0
        diskid/DISK-S5RPNJ0X903035Jp3  ONLINE       0     0     0

errors: No known data errors

Code: 
$ zpool status
  pool: zroot
 state: ONLINE
config:

    NAME        STATE     READ WRITE CKSUM
    zroot       ONLINE       0     0     0
      mirror-0  ONLINE       0     0     0
        ada0p3  ONLINE       0     0     0
        ada1p3  ONLINE       0     0     0

errors: No known data errors

Why does one resonate in /dev/diskid/? and the other in /dev/ada?
 
Did you manually create the zroot pool that uses diskid's ? Other zroot pool is a mirror so I think that you can detach one of the disks and then attach via diskid of it and do the same for other one. AFAIK FreeBSD's Installer does not create zfs pool with diskids but disk names like ada0 instead.
 
I did not create the original pool with the diskid but with:
Code: 
# gpart add -t freebsd-zfs ada?
# zpool create -f zroot /dev/ada?p?

On the machine that resonates in /dev/ada?, there is no folder /dev/diskid/
 
"geom withering"
Assume every type of "id" is enabled (diskid, gpt, glabel, dev) they are all available until the first exclusive access (think mount here).

nxjoseph is correct about the installer and since it's a mirror you should be able to detach/attach, wait for resilver, detach/attach the other other.

On the second system:

"ls -ltr /dev"
probably shows no /dev/diskid
zpool detach zroot ada1p3
now go look at ls -ltr /dev there is likely a "/dev/diskid/somethingrelated to ada1p3
zpool attach zroot /dev/diskid/whatever it says for p3
zpool status probably shows zroot resilvering, ada0p3 and /dev/diskid/something
When that completes, then do
zpool detach zroot ada0p3
zpool attach zroot /dev/diskid/blahblahblah
zpool status shows resilvering

You can also do gpt labels instead of diskids
 
mer said:
"geom withering"
Assume every type of "id" is enabled (diskid, gpt, glabel, dev) they are all available until the first exclusive access (think mount here).

nxjoseph is correct about the installer and since it's a mirror you should be able to detach/attach, wait for resilver, detach/attach the other other.

On the second system:

"ls -ltr /dev"
probably shows no /dev/diskid
zpool detach zroot ada1p3
now go look at ls -ltr /dev there is likely a "/dev/diskid/somethingrelated to ada1p3
zpool attach zroot /dev/diskid/whatever it says for p3
zpool status probably shows zroot resilvering, ada0p3 and /dev/diskid/something
When that completes, then do
zpool detach zroot ada0p3
zpool attach zroot /dev/diskid/blahblahblah
zpool status shows resilvering

You can also do gpt labels instead of diskids
Click to expand...

It works, thank you very much.
 
mer said:
nxjoseph is correct about the installer and since it's a mirror you should be able to detach/attach, wait for resilver, detach/attach the other other.
Click to expand...
Rolio43 said:
Rich (BB code): 
scan: resilvered 344G in 00:33:14 with 0 errors on Fri Mar 7 15:36:05 2025
Click to expand...

To avoid resilver, which would take about an hour here for both disks, boot a installer media, drop to "Live System"
Code: 
 # mkdir /tmp/zfs
 # zpool import -R /tmp/zfs -d /dev/diskid zroot
Next time the system is booted, zpool status should show diskids.

Eventually comment /dev/gpt/efiboot0 in /etc/fstab (if there is such a entry), since there will be no gpt labels availaible [1], otherwise the boot process gets stuck in single-user mode.

I've noticed, despite kern.geom.label.disk_ident.enable="1", there were no /dev/diskid/* on a VM test system. The pool imported from a installer media as shown above created them.


[1]
Code: 
 # ls /dev/gpt/*
ls: /dev/gpt/*: No such file or directory


 # gpart show -l
>       40  524287920  diskid/DISK-VB58b6823c-56eea31c  GPT  (250G)
         40     532480                                1  efiboot0  (260M)
     532520       2008                                   - free -  (1.0M)
     534528    4194304                                2  swap0  (2.0G)
    4728832  519557120                                3  zfs0  (248G)
  524285952       2008                                   - free -  (1.0M)

=>       40  524287920  diskid/DISK-VB5047bd44-0a8ab70f  GPT  (250G)
         40     532480                                1  efiboot1  (260M)
     532520       2008                                   - free -  (1.0M)
     534528    4194304                                2  swap1  (2.0G)
    4728832  519557120                                3  zfs1  (248G)
  524285952       2008                                   - free -  (1.0M)
 
T-Daemon Thanks. I was trying to avoid the reboot the system part.
T-Daemon said:
I've noticed, despite kern.geom.label.disk_ident.enable="1", there were no /dev/diskid/* on a VM test system. The pool imported from a installer media as shown above create them.
Click to expand...
That is interesting; I would expect enable the sysctl, then detach to show the diskids. I know that works as I expect with gpt labels ( /dev/gpt/whatever) Perhaps diskids are only done at boot or "new device". I think a way to test it would be to enable disk ids then attach an external drive, something that would normally show up at /dev/da*.

Booting from installer media and importing the preexisting pool, how does that wind up on the actual system? Is your zpool import actually modifying the ZFS metadata on the real devices or is it just modifying zcache on the install media?
 
T-Daemon said:
To avoid resilver, which would take about an hour here for both disks, boot a installer media, drop to "Live System"
Code: 
 # mkdir /tmp/zfs
 # zpool import -R /tmp/zfs -d /dev/diskid zroot
Next time the system is booted, zpool status should show diskids.

Eventually comment /dev/gpt/efiboot0 in /etc/fstab (if there is such a entry), since there will be no gpt labels availaible [1], otherwise the boot process gets stuck in single-user mode.

I've noticed, despite kern.geom.label.disk_ident.enable="1", there were no /dev/diskid/* on a VM test system. The pool imported from a installer media as shown above created them.


[1]
Code: 
 # ls /dev/gpt/*
ls: /dev/gpt/*: No such file or directory


 # gpart show -l
>       40  524287920  diskid/DISK-VB58b6823c-56eea31c  GPT  (250G)
         40     532480                                1  efiboot0  (260M)
     532520       2008                                   - free -  (1.0M)
     534528    4194304                                2  swap0  (2.0G)
    4728832  519557120                                3  zfs0  (248G)
  524285952       2008                                   - free -  (1.0M)

=>       40  524287920  diskid/DISK-VB5047bd44-0a8ab70f  GPT  (250G)
         40     532480                                1  efiboot1  (260M)
     532520       2008                                   - free -  (1.0M)
     534528    4194304                                2  swap1  (2.0G)
    4728832  519557120                                3  zfs1  (248G)
  524285952       2008                                   - free -  (1.0M)
Click to expand...

I tried import, on the live system it resonates well in diskid but once restarted, it puts back ada?p?
 
mer said:
Is your zpool import actually modifying the ZFS metadata on the real devices or is it just modifying zcache on the install media?
Click to expand...
I guess it's the first case, since /boot/zfs on the installer media is read-only.

zpool.cache isn't modified either:
Code: 
 # strings /boot/zfs/zpool.cache /etc/zfs/zpool.cache | grep -e diskid -e ada
/dev/ada0p3
/dev/ada1p3
/dev/ada0p3
/dev/ada1p3

I wanted to check zdb(8) information after pool imported by diskid, but hit a unusual situation. zdb claims "can't open 'zroot': No such file or dirctory". It's not reversible by importing the pool by adaN device names. zdb stands by its claim. This is reproducible on another VM. This looks like a bug. It's getting late here, I'll try tomorrow to investigate.
 
Rolio43 said:
I tried import, on the live system it resonates well in diskid but once restarted, it puts back ada?p?
Click to expand...
Ahh, that is interesting info to me.
It ties into what I was asking in post 6 and 7. Your experience indicates to me that "booted into live system, diskid works but the diskid information is NOT written to the physical devices".

So, what I would try next:
enable diskid, make sure your put it in /etc/sysctl.conf, then reboot
after reboot zpool status to verify everything is good, probably on /dev/adaXpY
then do
zpool detach zroot ada1p3
go check /dev/diskid
if you see an entry that corresponds to ada1, do:
zpool attach zroot /dev/diskid/whatevercorrespondstoada1p3

zpool status should show resilvering and new name on one of the pair.
wait for resilver to finish, then zpool detach the other adaXpY, zpool attach /dev/diskid/the nextthing for ada0p3
 
Rolio43 said:
I tried import, on the live system it resonates well in diskid but once restarted, it puts back ada?p?
Click to expand...
I've tried in VirtualBox and bhyve(8) (BIOS, UEFI), after the pool is imported with diskids from a installer media, every time the host system keeps the diskids. This is also valid with GPT labels (gpt/zfs0, gpt/zfs1: zpool import -d /dev/gpt zroot).
 
T-Daemon said:
I've tried in VirtualBox and bhyve(8) (BIOS, UEFI), after the pool is imported with diskids from a installer media, every time the host system keeps the diskids. This is also valid with GPT labels (gpt/zfs0, gpt/zfs1: zpool import -d /dev/gpt zroot).
Click to expand...

I did other tests, I had put the variable kern.geom.label.disk_ident.enable=1 in /etc/sysctl.conf
I finally put it in /boot/loader.conf
I did a direct import on the system on a raidz2 :
Code: 
# zpool export raid6
# zpool import -d /dev/diskid raid6

Then modified another disk with the live system :
Code: 
# zpool import -R /tmp/zfs -d /dev/diskid zroot

Now it works since I put the variable kern.geom.label.disk_ident.enable=1 in /boot/loader.conf
I think that allows the variable to be taken into account earlier by the kernel.
 
You must log in or register to reply here.
Back
Top