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

[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.