From owner-freebsd-questions@FreeBSD.ORG Fri Oct 16 19:37:26 2009 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BB264106568D for ; Fri, 16 Oct 2009 19:37:26 +0000 (UTC) (envelope-from af.gourmet@videotron.ca) Received: from relais.videotron.ca (relais.videotron.ca [24.201.245.36]) by mx1.freebsd.org (Postfix) with ESMTP id 929C78FC17 for ; Fri, 16 Oct 2009 19:37:26 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=UTF-8 Received: from [192.168.0.51] ([96.21.103.185]) by VL-MO-MR004.ip.videotron.ca (Sun Java(tm) System Messaging Server 6.3-4.01 (built Aug 3 2007; 32bit)) with ESMTP id <0KRM004DJH6DMKC0@VL-MO-MR004.ip.videotron.ca> for freebsd-questions@freebsd.org; Fri, 16 Oct 2009 15:37:26 -0400 (EDT) Message-id: <4AD8CB77.4080801@videotron.ca> Date: Fri, 16 Oct 2009 15:37:27 -0400 From: PJ User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) To: Manolis Kiagias References: <4AD8B65C.9020603@videotron.ca> <4AD8B9A9.7030306@otenet.gr> <4AD8C62C.2060009@videotron.ca> <4AD8C7B9.8030108@otenet.gr> In-reply-to: <4AD8C7B9.8030108@otenet.gr> Cc: "freebsd-questions@freebsd.org" Subject: Re: GEOM label clarification X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 19:37:26 -0000 Manolis Kiagias wrote: > PJ wrote: > >> Manolis Kiagias wrote: >> >> >>> PJ wrote: >>> >>> >>> >>>> If I understand correctly from the manual, giving the labels their slice >>>> name (/dev/label/rootfs rather than /dev/ad4s1a) will assure that >>>> regardless of the disk, the boot will be from the disk being booted and >>>> not from another disk as happened to me recently - the fstab on disk ad4 >>>> was referncing ad12 so the boot was from ad12 rather than ad4. >>>> The handbook says: >>>> "By permanently labeling the partitions on the boot disk, the system >>>> should be able to continue to boot normally, even if the disk is moved >>>> to another controller or transferred to a different system. For this >>>> example, it is assumed that a single ATA disk is used, which is >>>> currently recognized by the system as ad0." >>>> If the disk is moved to another system, it may no longer be ad0... So >>>> will it still boot correctly? >>>> >>>> >>>> >>>> >>>> >>> In short, yes. I do this routinely all the time. >>> Assuming of course that the device is connected to a controller that >>> FreeBSD recognizes. >>> This should be a non-issue for standard ATA/SATA disks. >>> >>> >>> >>> >>>> Or should the ufsid labels be used? >>>> >>>> >>>> >>>> >>>> >>> The ufsid is also an option if you do not wish to create the labels >>> yourself. >>> The advantage of user-created labels is that they are not 'cryptic' like >>> the ufsid ones >>> and you may actually remember them :) >>> >>> >>> >>> >>>> Will both of these contortions work? >>>> >>>> >>>> >>>> >>> Yes, both will do. >>> >>> >>> >>> >> Thanks for the reassurance. Now to start labelling. Uh.. I guess that >> means that if I label 1 disk and then clone it to several others, they >> wil all work from any system... Well, I guess I'll try it. Thanks again. >> >> >> >> > How are going to clone it? Will the clone also copy the labels? > For example, if doing a dump / restore (which I often do) I recreate the > partitions manually, newfs them, label them and then restore the > contents. In many cases I use a live (Fixit) system for this. > I'm looking into that just now. I am playing with two disks... one is 80gb sata on USB... and the second is 250Gb sata on USB. I had tried to set them up with livefs but the 80Gb is all wrong... I usually set up 2Gb on /, 3Gb on swap, 2gb on /tmp, 2gb on /var and 50gb on /usr . But I just newfsd the partitions on the 80gb and found that the da0s1d was 50gb which doesn't make sense as I had set it for 2gb and d should have been /tmp, e = /var, f= usr and g=/home. That explains why I ran out of space when trying to restore to the disk. So now I'm going to try to redo the disk manually with fdisk, bsdlabel and newfs. We'll see...