Great to hear the progress.
I’ve started a new thread. Users can discuss interest and report progress there.
I am getting a lot of alerts:
New alerts:
• Stored machine account secret is invalid. This may indicate that the machine account password was reset in Active Directory without corresponding changes being made to the TrueNAS server configuration…
Current alerts:
• Stored machine account secret is invalid. This may indicate that the machine account password was reset in Active Directory without corresponding changes being made to the TrueNAS server configuration…
I am not getting these from 25.04.2.4 but am from the 25.10-RC1 (I also got these from the previous Beta).
In good news I threw this on a non critical Truenas at work. It’s a very old server that I use to host some VMs that do PCAP work. The server only has 32GiB of RAM and it has been using about 23GiB for ARC. After the RC1 update it’s now using 27GiB, at 15% improvement. A nice tune up for an aging machine.
If it doesn’t clear reliably , report it as a bug. If it does clear, what was the process.
Are you using Active directory?
It clears and then reappears on a irregular basis. Quite frequent though. No user action though
Yes - I am using Active Directory
1 Like
It might be worth starting a thread in General channel… see if anyone else has or does not have the issue or has worked out how to resolve. Bug report if there’s no help that way.
Yes, windows without bitlocker does not care about secure boot.
If bitlocker is enabled and secure boot is disabled, the machine will not boot until you enter the bitlocker key or re-enable secure boot.
Guess most people don’t know the details and think it must be enabled.
So, simply do not enable it, unless you will configure bitlocker.
Reasons for being bonkers
- On a real machine I can change the boot type from UEFI+Secure Boot to (UEFI-Secureboot | CSM/Legacy), so I should be able to do the same in a VM.
- You need to be able to change boot mode. See the example below.
- This cripples a VM and removes configurability from the user (i.e. Incus and VM disks storage locations)
- The UI should not be enforcing configurations such as this.
Example
- I have a windows 11 VM running fine and it loads with secure boot and GPT.
- The OS then fails and I need to boot using an offline CD ISO (which does not support EFI boot or Secure Boot) so I can repair it.
- With this new option I can no longer fix my OS.
1 Like
I have to agree.
VM options should mimic the BIOS of a real machine: Enable, disable all options.
I understand why IX is making it an option during creation only, to avoid people changing it later and then opening non-bugs.
Need secure boot after creating the VM?
You can always create a new vm with the exact settings, plus secure boot.
Which offline CD ISO is that?
Most/all do have UEFI boot…
In your example, you can still fix the machine:
You need to provide the Bitlocker key to unlock the failed drive and then you can run chkdsk or diagnostics etc.
2 Likes
Isn’t this an attempt to override the benefits of secure boot?
Unlike a physical server, TrueNAS has a primary goal of being a highly reliable infrastructure with greater data integrity. Do VMs fail like this when using ZFS?
You can always rebuild a VM and attach data “drives” or shares… with or without secure boot. Best practices might be different from a single drive real machine.
We also have concerns about supporting users through complex processes… the type of operation you described would never be tested.
Lets review some real situations…and see if there are better approaches.
1 Like
I will just address a few of the things mentioned as I am passionate about this one.
I don’t build a new PC and swap the disks when I want this feature, I just go into the BIOS and change one option.
UEFI and Secure boot are different things. You can boot UEFI without secure boot. This is intentional for situations where there is a mismatch in certificates of the software being loaded will not be allowed because it is modified or not signed. I am not an expert here, all I know is that if i turn it off then i can load my disks.
I did not mention Bitlocker. I don’t use it myself nor do any of my clients.
No, quite the opposite. If I can never turn secure boot off, I will never turn it on which is exactly what everyone else will do when they discover this issue.
My proposal allows an admin to have secure boot on until they need to turn it of, do there thing and then turn it back on like any good IT technician would do.
I think you are mixing hardware and software up. Even if the VM “hardware” never fails, it does not mean that a windows update will not kill the software, yes i know Windows DVDs are signed and secure boot enabled, but I am using this as an example of software failure.
Yeh, I am not doing this as it is bonkers. See above for more notes.
This is not complex period.
- If an admin of a TrueNAS box does not understand this concept then he/she should not be left in charge of someone’s data.
- If secure boot is not on, OS will still load via UEFI, some OS might mention that secure boot is not enabled boot that is it.
- If you try and boot an UEFI whilst on legacy boot, the OS will not load, however it is highly likely this is because an admin incorrectly changed the boot settings within the last 5 minutes so should remember what they did. Even if there was a large amount of time between the boot change and the actual booting of the VM, it is fairly obvious what the boot issue is.
- No VM platform that I know of enforces, only setting secure boot at VM creation because it is pointless and a bad thing.
- A rare situation is that developers what to test their software with and without secure boot.
TrueNAS VMs must support the following boot configurations
- Legacy BIOS (MBR)
- UEFI
- UEFI + Secure Boot
Thanks
2 Likes
Overall good. I have one custom app, and it cannot be edited or updated. A somewhat cryptic error message: ValueError: 'error' required in context
I looked at “Security Context” and cannot see anything relevant. Everything’s unchecked there: Not privileged, no extra capabilities, no custom user.
While I admire your passion, and in this instance you are also absolutely correct, IX are not known for ever backing down from odd decisions, but I do wish you luck.
1 Like
@shoulders can you confirm, if this was configurable with the VM shutdown only that would meet your need?
2 Likes
Do you mean that if the VM was powered down that boot option could be edited?
If so, this would meet my needs as this behaviour is the same in VirtualBox and sort of matches a real PC. I do not need an F12 boot option like you get on some laptops which allow you to change the boot mode on an active system
3 Likes
I’ve raised a ticket with the engineering team to get this evaluated.
2 Likes
Trevor68 stands corrected! 
1 Like
There has been at change for the better at TN.
I also think the podcast has really helped because they listened and you can get feedback from the TN team themselves.
They said they would go through the feature requests, and now they are.
And happy to be so! 