Does anyone know which log file shows cloud-init errors during provisioning? The JSONified cloud config in the customer_metadata gets ignored and I can not find any error related to this issue.

TheTim0Nat0r : what kind of instance is it?

neuroserve: lx and kvm

there could be logs in /zones/<zonename>/logs - at least the console log should have some cloud-init output

Does agetty have something to do with it? Thats the only thing I could find: "agetty: cannot connect on UNIX port"

Never mind, found this in the guest : i.gyazo.com/48fc296f3cd3766afb964ba2a2fd53d4.png

you should be able to update the metadata of an instance with sdc-updatemachinemetadata (docs.tritondatacenter.com/public-cl…ata/metadata#use-cases-for-metadata)

Been updating metadata multiple times, the string has changed but not the behaviour unfortunately

danmcd rmustacc: any idea of what to do with the sestopo output to find the slot / light it up?

does the slot show up in fmtopo -V ?

jbk us-east-storage.solutions.iqvia.com/bruce_dev/public/topo-v

is that cut off? it seems to stop at the first bay

hmmm

let me reupload

Same url, 6264 lines

yeah looks like it stops there.. i wonder if there's something it's not liking about the enclosure

my understanding is that the t10 standards for ses can be a bit.. open to interpretation by vendors

lol, so what do I tell the DC guy who has to replace the drive?

does sestopo output anything?

us-east-storage.solutions.iqvia.com/bruce_dev/public/sestop-ses0 us-east-storage.solutions.iqvia.com/bruce_dev/public/sestop-ses1

try 'TOPOSESDEBUG=1 fmtopo -V' -- that should output debug info which might help explain why it's not enumerating the contents despite sestopo showing they exist

though that output goes to stderr

so you might need fmtopo -V > topo.txt 2>debug.txt (or 2>&1...) to capture it

"/usr/lib/fm/fmd/fmtopo: failed to get properties for bay=0: (null)"

"/usr/lib/fm/fmd/fmtopo: failed to get properties for FAN6=0: (null)"

that is strange... the '(null)' appears to be coming from topo_strerror(), but unless there's something smartos-specific going on there, it should always return a string, and never NULL

Nothing AFAICT we change there:

kebe(~/ws/ij-cr)[0]% diff {~/nfslinks/nowhere/ws/illumos-gate,.}/usr/src/lib/fm/topo/libtopo/common/mkerror.sh

kebe(~/ws/ij-cr)[0]%

just to see.. if you do 'UMEM_DEBUG=guards TOPOSESDEBUG=1 fmtopo -V'

does it crash?

danmcd: looking at topo_strerror() -- it seems like it should always return a string

no

unless i'm missing something

and looking at that error message from fmtopo, there appears to only be one spot where that happens

Smithx10: I've not had any chance to review or dig, sorry.

one thing that's (maybe) interesting is there's an ARRAY_DEVICE element that seems like it's actually a 'container' for the actual drive bays.. i haven't dug too deeply, but the impression I get is that there's an assumption that ARRAY_DEVICE is a slot/bay

and it's also enumerated first

hmm

I guess to make it easier I could take this drive out of the pool

and maybe make the pool do work?

and the non blinky drive could be the other spare.... or it....

that might work..

you could also try doing a dd if=/dev/dsk/<other spare> of=/dev/null to make the other spare light up