Kernel panic with latest TrueNAS SCALE

I am playing with the latest TrueNAS SCALE 24.10.2 (investigating whether I can upgrade from CORE).

  • I did a completely fresh install on a new drive
  • Did basic network/service configuration, imported pools, conf. SMB shares
  • Played around with docker/container and configured pihole

Everything worked perfectly, I was already in a state of happiness and confident to make the move swiftly. However, at some point I got problems with DNS resolution, had the impression it had to do with the mDNS-service of TrueNAS interfering so I turned it off. After that I decided to reboot the NAS. However, it never came up again… Looking at the console, I observe a “Kernel panic - not syncing: No working init found.” I attach the screenshot of the console with additional logs.

When I chose the “Advanced options” within grub and choose the other boot-option (+debug) there, TrueNAS boots fine again. This is how it works now. But another reboot brings back the Kernel panic - it’s reproducible.

Hardware is
Intel(R) Xeon(R) CPU E3-1270 v3 @ 3.50GHz
ASRock Rack E3C226D2I
16GB EEC RAM
a bunch of Toshiba HD

hw-setup is running for years without problems.

Please, do you have any ideas about what could the problem be here? I really would like to switch to SCALE, when it boots it’s fantastic! :slight_smile:

Kind Regards

Can you elaborate on what you did here?

Maybe this is something that can be fixed if you just save a config and reinstall TrueNAS.

Sure. I’m talking about Network/Global Konfiguration/Service Announcement. Here I disabled mDNS and also NetBIOS-NS.

I tried enabling both again but the situation persists. The system kernel panics right at the beginning of the boot process.

I also have similar since the latest update.

Feb  2 00:05:55 freenas kernel:  <TASK>
Feb  2 00:05:55 freenas kernel:  dump_stack_lvl+0x47/0x60
Feb  2 00:05:55 freenas kernel:  warn_alloc+0x165/0x1e0
Feb  2 00:05:55 freenas kernel:  ? srso_alias_return_thunk+0x5/0xfbef5
Feb  2 00:05:55 freenas kernel:  ? __alloc_pages_direct_compact+0xb3/0x2c0
Feb  2 00:05:55 freenas kernel:  __alloc_pages_slowpath.constprop.0+0xd0c/0xe20
Feb  2 00:05:55 freenas kernel:  ? srso_alias_return_thunk+0x5/0xfbef5
Feb  2 00:05:55 freenas kernel:  __alloc_pages+0x32b/0x350
Feb  2 00:05:55 freenas kernel:  alloc_page_interleave+0xf/0x80
Feb  2 00:05:55 freenas kernel:  atomic_pool_expand+0x74/0x1f0
Feb  2 00:05:55 freenas kernel:  __dma_atomic_pool_init+0x49/0xb0
Feb  2 00:05:55 freenas kernel:  dma_atomic_pool_init+0x13d/0x160
Feb  2 00:05:55 freenas kernel:  ? __pfx_dma_atomic_pool_init+0x10/0x10
Feb  2 00:05:55 freenas kernel:  do_one_initcall+0x5d/0x320
Feb  2 00:05:55 freenas kernel:  kernel_init_freeable+0x320/0x470
Feb  2 00:05:55 freenas kernel:  ? __pfx_kernel_init+0x10/0x10
Feb  2 00:05:55 freenas kernel:  kernel_init+0x1a/0x1c0
Feb  2 00:05:55 freenas kernel:  ret_from_fork+0x34/0x50
Feb  2 00:05:55 freenas kernel:  ? __pfx_kernel_init+0x10/0x10
Feb  2 00:05:55 freenas kernel:  ret_from_fork_asm+0x1b/0x30

Try booting from a different boot device. Maybe your current one is partially corrupt or failing.

The snippet you posted looks different.

Post your own thread and include full details about your hardware, software and any events leading up to the crash and maybe someone here can offer some advice.

Thanks for this idea. Would you think this can still be an issue even if a scrub for the particular boot-pool runs through without problems?

At this point, I see it as a good option to check.

But before that I would run memtest86 overnight, just because it’s so little effort to do. I would do this even though you have ECC RAM, just in case something funky is going on in terms of stability. Otherwise a possible issue with the RAM could carry the issues over to the new drive.