[PATCH] olpc.fth - grow the root filesystem partition on boot

Peter Robinson pbrobinson at gmail.com
Thu Mar 15 03:58:03 EDT 2012


On Thu, Mar 15, 2012 at 12:47 AM, James Cameron <quozl at laptop.org> wrote:
> On Thu, Mar 15, 2012 at 12:28:29AM +0000, Peter Robinson wrote:
>> On Wed, Mar 14, 2012 at 11:48 PM, James Cameron <quozl at laptop.org> 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 <quozl at laptop.org> 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 <richard at laptop.org> wrote:
>> >> >> >>> On Wed, Mar 14, 2012 at 1:35 AM, James Cameron <quozl at laptop.org> 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.

Well it works fine for 100s of devices in our datacenter at work,
maybe there's some mechanism not implemented in mmc or the linux code.
cjb might be able to fill in some of the gaps..

Peter

> # 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/



More information about the Devel mailing list