When svc.configd(1M), the Solaris Repository Daemon,
is started, it does an integrity check of the smf(5)
repository, stored in /etc/svc/repository.db. This
integrity check can fail due to a disk failure, the database
file being corrupted either due to a hardware bug, a software
bug, or an accidental overwrite. If the integrity check fails,
svc.configd will write a message to the console, similar
to the following:
svc.configd: smf(5) database integrity check of:
/etc/svc/repository.db
failed. The database might be damaged or a media error might have
prevented it from being verified. Additional information useful to
your service provider is in:
/etc/svc/volatile/db_errors
The system will not be able to boot until you have restored a working
database. svc.startd(1M) will provide a sulogin(1M) prompt for recovery
purposes. The command:
/lib/svc/bin/restore_repository
can be run to restore a backup version of your repository. See
http://sun.com/msg/SMF-8000-MY for more information.
and exit, informing svc.startd(1M) that system
maintenance is needed. svc.startd(1M) will then
starts sulogin(1M), allowing the system
administrator to perform maintenance.
Once the system administrator has logged in, he should
run /lib/svc/bin/restore_repository, which will
take him through the steps necessary to restore a non-corrupt
backup. smf(5) automatically takes backups of the
repository at key system moments:
- The
boot backup is taken immediately
before the first change to the repository is made during each
system startup.
- The
manifest_import backup is taken
after svc:/system/manifest-import:default
completes, if it imported any new manifests or ran any upgrade
scripts.
The system maintains up to four backups of each type, deleting
the oldest backup when necessary. The backups are stored as
/etc/svc/repository-type-YYYYMMDD_HHMMSS,
where YYYYMMDD and HHMMSS are the date
(year, month, day) and time (24-hour hour, minute, second),
when the backup was taken.
When started, /lib/svc/bin/restore_repository
prints out a message similar to the following:
Repository Restore utility
See http://sun.com/msg/SMF-8000-MY for more information on the use of
this script to restore backup copies of the smf(5) repository.
If there are any problems which need human intervention, this script will
give instructions and then exit back to your shell.
Note that upon full completion of this script, the system will be rebooted
using reboot(1M), which will interrupt any active services.
If the system being recovered is not a local zone (see
zones(5)), the script will give you instructions
on how to re-mount / and /usr
read-write, so that it can recover the databases. After
printing the instructions, the script will exit.
The administrator should follow the directions given, paying
careful attention to any errors which may occur.
After / has been mounted writable (or if the
system is a local zone), restore_repository will
prompt you for the repository backup you would like to
restore, with a message similar to:
The following backups of /etc/svc/repository.db exists, from
oldest to newest:
... list of backups ...
The backups are named based on their type and the time when they were taken.
Backups beginning with "boot" are made before the first change is made to
the repository after system boot. Backups beginning with "manifest_import"
are made after svc:/system/manifest-import:default finishes its processing.
The time of backup is given in YYYYMMDD_HHMMSS format.
Please enter one of:
1) boot, for the most recent post-boot backup
2) manifest_import, for the most recent manifest_import backup.
3) a specific backup repository from the above list
4) -seed-, the initial starting repository. (All customizations
will be lost.)
5) -quit-, to cancel.
Enter response [boot]:
If you type enter without specifying a backup to
restore, the default response, enclosed in []
will be chosen. Entering -quit- will exit the
restore_repository shell, returning you to the
sulogin(1M) prompt. Entering -seed-
will restore the "seed" repository, which is designed for use
during initial installation and upgrade -- using it as a recovery
repository should be a last resort, since it is not designed
for that use.
Typically, the most recent backup should be chosen.
Once the backup to restore has been selected, it is validated
and integrity checked. If there are any problems,
restore_repository will print error messages and
prompt for another selection. Once a valid backup has been
selected, restore_repository will print out the
steps it is going to take, and prompt for final confirmation:
After confirmation, the following steps will be taken:
svc.startd(1M) and svc.configd(1M) will be quiesced, if running.
/etc/svc/repository.db
-- renamed --> /etc/svc/repository.db_old_YYYYMMDD_HHMMSS
/etc/svc/volatile/db_errors
-- copied --> /etc/svc/repository.db_old_YYYYMMDD_HHMMSS_errors
repository_to_restore
-- copied --> /etc/svc/repository.db
and the system will be rebooted with reboot(1M).
Proceed [yes/no]?
Typing yes will cause the actions listed to be
carried out, including making the system reboot, remedying the
fault. See the
"SMF Troubleshooting Guide" for additional details.
