Thread (55 messages) 55 messages, 6 authors, 2021-03-09

Re: [OE-core] [PATCH 05/24] dosfstools: update 4.1 -> 4.2

From: Martin Jansa <hidden>
Date: 2021-03-03 16:58:34

On Wed, Mar 03, 2021 at 08:34:23AM -0800, Khem Raj wrote:
On Wed, Mar 3, 2021 at 8:16 AM Martin Jansa [off-list ref] wrote:
quoted
Steve, Colin:

keep in mind that this version also introduces some new restrictions, e.g. rpi-sdimg IMAGE_FSTYPE in meta-raspberrypi is now failing with:

mkfs.vfat: Label can be no longer than 11 characters

not sure how common this will be in other BSPs, but people might be surprised with such failures in LTS (like they were from the need to update oe-core/dunfell checkout to get python3targetconfig.bbclass recently when other layers started to require it).
thanks for this info Martin, 4.1 was released in 2017, so 4.2 is not a
bugfix only release by any means. It should be out of policy for LTS
backport. since we have different tools and techniques to partition
storage media
this tool plays a vital role and we should be very careful making
changes to it, especially in releases.
For reference this is the fix for meta-raspberrypi:
https://github.com/agherzan/meta-raspberrypi/pull/822
and this is the change in upstream which enforced this (it was checking
it in fatlabel for long time), but not in mkfs.vfat until recently:
https://github.com/dosfstools/dosfstools/commit/c598354

This mkfs.vfat error is relatively easy to spot (as it will usually
happen during build for us) and relatively easy to fix.

If I understood Colin correctly, then older dosfstools would break even
older partitions created by mtools (e.g. if you (let automatically) run fsck.vfat from
dunfell based image on device with /boot partition originally created with mtools
from warrior days), but it's not clear to me from what Colin said or from mtools mentions in:
https://github.com/dosfstools/dosfstools/releases/tag/v4.2

Some demonstration of this issue would be nice in the backport request
to persuade people it's worth an exception of backport policy or
maybe only the actual fix should be backported to v4.1.

Cheers,
quoted
On Tue, Mar 2, 2021 at 2:43 PM Alexander Kanavin [off-list ref] wrote:
quoted
On Tue, 2 Mar 2021 at 14:26, Colin Finck [off-list ref] wrote:
quoted
On Mon, Mar  1, 2021 at 05:58 PM, Alexander Kanavin wrote:
quoted
Can you send a followup patch please, on top of master-next?
Here we go: https://lists.openembedded.org/g/openembedded-core/topic/patch_dosfstools_build/81024606

Who decides about backporting or not backporting dosfstools 4.2 to Dunfell?
I can only stress again that a large number of devices in the wild are currently running on FAT boot partitions, and come with a dosfschk version that likes to destroy these boot partitions.

That would be Steve. It's best if you cherry-pick the needed patches into current dunfell tip, and send them here with [dunfell] prefix, adding the rationale to the commit messages.

Alex

Attachments

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help