[SOLVED] Proxmox 8.1.3 SecureBoot and *BAD*gran size errors - how to fix?

B

bearhntr

Member
Sep 9, 2022
167
13
23
Atlanta, GA USA
I have an old Optiplex 7010 - which was my old Server 2016 Domain Controller. I have made a 2019 (may go to 2022) Proxmox VM on another host. Everything appears to be working, but I like to look at the syslogs to see if there are any potential "BOOM" items.

These items below jumped out and just curious if and what they are and if anything can be done to fix them?

The BLUE - says "Secure Boot disable", and I believe that the installation requires this - I am running version 8.1.3. Can I not enable Secure Boot with this version?

The RED - makes no sense to me at all - any ideas what it is or how to fix it?


Dec 20 10:22:28 pve02 kernel: secureboot: Secure boot disabled
Dec 20 10:22:28 pve02 kernel: SMBIOS 2.7 present.
Dec 20 10:22:28 pve02 kernel: DMI: Dell Inc. OptiPlex 7010/0KRC95, BIOS A29 06/28/2018
Dec 20 10:22:28 pve02 kernel: tsc: Fast TSC calibration using PIT
Dec 20 10:22:28 pve02 kernel: tsc: Detected 3392.389 MHz processor
Dec 20 10:22:28 pve02 kernel: e820: update [mem 0x00000000-0x00000fff] usable ==> reserved
Dec 20 10:22:28 pve02 kernel: e820: remove [mem 0x000a0000-0x000fffff] usable
Dec 20 10:22:28 pve02 kernel: last_pfn = 0x420600 max_arch_pfn = 0x400000000
Dec 20 10:22:28 pve02 kernel: total RAM covered: 16318M
Dec 20 10:22:28 pve02 kernel: gran_size: 64K chunk_size: 64K num_reg: 10 lose cover RAM: 6M
Dec 20 10:22:28 pve02 kernel: gran_size: 64K chunk_size: 128K num_reg: 10 lose cover RAM: 6M
Dec 20 10:22:28 pve02 kernel: gran_size: 64K chunk_size: 256K num_reg: 10 lose cover RAM: 6M
Dec 20 10:22:28 pve02 kernel: gran_size: 64K chunk_size: 512K num_reg: 10 lose cover RAM: 6M
Dec 20 10:22:28 pve02 kernel: gran_size: 64K chunk_size: 1M num_reg: 10 lose cover RAM: 6M
Dec 20 10:22:28 pve02 kernel: gran_size: 64K chunk_size: 2M num_reg: 10 lose cover RAM: 6M
Dec 20 10:22:28 pve02 kernel: gran_size: 64K chunk_size: 4M num_reg: 10 lose cover RAM: 6M
Dec 20 10:22:28 pve02 kernel: gran_size: 64K chunk_size: 8M num_reg: 10 lose cover RAM: 6M
Dec 20 10:22:28 pve02 kernel: *BAD*gran_size: 64K chunk_size: 16M num_reg: 10 lose cover RAM: -10M
Dec 20 10:22:28 pve02 kernel: *BAD*gran_size: 64K chunk_size: 32M num_reg: 10 lose cover RAM: -26M
Dec 20 10:22:28 pve02 kernel: *BAD*gran_size: 64K chunk_size: 64M num_reg: 10 lose cover RAM: -58M
Dec 20 10:22:28 pve02 kernel: *BAD*gran_size: 64K chunk_size: 128M num_reg: 10 lose cover RAM: -120M
Dec 20 10:22:28 pve02 kernel: *BAD*gran_size: 64K chunk_size: 256M num_reg: 10 lose cover RAM: -248M
Dec 20 10:22:28 pve02 kernel: *BAD*gran_size: 64K chunk_size: 512M num_reg: 10 lose cover RAM: -496M
Dec 20 10:22:28 pve02 kernel: *BAD*gran_size: 64K chunk_size: 1G num_reg: 10 lose cover RAM: -480M
Dec 20 10:22:28 pve02 kernel: *BAD*gran_size: 64K chunk_size: 2G num_reg: 10 lose cover RAM: -1504M
Dec 20 10:22:28 pve02 kernel: gran_size: 128K chunk_size: 128K num_reg: 10 lose cover RAM: 6M
Dec 20 10:22:28 pve02 kernel: gran_size: 128K chunk_size: 256K num_reg: 10 lose cover RAM: 6M
Dec 20 10:22:28 pve02 kernel: gran_size: 128K chunk_size: 512K num_reg: 10 lose cover RAM: 6M
Dec 20 10:22:28 pve02 kernel: gran_size: 128K chunk_size: 1M num_reg: 10 lose cover RAM: 6M
Dec 20 10:22:28 pve02 kernel: gran_size: 128K chunk_size: 2M num_reg: 10 lose cover RAM: 6M
Dec 20 10:22:28 pve02 kernel: gran_size: 128K chunk_size: 4M num_reg: 10 lose cover RAM: 6M
Dec 20 10:22:28 pve02 kernel: gran_size: 128K chunk_size: 8M num_reg: 10 lose cover RAM: 6M
 
Hi,
as for the first part, that's absolutely okay. While proxmox 8.1.3 can use secure boot now, it does not need to.
If you want to use secure boot though, you should be able to go into your bios and enable it, since we recently got the ability to officially sign our kernel.

As for the second part, I was about to point to the same resource as @MarkusF
 
  • Like
Reactions: MarkusF and Folke
Hello,
The red lines relate to MTRR. (Memory Type Range-Registers) These special CPU registers are used to specify the caching behavior for different memory regions.

If you see this in the logs, refer to the answer from @leesteken:
Code: 
mtrr_cleanup: can not find optimal value
please specify mtrr_gran_size/mtrr_chunk_size

If these two lines do not show up however and you are still seeing the messages in red, check whether your kernel parameters contain "mtrr=debug"
 
Gonna check out some of the other suggestions as they relate to MTRR. I ran MemTest86+ (latest version) for 4+ hours - 3 complete passes before I stopped it. See below - no errors detected at all.

1703121020494.png
 
fschauer said:
Hello,
The red lines relate to MTRR. (Memory Type Range-Registers) These special CPU registers are used to specify the caching behavior for different memory regions.

If you see this in the logs, refer to the answer from @leesteken:
Code: 
mtrr_cleanup: can not find optimal value
please specify mtrr_gran_size/mtrr_chunk_size

If these two lines do not show up however and you are still seeing the messages in red, check whether your kernel parameters contain "mtrr=debug"
Click to expand...

As I had no VMs on this server yet (well one that was not really setup yet) - I enabled SECURE BOOT and reloaded from scratch. These are from the very FIRST boot after the install. The lines you asked about are there (see red below).


Dec 20 20:24:49 pve02 kernel: gran_size: 256M chunk_size: 512M num_reg: 7 lose cover RAM: 190M
Dec 20 20:24:49 pve02 kernel: gran_size: 256M chunk_size: 1G num_reg: 7 lose cover RAM: 190M
Dec 20 20:24:49 pve02 kernel: gran_size: 256M chunk_size: 2G num_reg: 8 lose cover RAM: 190M
Dec 20 20:24:49 pve02 kernel: gran_size: 512M chunk_size: 512M num_reg: 5 lose cover RAM: 446M
Dec 20 20:24:49 pve02 kernel: gran_size: 512M chunk_size: 1G num_reg: 6 lose cover RAM: 446M
Dec 20 20:24:49 pve02 kernel: gran_size: 512M chunk_size: 2G num_reg: 7 lose cover RAM: 446M
Dec 20 20:24:49 pve02 kernel: gran_size: 1G chunk_size: 1G num_reg: 4 lose cover RAM: 958M
Dec 20 20:24:49 pve02 kernel: gran_size: 1G chunk_size: 2G num_reg: 4 lose cover RAM: 958M
Dec 20 20:24:49 pve02 kernel: gran_size: 2G chunk_size: 2G num_reg: 3 lose cover RAM: 1982M
Dec 20 20:24:49 pve02 kernel: mtrr_cleanup: can not find optimal value
Dec 20 20:24:49 pve02 kernel: please specify mtrr_gran_size/mtrr_chunk_size
Dec 20 20:24:49 pve02 kernel: MTRR map: 8 entries (5 fixed + 3 variable; max 25), built from 10 variable MTRRs
Dec 20 20:24:49 pve02 kernel: x86/PAT: Configuration [0-7]: WB WC UC- UC WB WP UC- WT
Dec 20 20:24:49 pve02 kernel: e820: update [mem 0xdb800000-0xffffffff] usable ==> reserved
Dec 20 20:24:49 pve02 kernel: last_pfn = 0xdaa11 max_arch_pfn = 0x400000000
Dec 20 20:24:49 pve02 kernel: secureboot: Secure boot enabled
Dec 20 20:24:49 pve02 kernel: RAMDISK: [mem 0x3c621000-0x3fffafff]
Dec 20 20:24:49 pve02 kernel: ACPI: Early table checksum verification disabled
Dec 20 20:24:49 pve02 kernel: ACPI: RSDP 0x00000000D77F3000 000024 (v02 DELL )
Dec 20 20:24:49 pve02 kernel: ACPI: XSDT 0x00000000D77F3088 000094 (v01 DELL CBX3 01072009 AMI 00010013)
Dec 20 20:24:49 pve02 kernel: ACPI: FACP 0x00000000D77FD288 00010C (v05 DELL CBX3 01072009 AMI 00010013)
Dec 20 20:24:49 pve02 kernel: ACPI: DSDT 0x00000000D77F31B0 00A0D6 (v02 DELL CBX3 00000022 INTL 20091112)


Gonna do some reading on the MTRR stuff. I still have to enable the iommu stuff, so that my HBA (LSI 9211-8i) controller can be used for NAS (not sure I am liking TrueNAS - for sure hated OpenMediaVault when I tried that.
 
OK -- I made the following change to the system GRUB line (the Underlined below) and rebooted -- see what I get now in RED.

# If you change this file, run 'update-grub' afterwards to update
# /boot/grub/grub.cfg.
# For full documentation of the options in this file, see:
# info -f grub -n 'Simple configuration'

GRUB_DEFAULT=0
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
#GRUB_CMDLINE_LINUX_DEFAULT="quiet" (Original)
GRUB_CMDLINE_LINUX_DEFAULT="quiet intel_iommu=on iommu=pt enable_mtrr_cleanup mtrr_spare_reg_nr=1 mtrr_gran_size=32M mtrr_chunk_size=128M"
GRUB_CMDLINE_LINUX=""

From the new BOOT:

Dec 20 20:40:45 pve02 kernel: SMBIOS 2.7 present.
Dec 20 20:40:45 pve02 kernel: DMI: Dell Inc. OptiPlex 7010/0KRC95, BIOS A29 06/28/2018
Dec 20 20:40:45 pve02 kernel: tsc: Fast TSC calibration using PIT
Dec 20 20:40:45 pve02 kernel: tsc: Detected 3392.120 MHz processor
Dec 20 20:40:45 pve02 kernel: e820: update [mem 0x00000000-0x00000fff] usable ==> reserved
Dec 20 20:40:45 pve02 kernel: e820: remove [mem 0x000a0000-0x000fffff] usable
Dec 20 20:40:45 pve02 kernel: last_pfn = 0x420600 max_arch_pfn = 0x400000000
Dec 20 20:40:45 pve02 kernel: total RAM covered: 16318M
Dec 20 20:40:45 pve02 kernel: gran_size: 32M chunk_size: 128M num_reg: 8 lose cover RAM: 30M
Dec 20 20:40:45 pve02 kernel: MTRR map: 8 entries (5 fixed + 3 variable; max 25), built from 10 variable MTRRs
Dec 20 20:40:45 pve02 kernel: x86/PAT: Configuration [0-7]: WB WC UC- UC WB WP UC- WT
Dec 20 20:40:45 pve02 kernel: e820: update [mem 0xda000000-0xffffffff] usable ==> reserved
Dec 20 20:40:45 pve02 kernel: e820: update [mem 0x420000000-0x4205fffff] usable ==> reserved
Dec 20 20:40:45 pve02 kernel: WARNING: BIOS bug: CPU MTRRs don't cover all of memory, losing 16MB of RAM.
Dec 20 20:40:45 pve02 kernel: update e820 for mtrr
Dec 20 20:40:45 pve02 kernel: modified physical RAM map:


Do you think I need to adjust this?
 
leesteken said:
You lose 30MiB but some other combinations only loses 6MiB (see your post) and maybe some lose even less. I would go for one of those, but it does not matter much.
Click to expand...
Yes -- I did a little more reading and made another adjustment and rebooted.

Dec 20 21:13:44 pve02 kernel: microcode: updated early: 0x20 -> 0x21, date = 2019-02-13
Dec 20 21:13:44 pve02 kernel: Linux version 6.5.11-7-pve (build@proxmox) (gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP PREEMPT_DYNAMIC PMX 6.5.11-7 (2023-12-05T09:44Z) ()
Dec 20 21:13:44 pve02 kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-6.5.11-7-pve root=/dev/mapper/pve-root ro quiet intel_iommu=on iommu=pt enable_mtrr_cleanup mtrr_spare_reg_nr=1 mtrr_gran_size=8M mtrr_chunk_size=64M
Dec 20 21:13:44 pve02 kernel: KERNEL supported cpus:


Now I am seeing it this way:

Dec 20 21:13:44 pve02 kernel: SMBIOS 2.7 present.
Dec 20 21:13:44 pve02 kernel: DMI: Dell Inc. OptiPlex 7010/0KRC95, BIOS A29 06/28/2018
Dec 20 21:13:44 pve02 kernel: tsc: Fast TSC calibration using PIT
Dec 20 21:13:44 pve02 kernel: tsc: Detected 3392.289 MHz processor
Dec 20 21:13:44 pve02 kernel: e820: update [mem 0x00000000-0x00000fff] usable ==> reserved
Dec 20 21:13:44 pve02 kernel: e820: remove [mem 0x000a0000-0x000fffff] usable
Dec 20 21:13:44 pve02 kernel: last_pfn = 0x420600 max_arch_pfn = 0x400000000
Dec 20 21:13:44 pve02 kernel: total RAM covered: 16318M
Dec 20 21:13:44 pve02 kernel: gran_size: 8M chunk_size: 64M num_reg: 9 lose cover RAM: 6M
Dec 20 21:13:44 pve02 kernel: MTRR map: 8 entries (5 fixed + 3 variable; max 25), built from 10 variable MTRRs
Dec 20 21:13:44 pve02 kernel: x86/PAT: Configuration [0-7]: WB WC UC- UC WB WP UC- WT
Dec 20 21:13:44 pve02 kernel: e820: update [mem 0xdb800000-0xffffffff] usable ==> reserved
Dec 20 21:13:44 pve02 kernel: e820: update [mem 0x420000000-0x4205fffff] usable ==> reserved
Dec 20 21:13:44 pve02 kernel: WARNING: BIOS bug: CPU MTRRs don't cover all of memory, losing 6MB of RAM.
Dec 20 21:13:44 pve02 kernel: update e820 for mtrr


:) Appreciate all the help folks - these forums are a god-send for us beginner Linux folks.
 
Should I be concerned with this error?

root@pve02:~# cat /proc/mtrr

reg00: base=0x000000000 ( 0MB), size= 2048MB, count=1: write-back
reg01: base=0x080000000 ( 2048MB), size= 1024MB, count=1: write-back
reg02: base=0x0c0000000 ( 3072MB), size= 256MB, count=1: write-back
reg03: base=0x0d0000000 ( 3328MB), size= 128MB, count=1: write-back
reg04: base=0x0d8000000 ( 3456MB), size= 64MB, count=1: write-back
reg05: base=0x0db800000 ( 3512MB), size= 8MB, count=1: uncachable <<< Error
reg06: base=0x100000000 ( 4096MB), size= 4096MB, count=1: write-back
reg07: base=0x200000000 ( 8192MB), size= 8192MB, count=1: write-back
reg08: base=0x400000000 (16384MB), size= 512MB, count=1: write-back
 
You must log in or register to reply here.

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Quick Navigation

Home Get Subscription Wiki Downloads Proxmox Customer Portal About

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!
Community platform by XenForo® © 2010-2024 XenForo Ltd.
Top Bottom