On Thu, 2007-08-02 at 15:58 -0700, Jan Setje-Eilers wrote:
> It sounds like it would be acceptable for whatever tool is used to
> update these files to do whatever sync is needed atomically as part of
> the update. Sadly for most of these files this tool is still a text
> editor and we don't get to fix that in a patch release. :(
I don't think it's necessary to use this case to fix *this* problem --
solaris administrators have had to deal with this all along, and you're
not going to make things worse if solaris continues to read these
manually-edited files individually at boot time.
> However it seems like the files of concern fall into a category of
> their own that is currently being dealt with in a manner that should
> actually be reserved for out of sync kernel binaries. This suggest we
> have the following three types of files in the archive:
>
> 1) Kernel binaries (including modules and drivers)
...
> 2) Files that are either caches or only grow or can be safely re-read
> later.
....
> 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.
> Ideas, thoughts, comments?
First, I don't believe we have proof that editable/volatile files
present in the boot archive fall only into categories (2) and (3), nor
sufficient controls to prevent files outside (2) & (3) from being added.
I believe it's unreasonable to have files of type (3) in the boot
archive used when a solaris system boots from its own root file system.
I believe that a change to force the administrator to run "bootadm
update-archive" after editing files of type (3) is a change not
compatible with the Patch binding requested for this case. While it is
true that this exact change was inflicted on solaris x86 in solaris 10
update 1, there were mitigating business reasons why this appeared to be
the least bad option open to us at the time. These reasons do not
appear to be present for sparc.
The main architectural benefit of newboot is that it reads in all files
needed to mount the root filesystem before the kernel is started. This
benefit would still be present if these files weren't packed into a
single boot archive on disk but were read individually from the root
filesystem.
I believe most if not all of the operational problems with the boot
archive would go away if, in a default install of solaris booting from
its own root filesystem, a list of critical configuration files of type
(2) and (3) were read individually from the root filesystem into memory
to supplement the boot archive before the kernel starts. (I
specifically do not want a system where the kernel reads them in on
demand).
With 20:20 hindsight, I can now say that the operational instability
inherent in putting volatile/editable files in the boot archive should
never have been inflicted on administrators of solaris on x86. I will
not stand by and see the instability inherent in the current monolithic
boot archive system inflicted on sparc systems as well.
This must change or else I will derail so I can vote against this
proposal.
- Bill
