"Stephen E. Baker" <baker.stephen.e@xxxxxxxxx> writes: > On Sat, Jun 4, 2022 at 8:11 PM Stephen E. Baker > <baker.stephen.e@xxxxxxxxx> 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
