I recently discovered a V210 test machine in our lab machine stuck in a
smf-console-spawning loop, spewing:
----
Requesting System Maintenance Mode
(See /lib/svc/share/README for more information.)
svc.configd exited with status 102 (database initialization failure)
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.
Requesting System Maintenance Mode
(See /lib/svc/share/README for more information.)
svc.configd exited with status 102 (database initialization failure)
svc.configd: smf(5) database integrity check of:
/etc/svc/repository.db
---
I got a similar message (but only once) while netbooting; I then managed
to get a single-user root shell.
The next odd thing I noticed was:
# cd /etc/svc
# ls
repository.db volatile
# ls -l
./volatile: Value too large for defined data type
total 739
-rw------- 1 0 sys 535552 Aug 6 2007 repository.db
Eventually I thought to run:
# date
Thu Aug 7 11:02:23 PDT 1902
my best guess is that somehow system time was outside the range
representable as a 32-bit time_t when /etc/svc/volatile was mounted.
This caused the last-modified date of /etc/svc/volatile to be outside
the 32-bit epoch, causing some number of 32-bit "stat" calls to return
EOVERFLOW; clearly svc.startd and friends were too freaked out by this
to recover.
The system became healthy again once I set the clock.
I suspect there are multiple bugs here; SMF is just the thing which
trips *first*. Including the current date in the error message would
have been a big clue about what was off.
- Bill
