From owner-freebsd-mobile Thu Nov 20 14:31:12 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA14366 for mobile-outgoing; Thu, 20 Nov 1997 14:31:12 -0800 (PST) (envelope-from owner-freebsd-mobile) Received: from duncan.cs.utk.edu (DUNCAN.CS.UTK.EDU [128.169.94.83]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id OAA14360 for ; Thu, 20 Nov 1997 14:31:08 -0800 (PST) (envelope-from key@cs.utk.edu) Received: from LOCALHOST.cs.utk.edu by duncan.cs.utk.edu with SMTP (cf v2.11c-UTK) id QAA23366; Thu, 20 Nov 1997 16:42:20 -0500 Message-Id: <199711202142.QAA23366@duncan.cs.utk.edu> To: Nate Williams cc: Ken Key , freebsd-mobile@freebsd.org Subject: Re: boot floppies for 2.2.5-STABLE that speak PCMCIA? From: Ken Key In-reply-to: Your message of Thu, 20 Nov 1997 13:22:37 -0700. <199711202022.NAA11157@mt.sri.com> Date: Thu, 20 Nov 1997 16:42:13 -0500 Sender: owner-freebsd-mobile@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > I've been running v2.2.2-PAO on a ThinkPad 560 w/ LinkSys EC2T. > > Per the comments of Nate Williams the past few weeks, it sounds like > > I want to run v2.2.5-STABLE (is that the same as the 2.2-YYMMDD-SNAP?) > > No, it's not the same. I don't believe there has been an updated > 2.2.5-STABLE snap. Ah, I've also been pulling the RELENG_2_2 tag via cvsup, which I now assume maps to 2.2.5-STABLE. Now I'm confused. I had assumed the 3.0-*-SNAP's were "freebsd-current" and the 2.2-*-SNAPS were "freebsd-stable", per the handbook. If the 2.2-*-SNAPs aren't RELENG_2_2, what are they? Or if I'm completely confused, clues into the supfile tag to use for 2.2.5-STABLE would be appreciated. > Mine works great. :) Excellent! A goal is in sight! > Can you use your existing setup to update just the sources and build > from that using CVSup/CTM? That's the 'standard' way of updating, and > it let's you continue to update as changes are made once you get things > setup initially. The handbook has information on how to do that. That's what I eventually want to do but I'm worried about failure modes with the upgrade interacting with PAO already on the system. I also want to wipe and repartition the system, so install time sounded like a good time. However, it now sounds like my choice for doing the wipe means putting PAO back on after partitioning/newfs'ing and then cvsup/build/upgrade. Hmm, that partition map doesn't look so bad after all - I think I'll update the sources and install over the running PAO and see what happens first... Thanks for the info! K^2 -- Ken Key (key@cs.utk.edu) Univ. of Tennessee, Knoxville