00:06:23 <Smithx10> thanks sommerfeld 
11:04:07 <Reinhilde> next time you reach for an AI tool, remember Jia Tan.
11:04:16 <Reinhilde> the AI tools *are* Jia Tan.
14:54:58 <gitomat> [illumos-gate] 17978 want cp/mv/ln -T -- Robert Mustacchi <rm⊙fo>
14:54:58 <gitomat> [illumos-gate] 17979 ln should support -L and -P -- Robert Mustacchi <rm⊙fo>
16:06:47 <tsoome> nice!
19:23:55 <Agnar> I need help with one of my servers. I had to move the disks (and all pcie cards) from my old X4270M2 to a X8-2L. the system boots, but refuses to see the Dual 10G Ethernet (ixgbe) and two of three NVMe devices (one shows up, "SK hynix") while both kingston cards are invisible. however, prtconf -dD does show all the devices - for the ixgbe even all instances and also the driver loads, but dladm show-phys is 
19:24:01 <Agnar> not showing any ixgbe
19:40:13 <Agnar> (550) spin:/root# prtconf -dD | grep ixgbe pci108e,7b11 (pciex8086,10fb) [Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection] (driver name: ixgbe) pci108e,7b11 (pciex8086,10fb) [Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection] (driver name: ixgbe)
19:41:23 <Agnar> (560) spin:/root# update_drv -a -v -i '"pci108e,7b11"' ixgbe
19:41:23 <Agnar> exit status = 0
19:41:23 <Agnar> devfsadm: driver failed to attach: ixgbe
19:41:23 <Agnar> exit status = 1
19:41:23 <Agnar> Warning: Driver (ixgbe) successfully added to system but failed to attach
19:44:34 <Agnar> I do have rebuild /etc/path_to_inst multiple times, but nothing changed
19:48:36 <tsoome> you get failure in ixgbe_attach(), most of those errors are logged with ixgbe_error() which is using "!%s" (man cmn_err: The message goes only to the system log.)
19:52:07 <Agnar> messages and syslog have *no* log for ixgbe, and syslog sends kern.debug to messages
19:54:55 <tsoome> fmadm faulty?
19:55:22 <Agnar> nothing, I had three entries which I have acquit'ed
19:56:24 <richlowe> if you evacuated a system like that, I would still be willing to bet it's confused about state
19:56:32 <richlowe> what I can't do is find a good guess as to what
19:57:20 <Agnar> richlowe: I agree on the confused part. I just wonder where it persists device data outside of path_to_inst and driver_aliases
19:57:48 <sommerfeld> do the devices show up in the output of /usr/lib/pci/pcieadm show-devs ?
19:58:13 <Agnar> oh, AND: if I boot from a OI install stick, all devices are configured correctly
19:58:37 <tsoome> and are available?
19:58:42 <Agnar> sommerfeld: yes: af/0/0  PCI            --             82599ES 10-Gigabit SFI/SFP+ Network Connection
19:58:45 <Agnar> af/0/1  PCI            --             82599ES 10-Gigabit SFI/SFP+ Network Connection
19:59:35 <Agnar> tsoome: yes
20:00:57 <sommerfeld> Agnar: did the path_to_inst rebuild include rebuilding the boot archive?
20:01:05 <sommerfeld> (and then rebooting?)
20:01:32 <Agnar> sommerfeld: erm, I have deleted it and boot -arvw
20:02:05 <richlowe> I would probably do an explicit rebuild and double check
20:02:20 <richlowe> it's usually very good about doing an automatic reboot during boot to keep things from getting confusing
20:02:37 <richlowe> but I'm not 100% sure if that's clock sensitive at all or anything
20:03:51 <Agnar> richlowe: could you elaborate on how you would do an explicit rebuild? I'm fighting with this system for four days and did a lot of rain dance already so I don't want to do any mistake
20:04:09 <richlowe> `bootadm update-archive` `-R` selects an alternate root, `-v` is verbose
20:04:23 <Agnar> ah, the boot archive
20:04:29 <Agnar> let me try that
20:07:36 <Agnar> the old X4270M2 powered off on monday night because of an electrical defect. so I checked ebay for good alternatived...thanks to AI, it doesn't matter if you look for a 15,10 or 5y old server - you basically pay per GB  of RAM, regardless of the age.
20:07:40 <sommerfeld> note that there is other state in /etc/devices/* that could potentially be stale.
20:07:56 <Agnar> sommerfeld: can I safely delete that?
20:09:37 <Agnar> ok, so regenerating the boot-archive hasn't changed anything
20:14:03 <Agnar> I have deleted all files in /etc/devices/, did update the boot archive and rebooting now
20:14:47 <sommerfeld> Thinking two different paths here.  1) while running off the busted root, try cleanups with devfsadm -v -C.  2) boot off of OI stick, import busted root, install a new BE into that root and make sure it can see devices.   Then migrate your new config into the new root BE from the old BE. 
20:15:39 <Agnar> killing /etc/devices was the trick!!
20:15:48 <Agnar> w00t!!
20:16:13 <Agnar> ok, I'm going to blog that tomorrow - thanks a lot to you all :))
20:16:15 <richlowe> I wonder if it was the unit address persistence or what
20:16:56 <Agnar> richlowe: I would assume that, but killing files called "cache" usually makes sense too :)
20:17:22 <sommerfeld> cache invalidation is hard.
20:17:39 <Agnar> indeed, see nscd :)
20:41:46 <gitomat> [illumos-gate] 17956 decode nvme extended SMART logs -- Robert Mustacchi <rm⊙fo>