> > 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.
The idea behind leaving that check in maintenance mode is that it communicates what state the machine is running in, so I think that's correct. Since the archive will most likely just get updated by system/ boot-archive-update, I don't see a reason to disable that. However I understand the desire for a copy of the files that the system is currently running with to be available so decisions can be made based on their state. > > 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. It makes me nervous as well, hence "potentially". OTOH I don't want to entirely dismiss this approach without fully exploring its pros and cons. Not that it's available yet, but would you feel any differently if this was a kexec? I know I would. In fact I'd even consider attacking the general boot-archive case with a kexec of a tiny fail-safe that updated the archive and then re-exec'd the intended kernel. > > 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. It's something we will be able to do on efi based systems, and is really something I regard as a huge gaping bug in BIOS systems, so I'm not willing to dismiss based on that. -jan
