From owner-freebsd-stable@FreeBSD.ORG Fri Sep 17 18:54:29 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 342E3106566C for ; Fri, 17 Sep 2010 18:54:29 +0000 (UTC) (envelope-from matheusber@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id D51E58FC20 for ; Fri, 17 Sep 2010 18:54:28 +0000 (UTC) Received: by yxn35 with SMTP id 35so1033003yxn.13 for ; Fri, 17 Sep 2010 11:54:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:received:received :message-id:in-reply-to:references:date:subject:from:to:user-agent :mime-version:content-type:content-transfer-encoding:x-priority :importance; bh=ELgCKCJdNSEo89coYDlbzcLBzE3IJVjjD3vWHKZjCgM=; b=F1OAndJspeQaA0HWIodP38tRPiHJlBsomHDsKiN953wH5ImJi8BzMjR6Bl5IWf6aMN a3a1FFaLof7fwt+jWkkImiqVMo516RFMLL3D2wnqZ3OCjYCDbN2+9Y5YCe6ZrpfYNCsk 2VPxfSa+p8LapuWteTaFOyb76lePquN5ZqSoc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:in-reply-to:references:date:subject:from:to :user-agent:mime-version:content-type:content-transfer-encoding :x-priority:importance; b=PUy/7sE4TpPFVfBOMRSwmKk2Ar+6YwOU5FjjpArg2g+6fc+hTUCljTfSbAZJEnCXJU Js+G8FQXvHClYBRY/PWnQi980IWLovgXfX+IhqN2P0qfOXN3tzZVUdVHQGVI4xmBQSAa KZlLwaB2+xEClT4FKGsQL278H0AQUBheUxJcE= Received: by 10.100.153.15 with SMTP id a15mr5929910ane.179.1284748360675; Fri, 17 Sep 2010 11:32:40 -0700 (PDT) Received: from cygnus.homeunix.com ([187.114.195.173]) by mx.google.com with ESMTPS id w1sm6561621ana.36.2010.09.17.11.32.37 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 17 Sep 2010 11:32:39 -0700 (PDT) Sender: Nenhum_de_Nos Received: by cygnus.homeunix.com (Postfix, from userid 80) id 33F67B805E; Fri, 17 Sep 2010 15:32:32 -0300 (BRT) Received: from 189.59.75.37 (proxying for 10.12.1.221, 10.12.0.101) (SquirrelMail authenticated user matheus) by cygnus.homeunix.com with HTTP; Fri, 17 Sep 2010 15:32:32 -0300 (BRT) Message-ID: In-Reply-To: References: <201009171238.o8HCcwCl084727@lurza.secnetix.de> Date: Fri, 17 Sep 2010 15:32:32 -0300 (BRT) From: "Nenhum_de_Nos" To: freebsd-stable@freebsd.org User-Agent: SquirrelMail/1.4.15 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: Re: How to predict drive number change for 7.3->8.1 upgrade? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Sep 2010 18:54:29 -0000 On Fri, September 17, 2010 13:10, Freddie Cash wrote: > On Fri, Sep 17, 2010 at 5:38 AM, Oliver Fromme > wrote: >> Michael Sperber wrote: >>  > I just upgraded my desktop system from 7.3 to 8.1, and the main hard >>  > drive, which was /dev/ad6 before is now /dev/ad10.  Consequently, >> the >>  > initial boot failed when trying to mount the root file system from >> ad6. >>  > >>  > The desktop system is now fixed, but I also have a rented server >> with >>  > only a serial console, and I worry that the upgrade is going to >> leave me >>  > with a dead machine.  Is there any way to predict how the drive >> number >>  > changes?  (Why does it change at all?)  If so, what's the proper >> way to >>  > tell the system the initial root device *before* rebooting? >> >> Remove "options ATA_STATIC_ID" from your kernel config >> before building the new kernel and rebooting.  Then your >> first disk will be ad0, no matter what controller and >> channel it is connected to.  Be sure to update your >> /etc/fstab file. > > Problem with doing that (no ATA_STATIC_ID) is that if you change the > order that your PCI devices are enumerated, you will change the order > in which your disks are probed, and all your numbers change again. :) > And there's an option for this in every BIOS I've worked with. Plus, > moving addon controllers from one slot to another will also re-number > your devices. > > The best, long-term, solution is to label your devices/filesystems so > that the name never changes, no matter what happsn to the underlying > device nodes. There are multiple ways to do so, depending on whether > you want to label the disk, the slice, the partition, or the > filesystem: > - glabe; > - gpart labels > - filesystem labels I have the same issue, a virtual machine rented in some datacenter. I'd like to know a way that is safe, as I did already on another box the glabel way without newfs on the label (but the underlying device). never got problems thought, but I figure this way is better for aditional disks, not / and system slices. thanks, matheus -- We will call you cygnus, The God of balance you shall be A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? http://en.wikipedia.org/wiki/Posting_style