does it not?

rtprio: does it not what?

hm

I was wondering why updating from 14.3 --> 15.0 pf was blocking packets

in 14.3 pass out was default in pf, if you blocked in you had an implicit pass out

but in 15.0 this is gone, and you must explicitly pass out

interesting...

adonis: you cant smartctl -a /dev/gpt/id/${uuid}?

rtprio, What? /dev/gpt/id/something? Does that exist? Does something enable it?

rwp: i thought it could be

/dev/gptid/832f9f02-92ec-11ed-a294-589cfc0428ea hrm, but that's a partition

why not prevent the identifiers from changing?

rtprio: smartctl -a /dev/gpt/<gpt_label> doesn't work. How do I prevent the identifiers from changing?

well, let's back up; what drive is it?

I have multiple drives in a zfs pool (3.5 spinning disks). I assigned labels to them.

I'm not sure how or why, but sometimes the drives identifier ada0, ada1, gets shuffled around and ada0 might not exist anymore.

which breaks my smartd.conf

does this happen randomly on boot or ...

yes its on reboot/shutdown/startup of system.

shutdown+startup

its important to note that freebsd is running a vm, and the disks are passed through to it.

uh, something causes it

running *as a vm

ok, there it is

that is an ... unusual way to run ZFS

:).. I used to run on baremetal but since I have a lot of cores on my zfs machine I turned into a vm host

inside the host is my freebsd vm with zfs pool (pass-through disks)..

Unfortunately modern kernels (both *BSD and Linux) order /dev/da? drives at boot time and rather dynamically and prone to race conditions. As far as I know it is not possible to force this to be persistent. Other than UUID labels.

there _used_ to be a kernel option to make them more static

but i can't seem to find it again

I just haven't run into a case myself where it mattered for my smartd.conf configuration which drive was which drive.

My systems all have two drives or eight drives or whatever but they are all equiv and so it doesn't matter if they are re-ordered at boot time or not. And for ZFS I am using GPT partitions so those are persistent but those are not used by smartd.

rwp: are you just doing DEVICESCAN in your smartd.conf?

Nope. I list them out. Example: /dev/da0 -a -I 190 -I 194 -o on -S on -s (S/../../[1-6]/03) -m root

And so on 1, 2, 3, ... with different hours to run self tests but it doesn't matter if they have moved around as long as all of them get a self test each night.

I skew the hours so that they don't all run at the same time.

rwp: I'm doing the same, the issue is on reboot's etc, that da0 may no longer exist because it became da1. So a group of disks da0-da4 referenced in my smartd.conf becomes da1-da5

At reboot I have never seen 0 be vacant. The kernel will always allocate device ids starting with 0 and on through N.

here's an idea, don't reboot

rwp: Ok, I'm probably wrong.. then what happen is da0 becomes ada0..

happens*

what the heck is your virtualization doing

I obviously have to test what scenario causes this issue better lol, but that’s the gist yea.

da0 is for SCSI, SAS, USB devices. ada is for SATA devices. If you have ada then you have a SATA device.

A /dev/daX device will not become a /dev/adaX device. It will just always be a /dev/adaX device.

My example above is for a system with SAS disks. And you were talking about /dev/daX so I went there for the example.

hmm ok, I have be to be wrong then as to how the identifiers are changing.

well is just the number changing or what

let me reboot now.

Usually it is just the number changing.

ok, I can't lol.

And especially if two SATA devices are on different SATA controllers such as when two are on the primary motherboard bridge and the motherboard has six more on a secondary controller. There appears to be a race condition enumerating them and those are what I see changing most often.

wait

I have a group of disks on SCSI yes, and another group on SATA

why not just run smart on the host when the vm goes down

this just seems... backwards

rtprio: why would I run it on the host for the disks that are passed through. Once passed through they are no longer even seen by the host.

rwp: regarding the starting from 0, I'm looking at my ada disks right now and they are starting from ada2

I did some research and apparently kern.geom.label.disk_ident.enable=1 will enable /dev/diskid/* but none of my systems have it enabled. Do newer installed systems enable it by default?

rwp: that’s from a 6-port sata controller with only disks connected

4* disks connected

Interesting. I haven't seen that myself. I am going to enable kern.geom.label.disk_ident.enable=1 on one of my test systems and see what happens.

rwp: ok, no, I'm wrong again, sorry. I do see I have a ada0 and ada1, those just don't show via 'camcontrol devlist'

I am curious. If you run "camcontrol devlist" do the passX numbers also start at 2?

Oh, okay, whew! Because that preserves what I thought must happen.

So my vm has ada0 and ada1 which are not pass through disks but logical disks that I created in the vm host itself and gave to freebsd.

logical virtual disks

ada2-ada5 are sata disks from the 6port sata controller I'm passing through

I'm looking at the history of my smartd.conf.. and yea I see it used to reference ada0 and ada1 as some of my pool disks..

I am not quite tracking. Your FreeBSD system with the /dev/adaX starting at 2 is a virtual machine? And the hosting system is a FreeBSD system with /dev/adaX starting at 0? Wish I had a diagram...

I'll explain. My FreeBSD system is a VM. It has two disks (virtual disks) given to it from the vm host that show up as adaX disks. It also has another group of 8 disks that are passed through completely, a group of 4 disks on a SCSI controller and a group of 4 on a SATA controller.

the virtual disks are simply for OS storage and a swap partition. The 8 passed through disks are for the zfs pool. The 8 passed through disks are what I am monitoring in smartd.conf.

I can see in my smartd.conf history that at some point the disks monitored were ada0-ada3, da0-da3. But then that broke as it seemed the sata disks changed from being ada0-ada3 to ada2-ada5.

On the system I enabled that kernel option and rebooted has an internal mmcsd nand flash storage device but I am not using it at all. That device then showed up in /dev/diskid/DISK-A2AE2A17 and all partitions on it. But that device is not smart capable. None of the SATA disks on that system show up in that directory.

I imagine that at early boot time all devices are in /dev/diskid/* but then as they are consumed and mounted the kernel removes all other devices, as it does, to prevent then from being accessed.

And so the result on my test system is that only the unused device is left in /dev/diskid/* so even if that "works" it is not useful for smart access.

rwp: how does FreeBSD determine that my two vm disks should stay at ada0 and ada1 (my pool disks ada2-ada5) instead of flipping to ada4, ada5 (my pool disks ada0-ada3)?

on a reboot

is it just a matter of which disks it detects first?

I don't know. It's outside my expertise. But I would have said they are not guaranteed to be stable. They might change on reboot. And that's the issue.

good morning

yup that the issue :D

Not to ghost you but I need to drop afk immediately for a bit...

rwp: no prob!

i tried wayland but with my old hardware and legacy driver, it seemed like it is better to stick with X

I feel like opening a ticket on smartmontools. Would be nice if it just supported identifying disks by /dev/gpt/<label>.

do it

:scratches_head.. I feel like this will go the way of "no, fbsd needs a way to identify disks in a manner that doesn't change. Labels are for partitions not disks."

lol who knows what they'll say

related: smartmontools/smartmontools #295

or you could run scrutiny which monitors all disks and keeps track by drive serial number

rtprio: Hmm, that’s a good idea!

thatll bypass the issue since scrutiny will just do smartctl --scan and remap the drives via their serial numbers everytime.

that’s what I expect at least :)

alright, sleep time. rtprio, rwp, thanks a lot!

mornings, y'all.

Howdy.

is there a good place to discuss specifically available GUIs and themes for freebsd - and assumingly any other unix os too? I’m guessing most of you guys in here aren’t big in to GUIs

GoSox most people here use GUIs :-)

oh you do? it sounds like you’re all cli only types

but anyway, i’m just about to jump in to bed so no gui related questions today :D

GoSox: I think by "GUI" you mean desktop environments.

idk if you can install gnome or KDE on freebsd...

i am new to this camp too so

ugh

istg I hate networking sometimes

pf is disabled, IPv6-only, bhyve vm has an IPv6 address, with the gateway of an IPv6 address on the tap interface (I know I could have use LLA but meh, but there is no route

tcpdump shows solicitation packets coming in on tap

but no response, despite the fact tap has the address being asked for...

im prob just going to need to bridge at this point

as I am days behind and I am not going to get paid otherwise

okay bridged it and it works, but I dont want to bridge I was it routed...

I do that with all my other VMs, but for some reason I cant get it to work with IPv6

must have fucked something up

or maybe not, because the host is getting NS but isn't responding to them, and pf isn't blocking it because pf is disabled

so why would the host ignore the NS coming in on tap0 when it has the address its fucking asking for

So according to xz(1) `-c, --stdout, --to-stdout` are options to "Write the compressed or decompressed data to standard output instead of a file. This implies"

Burt whenever I try it, I just get xz: Compressed data cannot be written to a terminal

xz: Try `xz --help' for more information.

'xz --help' says same: -c, --stdout write to standard output and don't delete input files

so, I updated one of my systems from 14.3 to 15.0. and for some reason it also upgraded my jail. now pkg/freebsd-update is broken in that (as it believes to be 15.0) is there something I can do to fix that?

or at least freebsd-update/pkg think they are on 15.0

imo it gets weirder hst.sh/agebacucuq.makefile this is on the host

hm, seems like os-release doesn't get changed when you upgrade FreeBSD? is that normal?

rrahl0 has already left but if /etc/rc.d/os-release did not get upgraded then I think the system did not get upgraded. That's a file in base. And that file did not get updated. Therefore base did not get upgraded.

how can I make pkg automatically restart a service when a specific package is upgraded

to the question I asked "can you make installworld/installkernel from sshfs" it seems like the answer is yes!