Gangadhar Mylapuram writes: > Darren J Moffat wrote: > > I really think this case is solving the wrong problem. > > > > The problem is that we depend on the boot archive at all and that we > > allow it to get out of date and even worse allow a system to stop very > > early in boot because of that. > > > > I would much rather see we solve the root cause and rethink the whole > > boot-archive issues - particularly in light of the fact that GRUB and > > OBP can actually read ZFS. For network boot the boot-archive approach > > is still desirable but the boot server can deal with the archive updates > > in that case. > > As per Jan (Jan.Setje-Eilers at Sun.COM), this is going to be the long term > approach (at least for now).
The project as proposed doesn't actually fix the problem. If the system panics or power is removed, the very same issue occurs, and uadmin is not involved, so no enhancement of uadmin will work for those cases. The CR cited correctly describes archive failure as the problem, not uadmin. Worse still, having these odd parameters as "Committed" interfaces to satisfy the usage model of just one or a few customers sounds very likely to result in useless folklore about Solaris being "unreliable" and needing "special configuration" in order to make it usable in an enterprise environment. That situation is very much against everything we're trying to design. Solaris needs to work right straight out of the box. I'll go further than Darren: I think adding this sort of functionality to uadmin is the wrong thing to do and just promotes confusion. The underlying problem needs to be fixed; the system needs to recover coherently when the boot archive is found to be out of date at boot time. If the user can see this service fail, log into the system console, remount root as read/write, update the archive, and reboot into a working system, why can't the system itself just do this simply mechanical chore on its own? -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
