On 2019-01-23, Ludovic Courtès wrote:
> Vagrant Cascadian <vagrant@debian.org> skribis:
>> After upgrading to linux-libre 4.20, and again tested with 4.20.3, an
>> aarch64 system failed to boot (using 4.19.10 worked fine):
>>
>> [    3.692351] device-mapper: ioctl: 4.39.0-ioctl (2018-04-03) initialised: dm-devel@redhat.com
>> ext2fs_check_if_mount: Can't check if filesystem is mounted due to missing mtab file while determining whether /dev/sda6 is mounted.
>> /dev/sda6: clean, 596262/6553600 files, 7663147/26214400 blocks
>> [    3.948786] EXT4-fs (sda6): Cannot load crc32c driver.
>> ERROR: In procedure mount:
>> In procedure mount: No such file or directory
...
>> Workaround or fix was to add to config.scm:
>>
>> (initrd (append (list "crc32c_generic" ... ) %base-initrd-modules))
>
> There are potentially two issues here:
>
>   1. Why wasn’t crc32c_generic.ko automatically pulled in by the initrd
>      build code?  Isn’t it a dependency of ext4.ko?

It is not a hard dependency, no. It's an optional feature only needed if
certain ext4 features are enabled on the filesystem (maybe metadata_csum
in this case?). So it's listed as a MODULE_SOFTDEP of ext4:

  fs/ext4/super.c:MODULE_SOFTDEP("pre: crc32c");


>   2. Is crc32c_generic built-in in our x86_64 kernel config?

On x86_64:

$ grep CRC32 /gnu/store/*linux-libre*4.20.4*/.config
CONFIG_CRYPTO_CRC32C=y
CONFIG_CRYPTO_CRC32C_INTEL=y
CONFIG_CRYPTO_CRC32=m
CONFIG_CRYPTO_CRC32_PCLMUL=m
CONFIG_CRC32=y
# CONFIG_CRC32_SELFTEST is not set
CONFIG_CRC32_SLICEBY8=y
# CONFIG_CRC32_SLICEBY4 is not set
# CONFIG_CRC32_SARWATE is not set
# CONFIG_CRC32_BIT is not set
CONFIG_LIBCRC32C=m

On aarch64:

$ grep CRC32 /gnu/store/*linux-libre*4.20.3*/.config
CONFIG_CRYPTO_CRC32C=m
CONFIG_CRYPTO_CRC32=m
CONFIG_CRC32=y
# CONFIG_CRC32_SELFTEST is not set
CONFIG_CRC32_SLICEBY8=y
# CONFIG_CRC32_SLICEBY4 is not set
# CONFIG_CRC32_SARWATE is not set
# CONFIG_CRC32_BIT is not set
CONFIG_LIBCRC32C=m

on aarch64 4.19.10 also contained:

CONFIG_CRYPTO_CRC32_ARM64_CE=y

Which is no longer available in 4.20.x upstream in commit
598b7d41e544322c8c4f3737ee8ddf905a44175e.

So my hunch is that crc32c-ce was used in 4.19.x, but 4.20.x needed the
generic crc32c implementation.


live well,
  vagrant