My problem is, that we are talking about CF-card systems. I want to keep the installation small. I have a build machine here so I can create all packages needed and create my own package repository. So I'm not afraid to find out that a package is missing after upgrading.
But I think there is a misunderstanding. I was talking about, mmhh, let's say fdisk partitions. I want to create two absolut independent installations. My problem is, that disklabel always uses the whole disc (c:), I'm not able to switch between the fdisk-partitions (wd0 / rwd0c is always the same). If I got you right you created something like this: wd0a: /root1 wd0b: "shared" swap wd0d: /root2 [...] That means that you only switch the mount-point during installation, keeping the partitions untouched, right? Regards Hagen Volpers > -----Urspr|ngliche Nachricht----- > Von: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] > Im Auftrag von Ingo Schwarze > Gesendet: Freitag, 27. Mdrz 2009 01:25 > An: misc@openbsd.org > Betreff: Re: Multiple obsd installations on one harddrive > > Hi Hagen, > > Hagen Volpers wrote on Fri, Mar 27, 2009 at 12:38:27AM +0100: > > > I have a question regarding openbsd and partitions. > > I want to have more than one obsd installation on one harddrive. > > At least on i386, no problem whatsoever. > Just define one /root partition per installation > and have the right /etc/fstab in each one to mount > the right partitions. Usually, you will also define > one /usr and one /var per installation, but depending > on what you do, you can also put everything into the > respective /root partition. Usually, /tmp and /home > can be common for all. > > In the bootloader, you can easily specify which root > partition and which kernel to boot right now. > > For some time, i used a build machine with four parallel > installations: > Previous release, most recent release, -current and one scratch area > for testing work that might break things really badly. I > stopped doing > such stunts when i switched my production servers from -stable > to -current. It reduced the overall workload needed for maintenance. > > > The idea behind that question ist to be able to install a newer > > release in parallel, chroot into it, compile stuff, install packages > > etc and boot into that partition when it's done. > > Uh, that often won't work. When you chroot into it, you still > have the wrong kernel running. Compiling stuff might or might > not work, so according to Murphy, it probably won't when it's > most pressing. > > Better boot one version at a time and work with that. When > working with OpenBSD, you get no points for excessive cleverness. > Just do things in standard and simple ways, even if that may > seem dull and boring on first sight, but it typically work best. > > > I want to avoid onside reinstallations > > If that's all, just use the standard upgrade process twice a year. > It's painless. > > > (and I don't want to have several old versions of libs, in short, > > the default patch-way). > > Why? Where's the problem with old libs? > > Old libs are good. When you update ports, there are often some > few that need special handling and are perhaps not available right > away, in particular those you had to compile yourself (if any). > When you keep the old libs around, (nearly) all old ports continue > working until you come around to updating them. > > When i am forced to reinstall a machine from scratch, i nearly > always have some kind of partial service interruption because one > of the ports is not available yet and what i have won't work > with the newest libs. It's mostly harmless, but it's a nuisance > and fixing it is a waste of time. > > > I don't know if that is a good idea, perhaps there is a much > > easier way. > > Your suggestions guarantees lots of additional work for very little > gain, if any. The gain will definitely not be in correctness, > stability or security. Not even in time or simplicity. > > Yours, > Ingo
