Nick Holland wrote:
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..."
Yes that was it. (;>
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".
Understood. I also thought only at the a.out stuff.
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:
Using packages and removing them as you suggested and then putting them
back after the fact sound good to me and makes the system pretty simple
I guess. So, all look go to me and sure answer the question I had in the
back of my mind! (;> May be I will do more remote upgrade now. Always
more comfortable doing it at home with a beer or two. Might increase the
risk with the beer, but sure increase the pleasure as well! (:>
"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. :)
Sure did! Always a pleasure to read your answers.
Many thanks Nick!
Daniel
