Correct : The IO nodes are running a full linux install (RHE 6.4) on the same hardware as the CNK nodes.

On vesta I do not have an account and I am not certain the IO nodes are available for direct login. I’m using the BGQ at CSCS which is an EPFL machine. The IO nodes are open for some special projects where we
are trying to customise the IO.

I’m compiling hwloc using clang (bgclang++11 from ANL) to run on IO nodes af a BGQ. It seems to have compiled ok, and when I run lstopo, I get an output like this (below), which looks reasonable, but there are 15 sockets instead of 16.
I’m a little worried because the first time I compiled, I had problems where apps would report an error from HWLOC on start and tell me to set HWLOC_FORCE_BGQ=1. when I did set this env var, it would then report that “topology became empty” and the app would
segfault due to the unexpected return from hwloc presumably.

Can you give a bit more details on what you did there? I'd like to check if that case should be better supported or not.

I wiped everything and recompiled (not sure what I did differently), and now it behaves more sensibly, but with 15 instead of 16 sockets.

Should IO be worried?

The topology detection is hardwired so you shouldn't worried on the hardware side.
The problem could be related to how you reserved resources before running lstopo.
Does lstopo --whole-system see more sockets?
Does BG_THREADMODEL=2 help?