[freebsd-questions] root passwd change

[Eric Pogroski]

On Wed, 22 Oct 2003 10:06:12 -0400
Lowell Gilbert <freebsd-questions-local at be-well.no-ip.com> wrote:

> Eric Pogroski <pogrose at twcny.rr.com> writes:
> 
> > here's whats needed:
> > 
> > <presuming a full, multiuser system is running>
> > # shutdown now
> > # <hit return at the prompt for 'sh'> (csh & tcsh both go fubar in
> > single-user mode) <at this point, all of the filesystems are
> > still mounted> 
> > # passwd root	<--- this is important - lost one system by NOT doing
> > this
> > # exit	-or-	reboot	<--- I prefer a reboot, but that's me.
> 
> Oh, right; we're only trying to change the root password here.  That's
> not actually affected by securelevel at all, so that was a red herring
> for me to bring up securelevel in the first place.
> 
> > work's about 9 times out of 10. It's the tenth one that makes you
> > bald from frustration... :)
> 
> You need the ability to invoke shutdown.  Since you don't have the
> root password, you need some other account with either root (via sudo,
> for example) or operator-group access.
> _______________________________________________
> freebsd-questions at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to
> "freebsd-questions-unsubscribe at freebsd.org"

Alright, before this turns ugly, I have a better way to go about this:

either a) just reboot the box, and boot off of a fixit disc, and use the
emergency terminal, follow the directions regarding soft linking
/etc/groups & /etc/*.db, and then change the password from there

or b) reboot the box, hit any key but enter when the countdown appears,
and enter single user mode, and do (providing no errors on boot):
	mount -u / (takes the / partition out of read only mode)
	mount -a -t ufs (mounts /tmp, /usr, and /var, and any other ufs
filesystems for you)
	passwd root <enter new pass, confirm new pass>
	reboot
	login as root

it's kinda like doing the build world routine, only no fsck or massive
amounts of compiling.

However, if kern.securelevel is set to anything but '-1', and
kernsecurelevel_enable is set to "YES" in rc.conf, your not going to get
in without some good, old fashioned hacking.
Seeing as it was never mentioned what either or both of the previous
settings are, we both are shooting in the dark here.