Is BOOTDD_EXTRA_SPACE from misc.py used correctly?

Is BOOTDD_EXTRA_SPACE from misc.py used correctly?

[claus.stovgaard]

Hi folks.

I think the BOOTDD_EXTRA_SPACE is used incorrectly in bootimg-efi.py
and bootimg-pcbios.py?

The background is that I am forced to create a rather small efi
partition of 25 MB. Not a big problem I thought, as the kernel, plus
initrd is only 12 MB. But the resulting partition was 28 MB.

After some digging I found this identical part in bootimg-efi and
bootimg-pcbios.

    blocks = int(out.split()[0])

    extra_blocks = part.get_extra_block_count(blocks)

    if extra_blocks < BOOTDD_EXTRA_SPACE:
        extra_blocks = BOOTDD_EXTRA_SPACE

    blocks += extra_blocks
    logger.debug("Added %d extra blocks to %s to get to %d total
blocks",
                 extra_blocks, part.mountpoint, blocks)

So we calculate some extra blocks and if the extra blocks is less than
the requested extra space we add BOOTDD_EXTRA_SPACE.

Why the value of 16 MB.

My guess was that it is for forcing mkdosfs to do a fat16 and not a
fat12, it need minimum 16 MB

A quick test showed that 8 MB gives fat12 and 16 MB gives fat16.

clst@clst-linux:~$ mkdosfs -n test -C test.img $(( 4096 * 2 )) -v
mkfs.fat 4.1 (2017-01-24)
mkfs.fat: warning - lowercase labels might not work properly with DOS
or Windows
test.img has 64 heads and 32 sectors per track,
hidden sectors 0x0000;
logical sector size is 512,
using 0xf8 media descriptor, with 16384 sectors;
drive number 0x80;
filesystem has 2 12-bit FATs and 8 sectors per cluster.
FAT size is 8 sectors, and provides 2041 clusters.
There are 8 reserved sectors.
Root directory contains 512 slots and uses 32 sectors.
Volume ID is bbbd3650, volume label test       .


clst@clst-linux:~$ rm test.img 
clst@clst-linux:~$ mkdosfs -n test -C test.img $(( 4096 * 4 )) -v
mkfs.fat 4.1 (2017-01-24)
mkfs.fat: warning - lowercase labels might not work properly with DOS
or Windows
test.img has 64 heads and 32 sectors per track,
hidden sectors 0x0000;
logical sector size is 512,
using 0xf8 media descriptor, with 32768 sectors;
drive number 0x80;
filesystem has 2 16-bit FATs and 4 sectors per cluster.
FAT size is 32 sectors, and provides 8167 clusters.
There are 4 reserved sectors.
Root directory contains 512 slots and uses 32 sectors.
Volume ID is bc573a89, volume label test

So would a better solution not be to rename it to BOOTDD_MINIMUM_SIZE
or something like this, and change the code to something like below:


    blocks = int(out.split()[0])

    blocks += part.get_extra_block_count(blocks)

    if blocks < BOOTDD_MINIMUM_SIZE:
        blocks = BOOTDD_MINIMUM_SIZE

    logger.debug("Set %s to %d total blocks", part.mountpoint, blocks)

Can see the current behavior is pretty old - from 2014
https://git.yoctoproject.org/poky/commit/?id=df634f3b1e02aa18f84b4b74f13c7260a21691aa

Please comment about the BOOTDD_EXTRA_SPACE
What do you think about my proposal.

Regards
Claus

Re: [OE-core] Is BOOTDD_EXTRA_SPACE from misc.py used correctly?

[Khem Raj]

On 5/18/22 5:55 AM, Claus Stovgaard wrote:
> Hi folks.
> 
> I think the BOOTDD_EXTRA_SPACE is used incorrectly in bootimg-efi.py
> and bootimg-pcbios.py?
> 
> The background is that I am forced to create a rather small efi
> partition of 25 MB. Not a big problem I thought, as the kernel, plus
> initrd is only 12 MB. But the resulting partition was 28 MB.
> 
> After some digging I found this identical part in bootimg-efi and
> bootimg-pcbios.
> 
>      blocks = int(out.split()[0])
> 
>      extra_blocks = part.get_extra_block_count(blocks)
> 
>      if extra_blocks < BOOTDD_EXTRA_SPACE:
>          extra_blocks = BOOTDD_EXTRA_SPACE
> 
>      blocks += extra_blocks
>      logger.debug("Added %d extra blocks to %s to get to %d total
> blocks",
>                   extra_blocks, part.mountpoint, blocks)
> 
> So we calculate some extra blocks and if the extra blocks is less than
> the requested extra space we add BOOTDD_EXTRA_SPACE.
> 
> Why the value of 16 MB.
> 
> My guess was that it is for forcing mkdosfs to do a fat16 and not a
> fat12, it need minimum 16 MB
> 
> A quick test showed that 8 MB gives fat12 and 16 MB gives fat16.
> 
> clst@clst-linux:~$ mkdosfs -n test -C test.img $(( 4096 * 2 )) -v
> mkfs.fat 4.1 (2017-01-24)
> mkfs.fat: warning - lowercase labels might not work properly with DOS
> or Windows
> test.img has 64 heads and 32 sectors per track,
> hidden sectors 0x0000;
> logical sector size is 512,
> using 0xf8 media descriptor, with 16384 sectors;
> drive number 0x80;
> filesystem has 2 12-bit FATs and 8 sectors per cluster.
> FAT size is 8 sectors, and provides 2041 clusters.
> There are 8 reserved sectors.
> Root directory contains 512 slots and uses 32 sectors.
> Volume ID is bbbd3650, volume label test       .
> 
> 
> clst@clst-linux:~$ rm test.img
> clst@clst-linux:~$ mkdosfs -n test -C test.img $(( 4096 * 4 )) -v
> mkfs.fat 4.1 (2017-01-24)
> mkfs.fat: warning - lowercase labels might not work properly with DOS
> or Windows
> test.img has 64 heads and 32 sectors per track,
> hidden sectors 0x0000;
> logical sector size is 512,
> using 0xf8 media descriptor, with 32768 sectors;
> drive number 0x80;
> filesystem has 2 16-bit FATs and 4 sectors per cluster.
> FAT size is 32 sectors, and provides 8167 clusters.
> There are 4 reserved sectors.
> Root directory contains 512 slots and uses 32 sectors.
> Volume ID is bc573a89, volume label test
> 
> So would a better solution not be to rename it to BOOTDD_MINIMUM_SIZE
> or something like this, and change the code to something like below:
> 
> 
>      blocks = int(out.split()[0])
> 
>      blocks += part.get_extra_block_count(blocks)
> 
>      if blocks < BOOTDD_MINIMUM_SIZE:
>          blocks = BOOTDD_MINIMUM_SIZE
> 
>      logger.debug("Set %s to %d total blocks", part.mountpoint, blocks)
> 
> Can see the current behavior is pretty old - from 2014
> https://git.yoctoproject.org/poky/commit/?id=df634f3b1e02aa18f84b4b74f13c7260a21691aa
> 
> Please comment about the BOOTDD_EXTRA_SPACE
> What do you think about my proposal.
> 

I think in your case you can set BOOTDD_EXTRA_SPACE to 0 perhaps to get 
desired behavior. Your analysis is correct. BOOTDD_EXTRA_SPACE ensures 
that much of space it available, but perhaps what we need is minimum size.

> Regards
> Claus
> 
> 
> 
> 
> 
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#165852): https://lists.openembedded.org/g/openembedded-core/message/165852
> Mute This Topic: https://lists.openembedded.org/mt/91185286/1997914
> Group Owner: openembedded-core+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [raj.khem@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
> 

Re: [OE-core] Is BOOTDD_EXTRA_SPACE from misc.py used correctly?

[Claus Stovgaard]

On Wed, 2022-05-18 at 08:48 -0700, Khem Raj wrote:
> 
> 
> On 5/18/22 5:55 AM, Claus Stovgaard wrote:
> > 
> > So would a better solution not be to rename it to
> > BOOTDD_MINIMUM_SIZE
> > or something like this, and change the code to something like
> > below:
> > 
> > 
> >      blocks = int(out.split()[0])
> > 
> >      blocks += part.get_extra_block_count(blocks)
> > 
> >      if blocks < BOOTDD_MINIMUM_SIZE:
> >          blocks = BOOTDD_MINIMUM_SIZE
> > 
> >      logger.debug("Set %s to %d total blocks", part.mountpoint,
> > blocks)
> > 
> > Can see the current behavior is pretty old - from 2014
> > https://git.yoctoproject.org/poky/commit/?id=df634f3b1e02aa18f84b4b74f13c7260a21691aa
> > 
> > Please comment about the BOOTDD_EXTRA_SPACE
> > What do you think about my proposal.
> > 
> 
> I think in your case you can set BOOTDD_EXTRA_SPACE to 0 perhaps to
> get 
> desired behavior. Your analysis is correct. BOOTDD_EXTRA_SPACE
> ensures 
> that much of space it available, but perhaps what we need is minimum
> size.

Thanks for your quick reply Khem.

I guess I can set the BOOTDD_EXTRA_SPACE to a value where it can fit
with my needs.

Currently there will always be 16 MB of free space on a boot partition
for EFI and bios. If we switch to a minimum size we risk that there is
no free space on the partition. I don't know if it could be a issue,
but I don't think so.

If there is a consensus to go in my proposed direction I will make a
patch and send, but if you think that the change of strategy is wrong,
I will just solve it for me, and don't change the current way. (Guess
it is very seldom that you have an issue with not having space for 16
MB free space on a boot partition)


Regards
Claus