On 3/23/16 5:43 , Guenther Alka wrote: > For me, Solarish, Supermicro mainboards, Avago HBAs and Intel nics > are nearly a guarantee for a trouble free Illumos setup. > > Now there is a new 1151/ X11-SS generation of mainboards available, that > might be the the number one solution for an entry level to midrange > barebone or virtualized storage solution with IPMI, up to 64GB ECC RAM, > CPUs like the dualcore G4400 up from 50 Euro to fast quadcore Xeons > both with ECC and vt-d support. > > There are models with 1G, 10G and with or without Avago/LSI 3008 HBA. > I now got one of the first X11SSH-CTF boards in Germany with HBA and 10G. > http://www.supermicro.com/products/motherboard/Xeon/C236_C232/X11SSH-CTF.cfm > > > I was able to install ESXi 6u2 but when I tried a barebone install of > OmniOS > 151016 or 151017, after booting from USB, I got a: > > - Probing for device nodes >> Console login, service cannot run, > enter user for system maintenance mode: > > > As I know, that the X550 10G nic is not yet supported, I disabled the nic > with a jumper setting and then the Avago 3008 HBA but with same result. > Boot order was set to legacy (EFI disabled) > > > A quick check with Oracle Solaris 11.3 gives the same result > Has anyone seen the same problem and has an idea how to solve?
Hi Guenther, Whenever these kinds of problems crop up, I know they can be quite frustrating, but with your help, we should be able to take it root cause, though it may be a bit involved. The very first thing I'd do is make sure I'm on an IPMI serial console and not some VGA console. The very first thing I do here is I boot to milestone=none, to help get a sense of where things might be going on. Usually these hangs are driver related, but sometimes I've seen things get gummed up for other reasons (though I don't have much OmniOS installer experience). The next thing I usually do is use kmdb. I add -v to the boot options and see what the last thing I see is. Note, that this last thing can be a little misleading, as it's often the last successsful thing that we see. Usually this means it's going to end up being a more manual process as I add -kd to the kernel command line in grub, which will drop you into kmdb. From kmdb I set the value of moddebug to 0x80000001 by running: > moddebug/W 0x80000001 This will cause us to trap into the kernel debugger every time we load a module. So what I do here is I use this to see what the last thing I see is. Once I have run that, I end up typing a lot of ':c' and trying to figure out what the last one I see is. Then once I have that, I'll go back and not using moddebug, set a breakpoint in that module's init or attach function and see what the last instruction I see is by stepping over things and seeing where exactly it's hanging. Does this help? Robert ------------------------------------------- illumos-discuss Archives: https://www.listbox.com/member/archive/182180/=now RSS Feed: https://www.listbox.com/member/archive/rss/182180/21175430-2e6923be Modify Your Subscription: https://www.listbox.com/member/?member_id=21175430&id_secret=21175430-6a77cda4 Powered by Listbox: http://www.listbox.com
