As I have already mentioned in the previous post, I'm not the biggest fan of Solaris 10 SMF. In all fairness I have to say it is a very capable beast that can simplify life in many departments, but it is a beast to nonetheless. The old model of starting up daemons on bootup via init scripts was a lot more limited than SMF, but it was very transparent. I always knew where to look with init scripts when things did not work the way I expected. With SMF it is that lack of transparency that is making it difficult when things become really wrong. One such scenario when things become really wrong is when SMF repository becomes corrupted and the system becomes essentially unbootable. And this is when a lot of people would get stuck as not everyone is familiar with the way SMF works. Where SMF departs significantly from the old ways is that is relies on a database, a relational database of all things, to store the configuration of all services configured on the system. Of course as with any relational database, the contents are stored in a binary file storing the service related data. On the plus side Sun decided not to re-invent the wheel and create a proprietary database for this task, instead opting for a well known and proven sqlite embedded database. Needless to say you can't open the database file with your favorite editor and see what when wrong, instead you need to use the sqlite utility and rely on your SQL prowess to interrogate the repository. The repository file itself is stored under the /etc/svc directory and is called repository.db, so in case the contents of the repository went south and the system became unbootable, this is the file you would need to replace with a good backup, so if you do not perform full backups of your systems, it is one of the files I would recommend backing up for safe keeping. You could usually accomplish the restore by booting the machine from external media or network, mounting the root slice and restoring the database file from backup. Regarding the database file itself, it is sometimes useful to find out if the file itself became corrupted or the problem is somewhere else. The easiest way to do that is to try openning the SMF database file using the sqlite utility:

# /lib/svc/bin/sqlite /etc/svc/repository.db
SQLite version 2.8.15-repcached-Generic Patch
Enter ".help" for instructions
sqlite>

Provided the database is healthy, you can snoop around the database and see into the guts of SMF using simple sqlite commands and SQL:

sqlite> .databases
seq name file
--- --------------- ----------------------------------------------------------
0 main /etc/svc/repository.db
1 temp /etc/svc/volatile/sqlite_nUUnnR1NXcQL1lF
sqlite> .tables
id_tbl prop_lnk_tbl snaplevel_lnk_tbl value_tbl
instance_tbl schema_version snaplevel_tbl
pg_tbl service_tbl snapshot_lnk_tbl
sqlite> .schema service_tbl
CREATE TABLE service_tbl (svc_id INTEGER PRIMARY KEY,svc_name CHAR(256) NOT NULL);
CREATE INDEX service_tbl_name ON service_tbl (svc_name);
sqlite> select svc_id, svc_name from service_tbl;
2|system/boot-archive
6|system/device/local
10|milestone/devices
14|system/identity
20|system/filesystem/local
24|system/manifest-import
28|system/filesystem/minima
........

Of course according to Sun you're not supposed to get into the repository contents and change anything, so please be careful with hacking the contents.