[sf-lug] recovery from loss of root password

[Rick Moen]

Quoting Alex Kleider (a_kleider at yahoo.com):

> There are a couple of documented methods of recovering when a root
> password is forgotten:
> 1. if boot loader is lilo, the boot: Linux init=/bin/sh option is
> supposed to provide a shell with root privileges and further details
> are documented in the Debian tips chapter (8) of the Debian Reference
> Unfortunately this is of little use since Debian now uses GRUB, not
> LILO.
> Preliminary question: is there an equivalent GRUB boot option?

Exactly the same.  Hit "e" to edit, type that "init=" stuff un, Return,
then "b" to boot.

Upon boot-up, you'll want to do "mount -o rw,remount /", to make sure
the root filesystem is read-write.  Then, "passwd root".  Then, whatever
is your favourite ritual to make sure the disk cache is flushed before
reboot.  Some people like the Standard Sysadmin Cheerleading Call:

   # sync
   # sync
   # sync
   # reboot

> 2. also from Debian Reference is the second method using "any emergency
> boot/root disk set." I _assume_ that the Debian netinstall CD should
> serve the purpose. ..so the first question becomes is this a valid
> assumption?

Assuming said boot/root disk includes adequate driver support for your 
mass-storage chipset, provides (boots to) a root shell, and has
necessary device node files.  (Some distro boot CDs, for instance, at
least in early stages lack some of the things in the prior sentence.)

To ensure that you reliably have the necessary driver support (useful if
you encounter new-ish hardware), it's handy to occasionally refresh your
maintenance CD image, and pick one that uses a reasonably cutting-edge
kernel and is updated frequently.  My current favourite is Sidux, whose
2007.3 "gaia" release is based on a 2.6.22.3-rc1 kernel
(http://sidux.com/).

I believe they refresh quarterly, which is good enough for me.

Some people prefer Knoppix, or Ubuntu live CDs, or Mandriva Move, or 
MEPIS, or SystemRescueCD, or any number of alternatives.


> One can "Execute a Shell" from the Debian installer main menu. If that
> option is chosen, one is told that "ash" is being offered, the root
> file system is a RAM disk, nano is available as an editor and the hard
> disk file systems are mounted on "/target".
> An ls command however shows no /target entry.
> So the second question: Is the notice just plain wrong?

I have no idea what exact situation you're seeing, for lack of access to
the information on your various virtual-console screens at the time
(Ctrl-Alt-F1, ...F2 ...F3), but looking at those will tell you what's 
recently happened, e.g., if the installer simply hasn't yet reached the
point of mounting target filesystems, or if it tried and failed, etc.

> Also, after executing
> # mkdir fixit 
> which does what it should, the following
> # mount /dev/hda1 fixit 
> yields the error:
> mount: Mounting /dev/hda1 on fixit failed: Invalid argument
> I've no idea what the invalid argument could be.

I don't either, offhand (though, if I saw that, I'd check in the
system's logfiles and/or the other virtual consoles), but maybe you
should try to solve an easier, problem, by using a live CD intended for
maintenance purposes, rather than a distro installer disk.

Also, are you _sure_ it's "hda1"?  If this is SATA, and especially if
you're in 2.6.x kernels, it might be "sda1", which gaffe would generate
that error message.

> Next installment (after problem solved:)
> I downloaded the Gentoo (vs. Debian) install iso, burned a CD  and
> booted from it,

Why an _install_ ISO?  You're not seeking to install an OS.   This is
what maintenance and live-CD images are for.

> then the # mkdir fixit followed by # mount /dev/hda1 fixit all worked.
> After that it was a simple matter of deleting the root password entry
> in
> /etc/shadow
> and finally # shutdown -r now
> remembering to get the Gentoo CD out of the drive in time.
> It remains a mystery why the Debian install CD doesn't work the same
> way.

Could be that it just hadn't reached the installation stage where it
created the device node files.  (This might well have been a
2.6.x-kernel-based CD, in which case the "/dev" tree is supposed to get
autopopulated using "udev".)  You can of course manually create /dev
files using the "mknod" command, at the cost of some moderate level of
masochism.   Or of course you could be specifying the wrong device name.

But use the right tool for the job, would be my primary advice.