home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / sys / next / misc / 21747 < prev    next >
Encoding:
Internet Message Format  |  1992-11-11  |  2.8 KB
  1. Xref: sparky comp.sys.next.misc:21747 comp.sys.next.sysadmin:6355
  2. Newsgroups: comp.sys.next.misc,comp.sys.next.sysadmin
  3. Path: sparky!uunet!zaphod.mps.ohio-state.edu!wupost!decwrl!concert!rock!taco!aeschwar
  4. From: aeschwar@ncsu.edu (Adam E. Schwartz)
  5. Subject: Standalone recovery & root access w/o login
  6. Message-ID: <aeschwar.721196562@news.ncsu.edu>
  7. Sender: news@ncsu.edu (USENET News System)
  8. Organization: North Carolina State University
  9. Date: Sun, 8 Nov 1992 04:22:42 GMT
  10. Lines: 52
  11.  
  12. Hi all,
  13.  
  14. I screwed things up on my standalone Station this morning after
  15. attempting to install the windowPackage.ps hack posted here 24 Oct, but
  16. managed to fix the problem in about 45 minutes (the time it took me to
  17. figure out I needed to interrupt the boot/init process to access the
  18. shell as root and restore the original windowPackage.ps).
  19.  
  20. (Yes, I was aware of the warning to "create a possibility to boot from
  21. another drive"... )
  22.  
  23. Anyway, wanted to share my experience to those who haven't (yet) had
  24. this sort of problem, epsecially you folks with standalones *without*
  25. that precious "nother drive". All this info is in the "Network and
  26. System Administration" book[let] NeXT provided with my Station.
  27.  
  28. My problem was I accidentally mangled the
  29. /usr/lib/NextStep/windowPackage.ps file, so when I rebooted my
  30. Station... BEHOLD! There was no login screen and *no* way to log in!
  31.  
  32. My Station is set to "verbose test mode", and after observing the
  33. messages at each step of the boot process (several times) I knew it was
  34. time to hit the ROM monitor, because I *knew* there was a way to
  35. interrupt the boot process and access the shell...
  36.  
  37. Well, ultimately I realized I had to reconfigure the paramaters (type
  38. "p") in the ROM monitor so that the boot command made the machine to boot
  39. in single-user mode (include the "-s" flag).
  40.  
  41. After doing this, it was a simple matter of rebooting (again) and typing
  42. <CONTROL>-<C> a few times to halt the process, and there I was at the
  43. UNIX command line, free to restore windowPackage.ps to its good old
  44. former self. (Of course, after making sure all was really OK, I restored
  45. the boot command (again in ROM mon) to boot in multiuser mode, which
  46. prevents such interactive access to UNIX.)
  47.  
  48. If I were a destructive sort, I could have deleted a bunch of important
  49. files, or changed root's password, etc., etc.
  50.  
  51. If you have a machine in a public area (such as a lab), I *strongly*
  52. suggest you establish a password for the ROM monitor. Likewise, set
  53. "Allow any ROM commands even if password protected" to "NO".
  54.  
  55. Well... this experience wasn't too bad, compared to the hours it took me
  56. to fix problems mounting DOS disks (there was a bad link... UGH!...
  57. learn by immersion... long story. ;^p )
  58.  
  59. --
  60. +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
  61. | Adam Schwartz  | W: 919-515-5424  | ASCII mail only, please. 
  62. | adam@ncsu.edu  |    (Raleigh, NC) | 
  63. +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
  64.