thanks sommerfeld

next time you reach for an AI tool, remember Jia Tan.

the AI tools *are* Jia Tan.

[illumos-gate] 17978 want cp/mv/ln -T -- Robert Mustacchi <rm⊙fo>

[illumos-gate] 17979 ln should support -L and -P -- Robert Mustacchi <rm⊙fo>

nice!

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

not showing any ixgbe

(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)

(560) spin:/root# update_drv -a -v -i '"pci108e,7b11"' ixgbe

exit status = 0

devfsadm: driver failed to attach: ixgbe

exit status = 1

Warning: Driver (ixgbe) successfully added to system but failed to attach

I do have rebuild /etc/path_to_inst multiple times, but nothing changed

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.)

messages and syslog have *no* log for ixgbe, and syslog sends kern.debug to messages

fmadm faulty?

nothing, I had three entries which I have acquit'ed

if you evacuated a system like that, I would still be willing to bet it's confused about state

what I can't do is find a good guess as to what

richlowe: I agree on the confused part. I just wonder where it persists device data outside of path_to_inst and driver_aliases

do the devices show up in the output of /usr/lib/pci/pcieadm show-devs ?

oh, AND: if I boot from a OI install stick, all devices are configured correctly

and are available?

sommerfeld: yes: af/0/0 PCI -- 82599ES 10-Gigabit SFI/SFP+ Network Connection

af/0/1 PCI -- 82599ES 10-Gigabit SFI/SFP+ Network Connection

tsoome: yes

Agnar: did the path_to_inst rebuild include rebuilding the boot archive?

(and then rebooting?)

sommerfeld: erm, I have deleted it and boot -arvw

I would probably do an explicit rebuild and double check

it's usually very good about doing an automatic reboot during boot to keep things from getting confusing

but I'm not 100% sure if that's clock sensitive at all or anything

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

`bootadm update-archive` `-R` selects an alternate root, `-v` is verbose

ah, the boot archive

let me try that

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.

note that there is other state in /etc/devices/* that could potentially be stale.

sommerfeld: can I safely delete that?

ok, so regenerating the boot-archive hasn't changed anything

I have deleted all files in /etc/devices/, did update the boot archive and rebooting now

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.

killing /etc/devices was the trick!!

w00t!!

ok, I'm going to blog that tomorrow - thanks a lot to you all :))

I wonder if it was the unit address persistence or what

richlowe: I would assume that, but killing files called "cache" usually makes sense too :)

cache invalidation is hard.

indeed, see nscd :)

[illumos-gate] 17956 decode nvme extended SMART logs -- Robert Mustacchi <rm⊙fo>