2006/525: New Boot Sparc

[Jan Setje-Eilers]

> > 		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