I have an i386 system currently running 5.2.1-RELEASE with a vinum mirror array (2 drives comprising /usr ). I want to upgrade this to 5.5-RELEASE which, if I understand correctly, no longer supports vinum arrays. Would simply chaning /boot/loader.conf to read gvinum_load instead of vinum_load work or would the geom layer prevent this from working properly? If not, is there a recommended way of upgrading a vinum array to a gvinum or gmirror array? Thanks, Sven
On Mon, Jun 26, 2006 at 12:22:07PM -0400, Sven Willenberger wrote:> I have an i386 system currently running 5.2.1-RELEASE with a vinum > mirror array (2 drives comprising /usr ). I want to upgrade this to > 5.5-RELEASE which, if I understand correctly, no longer supports vinum > arrays. Would simply chaning /boot/loader.conf to read gvinum_load > instead of vinum_load work or would the geom layer prevent this from > working properly? If not, is there a recommended way of upgrading a > vinum array to a gvinum or gmirror array?Lost of things have changed between 5.2.1 and 5.5. I think it would be best to make a backup and do a clean reinstall. Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20060626/7e7263ee/attachment.pgp
On Mon, 2006-06-26 at 19:15 +0200, Roland Smith wrote:> On Mon, Jun 26, 2006 at 12:22:07PM -0400, Sven Willenberger wrote: > > I have an i386 system currently running 5.2.1-RELEASE with a vinum > > mirror array (2 drives comprising /usr ). I want to upgrade this to > > 5.5-RELEASE which, if I understand correctly, no longer supports vinum > > arrays. Would simply chaning /boot/loader.conf to read gvinum_load > > instead of vinum_load work or would the geom layer prevent this from > > working properly? If not, is there a recommended way of upgrading a > > vinum array to a gvinum or gmirror array? > > Lost of things have changed between 5.2.1 and 5.5. I think it would be > best to make a backup and do a clean reinstall. > > RolandSadly this may not be an option; this is a production server that can at best stand an hour or so of downtime. Between all the custom symlinked directories, applications, etc, plus the sheer volume of data that would need to be backed up, an in-place upgrade would be infinitely more desirable. If it comes to the point of having to back up and do a fresh install I suspect I would be using the 6.x series anyway. I was really hoping that some way of upgrading in-place were available for vinum. Sven
-----Original Message----- From: owner-freebsd-stable@freebsd.org [mailto:owner-freebsd-stable@freebsd.org] On Behalf Of Sven Willenberger Sent: Monday, June 26, 2006 12:15 PM To: Roland Smith Cc: freebsd-stable Subject: Re: vinum to gvinum help On Mon, 2006-06-26 at 19:15 +0200, Roland Smith wrote:> On Mon, Jun 26, 2006 at 12:22:07PM -0400, Sven Willenberger wrote: > > I have an i386 system currently running 5.2.1-RELEASE with a vinum > > mirror array (2 drives comprising /usr ). I want to upgrade this to > > 5.5-RELEASE which, if I understand correctly, no longer supports > > vinum arrays. Would simply chaning /boot/loader.conf to read > > gvinum_load instead of vinum_load work or would the geom layer > > prevent this from working properly? If not, is there a recommended > > way of upgrading a vinum array to a gvinum or gmirror array? > > Lost of things have changed between 5.2.1 and 5.5. I think it would be> best to make a backup and do a clean reinstall. > > RolandSadly this may not be an option; this is a production server that can at best stand an hour or so of downtime. Between all the custom symlinked directories, applications, etc, plus the sheer volume of data that would need to be backed up, an in-place upgrade would be infinitely more desirable. If it comes to the point of having to back up and do a fresh install I suspect I would be using the 6.x series anyway. I was really hoping that some way of upgrading in-place were available for vinum. Sven DSW> Sven, your best bet will be to build a set of disks off-line and then swap them in. That's the only way you can be sure to do it right. Ask yourself if the cost of finding and building a mule is worth more than the pain of screwing up. It _is_ well worth doing, there were many things that were still unglued in 5.2.1. -- Don Wilde Org 01737 505-844-1126 Earth Halted: Please reboot to continue
On Mon, Jun 26, 2006 at 12:22:07PM -0400, Sven Willenberger wrote:> I have an i386 system currently running 5.2.1-RELEASE with a vinum > mirror array (2 drives comprising /usr ). I want to upgrade this to > 5.5-RELEASE which, if I understand correctly, no longer supports vinum > arrays. Would simply chaning /boot/loader.conf to read gvinum_load > instead of vinum_load work or would the geom layer prevent this from > working properly? If not, is there a recommended way of upgrading a > vinum array to a gvinum or gmirror array?I did this upgrade not long ago (and later to 6.1). The process of switching from vinum to gvinum is pretty easy, although the specifics escape me now. Changing loader.conf and fstab are the main ones, but assuming you have console access you should easily be able to fix anything else that crops up. As Mark said, there were shared library version changes between these versions, so you'll end up needing to rebuild all your apps. I did this with portupgrade, but I got everything updated and working on 5.2.1 first so I wouldn't have to worry about that during the upgrade. A word of warning though. I'm currently left with no raid because somewhere along the line vinum/gvinum corrupted the metadata. This only happened after a disk failure and after switching to gvinum (could be coincidence), but has left me looking elsewhere - gmirror looks good - for a RAID system. See the archives of this list for details - summary is that the kernel module locks up when loading. Tim. -- Tim Bishop http://www.bishnet.net/tim/ PGP Key: 0x5AE7D984