Using zfsbootmenu breaks my laptop's touchpad

[wheeeyeyeye]

ZFSBootMenu build source

Release EFI

ZFSBootMenu version

ca3a81b

Boot environment distribution

CachyOS (arch)

Problem description

Problem: using zfsbootmenu breaks the touchpad on my laptop (ASUS ROG G14)

Symptoms:
Booting via zfsbootmenu results in this 1 logged error:

[    0.437320] usbcore: registered new device driver usb
[    0.443726] i2c_designware AMDI0010:00: Unknown Synopsys component type: 0xffffffff
[    0.453454] i2c_designware AMDI0010:01: Unknown Synopsys component type: 0xffffffff
[    0.460477] i2c_designware AMDI0010:02: Unknown Synopsys component type: 0xffffffff
[    0.466623] i2c_designware AMDI0010:03: Unknown Synopsys component type: 0xffffffff
[    0.466634] EDAC MC: Ver: 3.0.0

The touchpad works when booting via Refind.

I have tried following the instructions here: #347 and modifying my kernel command line accordingly:

noresume init_on_alloc=0 rw spl.spl_hostid=xxx initcall_blacklist=dw_i2c_init_driver,dw_i2c_driver_init

When booting with the modified command line, the Synopsys error disappears, but the touchpad is still not discovered.

I have also tried i2c_designware_pci.blacklist=yes with no different result.

Steps to reproduce

Install zfs on / and pacstrap CachyOS.
Install zfsbootmenu.
Install refind.
Boot using refind and touchpad will work.
Boot using zfsbootmenu and touchpad will not work.

[zdykstra]

Did you add those options to the KCL of your boot environment or to ZFSBootMenu? They need to be added to ZBM's KCL to keep it from trying to initialize the touchpad.

[wheeeyeyeye]

So this is the output of zbm-kcl:

❯ zbm-kcl
noresume init_on_alloc=0 rw spl.spl_hostid=5678f354 initcall_blacklist=dw_i2c_init_driver,dw_i2c_driver_init

My kernel flags in the config.yaml file for ZBM looks like this:

Kernel:
  CommandLine: ro quiet loglevel=0 zbm.import_policy=hostid
  Prefix: vmlinuz

[zdykstra]

So this is the output of zbm-kcl:

❯ zbm-kcl
noresume init_on_alloc=0 rw spl.spl_hostid=5678f354 initcall_blacklist=dw_i2c_init_driver,dw_i2c_driver_init

My kernel flags in the config.yaml file for ZBM looks like this:

Kernel:
  CommandLine: ro quiet loglevel=0 zbm.import_policy=hostid
  Prefix: vmlinuz

That means it's been added to your BE's kernel, in effect disabling it entirely in the booted OS. You'll need to edit either the ZBM EFI bundle or set the appropriate command line in rEFInd, depending on how you boot ZBM itself. After that, remove the flags from the org.zfsbootmenu:commandline property.

[wheeeyeyeye]

That makes sense. This is pushing the limits of my knowledge.

Does editing the ZBM EFI bundle correspond to editing the ZBM configuration file ( CommandLine: ro quiet loglevel=0 zbm.import_policy=hostid initcall_blacklist=dw_i2c_init_driver,dw_i2c_driver_init) and regenerating ZBM?

I have removed it from the BE KCL.

I currently boot directly into ZBM when testing this without using Refind as an intermediary. Do I need to setup ZBM with any special KCL when doing setup with efibootmgr?

[zdykstra]

zbm-kcl can also edit the embedded EFI KCL, you'll just need to pass it the right flag and the path to the EFI image. It'll embed a new one in there for you when you quit out of your editor. Alternatively, yes, you can add it to the generate-zbm config and regen the image.

[wheeeyeyeye]

I might have misunderstood what actions are needed. My current environment looks like this:

❯ zbm-kcl /efi/EFI/ZBM/vmlinuz.EFI
ro quiet loglevel=0 zbm.import_policy=hostid initcall_blacklist=dw_i2c_init_driver,dw_i2c_driver_init

❯ zbm-kcl
noresume init_on_alloc=0 rw spl.spl_hostid=5678f354

I boot into this without using Refind. Now I get the errors in the root OS, and touchpad is not working.

❯ dmesg | grep -i i2c
[    0.445236] i2c_designware AMDI0010:00: Unknown Synopsys component type: 0xffffffff
[    0.454897] i2c_designware AMDI0010:01: Unknown Synopsys component type: 0xffffffff
[    0.461375] i2c_designware AMDI0010:02: Unknown Synopsys component type: 0xffffffff
[    0.467925] i2c_designware AMDI0010:03: Unknown Synopsys component type: 0xffffffff

[zdykstra]

Double check if the i2c drivers are built-in or a module. If it's a module, you'll have to blacklist it. Alternatively, you can try booting one of our binary releases images to see if a different ZBM kernel version helps.

I don't have any equivalent hardware to help test on my end. The end goal though is to stop ZBM's kernel from intializing the hardware so it's unmolested by the time the final kernel boots. You might have to blacklist more drivers for your particular hardware; lsmod can help identify driver dependencies.

[wheeeyeyeye]

They are built in on CachyOS according to /proc/config.gz. I just changed to ZBM 3.0.1 with no difference.

So when editing the BE's KCL, it works in blacklisting the driver as it removes the error message when booting. However, the touchpad is still broken (or just fully unable to load due to the blacklist).

When editing the ZBM KCL, it has no effect and the driver is still loaded into the BE. The error message is still there when booting the BE.

[wheeeyeyeye]

Also found this thread of more people having the same problem: https://community.frame.work/t/touchpad-mouse-not-recognized-arch-linux-amd-13/48704/15

[Adito5393]

I also had this issue with a new MSI laptop. Got fixed by using the refind config.

cat << EOF > /boot/efi/EFI/zbm/refind_linux.conf
"Boot default"  "loglevel=7 zbm.timeout=60 initcall_blacklist=dw_i2c_init_driver,dw_i2c_driver_init"
"Boot to menu"  "quiet loglevel=0 zbm.show initcall_blacklist=dw_i2c_init_driver,dw_i2c_driver_init"
EOF

[bnuuydev]

This worked for me using Arch on the FW13, by adding the initcall_blacklist parameter to ZBM :)

[wheeeyeyeye]

cat << EOF > /boot/efi/EFI/zbm/refind_linux.conf
"Boot default" "loglevel=7 zbm.timeout=60 initcall_blacklist=dw_i2c_init_driver,dw_i2c_driver_init"
"Boot to menu" "quiet loglevel=0 zbm.show initcall_blacklist=dw_i2c_init_driver,dw_i2c_driver_init"
EOF

Nothing else changed?

[wheeeyeyeye]

This did not fix the problem for me. Same thing when fixing refind.

[ahesford]

This is not really a ZFSBootMenu bug, but a question of how you can get any Linux kernel to ignore the appropriate device driver at boot. Alternatively, you can figure out how to make the device driver survive a kexec.

Moving this to a discussion if people are interested in exploring the options.

[Peter4223]

tl;dr:
The precompiled EFI release from ZFSBootMenu official github page works for me, the generate-zb / CachyOS version does not.
With the precompiled release, none of configuration changes mentioned above were necessary.

To add some more information after encountering this issue and poking at it with a fresh install of cachyos:.
I'm not that deep into the internals, so my apologies if some of this is "obvious" (or partially wrong). It at least helped me to understand a bit on what is going on and solve my problem at hand.

Neither generate-zbm nor the version from cachyos/zfsbootmenu has the touchpad working automatically, not even with the initcall_blacklist settings above. I've unsuccessfully tried to blacklist the i2c_designware_platform module as well.

Band-aid to make the touchpad work until the next reboot:

echo "AMDI0010:00" | sudo tee /sys/bus/platform/drivers/i2c_designware/bind
echo "AMDI0010:01" | sudo tee /sys/bus/platform/drivers/i2c_designware/bind
echo "AMDI0010:02" | sudo tee /sys/bus/platform/drivers/i2c_designware/bind
echo "AMDI0010:03" | sudo tee /sys/bus/platform/drivers/i2c_designware/bind

i.e. use the AMDI0010:xx numbers from your dmesg error message.

• 01 for FRMW0004:00 32AC:0006 Wireless Radio Control / FRMW0004:00 32AC:0006 Consumer Control
• 03 for PIXA3854:00 093A:0274 Mouse / PIXA3854:00 093A:0274 Touchpad
• not sure about the others.

As far as I understand the underlying issue:

1. CachyOS builds the modules for i2c_designware directly into the kernel.

• CONFIG_I2C_DESIGNWARE_PLATFORM=y
• i.e. "modprobe -r i2c_designware_platform" returns modprobe: FATAL: Module i2c_designware_platform is builtin.

2. generate-zbm compiles the current kernel into the ZBM efi file, which means the driver is added as well and ZBM is able to control this device.

3. But the touchpad is not used -> the kernel sends the device to sleep.

4. Before the kexec hand-off from ZBMs kernel to cachy's kernel, the devices should've been woken up again. But they are not (in time), which causes the dmesg error. The kernel will not try again, this leaves the touchpad in an unusable state.

Not sure if this is something that has to be fixed by cachyos, or actually by the driver / kernel developers.

I've added this here, because it was one of the first places I found while looking at the issue, so hopefully it saves others a bit of time.