Hi, Having spent the past 2 hours trying to get my PC to the point of responding to any form of user input, I'm a bit grumpy, sorry if that comes through a bit too strong.
Three times now, I've had something happen to my nevada box (across different builds) that has resulted in no local console login. No way of accessing my PC, and no way to troubleshoot the problem locally. I've had dtlogin loops, that kept restarting X - no local console login was possible. I do mean endless! I've had an issue with one of the legacy scripts hanging the multi-user milestone. This one waits for _30_ minutes before giving up (I later found this out....I didn't think to try waiting THIRTY minutes to see what might happen....who would?!). Again, here the box seemed completely hung, no response to local user input. (ssh worked though) And just now, I've had some issue with iscsi (a bug I assume), where-by it'll boot, and just spill errors about my test iscsi target not working. This was the worst yet, as even though the network was up (I could ping the PC from another host), sshd wasn't responding, so not only did I not have local console access, remote access didn't work either. So I'd wait for a while (remembering the dtlogin incident) but it just dumps core and restarts. Finally I fixed the issue by following this guide http://www.opensolaris.org/jive/thread.jspa?threadID=21452&tstart=120 The crux of the issue: Each of these issues are/were extremely frustrating, but what's concerning me above all is that I've managed to get to the point of having an essentially unresponsive system 3 different ways in less then 3 months. This really screams to me that there is an issue with the way that opensolaris boxes boot up. Users are left with either a local screen that loops between console/X, no local console login at all, or worse no local AND no sshd access. Is this by design, or are the developers still working out the best way to link all the dependancies together? I'm happy to try and help out any way I can with this - maybe I'm just one of those people that manages to be break their boxes in weird and unusual ways... Hey the world needs testers eh? Finally, for my own education (and for next time...); When one does manage to break a service that is holding up the rest of the boot process, how do you disable it from a failsafe boot so you can get back to a non-crippled system? I tried to chroot /a, svcadm disable foo, but no joy there :/ Thanks Jonathan This message posted from opensolaris.org
