From owner-freebsd-fs@FreeBSD.ORG Wed Mar 13 13:34:15 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 0D2792D7 for ; Wed, 13 Mar 2013 13:34:15 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail12.syd.optusnet.com.au (mail12.syd.optusnet.com.au [211.29.132.193]) by mx1.freebsd.org (Postfix) with ESMTP id 8ADA9338 for ; Wed, 13 Mar 2013 13:34:13 +0000 (UTC) Received: from c211-30-173-106.carlnfd1.nsw.optusnet.com.au (c211-30-173-106.carlnfd1.nsw.optusnet.com.au [211.30.173.106]) by mail12.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id r2DDXxtC032494 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 Mar 2013 00:34:01 +1100 Date: Thu, 14 Mar 2013 00:33:59 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Cody Ritts Subject: Re: Aligning MBR for ZFS boot help In-Reply-To: <513F8F04.60206@caltel.com> Message-ID: <20130313232247.B1078@besplex.bde.org> References: <513C1629.50501@caltel.com> <513CD9AB.5080903@caltel.com> <513CE369.4030303@caltel.com> <1362951595.99445.2.camel@btw.pki2.com> <513E1208.5020804@caltel.com> <20130312203745.A1130@besplex.bde.org> <513F8F04.60206@caltel.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.0 cv=Q4OKePKa c=1 sm=1 a=u3bVZBOdoLwA:10 a=kj9zAlcOel0A:10 a=PO7r1zJSAAAA:8 a=JzwRw_2MAAAA:8 a=cUKNXEIY390A:10 a=6I5d2MoRAAAA:8 a=ikclS7t6qE9F1bxxU1YA:9 a=CjuIK1q_8ugA:10 a=3JYNrmlC3cAA:10 a=z_RuTD8k6CXfqtkX:21 a=7nNRCSddQ2EWGmUR:21 a=TEtd8y5WR3g2ypngnwZWYw==:117 Cc: freebsd-fs@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 13:34:15 -0000 On Tue, 12 Mar 2013, Cody Ritts wrote: > On 3/12/13 3:25 AM, Bruce Evans wrote: >>> Update -- >>> >>> fdisk WILL allow you to align without regards to drive geometry >>> >>> It can only be done in interactive mode: >>> http://lists.freebsd.org/pipermail/freebsd-geom/2011-May/004780.html >> >> It can be set in all modes. At least according to the man page: > > In interactive mode, you can simply set the start and size of your partition > be done with it and boot away. That will usually give nonsense beginning and ending CHS values. This will usually prevent BIOSes and non-broken versions of FreeBSD from detecting the geometry. It would also prevent booting on BIOSes that uses the CHS values; this is not usually a problem now. So this misconfiguration will mainly mess up printing of the partition table in utilities that print the CHS utilities, and cause warnings in utilities that want the CHS values to be correct, and propagate the misconfiguratation. > If you then export that config file, and > re-run it, you are back to being aligned to CHS. Only if the config file is broken. > I would imagine that adjusting your CHS ~correctly~ in the config file will > allow you to to do it, but I have not found myself motivated to really learn > about adjusting those values. I will have to pick that up someday I suppose. Yes this is necessary and very easy. Just type in the same geometry that you need to type in at the start of interactive fdisk to avoid the above problems. > For informational purposes here is > 1) partition w/ offset > 2) show results > 3) export/import config > 4) show results with adjusted offset > >> root@:/root # fdisk -i ada0 >> Do you want to change our idea of what BIOS thinks ? [n] You do want the change this. Use something like 32 sectors 64 heads (1MB cylinders). >> Do you want to change it? [n] y >> Supply a decimal value for "sysid (165=FreeBSD)" [165] >> Supply a decimal value for "start" [63] 4096 >> Supply a decimal value for "size" [125045361] 125041328 >> Correct this automatically? [n] After changing "what BIOS thinks" to something like the above, fdisk shouldn't see anything to correct. The start of 4096 is a multiple of 32*64 = 2048. I just noticed that despite being too chatty, "what BIOS thinks" has bad grammar. >> Explicitly specify beg/end address ? [n] >> Are we happy with this entry? [n] y >> Do you want to change it? [n] >> Do you want to change it? [n] >> Do you want to change it? [n] >> Do you want to change the active partition? [n] >> Should we write new partition table? [n] y >> >> root@:/root # gpart show ada0 >> => 63 125045361 ada0 MBR (59G) >> 63 4033 - free - (2M) >> 4096 125041328 1 freebsd [active] (59G) Looks like it got a bogus 63 from the same place as fdisk (from the "firmware" goemetry. The free area isn't really 4033 block sectors at 63, but 4095 blocks starting at 1 (for non-broken BIOSes and OSes). I used to start partitions at offset 1, but now use 63 for portability. However, 63 isn't portable either. The BIOS or another OS might have a different idea of the geometry. >> root@:/root # fdisk -p ada0 >> # /dev/ada0 >> g c124053 h16 s63 >> p 1 0xa5 4096 125041328 >> a 1 This shows fdisk -p using the same garbage default geometry as interactive fdisk. So fdisk -p output is not directly usable. There is no place in the partition table to store the geometry directly. It can sometimes be determined indirectly, but neither the kernel nor fdisk does so. Old kernels did so, and fdisk depended on this. However, fdisk shouldn't depend on this, so that fdisk can work on images of partition tables. Linux fdisk (fdisk-linux in ports) does this correctly. Not using OS-specific ioctls for this also improves portability. The kernel support for this was mainly to ensure that all FreeBSD utilities got a consistent view of the geometry, back when consistent views mattered. It's still confusing when the views are different. >> root@:/root # fdisk -p ada0 > command >> >> root@:/root # fdisk -f command ada0 >> ******* Working on device /dev/ada0 ******* >> fdisk: WARNING line 2: number of cylinders (124053) may be out-of-range >> (must be within 1-1024 for normal BIOS operation, unless the entire >> disk >> is dedicated to FreeBSD) >> fdisk: WARNING: adjusting start offset of partition 1 >> from 4096 to 4158, to fall on a head boundary >> fdisk: WARNING: adjusting size of partition 1 from 125041328 to 125041266 >> to end on a cylinder boundary This is broken. The non-interactive version should not adjust anything. Even the interactive version defaults to not adjusting. >> root@:/root # fdisk -p ada0 >> # /dev/ada0 >> g c124053 h16 s63 >> p 1 0xa5 4158 125041266 >> a 1 >> >> root@:/root # gpart show ada0 >> => 63 125045361 ada0 MBR (59G) >> 63 4095 - free - (2M) >> 4158 125041266 1 freebsd [active] (59G) So the bugs of fdisk -p producing wrong geometry, not editing its output to fix this, and the broken adjustment done by fdisk -f, result in the partiton offsets being corrupted by fdisk -f. Bruce