mirror of
https://github.com/rbalsleyMSFT/FFU.git
synced 2026-06-14 10:19:36 -06:00
Compare commits
8 Commits
| Author | SHA1 | Date | |
|---|---|---|---|
| 3cb9bc9931 | |||
| b388eae439 | |||
| c1b81004be | |||
| 02e423c0f2 | |||
| ce34e40a52 | |||
| 4f701c4b1c | |||
| 6c0ee8abc5 | |||
| 9bacac8f3d |
@@ -1,5 +1,29 @@
|
||||
# Change Log
|
||||
|
||||
# 2603.2
|
||||
|
||||
## What's Changed
|
||||
|
||||
Highly recommended to upgrade to this release due to potential SecureBoot issues
|
||||
|
||||
### Fixes SecureBoot-related boot issues on newly deployed FFUs
|
||||
|
||||
Fixes an issue where some devices may not boot after an FFU was applied if the FFU was built from a machine that had been updated to the Windows UEFI CA 2023 SecureBoot certificates.
|
||||
|
||||
Sometime at the start of this calendar year (Either January or February), a change was made in Windows to how BCDBoot functioned. If you took a CU from either of these months, BCDBoot will now check to see if the device has the 2011 or 2023 CA certificates. If 2023, the local BCDBoot will use the 2023 signed boot files when creating the System partition and these boot files will be deployed to the target system when the FFU is deployed. If the target machine hasn't updated to the 2023 certificates, boot will fail.
|
||||
|
||||
To fix this, FFU Builder now uses the version of BCDBoot from the ADK instead of the locally installed version. The version of BCDBoot from the 10.1.26100.2454 ADK December 2024 version (which is what FFU Builder considers the latest), will provide the boot files signed with the 2011 certs.
|
||||
|
||||
The version of [BCDBoot from the 10.1.28000.1 ADK](https://learn.microsoft.com/en-us/windows-hardware/get-started/what-s-new-in-kits-and-tools#bcd-boot) from November 2025 will default to using the 2023 certs as long as the machine supports the 2023 CA. This has been documented since this ADK was released. The behavior of this version of BCDBoot is what we're seeing now in devices that have been recently updated.
|
||||
|
||||
I suspect that when 26H2 is released, there will be a new ADK around that time and at that point we'll move to using that version of the ADK, which that version of BCDBoot will default to using the 2023 signed boot files and I suspect WinPE will probably default to doing the same. By then, hopefully, most in-market devices should have the 2023 certificates in UEFI and those that don't will need to get the certs or downgrade their ADK version to use the 2011 signed boot files.
|
||||
|
||||
### Fixes working directory handling
|
||||
|
||||
Creation and deletion of the dirty.txt marker file now use an explicit path based on $FFUDevelopmentPath, avoiding ambiguity and potential issues with relative paths.
|
||||
|
||||
**Full Changelog**: https://github.com/rbalsleyMSFT/FFU/compare/v2603.1...v2603.2
|
||||
|
||||
# 2603.1
|
||||
|
||||
## What's Changed
|
||||
|
||||
@@ -464,7 +464,7 @@ param(
|
||||
[switch]$Cleanup
|
||||
)
|
||||
$ProgressPreference = 'SilentlyContinue'
|
||||
$version = '2603.1'
|
||||
$version = '2603.2'
|
||||
|
||||
# Remove any existing modules to avoid conflicts
|
||||
if (Get-Module -Name 'FFU.Common.Core' -ErrorAction SilentlyContinue) {
|
||||
@@ -2781,11 +2781,25 @@ function Add-BootFiles {
|
||||
[string]$OsPartitionDriveLetter,
|
||||
[Parameter(Mandatory = $true)]
|
||||
[string]$SystemPartitionDriveLetter,
|
||||
[Parameter(Mandatory = $true)]
|
||||
[string]$AdkPath,
|
||||
[Parameter(Mandatory = $true)]
|
||||
[ValidateSet('x86', 'x64', 'arm64')]
|
||||
[string]$WindowsArch,
|
||||
[string]$FirmwareType = 'UEFI'
|
||||
)
|
||||
|
||||
WriteLog "Adding boot files for `"$($OsPartitionDriveLetter):\Windows`" to System partition `"$($SystemPartitionDriveLetter):`"..."
|
||||
Invoke-Process bcdboot "$($OsPartitionDriveLetter):\Windows /S $($SystemPartitionDriveLetter): /F $FirmwareType" | Out-Null
|
||||
# Use the ADK copy of BCDBoot so the boot binaries come from the validated ADK toolset
|
||||
# instead of the local OS installation, which can differ based on Secure Boot servicing state.
|
||||
$bcdBootArchitecture = if ($WindowsArch -ieq 'arm64') { 'arm64' } else { 'amd64' }
|
||||
$bcdBootPath = Join-Path $AdkPath "Assessment and Deployment Kit\Deployment Tools\$bcdBootArchitecture\BCDBoot\bcdboot.exe"
|
||||
|
||||
if (-not (Test-Path -Path $bcdBootPath)) {
|
||||
throw "ADK BCDBoot was not found at $bcdBootPath"
|
||||
}
|
||||
|
||||
WriteLog "Adding boot files for `"$($OsPartitionDriveLetter):\Windows`" to System partition `"$($SystemPartitionDriveLetter):`" using ADK BCDBoot at `"$bcdBootPath`"..."
|
||||
Invoke-Process $bcdBootPath "$($OsPartitionDriveLetter):\Windows /S $($SystemPartitionDriveLetter): /F $FirmwareType" | Out-Null
|
||||
WriteLog "Done."
|
||||
}
|
||||
|
||||
@@ -5692,7 +5706,8 @@ If (Test-Path -Path "$FFUDevelopmentPath\dirty.txt") {
|
||||
Get-FFUEnvironment
|
||||
}
|
||||
WriteLog 'Creating dirty.txt file'
|
||||
New-Item -Path .\ -Name "dirty.txt" -ItemType "file" | Out-Null
|
||||
$dirtyFilePath = Join-Path -Path $FFUDevelopmentPath -ChildPath 'dirty.txt'
|
||||
New-Item -Path $dirtyFilePath -ItemType "file" | Out-Null
|
||||
|
||||
# Early CLI prompt for additional FFUs (only if enabled and not provided)
|
||||
if ($BuildUSBDrive -and $CopyAdditionalFFUFiles -and ((-not $AdditionalFFUFiles) -or ($AdditionalFFUFiles.Count -eq 0))) {
|
||||
@@ -7024,7 +7039,7 @@ try {
|
||||
|
||||
WriteLog 'All necessary partitions created.'
|
||||
|
||||
Add-BootFiles -OsPartitionDriveLetter $osPartitionDriveLetter -SystemPartitionDriveLetter $systemPartitionDriveLetter[1]
|
||||
Add-BootFiles -OsPartitionDriveLetter $osPartitionDriveLetter -SystemPartitionDriveLetter $systemPartitionDriveLetter[1] -AdkPath $adkPath -WindowsArch $WindowsArch
|
||||
|
||||
#Add Windows packages
|
||||
if ($UpdateLatestCU -or $UpdateLatestNet -or $UpdatePreviewCU ) {
|
||||
@@ -7615,7 +7630,8 @@ else {
|
||||
}
|
||||
|
||||
#Clean up dirty.txt file
|
||||
Remove-Item -Path .\dirty.txt -Force | out-null
|
||||
$dirtyFilePath = Join-Path -Path $FFUDevelopmentPath -ChildPath 'dirty.txt'
|
||||
Remove-Item -Path $dirtyFilePath -Force | out-null
|
||||
# Remove per-run session folder if present
|
||||
$sessionDir = Join-Path $FFUDevelopmentPath '.session'
|
||||
if (Test-Path -Path $sessionDir) {
|
||||
|
||||
@@ -293,9 +293,10 @@ $script:uiState.Controls.btnRun.Add_Click({
|
||||
)
|
||||
|
||||
$startCleanupParams = @{
|
||||
FilePath = $pwshPath
|
||||
ArgumentList = $cleanupArgs
|
||||
PassThru = $true
|
||||
FilePath = $pwshPath
|
||||
ArgumentList = $cleanupArgs
|
||||
WorkingDirectory = $ffuDevPath
|
||||
PassThru = $true
|
||||
}
|
||||
if ($Host.Name -eq 'ConsoleHost') {
|
||||
$startCleanupParams['NoNewWindow'] = $true
|
||||
@@ -455,9 +456,10 @@ $script:uiState.Controls.btnRun.Add_Click({
|
||||
}
|
||||
|
||||
$startBuildParams = @{
|
||||
FilePath = $pwshPath
|
||||
ArgumentList = $pwshArgs
|
||||
PassThru = $true
|
||||
FilePath = $pwshPath
|
||||
ArgumentList = $pwshArgs
|
||||
WorkingDirectory = $config.FFUDevelopmentPath
|
||||
PassThru = $true
|
||||
}
|
||||
if ($Host.Name -eq 'ConsoleHost') {
|
||||
$startBuildParams['NoNewWindow'] = $true
|
||||
|
||||
@@ -835,7 +835,7 @@ $LogFileName = 'ScriptLog.txt'
|
||||
$USBDrive = Get-USBDrive
|
||||
New-item -Path $USBDrive -Name $LogFileName -ItemType "file" -Force | Out-Null
|
||||
$LogFile = $USBDrive + $LogFilename
|
||||
$version = '2603.1'
|
||||
$version = '2603.2'
|
||||
WriteLog 'Begin Logging'
|
||||
WriteLog "Script version: $version"
|
||||
|
||||
|
||||
@@ -1,3 +1,9 @@
|
||||
# Updates
|
||||
|
||||
## 2026-03-16 - [2603.2 Released](https://github.com/rbalsleyMSFT/FFU/releases)
|
||||
|
||||
Fixes an issue with devices not booting after applying an FFU. Highly recommended you update today.
|
||||
|
||||
# Using Full Flash Update (FFU) files to speed up Windows deployment
|
||||
|
||||
What if you could have a Windows image (Windows 10/11/Server/LTSC) that has:
|
||||
@@ -20,7 +26,7 @@ The Full-Flash update (FFU) process can automatically download the latest releas
|
||||
|
||||
# Getting Started
|
||||
|
||||
If you're new, check out the [Quick Start Guide](https://rbalsleymsft.github.io/FFU/quickstart.html).
|
||||
If you're new to FFU Builder or new to the FFU Builder UI version, check out the [Quick Start Guide](https://rbalsleymsft.github.io/FFU/quickstart.html).
|
||||
|
||||
This will be the fastest way to create your first FFU. There's a new [FFU Builder Quickstart Youtube video](https://youtu.be/kOIK5OmDugc) based on the 2602.1 UI Preview release.
|
||||
|
||||
|
||||
@@ -47,7 +47,7 @@ Once Hyper-V has been enabled and you have rebooted, create either an external o
|
||||
|
||||
If you haven't [downloaded the latest release yet, do so](https://github.com/rbalsleyMSFT/FFU/releases)
|
||||
|
||||
Once downloaded, extract the zip file to `C:\FFUDevelopment`. You can use another location, just be sure set your FFUDevelopmentPath to the new location (e.g. `D:\FFUDevelopment`).
|
||||
Once downloaded, open the zip file and copy the content of the FFUDevelopment folder to `C:\FFUDevelopment`. You can use another location, just be sure set your FFUDevelopmentPath to the new location (e.g. `D:\FFUDevelopment`).
|
||||
|
||||
After extraction, you most likely will need to unblock the files as they'll be tagged with the mark of the web. In PowerShell run:
|
||||
|
||||
|
||||
Reference in New Issue
Block a user