One of the sports in answering a question is to figure out what the asker's
true motives are, and what the likely results are going to be if things go
exactly as the asker wishes. Next you try to figure out what the results
are likely to be, regardless of the asker's wishes.
I've known R for a while, I know he understands a good educational
opportunity when he sees it, and data loss is usually very educational.
If not educational, funny. :)
RW wrote:
> I have seen plenty of Q&A about multibooting OpenBSD and
> Windows/Linux/whatever and although I did a lot of that stuff way back,
> I generally don't need it in the days of almost zero cost PC that are
> plenty good enough to run OpenBSD.
>
> So why this question? Well I was blessed by a client who had some
> troubles with a fairly recent grunty Intel mobo and donated it with its
> RAM to me for past favours.
isn't it wonderful when that happens? :)
> I figured it would make a pretty nice build machine, tossed a 160G SATA
> in and voila!
>
> 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.
After you get this all done, it will be interesting to see which one(s)
you actually use. :)
> Pretty soon the Release would be stable for latest and one back etc.
>
> I know that something like GAG would handle the boots but how would I
> slice and dice the drive?
>
> I managed to play with fdisk and set up partition 3 with about 40G at
> the end of the disk and use the "b" command in disklabel to describe
> the disk and whacked in a bunch of filesystems. Pretty standard install
> - booted and ran just file.
>
> Then I fdisked again to do partition 0, easy. Even remembered the 63
> offset.
>
> BUT (and I can see Nick Holland smiling here) when I get to the
> disklabel phase and use b to describe the disk, I still end up with all
> those other partitions visible.
:)
> I don't want to cream the first install unnecessarily so I'm here to be
> told.
aw, where's the education (or humor) in that? :)
> 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.
>
> 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.
>
> Anybody successful at this task?
I've only done two complete systems on one machine (my one and only
amd64 system, which I got and planned to never run a 32 bit OS or
app on, and then promptly put to work testing *sigh* i386 code...).
As you discovered, the disklabel goes in the /first/ A6 MBR partition,
not the /active/ A6 partition.
The trick is this: have only one A6 partition active at any one time.
The rest are..well, anything other than A6. You might be able to make
them FreeBSD or NetBSD partitions, and actually access them through a
bit of disklabel magic..haven't tried that, but it might work.
So..install one, reboot. During the install of the next, renumber
the old A6 partition to something else, create a new A6, install,
reboot, repeat.
Here's the problem: I highly recommend NOT changing the fdisk
partitions around while the system is running. It really didn't
like that one bit (I seem to recall a complete reload :) Boot
bsd.rd, change it there. That's the no-tools approach. Some of
the various bloated boot managers will do that for you in other
ways, calling it something like "partition hiding", seems not
just OpenBSD dislikes having multiple boot partitions on one
disk. :)
You *might* be able to save a copy of the MBR from each of your
MBR images (dd the first sector of the disk to a file), then dd
them back into place and reboot...that might keep the kernel from
noticing the "other" disklabels...but practice where you don't
need the data...
something like these completely untested lines:
dd if=/hole-in-foot/current.mbr of=/dev/rwd0c bs=1 count=1
reboot
(this will either install and boot off the MBR of your -current
partition, or reduce your file systems to something tantalizingly
close to useful, but just random enough to drive you nuts. I'm
not sure which. :).
For extra credit (and lost data), manually disklabel your disk so
that your /home, /swap and /tmp partitions are shared between the
installs. Remember: extra credit is given in school, and screwing
things up horribly is usually educational. :)
Now, most people know I'm not much a fan of virtualization ("It's
great when done right!" "Exactly. Show me it done right"), but
this might be a great place for it. Even something slow like qemu
might be perfect for your needs -- you want your speed (i.e., real
system) to be -current, as you will be doing most of your "I want
it done NOW!" compiles there. -stable/-rel and -prev-rel can be
in the emulators, as you won't be doing development there (RIGHT??),
just testing ideas and implementations, and if you need to build a
-stable for something, if it takes a couple days, that's not the
end of the world.
If you chose to implement this idea, do make backups. It's been
a while, not sure what things I may have forgotten. :)
Nick.
