1) Use install/recover media that's part of your OS, like an install CD or recovery CD 2) Use recovery media that happens to support your root filesystem, like one of the many Linux distributions that are intended for recovery - but only if the recovery distribution supports your root filesystem type! FreeBSD seems to prefer UFS, so if you go this route, please be sure your recovery distribution includes read/write UFS support! 3) There is actually another way though, using a foreign-OS recovery CD... If you're not put off by a program like "bpe", and filesystem support isn't working out, and you don't mind getting a bit hackish, then you can bpe the raw partition of the root filesystem, search for something like "root:" to locate the password entry, and then replace "root:aaaaaaaaaaaaa:0:0:bbbbbbbbbbbbbcccccc" with "root::0:0:aaaaaaaaaaaaabbbbbbbbbbbbbcccccc" - the key is not to change the number of characters in the password or shadow file entry. This should erase the root password - or similarly for a shadow file, if required. Note that this likely won't work for a filesystem like Sun's new ZFS, which checksums every disk block - then again, I gather initially ZFS isn't going to support use as a root filesystem anyway. 4) Use some sort of security issue to break in: 4/A) One of the easier ones, is if you can boot to multiuser, and you have an NFS export to the machine in question, and the NFS export does not remap root to nobody or similar. In that case, you can just drop a setuid-root copy of bash or other shell into the NFS filesystem, and run it as an unprivileged user to get an effective uid of 0 (you may need to specify a -p option with some shells so the shell won't automatically drop privilege). This most likely won't change your real uid, so you may want to try su'ing to root afterward, to change your real uid to root as well. 4/B) You may also be able to "break in" to root using something like a passwordless ssh, rsh, or similar (srsh? :), if it was set up previously. 4/C) And then there's always the possibility of going to an exploit archive, and trying some of them. 5) Some systems will allow you to boot single user without a password. It may be worth a try, but this is getting less common as time goes by. On linux systems, you can sometimes, instead of booting from just a kernel named "linux", instead boot with "linux init=/bin/sh" - this will come up to a shell before the single user stuff would've kicked in. Note that some *ix's will require some sort of indexed password database to be rebuilt from your /etc/passwd and/or /etc/shadow file. Tru64 sometimes needs this, and here are some partial notes from a fellow UCI employee, Steve Chen, about doing this on a FreeBSD system: 1) Get “disc1” ISO image from http://www.freebsd.org/where.html. In my case, FreeBSD v5.4 for I386 2) Boot from CD and select Repair/Fixit. Go with the “live filesystem” route so you’d have access to the UNIX utils off of the CD under /mnt2. 3) In my case the OS is Raid5 and the / device used is /dev/aacd0s1a