On Wed, Mar 03, 2021 at 08:34:23AM -0800, Khem Raj wrote: > On Wed, Mar 3, 2021 at 8:16 AM Martin Jansa <martin.ja...@gmail.com> wrote: > > > > 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, > > On Tue, Mar 2, 2021 at 2:43 PM Alexander Kanavin <alex.kana...@gmail.com> > > wrote: > >> > >> On Tue, 2 Mar 2021 at 14:26, Colin Finck <c.fi...@enlyze.com> wrote: > >>> > >>> On Mon, Mar 1, 2021 at 05:58 PM, Alexander Kanavin wrote: > >>> > 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 > >> > >> > >> > > > > > >
signature.asc
Description: PGP signature
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#148895): https://lists.openembedded.org/g/openembedded-core/message/148895 Mute This Topic: https://lists.openembedded.org/mt/80974296/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
