附:
SMF-8000-MY - Repository Integrity Check Failed (Doc ID 1021564.1)
APPLIES TO:
Solaris Operating System - Version 10 3/05 and later
All Platforms
PURPOSE
Provide additional information for message ID: SMF-8000-MY
DETAILS
Predictive Self-Healing Article
Repository Integrity Check Failed
Type
Defect
defect.sunos.smf.db.verify
Severity
Major
Description
The Solaris Repository Daemon discovered that the smf(5) repository is corrupt.
Automated Response
No automated response.
Impact
The Solaris Service Manager will start an sulogin(1M) shell on the console to allow the administrator to recover the system. The system will not be able to boot until a non-corrupted replacement is installed.
Suggested Action for System Administrator
Log in to the sulogin(1M) shell. Run the command /lib/svc/bin/restore_repository, and follow its instructions to restore one of the automatic backup copies of the repository. Upon successful completion, the system or local zone will be rebooted, and the restored repository will take effect.
Details
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, whereYYYYMMDDandHHMMSSare 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_repositoryshell, 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.
Product
Solaris 10 Operating System |