13:01:53 <nikolam> Maybe this repo should not exist, due to SmartOS copyrighted brand name ? https://github.com/SMARTos 
13:09:05 <nikolam> danmcd, This one seems to respond to update_drv -a -i pciex10ec,8161 rge    , not 8168
13:10:07 <nikolam> pciex10ec,8161
13:59:13 <nikolam> Do I need to make my own boot_archive, e.g. compile SmartOS with putting pciex10ec,8161  uts/into intel/os/driver_aliases to test it working on SmartOS ? 
14:13:48 <Dixie_F> Had an old zpool (zones_old) that wanted to import at boot (causing collisions and putting filesystem in maintenance) despite zfs set cachefile=none .  Eventually codex proposed just editing the usbkey list which worked but seemed like a terrible solution.  I have fixed this problem repeatedly in the past (12 years) Has something changed? Or am I just failing to remember something?
14:34:07 <tsoome> cachefile does not prevent collisions of mount points and such; there are different approaches depending on need. Like import the pool without mounting any datasets automatically and doing manual mounts later; or importing pool to alternate root tree (zpool import -R) - then you can have automatic mounts relative to alternate root.
15:32:08 <Dixie_F> This pool is not ever intended to be imported.  It is deprecated and the drives will be removed after data is transferred to the new pool (and such).  
15:34:44 <MelanieUrsidino> wouldn't you need to import it temporarily to take the data off it
15:46:34 <Dixie_F> We have taken the data off.  We just haven't deleted the pool or unplugged the drives.  So now, prior to the hack to the actual usb key, it faults on every boot.
15:48:57 <tsoome> you can rename the pool and export -- then it wont be imported automatically on boot
17:25:01 <danmcd> @nikolam Hang on... on this running system with your now-working rge can you please capture and share:
17:25:06 <danmcd> - prtconf -vd
17:26:54 <danmcd> - /usr/lib/pci/pcieadm show-devs -o vendor,device,subvid,subsys,subvendor,subsystem
17:27:22 <danmcd> You can shrink those outputs to JUST the realtek device.  This will help inform what to add into the PI (and NGL, illumos-gate as  well) for future releases.
17:29:58 <danmcd> I thought 8161 was a > GigE device too... which I know we don't yet support, but maybe I'm wrong.
17:33:40 <danmcd> And a quick dive in FreeBSD suggests we should indeed have 8161 in rge(4D)'s list of acceptable ones.