On 18/03/07, Nick Holland <[EMAIL PROTECTED]> wrote: > > > 1. Let's assume I use -CURRENT, and new release is done (for example > coming > > 4.1). What is a proper procedure to do at such point? Is simple ;) cvs > up, > > recompile, install, change configuration file according do upgrade > manual, > > sufficient? > > NO! (at least, not in general...) > Re-read faq5.html a few times until it all makes sense... > > You UPGRADE by installing the closest available binary. Always.
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. Also I'm not convinced that 'Always' is the ultimate tool, look at the sub question 1.2, but please correct me if I'm wrong. Just to remind: this is not discussion about 'how to do upgrade default OpenBSD installation' :) Building from source is only to update to a newer -stable, or for making > new code. Upgrading by source is only to inflict pain upon yourself if > your life is too easy. Don't share the pain, however. > > HOWEVER, if your goal is to grab a -current and then move to 4.1-release > when it comes out, you may well be too late now. Development has now > resumed, the developers are working on 4.2 now. If you don't know how > to tell, don't. So to further discuss -current case, sub questions are: 1.1. is release date on cvs head tagged or announced somehow? 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)) 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? 4. where can I find more information about upgrade scripts used during binary upgrades? someone has to write them, maintain them, etc. > 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. IF you do it right, things Just Work. > Unfortunately, itemizing the things you could do incorrectly is not really > possible. :) :) > For example, I expect (however not yet examined) some information to be > > found in upgrade script used by new release during upgrade. > > > > 2. Let's assume I use -STABLE 4.0, and after 4.1 is release I'll do > checkout > > of STABLE 4.1 - what are the steps to do the upgrade then? > > Documented in detail above. 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)? > I'm perfectly aware that it won't be easy nor supported, but considering > > myself experienced UNIX admin (grin :), and having time to spent, and > vmware > > hosts to broke ;) (with snapshot feature) I'd like to extend my > knowledge of > > OpenBSD by doing those two 'exercises'. > > Best way to learn is to screw stuff up. > Preferably in a controlled environment. :) Snapshots of virtual machines gives great possibilities to learn without problems, that's why I do not share many peoples fear of the great god named 'System Breakage'. I just revert it to the correct snapshot. -- radoslaw.
