On Sun, 01 May 2011 11:07:25 -0400 Nick Holland <n...@holland-consulting.net> wrote:
> On 05/01/11 07:13, David Steiner wrote: > > On Sat, 30 Apr 2011 11:24:30 -0400 > > Nick Holland <n...@holland-consulting.net> wrote: > > > >> > >> um... > >> bsd.rd assumes console. > >> > > > > which i don't have and am looking for a workaround. maybe bsd.rd > > should assume: accepts commands from a file/stdin to be automated? > > or even better: similar to yaifo allow ssh connections to finish the > > upgrade/install? i know the mantra: patches are welcome ;) > > > > > >> If you want to do a remote upgrade, how about using the (shudder) > >> *suggested* process in the upgradeXX.html docs? > > > > i've been doing that for awhile. i'm not convinced of this method: > > replacing the kernel and base packages, while the system is running, > > sounds dangerous. > > compared with...getting everything /exactly/ right in a redirection > file?? > > "sounds dangerous". Perhaps you would like to explain what magic bit > of knowledge you have that the rest of us lack? it says so in the FAQ: http://openbsd.org/faq/upgrade49.html "Upgrading without install kernel This is NOT the recommended process. Use the install kernel method if at all possible!" couple sentences later: "Stop any appropriate applications: During this process, all the userland applications will be replaced but may not be runnable, and strange things may happen as a result." so it's not recommended and strange things may happen if you're not careful. > upgradeXX.html is on its 14th version now. It is how I upgrade almost > all my machines (I save a token few for bsd.rd to make sure it works), > it's basically how everyone with a remote system without a console > upgrades their systems. It works, both in practice and in theory. > You are trying to solve a NON-PROBLEM. well i'm glad it's been working for you. i'm not against this method in any way, just being cautious in upgrading remote boxes. therefore i prefer the bsd.rd method and am looking for a way to do this without console. until there's a proper "solution", i'll keep on using the TRIED-AND-TESTED OpenBSD method (tm). > > > YMMV. sofar it went ok with the upgradeXX.html process. i'll try it > > with yaifo sometime. > > Ah, there's a good plan. > Replace a process developed, tested and monitored by the OpenBSD > people with a roll-your-own. Yep, because you know SO much better > than we do. Uh-huh. > > > Were I to guess, you are probably basing your "sounds dangerous" on a > flawed idea of how things work based on some other operating system. wrong, see above what it's based on. your own FAQ. > OpenBSD uses a monolithic kernel -- all the parts to the kernel are in > the kernel file, which is loaded into RAM at boot. You may now safely > delete the kernel if you so desire once the system is booted, it isn't > used until the next boot. You may also REPLACE the kernel, it has NO > impact on the running system until reboot. > > As for the other binaries, sure, some are loaded and unloaded on the > fly on a running system, but nothing on the base system will suffer > problems by being killed this way. As for other things, that's why > we advise you shut 'em down first. I like apps with a robustness to > them, so I just like letting them whimper and die. > > So, that basically leaves the extraction process and reboot. "reboot" > is a statically linked binary. We copy that to "oreboot" to make sure > the old one is still available, but I've tested a lot of platforms > over the last few releases and have been unable to find a combination > where an old kernel can't run the new reboot successfully, but we > don't promise this, so we save "reboot" as "oreboot". > > Extraction via tar and gunzip are the "problems". They are both in > baseXX.tgz, this is why that's the last package to unpack. But, they > are loaded into RAM (along with any libraries) at the start of the > process, and no need to "reload" them exists unless a new tar or > gunzip process is started. > > After you have unpacked the userland, your system is pretty well > hosed, about all that is running is your old kernel from RAM and your > shell, not much else to do other than reboot it, which (fortunately) > is just an interaction between the kernel in memory and the reboot > program (which you saved an old copy of). > > The older process of "replace kernel, reboot, replace userland, > reboot" is a bit more ascetically pleasing, but kept caused problems > due to things like pppoe and PF, and thus, the "replace everything > and reboot" process was implemented, and seems to be overall, a > better option. i appreciate your detailed explanation. thank you, it gives me a better idea of what's going on in the upgrade process and how to manage it. binary upgrades have worked without any hiccups on my file server. > And don't get me wrong.... yaifo does solve some problems for people, > but remote upgrades are not a problem that needs solving this way, and > there's a lot more that can go wrong that way than the suggested way. point taken. David
