I recently upgraded one of my TrueNAS systems from CORE (13.0-U6.7) to SCALE (25.04.1 Fangtooth.)
No issues encountered during the upgrade process. (Thanks iX developers!)
However, after completing the upgrade/install, I noticed that during the SCALE boot up sequence (which appears to be occurring post GRUB execution after the handoff to the linux O/S) that the boot console screen display resolution switches over to a much higher display resolution than it was originally when I was on CORE. Once there, it stays on this higher resolution output for the remainder of the start up sequence.
The increased boot console screen display resolution is causing an issue with my console display monitor (…which expects a lower resolution output for the console screen.)
Consequently, is there a way to tell Fangtooth to reduce the console display screen output resolution so it will be at the same resolution that it was in CORE?
Thanks for the suggestion @MikeO3. I’ll give that a try and see if it resolves my issue. I use a rack mounted display console here for my TrueNAS CLI, so replacing it would be an expensive option.
I remounted “boot-pool/ROOT/25.04.1/usr” as rw and edited “/usr/local/bin/truenas-grub.py” to add the following directives to the "config = " portion of the script:
Looked good, so I then remounted the boot-pool as rw and ran “update-grub” to update grub boot loader… Rebooted again with high hopes and… no joy. I’ll have to investigate further to see where I’m going off the rails. <grrr…>
I then did an “update-grub” to activate the changes in grub and we’re now in business.
I still need to rewrite the ‘advanced serial console’ portion of the truenas-grub.py script so that the serial portion runs correctly in “console” mode rather than “gfxterm” mode when serial output is selected (…though I don’t use a serial console here.) It would be nice to be able to input the console resolution parameters in the web UI and have it propagate over to the low level system. (Perhaps a feature request is up coming?)
I’m still not sure why the GRUB2 parameters devoted to this purpose (i.e.: GRUB_GFXMODE and GRUB_GFXPAYLOAD_LINUX) aren’t passing gfx cfgs over to the kernel. However, it all works now and my console monitor is running at the correct screen resolution.
OK… So after some time, review, wading through incomplete documentation (which always seems to lag behind the actual software), and some head scratching; I believe that I have found a better way to accomplish console video output resolution changes.
By using the existing TrueNAS middleware “midclt call system.advanced.update” call from the TrueNAS shell, you can pass the additional Linux kernel parameter “video=HxVx@R” into the system “kernel_extra_options” variable, which will change the console resolution at the next boot up without resorting to changing any system scripts (…which is probably a process heavily frowned upon by the TrueNAS folks.)
So for my console video application the middleware shell command is:
Since the middleware facility to add additional kernel options already exists in TrueNAS, it seems that it would be a fairly straightforward process to add an item to the advanced options section of the GUI to send Linux boot parameters over to the kernel without having to access the shell. That maybe an item the developers might consider in the future.
doesn’t seem to work for me when trying to remove these invalid amd entries GRUB_CMDLINE_LINUX_DEFAULT="libata.allow_tpm=1 amd_iommu=on iommu=pt kvm_amd.npt=1 kvm_amd.avic=1 intel_iommu=on zfsforce=1 nvme_core.multipath=N libata.allow_tpm=1 int el_iommu=on zfsforce=1 nvme_core.multipath=N"
They don’t seem to be in the db, but somehow keep getting added to the truenas.cfg file
All of those additional options are being added to the truenas.cfg file by the middleware python script at boot time. While I haven’t done any specific research on this, I would suspect that if your using a ‘non-AMD’ processor, those options are likely to be ignored by the kernel and thus have no effect on your system.
yes, they are hard coded into the python-grub script. config = [ f'GRUB_DISTRIBUTOR="{vendor}"', 'GRUB_TIMEOUT=10', 'GRUB_DISABLE_RECOVERY="true"', 'GRUB_CMDLINE_LINUX_DEFAULT="libata.allow_tpm=1 amd_iommu=on iommu=pt ' 'kvm_amd.npt=1 kvm_amd.avic=1 intel_iommu=on zfsforce=1 nvme_core.multipath=N' f'{f" {kernel_extra_options}" if kernel_extra_options else ""}"', ]
spew out a bunch of errors for me as mine is intel and I don’t want iommu passthrough.
would have thought they would test for the CPU environment and at least give iommu options.
Very interesting… I use an Intel i3-6100 cpu on my scale system here. I have the same grub default parameters defined by the middleware in my ‘GRUB_CMDLINE_LINUX_DEFAULT’. However, I have seen no iommu or kvm related errors as you describe occurring on that system during boot up.
I’m currently running TrueNAS community edition v25.10.0.1. Just some thoughts… could it be a software revision related issue? Could it be related to kvm being enabled by default in the BIOS?
<grrr…>