From owner-freebsd-arm@FreeBSD.ORG Fri May 2 00:16:00 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 61C18DAB; Fri, 2 May 2014 00:16:00 +0000 (UTC) Received: from mail-ee0-x232.google.com (mail-ee0-x232.google.com [IPv6:2a00:1450:4013:c00::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C2A8A1D42; Fri, 2 May 2014 00:15:59 +0000 (UTC) Received: by mail-ee0-f50.google.com with SMTP id c13so2601706eek.37 for ; Thu, 01 May 2014 17:15:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=dvh+GK3aK66bssioQjyKeOZum1G4yn/0IW6d//q3Haw=; b=ct6aPULrVgSZQIHMogKQnluHDFogey7NaU87DAp6O8Sd3zwM6HrF2fhwOnJzROaPKs FBav0+/8rD5ReimKtrLQ4EHOpgvIMPTA1Yzvd8mWupERD+kHIyKpa+3oNxCZ+4+8ppZD 8m4pEFkoqQ8ezD/0COnrNaK4v1xZ0YF7TqM1srRHQ8Okgk0rfVoW1RewsnPtJ8sL6veh OQvtIavD4txM9Hd9pSNWFxaeCgnSszoT5GAH1v/KUs/BcXOnkLthhC6Nm5XXVSr8mSaR lj1kE9Kt8WEmq44yAUMoAgKouheZxqA0K1Pc8cZA/+3wX6a9ywiBWHUMtyJ3GF+ve20q vqLQ== X-Received: by 10.15.91.77 with SMTP id r53mr11899846eez.70.1398989757669; Thu, 01 May 2014 17:15:57 -0700 (PDT) Received: from ketas-laptop.mydomain (ketas-laptop6.si.pri.ee. [2001:ad0:91f:0:21a:6bff:fe66:2ad3]) by mx.google.com with ESMTPSA id 45sm165355eeh.9.2014.05.01.17.15.55 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 01 May 2014 17:15:56 -0700 (PDT) Sender: Sulev-Madis Silber Message-ID: <5362E3B7.6000105@hot.ee> Date: Fri, 02 May 2014 03:15:51 +0300 From: "Sulev-Madis Silber (ketas)" User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: Nathan Whitehorn Subject: Re: crochet - why does it (try to) change files in /usr/src? References: <20140501005611.3401d271adf4db31cf8e9246@getmail.no> <5361AC27.8020001@freebsd.org> <5361B72D.2000506@hot.ee> <5361BBB9.9050208@freebsd.org> In-Reply-To: <5361BBB9.9050208@freebsd.org> X-TagToolbar-Keys: D20140502031549241 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: FreeBSD ARM X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 May 2014 00:16:00 -0000 On 2014-05-01 06:12, Nathan Whitehorn wrote: > On 04/30/14 19:53, Sulev-Madis Silber (ketas) wrote: >> On 2014-05-01 05:06, Nathan Whitehorn wrote: >>> With both mkimg and makefs in the tree now, there should be almost no >>> need for md devices for image generation anymore. >>> -Nathan >> >> That would only work for devices that don't need FAT filesystems. >> >> >> Also, if you want to build image root-less, you need to figure out how >> to get correct file permissions into your image file. Surely you can get >> those into file, just you can't do it directly on filesystem. >> > > makefs knows how to do permissions fine, either from the file itself or > a manifest, and should be acquiring FAT support from NetBSD shortly. It > also supports building opposite-endian UFS file systems, which is very > useful for embedded applications. > -Nathan Not related much, but lately I tried to create partition table where first partition starts from 512k sector #8192... After multiple tries with gpart and fdisk I found that this is totally impossible. Felt like trying to get square peg into round hole, no matter how I tried, it always realigned the partition into wrong sector. I guess this is because of those stupid C/H/S values (does anything use them these days?)? I even looked the code that does this, but didn't know how to exactly fix this. On 11-CURRENT, gpart even complained about partition not aligned to 4m... but it was impossible to have it aligned properly, no matter how I tried. I wish I could force alignment of partitions. Although... now I checked it again and I'm confused what exactly happens there. Can anyone confirm that indeed is wrong behavior. Because it looks like it is.