Re: simplify ext4_sb_read_encoding regression

[Gabriel Krisman Bertazi <krisman@collabora.com>]

"Stephen E. Baker" <baker.stephen.e@gmail.com> writes:

> On Sat, Jun 4, 2022 at 8:11 PM Stephen E. Baker
> <baker.stephen.e@gmail.com> wrote:
>>
>> I reached out on the archlinuxarm IRC room and amstan offered the use
>> of his device.
>>
>> When he boots my image he sees:
>> "EXT4-fs (sda2): can't mount with superblock charset: utf8-12.1.0 not
>> supported by the kernel. flags: 0x0."
>
> At amstan's request I created a new root filesystem without casefold,
> and created a loop device with casefold enabled. I am able to boot
> with that filesystem.
>
> zgrep UNICODE /proc/config
> CONFIG_UNICODE=y
> CONFIG_UNICODE_UTF8_DATA=y
> CONFIG_UNICODE_NORMALIZATION_SELFTEST=m
>
> mount /dev/loop0p1 /mnt
> [ 679.358591] EXT-fs (loop0p1): can't mount with superblock charset:
> utf8-12.1.0 not supported by the kernel. flags: 0x0

That is great news.  It should allow us to do more investigation.  This
message can unfortunately come from a few error cases, but, most likely,
it is from a failure to get the utf8_data_table symbol.

Since you don't need the module to boot this kernel anymore now that
your rootfs is no longer casefolded, can you try building with
CONFIG_UNICODE=m, modprobe the module, and see if you can mount
/dev/loop0p1 successfully?  If it works, we should be able to discard
the steps being done to generate the bootable uimg and the flashing from
the equation being done at [1].

I've built a vanilla aarch64 kernel and ran over qemu, but I haven't
been able to reproduce it, or notice anything out of the ordinary in the
symbols.  It makes this bug quite puzzling at the moment.

[1] https://github.com/archlinuxarm/PKGBUILDs/blob/30c181baea493effe3bea7b3a2c3ec6ee62b41ae/core/linux-aarch64/PKGBUILD#L201-L228.

-- 
Gabriel Krisman Bertazi