Solved Mounting / with a persistent name

H

hirada

Hello,

I am having the strange issue, that removing a pcie card from a specific slot renders my system, a rather minimal 15.1/pkgbase, unbootable. I am being dropped into mountroot due to an error 19. This behaviour is consistent and repeatable.
Not sure what is going on here, but I would like to change my fstab from
Code: 
/dev/nda1p2     /               ufs     rw      1       1
to something more persistent.

Here starts the problem. While / does of course have a gpt label, SYS, this does not appear below /dev/gpt:
Code: 
# gpart show -l /dev/nda1
=>      40  28131248  nda1  GPT  (13G)
        40    532480     1  (null)  (260M)
    532520  26730496     2  SYS  (13G)
  27263016    868272        - free -  (424M)


# ls -l /dev/gpt
total 0
crw-r-----  1 root operator 0x68 Jul 27 14:45 vmpool

With vmpool being on a completly different drive.

Are there any options left? Or am I out of luck. I am unable to identify any other markers I might be able to use.
As /dev/gptid and /dev/diskid are also only listing the respective ids from the vmpool partition, but not from the root drive.

It seems, my boot/root drive is absent, besides gpart and mount. Even though the machine obviously has booted fine (as long as the card is in its pci slot).
Also, gpart modify -l lets me change the label. But, even after a reboot, it does still not appear below /dev/gpt.

Code: 
# mount | grep nda1p2
/dev/nda1p2 on / (ufs, local, soft-updates, journaled soft-updates)



# sysctl kern.geom.label.gpt.enable
kern.geom.label.gpt.enable: 1

This is somewhat consistent with mountroot, where ? also only displays the zfs drive, after the pcie card has been removed. That zfs drive, again, is located on a physically different nvme.

Any documentation I might have missed?
 
hirada said:
While / does of course have a gpt label, SYS, this does not appear below /dev/gpt
Click to expand...
Default installation has these in /boot/loader.conf:
Code: 
kern.geom.label.disk_ident.enable="0"
kern.geom.label.gptid.enable="0"
If the disk was mounted using the /dev/nda1p2 device, the other disk device 'labels' disappear. To avoid confusion, because the same disk would show up with 3 or 4 different 'names'.
 
Bummer: At least I have found the reason for not booting, just as I posted I realised, I had passthrough devices set in loader.conf. Of course the pcie ids change by removing cards.

However, this does not solve the original issue of using persistent naming in fstab, what I still very much would like to do. But it may reduce side tracking.
 
Just use the GPT label, it apparently has one (looking at the gpart(8) output). If you're stuck on the mountroot prompt, enter that same label name, probably something like ufs:/dev/gpt/SYS
 
SirDice said:
Default installation has these in /boot/loader.conf:
Code: 
kern.geom.label.disk_ident.enable="0"
kern.geom.label.gptid.enable="0"
If the disk was mounted using the /dev/nda1p2 device, the other disk device 'labels' disappear. To avoid confusion, because the same disk would show up with 3 or 4 different 'names'.
Click to expand...
Show up with different names until something "claims" it; claiming being a mount command?
I think by default gpart labels exist in /dev/gpt until the device/parititon is mounted by /dev/ada0p1 (path)

So boot as SirDice says, then edit /etc/fstab to use the label.
 
I typically remove them, I don't mind the same device showing up multiple times under different names, I'm aware this happens and why. But it often confused the heck out of newbies.
 
Thanks very much, that was unexpectedly fast. I've now set both to "1" and rebooted, but the labels do not reappear. Is this irreversible, if once mounted by partition?

Code: 
# uptime; sysctl kern.geom.label.gptid.enable kern.geom.label.disk_ident.enable
 3:39PM  up 34 secs, 1 user, load averages: 0.10, 0.03, 0.01
kern.geom.label.gptid.enable: 1
kern.geom.label.disk_ident.enable: 1

I've also changed the gpt label again and rebooted, no change.
 
Hum... Here, the efi partition is mounted, yet its label is still visible in /dev/gpt.
Conversely, the root file system label "zfs0" isn't visible. I think there is something more to understand.
 
Just for the record. Removing the label, rebooting and recreating one does not help either
Code: 
gpart modify -i2 -l "" /dev/nda1
reboot ...
Code: 
gpart modify -i2 -l "SYSTM" /dev/nda1
reboot ...
Code: 
# ls -la /dev/gpt
total 1
dr-xr-xr-x   2 root wheel     512 Jul 27 16:01 .
dr-xr-xr-x  13 root wheel     512 Jul 27 16:01 ..
crw-r-----   1 root operator 0x68 Jul 27 16:01 vmpool
 
Emrion said:
Hum... Here, the efi partition is mounted, yet its label is still visible in /dev/gpt.
Conversely, the root file system label "zfs0" isn't visible. I think there is something more to understand.
Click to expand...
Yeah, sometimes the whole geom withering seems inconsistent, but I'm probably misunderstanding something.
I think I would start by booting a live image, then poking in /dev to see what's there.
 
mer said:
Yeah, sometimes the whole geom withering seems inconsistent, but I'm probably misunderstanding something.
I think I would start by booting a live image, then poking in /dev to see what's there.
Click to expand...
Yes. geom seems somewhat inconsistent from this point of view. I unmounted the efi partition. Then, I mounted it manually (previously it was by fstab), this time its label disappeared from /dev/gpt.

So, it deserves the try. Just be prepared to rescue the system in case things go wrong.

Or... I think I have somewhere a VM with ufs-on-root, I can try if this can help.
 
Don't need to put the efi partition in fstab any way. The installer automatically puts it there, I often change it to noauto. I'll mount it when I need to update loader.efi but keep it unmounted during normal operations.
 
SirDice said:
Don't need to put the efi partition in fstab any way. The installer automatically puts it there, I often change it to noauto. I'll mount it when I need to update loader.efi but keep it unmounted during normal operations.
Click to expand...
This is a VM and I left the installer automatically mounted the efi partition. For me, this has no importance. I have a snapshot, I can roolback if inadvertly I do something evil with the content of this partition. That said, you are right, it's probably safer to let it unmounted.
 
I like the idea of being forced to manually mount partitions sometimes; something like an efi partition: yeah I want to know when that's mounted (potential security issues). noauto is the good compromise: it's in fstab, but not automatically mounted.
 
It works on my VM. You can go for
/dev/gpt/SYSTM in /etc/fstab now, if I well followed the story. But, check twice what you put in fstab!

In fact, it's a little more vicious than we thought. If you mount with the geom name, you don't have the label in /dev/gpt. But, if you mount with the gpt label, you see the gpt label in /dev/gpt. And you have still the geom name in /dev. It's why I saw my ESP gpt label, because it was mounted by its label name in fstab.
 
That's interesting. My understanding is a few of the /dev entries are created by default (diskid, gptid) based on a uuid generated somewhere. gpt labels and geom labels are different level (I think) and then we have the "raw" /dev/adaNpY which never seems to go away.

But I think bottom line circle back to OP, there are "labels" that are consisistent, regardless of where the device physically lives on a bus (unique id similar to ethernet mac being unique) and using that in /etc/fstab should be consistent. Removing the old "wired" definitions needed to get around this.
 
Thanks very much to all. Emrion extra thanks for giving it a go and actually trying it out. I took the leap and can confirm, enabling the sysctls as per SirDice and then kind of blindly changing the fstab to gpt, made also my machine reboot cleanly.
 
You must log in or register to reply here.
Back
Top