On Thu, Mar 15, 2012 at 12:28:29AM +0000, Peter Robinson wrote: > On Wed, Mar 14, 2012 at 11:48 PM, James Cameron <[email protected]> wrote: > > On Wed, Mar 14, 2012 at 11:33:32PM +0000, Peter Robinson wrote: > >> On Wed, Mar 14, 2012 at 11:29 PM, James Cameron <[email protected]> wrote: > >> > On Wed, Mar 14, 2012 at 07:02:51PM -0400, John Watlington wrote: > >> >> > >> >> On Mar 14, 2012, at 6:04 PM, James Cameron wrote: > >> >> > >> >> > On Wed, Mar 14, 2012 at 08:37:23AM -0600, Daniel Drake wrote: > >> >> >> On Wed, Mar 14, 2012 at 7:06 AM, Richard Smith <[email protected]> > >> >> >> wrote: > >> >> >>> On Wed, Mar 14, 2012 at 1:35 AM, James Cameron <[email protected]> > >> >> >>> wrote: > >> >> >>>> Grows the second partition so that it takes up all remaining space > >> >> >>>> on > >> >> >>>> the eMMC or microSD card. ?Fix for #11690. ?Part of #10040. > >> >> >>>> > >> >> >>>> Costs 120ms. ?(Use of a flag file costs 130ms). > >> >> >>>> > >> >> >>> > >> >> >>> I don't think its necessary to do this check every boot. I propose > >> >> >>> you > >> >> >>> move it to after fs-update has installed an image. > >> >> >> > >> >> >> Also, olpc.fth isn't executed in the secure boot path, so it does > >> >> >> need > >> >> >> to be put somewhere else. I like Richard's suggestion. > >> >> > > >> >> > This would break fs-verify, and is therefore unacceptable. > >> >> > >> >> Is this really a concern ? ? It doesn't break fs-verify if one is using > >> >> the correct > >> >> image for the storage device in question. ? Or are we tweaking the > >> >> filesystem > >> >> to get the extra few MB with some cards ? > >> > > >> > With #11690 and #10040 fixed, we would only need to create one image for > >> > the smallest storage device shipped. ?Every image would then be the > >> > correct image. > >> > > >> > Yes, this method can be used to "free up" the unused space between the > >> > size of the smallest image and the size of the smallest storage device > >> > shipped, but that is a side-effect. > >> > > >> > fs-verify is used after fs-update in factory to ensure that the > >> > fs-update was successful. > >> > >> Stupid question but can't you just do fs-update -> fs-verify to verify > >> the image installed is imaged over correctly -> fs-expand to expand it > >> to a full size once we know the image is good? > > > > Yes, but that would be an extra step for deployment. > > > > I would prefer to solve this by having Linux expand the partition, but > > I'm told that can't work because Linux doesn't see the new size until > > next boot. ?Do you know a way to avoid a reboot? > > There's the partprobe utility which is part of the parted package, we > ship it. It will re-read the partition table without a reboot.
No, it doesn't. # fdisk /dev/mmcblk0 [ delete partition, create new partition with same starting position but idfferent length, then write partitino table ] # partprobe /dev/mmcblk0 Error: Partition(s) 2 on /dev/mmcblk0 have been written, but we have been unable to inform the kernel of the change, probably because it/they are in use. As a result, the old partition(s) will remain in use. You should reboot now before making further changes. # -- James Cameron http://quozl.linux.org.au/ _______________________________________________ Devel mailing list [email protected] http://lists.laptop.org/listinfo/devel
