I have Gigaybte X470 AORUS GAMING 5 WiFi F63c, which has two variables named Setup.

setup_var.efi lists both of them and asks to rerun with the variable ID for selecting one of the two variables

But when I re-run with -i option, the exact same thing happens again (option -i has no effect)

Good evening and thank you so much for taking care of issue #7. I can confirm that the bug got solved with the newest release. About the newest release, I noticed that there's a new argument (--write_on_demand) which aims to avoid useless writes on the offset unless it has a different value.

In theory this is a good practice, but in the real-life tests, it seems that this argument is simply ignored, as I read Written offset blablabla. Is this just a matter of a wrong print statement, or the argument isn't properly parsed?

From my very low RUST knowledge, the argument is properly parsed (source).

Good morning and thank you so much for writing this tool. I'm using it and despite it serves the same purpose as modGRUBShell.efi it's way more portable (especially when having ESPs with low space issues).

Anyway, I'm experiencing a weird bug while trying to execute the tool via OpenCore. I don't know if you ever had any Hackintoshing experience in the past or not, but basically it's a bootloader and for what concerns us, it can be used also for creating custom tools entries (e.g. CFG Lock unlock entry which runs .\setup_var.efi CFG_LOCK_OFFSET 0x00 -n VarStoreId).

What basically happens is that after adding the tool in the bootloader configuration file, it skips the first argument.

Below the code that I added to the bootloader configuration file:

<dict>
	<key>Arguments</key>
	<string>0x527 0x00 -n Setup</string>
	<key>Auxiliary</key>
	<true/>
	<key>Comment</key>
	<string>UEFI command-line tool for read/write access of variables - CFG Lock unlock</string>
	<key>Enabled</key>
	<true/>
	<key>Flavour</key>
	<string>Auto</string>
	<key>FullNvramAccess</key>
	<true/>
	<key>Name</key>
	<string>setup_var - CFG Unlock</string>
	<key>Path</key>
	<string>setup_var.efi</string>
	<key>RealPath</key>
	<true/>
	<key>TextMode</key>
	<true/>
</dict>

What concerns us is the Arguments key with the value 0x527 0x00 -n Setup. If I run that custom entry, it doesn't write in the offset but rather reads the value of 0x00 under Setup VarStoreName, so it skips the first argument.

I already discussed this with the devs of the bootloader (you can read more here), and they pointed out this line which may be the reason of the bug.

The only way I could find to temporarily fix it is adding .\setup_var.efi (potentially can be literally any string, as it doesn't need to be any particular value) so the tool correctly parses the argument.

Do you think this can be fixed? Thank you so much and have a great day

-- dreamwhite

Hello, I am very happy to know that this project exists. Amazing job.

I immediately shared it with my friend @dreamwhite and I saw he has already pinged you to fix some niche things ad discrepancies, it's so nice to see that you've quickly fixed everything he noticed that was broken/missing :)

By the way, we're mostly using this tool for BIOS mods (DVMT Pre Allocated / CFG Lock etc) but I have a weird laptop where the trackpad works for Linux and Windows when I set it to APIC interrupt, and this mode is unsupported for macOS; on the other hand, GPIO interrupt works for macOS but not for Windows/Linux.

This tool comes very handy in conjuction with OpenCore Tools section, where you can send parameters when launching an option in the picker. However, after launching the tool, the user is forced to soft shutdown by pressing once the button (no force shutdown) and then boot back again with the edited BIOS option.

Would it be possible to set an argument to reboot after the change is applied to speed things up?

something like

setup_var.efi 0x2CA 0x01 -n Setup --reboot

G'day and thank you very much for this. For my laptop which randomly likes to reset CFG Lock and such, this has been a lifesaver - my rEFInd bootloader entries are now using .nsh scripts that perform my desired setup_var calls then load a Linux kernel/Windows bootmgr/whatever, ensuring that every boot will have my ideal UEFI vars set.

I am worried, however, that these values are being written on every boot, even if it's not necessary. I can't imagine UEFI storage (nvram?) is designed to be especially durable....

...so, with that said, it would be really great if the tool could read the existing value, and ONLY write your value if it's actually different. Just to save unnecessary writes.

Thanks for your consideration!

The Human Interface Infrastructure section of the UEFI spec uses the term Variable Store. This is where VarStoreId and VarOffset originate from. Since IFR Extractor does, I would also stick to this terminology to avoid confusion.