RStachowiak wrote: > On 18/03/07, Nick Holland <[EMAIL PROTECTED]> wrote: ... > The question was not about normal upgrade procedure (which I'm perfectly > aware of ) but about internal working of system during upgrade phase to > let me understand it better and comprehend all corner cases.
The formal upgrade process is by binary. So, if what you want to see is the internal operations of an upgrade, it's also binary... ... > So to further discuss -current case, sub questions are: > 1.1. is release date on cvs head tagged or announced somehow? It's tagged, yes. It really isn't announced. > 1.2. being on current and missing 'switch point' and then doing a binary > upgrade will (or rather can) result in system breakage, true? (that's why > typical 'use binary' answer won't work here (and why I'm so inclined to > learn more about process)) No, missing the "switch point" then doing a binary UPGRADE is fine. The problem is, you may end up trying to do a DOWNGRADE. That's a good way to make a mess of your system. The answer in this case is, "stick to 4.0", then. If you have missed the opportunity to download a -release or near-but-still-pre-release version, stick to the previous -release. Keep in mind, if you force your way to 4.1 before it is officially released, you had best really know what you are doing. If a serious bug is found between now and May 1, patches and -stable for 4.1 will not be released until release day. Yes, this has happened before. > 3. so if 2==true, what are other steps done by the people using -current > (looks like many of them are) do before/during/after upgrade ? Maybe I > should seek advice on different OpenBSD ml? Some people just run -current all the time. The only reason I run -release/-stable on some of my machines is to make sure I have a bunch of machines to test the upgradeXX.html instructions and patch file. Only reason a lot of developers run -stable at all is so they can more easily install packages after initial install. Some people grab snapshots regularly, and keep an eye on 'em, and when they switch to [next-release]-beta, start installing that, so their first upgrade is trivial, and also to make sure that they have a pre-release version handy. When you want to jump from one -current to a newer -current, you look at the "following current" page, http://www.openbsd.org/faq/current.html for guidance. > 4. where can I find more information about upgrade scripts used during > binary upgrades? someone has to write them, maintain them, etc. They are in the source tree, managed through cvs, as is everything in OpenBSD. See src/distrib/miniroot. >> What I'm looking for is: >> > a. maybe even incomplete but some description of steps to be taken >> >> See the FAQ. When going from -current to a /newer/ release, follow the >> "upgradeXX.html" instructions. Be aware that the magical "upgradeXX.patch >> " >> file assumes going from previous-release to new-release, not >> previous-current >> to new-release, so it is going to choke and belch a few places. > > > definitely, that's what I'm trying to understand. Probably I'll summarize it > then in some nice howto, if people be interested. for it example it should > let upgrade systems sooner, just after release being committed to the tree > without need to wait for all CDs to be prepared. Please don't. 4.1 exists now, but it is not yet supported, and won't be until May 1. Making it "easy" for people to get themselves into an unsupported state is NOT doing anyone a service. When writing documentation, you really should do it from an "I understand this" position, not a "I got it to work" position. Too many people still believe if it is in written form, it's true. There is too much crap documentation out there, much of it headed with "HOWTO". ... > Let me rephrase the question: Using environment described above and doing: > 2.1 checkout of 4.1 stable > 2.2 compilation of 4.1 stable > 2.3 installation of results > 2.4 applying upgradeXX.html steps > 2.5 doing things found in upgrade script from cdXX.iso > > Is there any major step I'm missing (from binary type of upgrade)? Unfortunately, your statements are not clearly defining the starting point. If you are doing this from a 4.0 machine, your step 2.2 is likely to fail. If it doesn't, 2.3 has already happened. 2.5 is done by steps 2.3. If you start from 4.1-release, 2.2 will just work, so you are done. You can /try/ starting from 4.0 and using the "Following Current" page and see if you can jump all the way from 4.0 to 4.1 in one shot. But, 1) Don't bet on it working. 2) remember you end up with a not-yet supported system. Nick.
