[rescue] Dictionary overflow?
sun.mail.list47 at oryx.cc
Wed Jun 15 17:53:46 CDT 2011
I had always done a boot -ar from the OK prompt, then answer the
prompts, but from (IMHO) the odd reply from the web page you came up
with, I went ahead and did a Yahoo search just to make sure I wasn't
The other obvious rebuild option I should have remembered was to use
devfsadm, as documented here.
The more peripherals you have hanging off of your system, the bigger
your /etc/path_to_inst file will be.
I don't want to come across as some type of authority on path_to_inst
files here. I have been administering Solaris systems since 1995, and
have probably rebuilt the path_to_inst file half-a-dozen times. If that
is truly your problem, I don't think that you are in that bad of shape.
I can't say that I have ever had to recover a path_to_inst file from
With all that out of the way, I truly hope that your problem is
something as simple as just a corrupted path_to_inst file. As stated
earlier, I don't recall ever encountering a dictionary overflow error,
and I hope that the web page you uncovered was correct in
troubleshooting your issue.
On 06/15/11 16:01, Justin Haynes wrote:
> Can you post a couple of techniques? I think it would be interesting to
> have in the archive. I'm not sure what you had in mind, but this reminds me
> of a story that illustrated to me the difference between this kind of hard
> ware and 'commodity' hardware of today.
> At the University of Houston a certain expert in the engineering department
> was called upon to solve a problem. One of the main (or the main, I forget
> which) mail server which was running SunOS had had some kind of catastrophic
> problem and the mailsystem was down without a usable backup. (I'm not
> suggesting that UH didn't do backups -but for some reason restoration was
> not an option)
> The admin sat at the Boot PROM and rebuilt a bootable kernel from the
> i-nodes. I apologize for the lack of detail, but the point is that I was
> impressed with the idea of a system that is recoverable under almost any
> circumstances if you Know What You Are Doing. And that there would be
> enough utility to local out of band management to manipulate the system
> without some sort of external tool.
> Certainly the process might have been rigorous or painful, but it was
More information about the rescue