On Wed, 10 Oct 2007 22:51:26 +0200, Tilo Stritzky wrote: >On 10/10/07 21:37 RW wrote: >> Then (the devil made me do it!) I thought: Why not four OpenBSDs as in >> Release, Release minus one, current and some experimental stuff. Just >> multiboot to whichever and away. >> >> Is it at all possible? If so what is the trick? I <did> flag the new >> MBR entry as active and I can't see anything in the docs that >> contemplates this kind of set-up. >> >It's actually not very difficult but ... >"If you have to ask, you shouldn't be doing it"
Pushing boundaries on a machine without internet connection and (unless it works) not a part of critical infrastructure is just fun for learning. If it blows up an OpenBSD flush and install another way is not exactly the punishment that Linux or Windows would inflict. ;-) > >Start your first install. Make one fdisk partition (OpenbSD type). >disklabel as many slices as you want OpenbSD releases (plus swap, plus c). >Install one on slice a. Hmmm. Right there is the showstopper. I <did> say it was so I could build stable for at least a couple of releases. I have 9 slices on my present builder and could probably lose a couple. but only one to build and clean on? Not for me. I have listened to the experienced crew about having filesystems you can just flush rather than rm -rf * on. Looks like a lost cause. I did really want to get out of all the drive swapping with wear on the connectors (the old IDE trays at least had rugged sockets like the old centronix ones, the SATA trays have an edgecon and I don't rate edgecons as suitable for lots of insert/remove cycles with a heavy mechanical load) but if it don't fly, c'est la vie. Thanx, Rod > >When done, start the next install. > >Before doing the actual install, jump into shell, hack the install-script's >ROOT_DEVICE (or something like it) to a different slice (say d). >Exit shell, proceed with install. This installation will end up on that very >slice. > >And so on. > >Now every time you want to a boot any installation other then the one on >"a"-slice you use the boot loaders "set device .." to select the kernel you >want. *AND* you have to tell that kernel which root partition to use (-a >flag in boot). > >That's it. > >> If there is an answer at Mother Google's I cannot construct a smart >> enough query to not be drowned in all the OpenBSD and <some other OS> >> questions. > >I don't think there is one and there is reason for it too. >This is unsupported. This is weird. This is outright dangerous. >The potential for holes in your feet is really high. > >Sooner or later you will end up running current binaries on a release >kernel or vice versa. You will probably get your packages mixed up. >There have been changes in the disklabel which are compatible one way >only. There is probably a lot more. >The failuremodes of all this are subtle and mean. You will spend more >time scratching your head and thinking "WTF?" then it would cost you to >re-install from scratch everytime you like to run a different release. >(Well, maybe I'm exaggerating but in hindsight it really feels like this) >> >> Anybody successful at this task? >> >I ran this for same time on my laptop. I wanted to run current on it, >but also have fallback release installation. In the end it turned out I >never used the release. So after spending some serious time and learning >a lot more then I ever hoped for (but nothing of this is lost) I scrapped it. > >If you really must do this (I recognize there is must and *must* ;) I >reckon you go for seperate media. Seperate disk drives, or even better >removable media (USB sticks, clearly labeled; maybe live-CDs). > >I just got a brand new office PC, 64bit CPU. But I'm stuck with some >Apps in i386 compatibility. So I installed i386 for work. Next week I'm >going to get an USB stick and put an amd64 install on it, for play :) > > >regards >tilo > >> Thanx, >> >> Rod/ >> >> From the land "down under": Australia. >> Do we look <umop apisdn> from up over? > >From the land "down under": Australia. Do we look <umop apisdn> from up over?
