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ā¦>
Ok hereās the addendum to the āset console display resolutionā investigation:
First, I found that āGRUB_TERMINAL_OUTPUT=āconsoleāā needed to be set as āGRUB_TERMINAL_OUTPUT=āgfxtermāā to allow the grub GFX setups to have effect.
Afterwardsā¦ still āno cigarā on getting the linux kernel to recognize the grub GFX settings as directed.
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ā¦>