Actually, it doesn’t really explain it. It would be the hex number that had to jump ahead to make it look like it was decimal, not the other way round.
They skipped 10-15 decimal (hex 0A-0F), and this is now 16 (hex 10) … so if you write this versions as hex, it would go from 3.09 to 3.10. So it kinda makes sense? 
1 Like
Just another “all seems good” report here, running Fedora 42 Workstation.
fwupdmgr get-updates was offering both the BIOS and the dbx database update. To get around the efivars filesystem being full issue I updated only the BIOS with
fwupdmgr update <GUID for BIOS update shown in get-updates output>
After the update the machine booted up normally. Then the graphics got in a funky state but it seemed related to my Thunderbolt dock and/or external display. After a hard reboot, the machine was fine. I then performed the efivars workaround from the github issue above (reset Secure Boot config to factory defaults) and things seem normal, including:
$ df -h /sys/firmware/efi/efivars/
Filesystem Size Used Avail Use% Mounted on
efivarfs 148K 49K 95K 34% /sys/firmware/efi/efivars
The (new BIOS) Secure Boot factory defaults include the updated dbx so fwupdmgr get-updates shows everything up to date now.
But why would you skip them, if not to allow you to release version 3.10 (decimal) without any confusion? It’s like one department decided to skip some hex numbers to help make it so that the decimal BIOS numbers could make sense with the hex BIOS versions, while another had already decided to convert hex to decimal. Now we have hex version 310 and BIOS decimal version 3.16. Still a mess.
Indeed. Waiting for BIOS updates - to fix problems - is . . one thing. For there to be confusion about which BIOS is which . . seems desperate.
Framework’s recommended way of determining BIOS version reports ‘Version: 03.09’ on my Linux system; but fwupdmgr offers me no update to that version.
Same for me. No updates using fwupdmgr
1 Like
It’s not unusual for BIOS version numbers to skip versions. Sometimes it’s due to internal beta builds. Or wanting to align versions. I’ve often seen on my desktop board the ‘gap’ between version numbers be +4, sometimes even +5.
Look at the previous release - we had multiple buggy builds that were held back and the effective stable delta was 3.05 to 3.09. What’s the difference except that intermediate versions were de facto ‘public beta’?
Honestly, it’s completely irrelevant, the only thing that matters is satisfying {nextVersion} > {prevVersion}. It’s just numbers… Calling it a mess is a bit silly.
4 Likes
Upgraded sucessfully with fwupdm 
So you’re saying they didn’t go from 309 hex to 310 hex to stay as decimal lookalike numbers?
I guess that does fit what happened.
No. What I’m saying it it doesn’t matter if there was any specific reason and I see no reason why anybody should care. The only thing that’s relevant to an end user, and dare I say the system itself, is to validate if {nextVersion} > {prevVersion}. The base is irrelevant.
3 Likes
Easy for you to say Mr. or Ms. 12648430. 
3 Likes
Just wondering why hex and decimal were given as the reason for going from 3.09 to 3.16, while we still have to have the BIOS 3.16 showing as 310 in Device Manager.
From a curiosity perspective I can certainly stand behind this question. I’m not too familiar with Windows, but I wouldn’t be surprised if raw values reported to the OS are hexadecimal, while the “human-readable” values would be reported as per whatever is encoded as the "version string”. This would explain why the value under Firmware device in Device Manager would show as 310.
Does it also read 310 / 3.10 in other places where there is a text-readable version? If so, that would be more peculiar. In general, I see “3.16” everywhere where the returned value is plain text.
So I don’t think it’s a discrepancy, as somebody else suspected above, or Framework trying to “visually” match between bases. I think the most likely scenario is what you already alluded to, i.e. unpublished intermediate builds. Or just skipped builds, for whatever reason.
Edit: Sorry, I just came across FW’s explanation for the jump, not sure how I missed this earlier in the thread.
Not familiar with the specifics here, but I still see it as a rather benign reason.
1 Like
You should nag the one who designed the Device Manager(Microsoft), not the one who attempts to workaround the madness.
Hello all, just tried this update today and would like to warn people about this issue:
Not sure if it’s actually consistently reproducible, but I would suggest unsetting the supervisor password before the upgrade.
NOTE:
I’m located in Taipei, so if Framework people like to check it out in person, feel free to reach out to me. I will resist the temptation to do a full mainboard reset for a couple of days.
UPDATE: A certain incident at my workplace forced me to do the BIOS password reset procedure on my system, as a result, I can no longer reproduce this problem.
If I don’t respond to the PM, ask Daniel to ping me on Matrix/Element. I’m also available in the Unofficial Framework product Taiwan user community Telegram group as @brlin_tw.
1 Like
I’m pretty certain Device Manager just presents the hex there that the user chooses to put in a particular field for that purpose. Evidence from my other PCs suggests that it doesn’t have to be the version and could be the checksum of the BIOS, or just the same “1” for every version ever released.
It doesn’t matter: the new firmware version is specifically chosen to avoid the ambiguous interpretation by the software (no 03.10 version ever existed, so no one will confuse it with the 03.16 version).
Some software may still treat the string as a sortable version string(e.g. fwupd), so the field shouldn’t be treated as a free-form string.
Why bother to show the version in Device Manager if we’re not allowed to refer to it?
Definitely something to keep an eye on.
On that note, I also have a BIOS supervisor password and upgraded to 3.16 yesterday through LVFS. I did not encounter any such issues and entering BIOS set up works just fine.
2 Likes
I second this. ryzenadj is too useful too loose it