[meta-freescale] Improving SD-Card images

[Maciek Borzecki]

On wto, 2014-07-22 at 13:04 +0200, Jens Rehsack wrote:
> Am 22.07.2014 um 09:37 schrieb Maciek Borzecki <maciej.borzecki at open-rnd.pl>:
> 
> > On wto, 2014-07-22 at 09:09 +0200, Jens Rehsack wrote:
> >> Am 22.07.2014 um 08:37 schrieb Maciek Borzecki <maciej.borzecki at open-rnd.pl>:
> >> 
> > Having spent roughly 3 days with wic code, I'll try to point out what's
> > missing.
> 
> So it will be smart to steal^Wborrow your code :)
> 
> >> # vfat boot partition
> >> part --source uboot-imx-img --ondisk mmcblk0 --fstype=vfat --active --align 1024 --size 10
> > Source pluging for building parition with uboot-imx. My original though
> > was that it would be nice to have a general plugin that covers this, at
> > least partially and only for u-boot. Now, I'm not sure if it's right
> > approach. The beaglebone code that I posted has only one BBB specific
> > step, which is copying over MLO. 
> > 
> >> # root-fs
> >> part / --source rootfs --ondisk mmcblk0 --fstype=squashfs --label root --align 1024
> > squashfs is not supported, needs adding
> 
> Sure - or for the moment stick at old way to build image.
> 
> >> # recovery-root-fs
> >> part /recovery --source recoverfs --ondisk mmcblk0 --fstype=squashfs --label root --align 1024
> >> # data/tmp partition
> >> part /var/tmp --ondisk mmcblk0p --fstype=ext3 --label data --align 1024 --size 1024 --fsoptions sync
> >> # union-fs for root-fs changes - howto will come later
> >> part / --ondisk mmcblk0p --fstype=unionfs --label change --align 1024 --size 1536 --fsoptions sync
> > Current code assumes that any entry listed in kickstart corresponds to a
> > physical partition. In this case, there is no physical partition right?
> > I'd say that unionfs entry should not be listed here. Maybe Otavio can
> > comment on this this.
> 
> The plan is to have 2 independent root filesystems, one for daily operations,
> one for running updates (with ability to re-fetch URI) and emergency shell
> access.
> 
> The union-fs partition for overlaying to allow changes to operational rootfs
> (to avoid dozen of r/w partitions)
> 
> >> 
> >> And the crucial question is: where does the recoverfs filesystem image comes from, when rootfs is generated magically by image.bbclass?
> > I'd say another class, perhaps extending image. You'd basically want a
> > subset of packages/files that end up in rootfs.
> 
> Is there any resource available which describes how to do that?

Not that I'm aware of. 

Perhaps it's a stupid workaround, but have you considered building 2
images separately? One for recovery, the other with regular rootfs.
Later on combine these 2 into a single SD card image using wic or
whatever is the preferred method.

Running wic can be decoupled from building an image. It should be
possible to build a regular and recovery images. Prepare a kickstart
file that combines the two, plus a boot partition and an empty data
partition. Then run wic manually to obtain a single image file.



-- 
Maciej Borzęcki
Senior Software Developer at Open-RnD Sp. z o.o., Poland
www.open-rnd.pl
mobile: +48 889 117 365, fax: +48 42 657 9079

Niniejsza wiadomość wraz z załącznikami może zawierać chronione prawem
lub poufne informacje i została wysłana wyłącznie do wiadomości i
użytku osób, do których została zaadresowana. Jeśli wiadomość została
otrzymana przypadkowo zabrania się jej kopiowania lub rozsyłania do
osób trzecich. W takim przypadku uprasza się o natychmiastowe
zniszczenie wiadomości oraz poinformowanie nadawcy o zaistniałej
sytuacji za pomocą wiadomości zwrotnej. Dziękujemy.

This message, including any attachments hereto, may contain privileged
or confidential information and is sent solely for the attention and
use of the intended addressee(s). If you are not an intended addressee,
you may neither use this message nor copy or deliver it to anyone. In
such case, you should immediately destroy this message and kindly notify
the sender by reply email. Thank you.