Darren J Moffat wrote: > I'm derailing this case there appears to be a very strong consensus from > those that have commented on the case that: > a) it doesn't solve the root causes of the problem > b) it could actually make it worse in some cases > c) makes Solaris look like it needs tuning for enterprise use.
This sounds like you're simply opposed to this case, I'm not sure I understand what you hope to achieve by derailing it. I actually agree with much that James has brought up and have been considering ways to make this a non-public interface that will work to get this customer out of their current situation. > While the case technical content is obvious it is highly controversial. > > I've thought about this more and I now feel so strongly about this case > that I would actually vote against it despite my previous comments. > > We need to stop "patching" and "hacking" around this issue and solve the > issue with the boot archive inconsistency once and for all. Either by > removing the use of the boot archive completely when booting from disk > (assuming doing so doesn't introduce a boot time regression) or by > ensuring that it is never out of date. The solution to this should > assume that at the time of uadmin we can't write to the root filesystem. That doesn't explain why it's wrong to attempt to update the archive if we can though. This is all an attempt to provide a self-consistent view of the world at the time the system shuts down. When the live system is anything but read-only, there are no hard guarantees surrounding this without the archive either, so perhaps your real complaint is the existence of the check. > I have rebuilt many many boot archives and not once have I ever been in > a situation where anything other than "svcadm clear boot-archive" or > boot from the failsafe and update it were the correct solution. Sure > this is a kernel developers view but an admin has even less chance of > knowing if there is another solution. There is work both to perform automated recovery, as well as to further refine the check (to automatically drive on whenever "clear" was the right solution) under way. However I don't see how that has anything to do with whether or not it is correct to update the archives on udamin when we can (ie the administrator has declared it reasonable to perform work at that point). -jan
