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? 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. > 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. 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. 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. Nick.
