Recovering an MX80 that is booting on “alternate media”

3 09 2012

Just came into the lab to find an MX80 sitting at a DB>   prompt.  Not having seen that before, and being in a rush, I powered it off and back on again.  It came up asking me to type recovery or just hit enter for single-user mode.  So here’s what I did….

If I did a “reboot” in single user mode it would come back up but say that it was running on alternate media.  I recalled something a while ago with M7i and M10i where the disk (I think) would drop out of the list of bootable devices.  This old article on cluepon seemed to be the solution at the time.

But there isn’t a hard disk in an MX80 – it has two 4GB flash disks in it instead.  See the top of this page for details.   When the system comes up, I was seeing the following, implying that two flash disks were present:

## Starting application at 0x00010080 ...
Consoles: U-Boot console
Will try to boot from
USB
nand-flash0
nand-flash1

But, still the alternate medial message would appear once the system was up:

Amnesiac (ttyu0)

root@% root
root@%
root@% OS 11.1R1.14 built 2011-03-28 22:27:29 UTC
root@%
root@% ICE: System is running on alternate media device      (/dev/da1s1a).
root@%
root@%

So I followed a bit of the cluepon article to look at the boot list, and this is what I got:

root@%  sysctl machdep.bootdevs
machdep.bootdevs: usb,nand-flash0,nand-flash1
root@%

So it lookst as though there are two flash devices in the boot list – should be ok, right?  But when I do a ‘mount’ I can see that there’s no ‘da0’ device listed:

root@% mount
/dev/da1s1a on / (ufs, local, noatime)
devfs on /dev (devfs, local)
/dev/md0 on /packages/mnt/jbase (cd9660, local, noatime, read-only, verified)
/dev/md1 on /packages/mnt/jkernel-ppc-11.1R1.14 (cd9660, local, noatime, read-only, verified)
/dev/md2 on /packages/mnt/jpfe-MX80-11.1R1.14 (cd9660, local, noatime, read-only)
/dev/md3 on /packages/mnt/jdocs-11.1R1.14 (cd9660, local, noatime, read-only, verified)
/dev/md4 on /packages/mnt/jroute-ppc-11.1R1.14 (cd9660, local, noatime, read-only, verified)
/dev/md5 on /tmp (ufs, local, noatime, soft-updates)
/dev/md6 on /mfs (ufs, local, noatime, soft-updates)
/dev/da1s1e on /config (ufs, local, noatime)
procfs on /proc (procfs, local, noatime)
/dev/da1s1f on /var (ufs, local, noatime)
root@%
root@%

Since this is a lab device, I went back into the CLI and did a ‘request system snapshot’, which has the effect of copying the booted drive contents onto the other.

root@% cli
root> request system snapshot
Verifying compatibility of destination media partitions...
Running newfs (899MB) on internal media  / partition (da0s1a)...
Running newfs (99MB) on internal media  /config partition (da0s1e)...
Copying '/dev/da1s1a' to '/dev/da0s1a' .. (this may take a few minutes)
Copying '/dev/da1s1e' to '/dev/da0s1e' .. (this may take a few minutes)
The following filesystems were archived: / /config

root>

Rebooted, and all appears to be working again….  Phew.

Advertisements

Actions

Information

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s




%d bloggers like this: