partition layouts and configuration

[Alexander Sack]

Hi Jimmy,

On Tue, Dec 16, 2014 at 12:45 AM, Jimmy Tang <jcftang at gmail.com> wrote:
> Hi Alex
>
> On Mon, Dec 15, 2014 at 11:12 PM, Alexander Sack <asac at canonical.com> wrote:
>>
>> On Mon, Dec 15, 2014 at 2:45 PM, Jimmy Tang <jcftang at gmail.com> wrote:
>> > Hi All
>> >
>> > I'm trying to grasp the filesystem and partition layouts as described
>> > here
>> > http://developer.ubuntu.com/snappy/filesystem-layout/
>> >
>> > How ever I wish to try and build an image for an arm based system
>> > (Novena),
>> > the usual layout for the novena boards that I have (like all the imx6i
>> > based
>> > systems) require that the first partition is reserved and formatted as a
>> > fat32 partition for loading up the kernel.
>> >
>> > I couldn't find any information on how to shift the partition layout by
>> > one.
>> > This is my desired layout
>> >
>> > - bootloader - /dev/sda1 - 512mb - fat32 partition
>> > - system-a - /dev/sda2 - 2gb - ext 2/3/4 primary root filesystem
>> > - system-b - /dev/sda3 - 2gb - ext 2/3/4 secondary root filesystem
>> > - writable - /dev/sda4 - rest of the disk - ext 2/3/4 persistent user
>> > data
>> >
>> > How does one configure core/snappy to alternate between sda2 and sda3
>> > when
>> > updates/reboots occur?
>>
>> Maybe its buggy, but in theory we are looking for partition label and
>> not hard coded device paths. Setting those for your partitions
>> accordingly might give what you want.
>>
>> In /usr/lib/python3/dist-packages/ubuntucoreupgrader/parser.py we have:
>>
>>   WRITABLE_DATA_LABEL = 'writable'
>>
>>   SYSTEM_DATA_A_LABEL = 'system-a'
>>
>>   SYSTEM_DATA_B_LABEL = 'system-b'
>>
>> ... and then ...
>>
>> def get_root_partitions_by_label():
>>     '''
>>     Returns a list of tuples of the recognised root filesystem partitions
>>     available on this system. The tuples contain the following triplet:
>>
>>         ( <partition-name>, <full-device-path>, <mountpoint> )
>>
>>     '''
>>     cmd = 'lsblk'
>>     recognised = (SYSTEM_DATA_A_LABEL, SYSTEM_DATA_B_LABEL)
>> ...
>>
>>
>> I assume you have tried this?
>>
>>  -  Alexander
>
>
> Ah okay that's clearer then, I'll be honest, I've been trying to dig up more
> documentation details on how the system is implemented before attempting to
> build my own image. I've not tried building an image just yet.

Give it a try! Moving from theory to practice often comes with lots of
answers of previously hard to figure simple questions :).

>
> To follow up on this discussion how does snappy/core select the the
> partition to boot up, is the mechanism tied to grub/syslinux? I ask this
> because if the boot loader needs to be modified, I am restricted by
> generating uboot scripts to change the rootfs when boot, although I can use
> partition labels, I am still interested in how the boot sequence is
> implemented.
>
> Again is a publicly available design or architecture document on how it's
> all implemented?

Right now, everything not on or linked from ubuntu.com/snappy nor
developer.ubuntu.com/snappy probably does not exist - at least for me
that is. What I know is that for now we only support grub and we
haven't looked at uboot yet; without knowing I would suspect that
reasonable modern u-boot probably come with the features needed to
make our system-image update story work.

Would be great if you could check it out by reading code and
experimenting with snappy and let us know if you managed to get this
to work with u-boot (and which version) - maybe even submit a patch
:)?

Thanks!

 - Alexander