Daniel Ouellet wrote: > Nick Holland wrote: > >> IF there is some reason you have to complete an upgrade in one reboot, >> or faster than the local boot media process goes, you might want to try >> the above referened footnote [1] below. (and if that sentence doesn't >> cure you of this delusion that I always write efficiently, concisely and >> clearly, I am sure there are other examples in this note. :) > > > The idea wasn't sure not to do the upgrade in one step at all. > > May be I didn't express my thought to well. I took it more as this, it > said to reboot after the first step, but then, the warning said it > should run, meaning, well it's possible not to reboot what so ever, > meaning even doing the first step only doesn't mean it will work and the > server would come back to life to do the second step. > > I never meant it as skipping the first step what so ever. I wouldn't > question your warning! (;> > > I was more curious as to what situation it may not work doing a remote > upgrade like this. I only thought of the a.out situation.
ah, ok, I think I understand...you were worrying about my use of qualifiers, probably this one: "...it should be done now, as usually, the new kernel will run old userland apps..." ok, yeah, that "usually" looks a little scary (you had me looking at the "should", which caused me to think you were trying to skip a step). The qualifier is there because I don't like making absolute of statements that I'm not sure will always be absolute, and that statement was untrue at least once in the past and may be again. Yes, I was thinking of the old a.out -> ELF conversion flag day on several platforms. However, I'm never going to rule out that a similar flag day might happen in the future, though I'm not aware of any plans for one now. So, do as you were doing, read the appropriate set of instructions, and don't just assume they are "just like last release". IF there is a catagoric reason why that wouldn't work on any platform, I'll certainly try to let you know. When doing a remote (or critical system) upgrade, that is not your real problem. What you have to worry about is other things you did to your system. The systems I test the remote upgrade process on are pretty simple -- one is entirely contrived, I install previous release on it (often, left over from the previous faq4 update actually), then upgrade it and make sure it works with the machine six feet away from me. Then I do the same thing with a couple machines that are actually pretty important to me and are a drive and most likely time off work to get to. So by the time it is committed, I'm pretty confident of the general idea. But the machines are all still "pretty simple". What I can't control is what really version specific app you have, or what change you made to /etc/rc or similar. That's why the primary disclaimer is the second sentence of the second paragraph at the top of the page: "If you are doing it on a critical or physically remote machine, it is recommended that you test this process on an identical, local system to verify its success before attempting on a critical or remote computer." You will note that is not in the remote upgrade part, that's in the "general, impacts everyone" part. For a reason. :) Hopefully, I got closer to your question that time. :) Nick.
