Hello Everyone!
I’m new to TrueNAS, switching from Synology. I’ve just build a server compsed of:
intel i5-12500
AsRock Z690M-ITX/ax M/B
Silicon Power RAM 32GB (3200)
boot disk M.2 SATA Lite-ON 128GB
(temporarily) 2x 2TB WD RED HDDs (planned 3x 4TB WD RED )
I have installed a fresh TrueNas Scale 24.04.02.01 (I tried also 24.04.00 and even 24.10 BETA) for the first time. After a successful instalation, tryng to first boot the system I’m stuck on “Loading initial ramdisk …” message. I checked out the forum and found a few topics on this but none of them solved my issue.
To sumarize my actions so far (based on other related forum topics):
I do not have any serial port on the M/B (and/so nothing is connected to it);
Console activation command (or whatever its called) is not present in GRUB setup (also confirmed to be deactivated in TrueNAS settings);
I do not have any additional GPU and I’m not using dummy HDMI plug;
I performed memtest with no errors in result;
I added: echo ‘test2’ in GRUB after initrd - it shows up on the screen during boot so I guess initrd was performed OK;
I tried to see some debugging on the screen during boot (added loglevel=8 and debbuging in GRUB) but nothing shows up. Unless I misunderstand and it does not work that way?;
I tried to boot the system with all peripherials (HDMI screen, usb keyboard dongle) disconnected;
None of the above helps. I managed to boot the system with acpi=off added in GRUB but as I read it’s not a real solution for this problem.
Some WD RED 4TB drives are SMR and are completely and absolutely unsuitable for use in a ZFS redundant vDev. (Some are CMR drives, and these were later rebranded to WD Red Plus.) You need to check your exact model to see if they are suitable or not. Same probably applies to 2TB drives.
Start install afresh.
Set BIOS to UEFI boot only.
Create a UEFI-based TN Scale installer flash drive and install from it.
The WD REDs I have are all CMR for sure. The 2TB are almost 10y old (so before WD introduced SMR into RED series) although still OK and to be used only for testing and migration from my old server, and the 2x 4TB are WD Red Plus indeed (I didn’t mentioned that earlier). I still need to buy one more 4TB HDD but maybe I’ll go for Seagate Ironwolf this time.
For the Truenas Scale installation, I did it with UEFI boot only, and the installation process itself goes smoothly ending up “successfully”. Unfortunately the first system boot after installation still stuck on “Loading initial ramdisk”.
I played around with motherboard ACPI settings, but that didn’t change anything.
Sorry for possibly dumb question. By checking hash you mean e.g. SHA256 Verification? If so, I just did that with the iso file I used to prepare my installation USB stick - this verification was successful.
Just be sure that the Ironwolf is at least as big as the WD Red Plus, as even one block smaller might stop you adding the drive without destroying and recreating the pool.
Thanks for pointing that out! I was not aware of that - I’ll check.
Actually my plan is to initially create the RAIDZ1 pool with 2x2TB + 1x4TB, migrate all the data from my old server and then replace the 2x2TB with 2x4TB one by one rebuilding the pool. I hope my pool will then expand. Is my thinking correct?
Small update on my boot issue:
I forgot to mention earlier that my M/B is updated to the latest BIOS version (19.02)
I tried to install TrueNAS Scale on one of the HDDs just for testing. Again, the installation was smooth, but it doesn’t boot properly.
I tried to install Debian 12 on this computer (on M.2 SATA SSD) and the same issue occurred. I was not able to even begin the installation process without adding the acpi=off option in the install GRUB and GRUB installation failed along the process as well.
I tried to do some troubleshooting on acpi according to this guide: https://wiki.ubuntu.com/DebuggingACPI
the result was that I could only launch TrueNAS with acpi=off not even acpi=ht. The UBUNTU guide says:
“If acpi=off works and acpi=ht fails, then the issue is in the ACPI table parsing code itself, or perhaps the SMP code.”
To be honest, I have no clue what to do with this knowledge then.
I saw somewhere that resetting CMOS may help with some compatibility issues in case of changing processor. As I’m using a second hand MoBo I cleared the CMOS memory. It helped somehow …but not for long.
I managed to go past the “Loading initial ramdisk…” message once, but then the boot was stuck on something like “VT-d active for gfx access”. Unfortunately after reboot it was stuck in the initial place and I was not able to reproduce it any more - even with subsequent CMOS resets.
EDIT1:
I went down the “VT-d” trace and found BIOS option to disable it. With that i was able to go past the “Load initial ramdisk…” finally. The thing is i was stuck with bunch of errors related to i915. With help of google i found a walkaround with kernel setting i915.modeset=0 in GRUB. This basically solved my issue and now I’m able to boot the system correctly!
The only thing is, I’m not exactly sure if and how using i915.modeset=0 will impact the performance of the server in the future.
My experience with the same problem was following:
all avaliable info about serial ports/console issues is misleading (also, it appears that in recent versions of truenas this suspected setting is removed from grub)
“Loading initial ramdisk” is basically the last message on your terminal before actuall boot process begins so it does not have any relationship with ramdisk itself
in my particular case, problem was related to video adapter and in particular differences in how video adapter is handled in UEFI environment, once I resolved the issue, machine booted correctly (translated: it was GPU issue because truenas did not know how to handle video output - but this is hardware issue, same thing happened with other OSes I tried, including debian and windows)
So, in my case this was UEFI related hw problem, not a truenas issue. Your mileage may vary.
I’m not sure how this can be a hardware issue where no hardware or configuration changes were made, and:
Prior to the upgrade there was no issues with the TN install
Install failure only occurs with the in-GUI upgrade path
Upgrade using clean install with a downloaded ISO is successful
Subsequent upgrades were successful (24.04.2.1 —> 24.04.2.2)
Others have reverted back to the previous builds with the same hardware and had successful installs.
Logically, nothing about this issue relates to the hardware in my humble opinion as nothing about the hardware has changed between successful installs and unsuccessful installs. The only changes were the update, and only it seems, via the in-GUI upgrade path.
I totally agree with you. Installing the same failing version from scratch and importing the previously working configuration is fine. Even new updates just work.
The only problem happens when updating in some cases. I suffered this twice with this same error, and my system is quite standard (HP Proliant MicroServer with Xeon E3 1220 and 16 GB of RAM). And it happened with USB or SSD system drive. I really don’t think it’s a HW problem…
