> > I get the impression that you're placing some value on how old the
> > data is.
>
> I'm placing a great deal of value on a system in normal operation never
> requiring manual intervention to come back up after an asynchronous
> interruption (power hit, panic, etc.,).
> > However in the case of a non-interfaced binary kernel
> > component that really doesn't matter.
>
> And that's why I conceded in the first message I sent to this case that
> it was okay to interrupt boot in the event an upgrade of the active root
> was interrupted. You'd be just as screwed without the boot archive.
>
> The only way to ensure you always run with a a matched set of kernel
> modules is via live upgrade or equivalent, where you upgrade a copy of
> the boot environment and atomicly swap the new one in once it's
> complete.
>
> To repeat what I wrote earlier today:
>
> Several of the files included in the boot archive (the files in /etc,
> for instance) have dynamic content which is expected to change under
> normal system operation in the presence of hardware changes (for
OK, lets say you edited etc/system and didn't sync the archive and
encounter a power failure.
With the archive we come up with the old etc/system and stop to tell
you about this.
Without the archive we come up and get the old non-rolled etc/system
and hopefully still run the check and stop to tell you about this.
Granted the log gets rolled faster and more dynamically than the archive
is updated. If you'd like to discuss ways to update the archive more
aggressively (I'm have some interest in FEM, a cron job would just make
things worse), I'm open to that.
> instance, USB hotplug or disk replacement).
You keep mentioning USB hotplug. That updates path_to_inst which since
it only grows has been part of filelist.safe since snv_44 (also in u4),
which means that action, which was a significant issue is a thing of the
past.
> If it's possible to
> continue to bypass the boot archive during boot,
It's possible, but has the following catches:
1) This only works on OBP platforms, x86 will need to be documented as
different and doesn't benefit from any of the effort invested in this.
That means we'll have to continue to solve that problem some other way
there.
2) You may still pick up old (hopefully not corrupt) versions of the files.
That means that this doesn't actually solve the problem as we still need
the check.
3) We continue calling back into OBP to do do this which leaves us with
one less place we managed to let go of the firmware.
> it seems to me that it
> should be possibile to omit dynamic files from the boot archive entirely
> and instead always read them from the root filesystem; if we limit cases
> where we report inconsistencies to cases where we crash in the middle of
> a non-alternate-root upgrade, I think we can make this dissatisfier
> just vanish.
>
> --
>
> I feel TCR-strong about this.
In that case we need another way to address this. Booting underneath the
archive is a neat trick we happen to be able to pull off on sparc. However
it doesn't solve the issue of wanting to avoid the up-to-datedness check.
-jan
