From owner-freebsd-current@FreeBSD.ORG Sun Oct 10 17:27:43 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 21DDA16A4CE for ; Sun, 10 Oct 2004 17:27:43 +0000 (GMT) Received: from phuket.psconsult.nl (ps226.psconsult.nl [213.222.19.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 133B643D3F for ; Sun, 10 Oct 2004 17:27:41 +0000 (GMT) (envelope-from fb-current@psconsult.nl) Received: from phuket.psconsult.nl (localhost [127.0.0.1]) by phuket.psconsult.nl (8.12.8p2/8.12.8) with ESMTP id i9AHRdYe083365 for ; Sun, 10 Oct 2004 19:27:39 +0200 (CEST) (envelope-from fb-current@psconsult.nl) Received: (from paul@localhost) by phuket.psconsult.nl (8.12.8p2/8.12.8/Submit) id i9AHRdln083364 for current@freebsd.org; Sun, 10 Oct 2004 19:27:39 +0200 (CEST) Date: Sun, 10 Oct 2004 19:27:38 +0200 From: Paul Schenkeveld To: current@freebsd.org Message-ID: <20041010172738.GA81108@psconsult.nl> Mail-Followup-To: current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6i Subject: nanobsd fdisk layout broken X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Oct 2004 17:27:43 -0000 Hi, For some Soekris boxes I will use soon, I thought I'd give nanobsd a try and encounterd the following problem. My Kingston compact flash has 695 cyls, 15 heads and 48 secs/trk according to dmesg when I insert it into my notebook. When I want a 10MB data slice (DATASIZE=10240) the i386.diskimage script is unable to populate the flash image, from _.md.tmp: + cat /tmp/nanobsd.WhzaHkUW g c695 h15 s48 p 1 165 48 245056 p 2 165 245104 245056 p 3 165 490160 10240 + fdisk -i -f /tmp/nanobsd.WhzaHkUW md0 fdisk: invalid fdisk partition table found fdisk: WARNING: adjusting size of partition 1 from 245056 to 244752 to end on a cylinder boundary fdisk: WARNING: adjusting start offset of partition 2 from 245104 to 245136, to fall on a head boundary fdisk: WARNING: adjusting size of partition 2 from 245056 to 244464 to end on a cylinder boundary fdisk: WARNING: adjusting start offset of partition 3 from 490160 to 490176, to fall on a head boundary fdisk: WARNING: adjusting size of partition 3 from 10240 to 10224 to end on a cylinder boundary ******* Working on device /dev/md0 ******* + fdisk md0 ******* Working on device /dev/md0 ******* parameters extracted from in-core disklabel are: cylinders=695 heads=15 sectors/track=48 (720 blks/cyl) and a bit later: + dd if=/dev/md0s1 of=/dev/md0s2 bs=64k dd: /dev/md0s2: short write on character device dd: /dev/md0s2: end of device 1910+0 records in 1909+1 records out 125165568 bytes transferred in 32.334543 secs (3870955 bytes/sec) Note how fdisk decides to make md0s2 slightly smaller than md0s1. Fdisk wants things to be aligned at cylinder or track boundaries (it's not clear to me when it wants one and when the other). The i386 architecture uses the first sector of any disk to store the MBR and reserves a whole track for this, so the first slice normally starts at the second track of the first cylinder. So with the formula used by i386.diskimage to calculate the size of a boot slice (total_sectors - sectors_per_track - datasize) / 2 the rounding formulas in fdisk may cause the second slice to be shorter than the first which breaks the nanobsd scripts. Therefore I propose to alter the calculations done in i386.diskimage such that: 1. The data slice (/etc) physically comes first, starts at the second track of the first cylinder and ends at a cylinder boundary. 2. The boot slices are physically located after the data slice and their size is an integral multiple of the cylinder size. The attached patch for i386.diskimage implements this resulting in two equally sized boot partitions starting and ending at cylinder boundaries and a data partition starting at the second track and ending at a cylinder boundary. Because of all the roundings, the actual size of the data slice will normally be larger that the value of DATASIZE in make.conf. Note that there is one more exercise left: change this calculation or the newfs parameters such that newfs will use all slices entirely instead of throwing away some sectors at the end of each slice. Regards, Paul Schenkeveld ------------------------------------------------------------------------ --- src/tools/tools/nanobsd/i386.diskimage.orig Mon Sep 6 22:57:28 2004 +++ src/tools/tools/nanobsd/i386.diskimage Sun Oct 10 18:43:46 2004 @@ -56,12 +56,14 @@ MD=`mdconfig -a -t vnode -f ${TMPFILE0} -x ${SC} -y ${HD}` rm -f ${TMPFILE0} ( -sl=`expr "(" ${SECTS} - ${SC} - ${DATASIZE} ")" / 2` cyl=`expr ${SECTS} / ${SC} / ${HD}` +sl_cyl=`expr "(" ${SECTS} - ${SC} - ${DATASIZE} ")" / 2 / ${HD} / ${SC}` +sl=`expr $sl_cyl "*" ${HD} "*" ${SC}` +ds=`expr ${SECTS} - ${SC} - ${sl} - ${sl}` echo g c${cyl} h${HD} s${SC} -echo p 1 165 ${SC} $sl -echo p 2 165 `expr ${SC} + $sl` $sl -echo p 3 165 `expr ${SC} + $sl + $sl` ${DATASIZE} +echo p 1 165 `expr ${SC} + $ds` $sl +echo p 2 165 `expr ${SC} + $ds + $sl` $sl +echo p 3 165 ${SC} $ds ) > ${TMPFILE1} cat ${TMPFILE1} fdisk -i -f ${TMPFILE1} ${MD}