I have installed the latest version of truenas fangtooth on my server today (minor point release - or so I thought).
Following the upgrade I am recieving the following error messages during boot and the machine does not come online.
There has been no changes hardware wise and the machine was fresh installed with the 25.04 release with upgrades done normally through the web interface to 25.04.1 and the now 25.04.2 release.
The machine was running without any issues before the upgrade attempt.
I do not have the exact model numbers etc of the MB etc but I can confirm that the system has the following specs:
Intel i7 11th gen
68GB Ram
5x 3TB sata drives (data pool)
1x 512GB nvme (apps and config)
1x 1TB nvme (vm passthrough)
1x 250GB ssd (os drive)
Not sure what other information might be needed.
Boot to previous boot environment, 25.04.1. You can try deleting the 25.04.2 boot environment and trying the upgrade again.
68 GB Ram, is that a mistake?
Sorry 64GB (typing on the phone is a little wonky)
I have tried both boot environment options and they both give exactly the same error.
I can attach screenshots as well for the precious environment, but its the same
I think your boot device may have died if you can’t boot to a previous version. Other issues could be RAM or CPU. You would boot a live Linux USB and run CPU stress tests and a RAM test like Memtest86+
You can try powering down and reseat RAM also.
Do you have a recent backup of the system configuration file? You can try downloading 25.04.2 ISO, image to USB and use that to boot and do a fresh install. Then you reload the configuration.
Maybe it’s just not my day but I am struggling to find a proper guide on using the tar file to restore my system on the new boot drive installation.
I have the pumba-25.04.1-20250804144720.tar file as provided to me before the update (it does include the secret seed also).
And once I do a fresh install, how do I restore the tar file?
Apologies if this is documented clearly somewhere I don’t seem to find the instructions, is there perhaps a link you can share?
Do I just “Upload” on this screen? => Managing the System Configuration | TrueNAS Documentation Hub
System menu, General Settings, then blue Manage Configuration button on upper right. Choose Upload File. I think it will accept the TAR file. I haven’t done one with the secret seed included. Screenshot from Fangtooth 25.04.1 version
Hardware: ASUS B560-PLUS (BIOS 2001), Intel Core i7-11700, 64GB Corsair DDR4, Integrated Graphics (iGPU)
Status: Resolved
TL;DR: The problem was not a dead boot drive. The issue was a severely fragmented memory map caused by the Intel iGPU’s memory reservation, which prevented the Linux kernel from initializing. After extensive testing, the solution was a single BIOS setting: Reducing the iGPU Memory allocation from 1024MB to 128MB. My original boot drive is functioning perfectly in a new mirrored setup and did not need to be replaced.
After an update, my system would fail to boot any Linux-based ISO (including the TrueNAS-SCALE installer and recovery media), throwing two critical errors:
error: Out of Memory/dev/root: Can't open blockdevThis error occurs in the very first stages of the kernel boot process, long before it tries to access the root filesystem on the boot drive. The “Out of Memory” error is misleading; it does not refer to a lack of physical RAM (I have 64GB). Instead, it means the kernel’s early boot allocator could not find a large enough contiguous block of memory in the lower physical address space to load its essential structures and the initramfs.
The culprit was my 11th Gen Intel CPU’s integrated graphics (iGPU). The BIOS was reserving a large, multi-gigabyte region for the iGPU’s frame buffer. This reservation fragmented the memory map, creating a “hole” that the Linux kernel’s boot-time allocator could not navigate.
Think of it like this: The kernel needs a long, continuous parking space right at the entrance (low memory) to unload its initial cargo. The iGPU was parking a huge trailer across multiple spots, making it impossible for the kernel to find the space it needed.
The error /dev/root: Can't open blockdev naturally points toward a storage issue. This led to the initial advice that my boot drive was dead and needed replacement. However, this is a secondary symptom.
Why it happens: The kernel panics because it cannot allocate the memory needed to initialize its subsystems, including those responsible for identifying hardware like SATA controllers and NVMe drives. The panic occurs when it fails to find the root device because the necessary drivers and processes never loaded correctly due to the memory allocation failure. The boot drive was never the problem; it was a victim of the earlier memory initialization failure.
Before finding the solution, I performed an exhaustive series of tests and fixes, all of which failed to resolve the issue. This process is important to document so others know what to skip.
Above 4G Decoding.memmap=2G$0x200000000 and limiting the kernel’s view with mem=62G. These helped diagnose the issue but were not a clean fix.After all else failed, the solution was one specific BIOS setting:
Path in BIOS: Advanced > System Agent (SA) Configuration > Graphics Configuration > DVMT Pre-Allocated
Change: Set from 1024M to 128M.
Why This Worked:
The DVMT (Dynamic Video Memory Technology) pre-allocation reserves a fixed, contiguous block of system RAM for the iGPU at boot. By reducing this demand from 1GB to 128MB, the BIOS creates a much smaller “reservation” in the memory map. This leaves a large enough contiguous block of free memory in the critical lower address range for the Linux kernel to successfully initialize itself. Once the kernel is up and running, it can dynamically allocate more video memory to the iGPU as needed, so reducing this pre-allocated value does not impact performance for tasks like Plex transcoding.
If you encounter a similar “Out of Memory” error followed by a kernel panic during boot, especially on a system with an Intel iGPU and a lot of RAM, do not assume your boot drive is dead as a first step.
The Number One Setting to Check:
Navigate your BIOS menus and find the DVMT Pre-Allocated or iGPU Memory Allocation setting. Reduce it to its minimum value (usually 64MB or 128MB). This was the definitive fix after every other recommended step failed.
My original boot drive with the update is running, and the system is completely stable. I hope this detailed explanation, and more importantly, the correction about the key setting, helps others who find themselves in this frustrating situation.
You might want to use Report a Bug in the TrueNAS GUI, even though you have fixed this. This sounds like something that maybe need fixing on the Linux / TrueNAS side. The full debug dump would help.
On upper right of TrueNAS GUI is a smile icon for Feedback / Report a Bug.