Other GPT partition labels stopped working

J

jem

I've just noticed that GPT partition labels are not being exposed under /dev on my FreeBSD router system. When I built the system, I gave my ESP a GPT label of "esp" and the label was accessible as /dev/gpt/esp, and I added a line to /etc/fstab that use that label to mount the ESP:

Code: 
/dev/gpt/esp    /boot/efi       msdosfs rw,noauto       0       0

# mount /boot/efi just failed for me, so I investigated the cause and found that a /dev/gpt directory doesn't exist, and neither does /dev/gptid.

My GPT labels are set as follows:

Code: 
[root@router ~]# gpart show -l
=>       40  234441568  diskid/DISK-50026B778374B4BE  GPT  (112G)
         40       2008                                - free -  (1.0M)
       2048     262144                             1  esp  (128M)
     264192    8388608                             2  swap  (4.0G)
    8652800  225788808                             3  (null)  (108G)

Can anyone suggest a reason why the partition labels and and UUIDs have stopped working?
 
First I would make sure you didn't disable them in /boot/loader.conf

Code: 
kern.geom.label.gptid.enable=0
kern.geom.label.gpt.enable=0
 
output of
sysctl -a | grep geom | grep label

There are systctls that expose the different ways disks can be found before the devices are withered.
 
I should have said, I checked those already. They're both enabled:
Code: 
kern.geom.label.gptid.enable: 1
kern.geom.label.gpt.enable: 1
 
what version of FreeBSD? Is there anything automounting the esp partition?
What is the exact error message returned from the failed mount command?
It looks like the "disk" is at /dev/diskid/DISK-50026B778374B4BE
Is there an entry below that representing the esp partition?

Typically if /dev/gpt is not visible that implies the entry was withered.
 
FreeBSD 13.2-RELEASE
Code: 
[root@router ~]# mount /boot/efi
mount_msdosfs: /dev/gpt/esp: Invalid fstype: Invalid argument
[root@router ~]# mount_msdosfs /dev/gpt/esp /boot/efi
mount_msdosfs: /dev/gpt/esp: Invalid fstype: Invalid argument
[root@router ~]# mount_msdosfs /dev/diskid/DISK-50026B778374B4BEp1  /boot/efi
[root@router ~]#
It mounts successfully when I use the diskid.

What do you mean by 'withered'?
 
There are a bunch of threads on here talking about withering, I'll explain it my understanding, may miss some technical details, but the overall should be "about right".

The GEOM layer does a bunch of good stuff, one of the things is present a physical device to the system.
Start with a single SATA attached device, typically call it ada0.
you use gpart to partition and attach labels to those partitions lets say you create 1 partition and gpart label it PartOne.

At the dawn of system time (when it boots) that partition actually shows up in multiple ways:
/dev/ada0p1
/dev/gpt/PartOne
/dev/diskid/somethingbasedonserial number
/dev/gptid/guidbased on something.

All of these are valid ways for you to identify that specific partition.
All of these ways are visible until you do something that requires exclusive access to that partition.
The most common "exclusive access" is the mount command.

If you do mount /dev/ada0p1 /blah, all the other references to that partition disappear from /dev.
If you do mount /dev/gpt/PartOne, all the other references disappear.

The "disappear" is called withering: the system hides all other ways to reference the partition when one is used.

In your specific case I'm guessing that something is referencing the disk via the diskid and causing the other ways to be hidden, that's why the last mount_msdosfs worked. Simply doing ls /dev and looking for a gpt or gptid subdir would show whats still available. If they don't exist, then something has caused them to be withered, a sysctl to disable them or a mount using a different method (ada0p1, diskid/blah)
 
You must log in or register to reply here.
Back
Top