> Lars Tunkrans wrote: > > My feeling is that the system should, on its own > initiative, immediately regenerate > > the boot-archive if some event makes it nessesary > to do so. > > To postpone the boot-archive regeneration until > the shutdown sequence is clearly > > not a strategy that fullfills the goal of the > boot-archive . At least I assume that the goal > > is to make the boot process more secure. and less > prone to failure. > > As it is now the validity of the boot-archive > after a power-outage is questionable . > > Without making any claims as to the elegance, quality > or desirability of > this solution... > > You can stick the following in your root crontab: > 12 * * * * /usr/sbin/bootadm update-archive > > (i.e. update the boot archive once an hour at a > completely arbitrary > twelve minutes past) > > When no update is actually required, "bootadm > update-archive" appears to > return ~instantly, so it's not going to generate a > large amount of load. > You could also configure cron to invoke the command > more or less > ften, as you see fit. Hourly appears, on balance, to > be often enough > for my systems. > > I've also seen discussion of disabling the SMF > service that checks the > integrity of the boot archive on boot... > svc:/system/boot-archive:default > but that's not something I've tried myself. > -- > > > Regards, > > Joshua M. Clulow > IT Consultant > JMCtech - http://www.jmctech.com.au/ > ABN: 49 933 254 106 > Mobile: +61 (412) 421 925 > E-mail: [EMAIL PROTECTED] > _______________________________________________ > opensolaris-discuss mailing list > opensolaris-discuss@opensolaris.org >
I like your cron idea, it's a temporary solution, the second is just as risky as the state now were in with the boot-archive. Also I found the separate issue of read block errors, I had a negative rounding error and no free cyl, left over, on the Solaris partition, as long as there are a few cyl left over to account for the rounding area, the error went away on the system reload., also another indicter when going into the format command would take a very long time, and the lucreate / lupgrade also got stuck looking at the drive geometry as well, the prtvtoc was not impacted with the latency, so not all the of these commansds is cleared up, This message posted from opensolaris.org _______________________________________________ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
