Cannot install from .ISO due to kernel mismatch

Hello all,

I wanted to try out fangtooth over christmas and found a bug, that was probably already introduced on 24.10.

System: see my signature for details

Steps to reproduce:

  • write .iso of either TrueNAS SCALE version 24.10.1 or version 25.04.0 to USB stick with balenaEtcher
  • boot from USB stick
  • select Install/Upgrade
  • select previous “boot-pool” HDD as destination (sdg3)
  • message “Formatting disk sdg”, then error
[0%] Warning: unable to wipe ZFS label from sdg3: The ZFS modules cannot be auto-loaded. Try running "modprobe zfs" as root to manually load them.
  • popup box shows
Installation Error: Command zpool create -f -o ashift=12 -o cachefile=none -o compatibility=grub2 -O acltype=off -O canmount=off -O compression=on -O devices=off -O mountpoint=none -O...
  • going to shell as root and trying “modprobe zfs” gives another error
modprobe: FATAL: Module zfs not found in directory /lib/modules/6.6.32-production+truenas
  • “ls” shows that the installer does have a directory /lib/modules/6.12.5-production+truenas, but not /lib/modules/6.6.32-production+truenas
  • “dmesg” shows that the actual kernel loaded is “Linux version 6.6.32-production+truenas …”

So, essentially the live system boots a 6.6.32 kernel, which then fails to auto-load modules because the matching modules cannot be found. Somewhere in the .ISO there must be a mismatch of kernel versions. Or maybe the 6.6.32 kernel image slipped onto the image.

These work-arounds helped me to mitigate:

  • using .update files to update (as I discovered this file in the .ISO :man_shrugging:)
  • using 24.04 installer to downgrade, then use .update to get back to 24.10.1

It would still be good to have this fixed in the installer. I’ll try to figure out jira and report the bug over there as well… (for version 24.10.1)

Please ignore this post for the moment. This bug may be an artefact from using balena Etcher, i.e. it’s possible I may not have completely overwritten the USB stick. I’ll update.

Ok, the problem was homegrown due to the fact that I had two USB sticks: one internal sticking on Terramaster motherboard, another one external.

I had specified to boot from the external USB via BIOS. But what then happened was unexpected. The live linux environment pulled the rootfs from the other (!) internal USB stick. So, kernal was from external USB, but /lib/modules from internal. => This gave confusing error messages.

Lesson learned: Remove the internal USB stick from your Terramaster system. It really IS that useless.

Upside: My new PiKVM arrived and now I can upload new ISO images using the web interface. USB sticks are history at least on this system!!

Thanks for returning to post the conclusion, and a Happy New Year.