Sounds like a major regression in the kernel if you ask me.

I have little time to investigate this myself. If you're going to file a bug against mkinitcpio, you really need to dig into this yourself and find out where it actually fails.

Dave,

thanks for the reply. i can take the time to test, but i dont know how mkinitcpio works. im actually reading the script now trying to figure it out. But i wouldnt count on it :(
i didnt know filing a bug report meant actually having to fix things. i found a problem. reported it! and of course im willing to help test. or should i just wait till this actually hits you?

i got in contact with the patch submitter and he is trying to chip in too.

also i forgot to mention: adding fs-ext4 to the modules list in mkinitcpio.conf fixes the problem.

I'm not asking for a fix, I'm asking for more detail in your bug report. Most of what's here is about the kernel change, but you're filing against mkinitcpio without much mention of it. What does the backup image contain? What is your /etc/mkinitcpio.conf? Perhaps you have some verbose output to attach...


If you want some direction through the mkinitcpio codebase, the bulk of the module handling is in add_module() in the functions file. You'll see that modinfo is used to resolve aliases and parse filepath/dependencies/firmware. Soooo how does modinfo behave on its own? What does 'modinfo ext4' do?

and FWIW, the image I generate looks fine. kmod tools all work just fine, too.

So I have tracked it down and the bug is mine. The problem is that while I added extra aliases and caused request_module to use them, I failed to take into account that there were other uses of the existing module aliases for filesystems in the kernel.

mkinitcpio is one of those existing users.

The problem case is having an ext3 root filesystem and using the ext4 module. So I am going to readd the MODULE_ALIAS("ext3") to the ext4 module, and for all of the other similar fileystems.

While tracking this down I realized that mkinitcpio is going to want to use the new aliases. So I expect you will want to apply the following patch. But no rush.

Hopefully my description and the patch below are enough to describe what was going on and what happened.

I had asked Tomas to get us in touch because I wasn't at all certain what mkinitcpio in Arch linux was doing.

diff --git a/install/autodetect b/install/autodetect
index 907a85a..982ef1c 100644
--- a/install/autodetect
+++ b/install/autodetect
@@ -9,6 +9,10 @@ build() {

# treat this as an alias, since ext3 might be aliased to ext4.
IFS=$'\n' read -rd '' -a resolved < \
+ <(modprobe -d "$_optmoduleroot" -S "$KERNELVERSION" -R "fs-$1" 2>/dev/null)
+
+ # treat this as an alias, since ext3 might be aliased to ext4.
+ IFS=$'\n' read -rd '' -a resolved < \
<(modprobe -d "$_optmoduleroot" -S "$KERNELVERSION" -R "$1" 2>/dev/null)

for r in "${resolved[@]}"; do

Yup, that all makes sense. Thanks Eric.

Actually, I don't quite understand the patch -- specifically, the need to resolve *twice*. If I re-add your aliases, then kmod writes a module.alias file that looks like:

alias fs-ext4 ext4
alias ext3 ext4
alias ext2 ext4
alias fs-ext3 ext4
alias fs-ext2 ext4

So whitelisting "ext2" in the autodetect hook would call "add_if_avail ext2", which would call "modprobe -R fs-ext2", which yields "ext4".

Isn't the only needed change here just to prefix "fs-" when resolving the filesystem name to a module?

edit: duh... doing that alone wouldn't be backwards compatible.