Apologies for the lack of detail while I initially posted it in a rush.
While I do have an internal Windows installation, I’m testing the feasibility of that approach as it could be used by someone with no internal windows installation and unwilling to create one. Especially considering the EFI updater, which should be the updater of choice for that scenario, is pulled for now.
Posted updated to include this information, thank you for pointing out the potential confusion. Will refine it again when I have some time.
why would you use the msi installer then?
I use Linux Arch and only used it to get the 12th Gen Intel Core BIOS 3.08 Beta Release#linuxotheruefi-shell-update-5 files onto an usb.
from there, you change the bootorder to the usb storage device and youd only change back to your main OS after the updates succeed or some trouble shooting intermediate.
sounds like you altered the availeble bootdevices inbetween reboots?!? this might relocate know paths for update files for the updater to keep track of progress altho the EFI version seem to know what to look for, the msi variant might not asume you change these.
DHowett is correct. Like I mentioned previously, the EFI installer is currently pulled for fixes following community feedback, it’s no longer available officially. Therefore, in the interim, the MSI-based unofficial method I previously shared is indeed one of the ways to go, if the user chooses to do so at their own discretion.
And it does appear to me that Framework has the capability of modifying the .msi updater conveniently, judging from Kieran being able to deliver 3.08b with just a few hours. Therefore, like I mentioned at the beginning, I want to put this experiment out there, so Framework can potentially consider to implicitly optimize for this scenario, while they take their time to work on an improved EFI updater.
I have installed the update, in general it seems to have went fine, but upon restart the “please wait while we are installing updates” and framework logo sometimes appears for a brief moment. In device manager I see the following about Retimer 23:
I wanted to test with fwhunt, if the firmware successfully fixed LogoFail. Binarly has not yet published the LogoFail rules, but I discovered that BRLY-SA-2023023 was probably not fixed.
Scanner result BRLY-SA-2023023 (variant: default) FwHunt rule has been triggered and threat detected! (IhisiServicesSmm)
I tried to run the update again just to see what will happen. Both 3.08 and 3.08b will run, but after reboot I get dumped right into Windows, without seeing any update progress bars. I don’t know if the updater detected versions already current, or after the initial run they left some flag in Windows and refused to run again because of that.
I don’t have the expertise dissecting into the .msi package, nor the time to wipe/swap the SSD to see if the updater will run again. But you can probably try to run it again, see if that resolves your retimer issue.
Just tried that a while ago, it indeed ran very quickly and there were no progress bars. The device manager entry about the retimer changed though. It now shows the firmware as up to date, but it insists that the device cannot start.
Interesting. Considering putting this into a support ticket if you wish.
Do you have spare SSD to swap in (or able to wipe your current SSD) to try if the installer will re-execute more completely in a fresh copy of Windows? If you try this please keep me updated, I’m also curious. (If you swap SSD, careful with BitLocker)
Another way is trying the (currently pulled but can be found) EFI Update method and see if that fixes it.
What Expansion Cards you have? Perhaps try running the update with no expansion cards?
If you dare, 3.06 is also something you can play with.
These are the options that I would consider if I encounter this issue, try them at your discretion.
Indicates the update failed to install somehow and Windows keeps retrying. Happened to me with the 3.06 Beta as well (one of the retimers). As they announced on that Beta update: unpower device completely for a few minutes and retry. Worked for me back then and at least publicly we saw nobody permanently bricking their device or retimer and in the end, retry after cold-power-up worked.
The MSI only directly installs the ME firmware (no matter if it is already up-to-date) and hands Windows the main BIOS image, and both ReTimer firmwares for Windows to give the UEFI if Windows decides that the firmware is not already up-to-date. So reinstalling the MSI should make no difference. Either Windows knows the firwmare is not already installed and will retry on its own, or Windows at least thinks it is already installed and will ignore what the MSI does (except for the ME firmware which is directly flashed and not via UEFI capsule method as the others are).
A new update probably be happening (or a new bios “beta”)
Would be cool to see Binarly releasing the LogoFAIL scan code, guess they cant yet, as it seems to scan exact byte sequences (instructions, and if there, somewhat expose the exploit? might still be under NDA or whatever)
I can share that I managed to resolve the issue by digging in the 3.06 beta thread. The following suggestion helped: 12th Gen Intel Core BIOS 3.06 Beta - #54 by chutwig
I uninstalled the retimer 23 device and ran the 3.08 msi again. This time the system rebooted and applied a firmware update again. After rebooting to windows, the retimer 23 reports no issues. So far all ports are functioning, I will test with a TB3 device today as well.
I think in the non-Beta release, it would be beneficial if Framework add the option of forcing a complete re-update, to resolve failure cases like this.
@Kieran_Levin Want to follow up on the previous comment. Do you have an update on where the release timeline stands? I know it was mentioned previously that the beta period would be 2 weeks, except in cases where there are blocking circumstances. Seeing as there’s been some issues with this release on the EFI installer, etc, does this push the release back until these things can be ironed out?
Just want to level-set expectations so this thread doesn’t devolve into the 3.06 beta thread.
I’d also like to add to that:
When FW decides to not progress to the release, but keeps the update itself online and available, they really should update the “Known Issues” listed.
The 3.06 beta update is still available and in over a year has never gotten any known issues listed that would allow customers to judge whether it might be worth it or still beneficial to them to install that update.
But obviously it must have had some rather serious issues to not progress to release.
I’d very much like to see that FW has learned from the past failures with software updates and is improving.
And it might also be beneficial to explain in a little more detail why the EFI version was taken down. Because reading through this thread, it looks like the issues it was pulled for were identical to the ones the 3.06 Beta EFI version had and that not only stayed up for over a year, but it is still up.
Is the 3.08 EFI updater actually dangerous to the device/risks bricking but the 3.06 is not? Or is this just strategy, because you’d like people to try a revised updater for the same version step?
I have my FW 13 laptop with a 1240-P i5. There aren’t any issues other than the HDMI signal dropping out frequently using a Thunderbolt enclosure. I tried setting the battery threshold to 100%. While it seemed like it worked for some time, the issues are back. I was looking to see if maybe is a BIOS thing, if so then i can perhaps flash an updated BIOS to it but This looks to be a Beta release. Not sure if I should flash it or wait until I find some kind of solution for the issue… What do you guys think?
