Jan Setje-Eilers wrote: > 3) Files that etc/system that contain information that can't always > be usefully processed later during boot, but if out of date _do > not_ leave the system in a dangerously unstable state. > > These files are currently being treated just like the kernel > binaries. However since the system is not dangerously unstable > at this point, it is reasonable to drive on and mount root > read-write. > > This means they should really get their own check. > > If this check fails, I propose the following: > > Print a warning to console. > > Leave a service (which won't block multi-user) in > maintenance mode so the state is communicated via svcs > -x.
I like this. > Drive on and mount root read-write. Up to this point I'm fine with this. > Update the archive. If you do that you are you possibly removing information that the admin may need to diagnose why the system was in this state ? Also it will make the service in main look strange - it said the boot archive was out of date but and admin will find that it isn't. I'd personally leave this to one of the "later" normal cases that causes an automatic update of the archive. > And potentially reboot immediately to the device we > just booted from now that the archive is updated. I really don't like the auto reboot it could cause application problems and will almost certainly surprise admins. I don't think we should ever autoreboot after getting this far up. > The auto-reboot still makes us a little nervous, so it may be > something that needs to be explicitly enabled based on site > policy, but at least on sparc we have a solid idea of what > boot device we booted from, so it may turn out to a reasonable > default action to take. and since we don't on x86 I don't think we should do this since one of the stated goals of this project is removing differences! Also consider that there will be other platforms eventually. -- Darren J Moffat
