[BUG]: Imager 2.0.6 on Windows 11 writes Trixie 64-bit images for Zero 2 W that fail after initial boot; cloned known-good card works

[Cybergrany]

What happened?

Summary

Raspberry Pi Imager 2.0.6 on Windows 11 appears to write Raspberry Pi OS Trixie 64-bit images for Raspberry Pi Zero 2 W in a way that does not boot reliably.

A freshly written card will sometimes appear to boot briefly at first, but then the system becomes unusable. On later boots, the board shows only a brief rainbow screen and does not continue booting normally.

I have ruled out several common causes, including bad SD cards and a faulty Pi, and I can boot the same hardware successfully from a cloned known-good card.

Environment

• Host OS: Windows 11
• Raspberry Pi Imager version: 2.0.6
• Target device: Raspberry Pi Zero 2 W
• Image used: Raspberry Pi OS Trixie 64-bit
• Display connected via HDMI
• Power via USB
• No other peripherals connected during testing

Problem description

With a freshly flashed SD card:

1. Insert fresh SD card written by Raspberry Pi Imager 2.0.6
2. Power on Raspberry Pi Zero 2 W
3. Initial boot may show:
   • "Welcome to Raspberry Pi Desktop" splash screen
   • brief rainbow screen
   • then blank screen
4. In some cases the Pi is briefly reachable over SSH during this early stage, then stops responding
5. After power cycling, behavior degrades to:
   • brief rainbow screen
   • no further visual/boot output
   • no SSH access
   • ACT LED showing a repeating 7-flash pattern

I also tested Raspberry Pi OS Lite. With Lite, I briefly see a login prompt for a few seconds, then the system appears to shut down / stop booting. After that, subsequent boots act like the main PiOS 64b image

Troubleshooting already performed

I have already tried the following:

• Reflashed multiple SD cards
• Tested with a second, brand-new Raspberry Pi Zero 2 W
• Cleared Raspberry Pi Imager cache
• Reinstalled Raspberry Pi Imager
• Re-downloaded the image through Imager
• Checked integrity of SD card after the issue appears + checked that important kernel files are valid/present
• Tested both full Raspberry Pi OS and Raspberry Pi OS Lite
• Verified that the boot partition contains the expected files after flashing
• Tested SD cards separately and they passed card integrity tests
• Confirmed that a cloned known-good SD card boots successfully on the same hardware

Important control test

A cloned SD card image from a known-good working installation boots correctly on the same Pi hardware + PSU.

This strongly suggests the problem is not:

• the Raspberry Pi Zero 2 W itself
• the SD cards
• the basic power/display setup

and instead points to either:

• the image written by Imager
• the way Imager 2.0.6 is writing the image
• or some interaction between Imager 2.0.6, this image, and Zero 2 W

Reproducibility

This is reproducible for me across:

• multiple SD cards
• two separate Raspberry Pi Zero 2 W boards
• after clearing Imager cache and reinstalling Imager (fresh download from official site)

Additional notes

Because a cloned known-good card works, and newly written cards from Imager do not, my current suspicion is that Raspberry Pi Imager 2.0.6 is producing a bad or unusable write in this setup.

Version

2.0.6 (Default)

What host operating system were you using?

Windows

Host OS Version

11 Home Edition 10.0.26200

Selected OS

RPI OS 64-bit (2025-12-04 release)

Which Raspberry Pi Device are you using?

Raspberry Pi Zero 2 W

What kind of storage device are you using?

microSD Card in an internal reader

OS Customisation

• Yes, I was using OS Customisation when the bug occurred.

Relevant log output

[Cybergrany]

Update: Imaging the legacy bookworm Lite OS works. Still no luck getting the latest trixie images working

[tdewey-rpi]

7 flashes sounds like you've not written an OS that has a viable kernel image: https://www.raspberrypi.com/documentation/computers/configuration.html#led-warning-flash-codes

When you first boot a Raspberry Pi OS image, the system performs a live resize of the boot partition. On Zero2W this can take a noticeable amount of time to complete - and it is imperative that you do not remove the power while this live resize is occurring, or you will risk damaging the filesystem written by Imager.

If you have cloned a previously booted SDcard, then that installation has already undergone this live resize - so it will appear to boot immediately.

I suspect, therefore:

1. You have imaged an OS, and the verification pass has completed successfully - indicating the download is as intended
2. You have then attempted to boot the Zero2W, perhaps unaware of the live filesystem resize
3. You have then removed the power/power cycled during this resize
4. Your filesystem is now damaged

How long are you waiting before pulling the power?

[Cybergrany]

Thanks for the response!

I'm aware that some time is needed at first boot of a new image. The first time around I left it to boot, observed the splash screen as usual, then screen went dark. I left it alone for about 10 mins (normally enough in my experience), then observed the 7 flash pattern, which was unusual.

On every imaging attempt of all 64bit trixie images it follows the same flow; boots normally (splash screen + modules loading for 3-5 mins) then goes directly to the 7 flash sequence. As stated, in the non-desktop images I get a few seconds of login prompt console, before it shuts down (interestingly enough it's a clean shutdown, all of the modules can be seen shutting down), and then any subsequent power cycles just go directly into the LED pattern

It's also worth noting that I've been flashing RPI Zero 2w's with the same install of the imager + same images for the last couple of weeks with no issues. Clean reinstall + manual clear of cache has the same effect

Could there be an issue with the images themselves? Were they updated recently?

[pelicanmedia]

I am also getting similar issues using v2.0.6 on macOS trying to flash 64-bit Trixie for a Pi 4 4GB (also tried on a Pi 4 1GB).
On boot, I get the rainbow splash screen, then a black screen, and seven green LED flashes. I have tried on three different, brand new SD cards. Same failures.

I can remove that failed SD card and install it in a Pi 5, and it boots to the desktop just fine. Remove it again and install it back in the Pi 4; it fails to boot.

Could there be an issue with the images themselves? Were they updated recently?

Yes, there seems to be issues with the images

[lurch]

Were they updated recently?

Nope, last update was on the 4th December 2025 https://www.raspberrypi.com/software/operating-systems/

Yes, there seems to be issues with the images

I've been doing some testing this afternoon, and there's not a problem with the images.

I've got a Pi 5 that is running 64-bit RPi OS Trixie from a USB flash drive, which is running RPi Imager 2.0.6 (writing images to the internal microSD slot). After using that to write 64-bit RPi OS Trixie (with no customisations) to a microSD card, that microSD card booted up just fine in both a Pi 4B and also a Pi Zero 2 W. So then I repeated the test but this time I used RPi Imager to customise the image, and again it booted up just fine (with the customisations applied) in both a Pi 4B and also a Zero 2 W.

I'll ask one of my colleagues to write some SD cards for me on their Windows laptop tomorrow, and then test those.

I can remove that failed SD card and install it in a Pi 5, and it boots to the desktop just fine. Remove it again and install it back in the Pi 4; it fails to boot.

The only thing I can think of that would explain that, would be if somehow kenel8.img (the Linux kernel used by Pi 4 B) is corrupted, but kernel_2712.img (the Linux kernel used by Pi 5) isn't corrupted. Are you letting RPi Imager fully verify the image after writing? Are you using RPi Imager to apply any OS customisations? Have you got the "Eject media when finished" option enabled in RPi Imager's settings?

[pelicanmedia]

Are you letting RPi Imager fully verify the image after writing?

I am, yes

Are you using RPi Imager to apply any OS customisations?

Yes. Hostname, Localisation (London, Europe/London, gb), User, WiFi, Remote Access (SSH enabled, use password authentication), Raspberry Pi Connect (disabled).

Have you got the "Eject media when finished" option enabled in RPi Imager's settings?

Yes, I have

I have just tried a new image with no customisations, and it booted fine.

Also, I just tried again with OS customisations but typed in the secure/hidden credentials again (user and WiFi password) rather than using the saved, albeit same, values. And it booted. BUT it booted to the desktop, then flashed a black screen and rebooted again. SO maybe something to do with the saved credentials?

[phattmatt]

As another data point I can successfully boot a freshly written, customised, Raspberry Pi OS Trixie Lite (64-bit) on my Raspberry Pi Zero 2W.

Host OS: Windows 11 Pro (25H2)
Imager Version: 2.0.6
Image: Raspberry Pi OS Lite (64-bit) - Release date: 2025-12-04
Pi Model: Raspberry Pi Zero 2 W
Customisations: Hostname, Localisation (London, Europe/London, gb), Username/Password, WiFi, Remote Access (SSH enabled, use password authentication), Raspberry Pi Connect (disabled).
SD Card Reader: UGREEN USB SD Card Reader

pi@rpizero2w-trixie:~ $ hostnamectl
 Static hostname: rpizero2w-trixie
       Icon name: computer
      Machine ID: b9ccd991994c4321b0394cc88d65e91a
         Boot ID: 2c4af11e178642008497d9b9e944ff34
Operating System: Debian GNU/Linux 13 (trixie)
          Kernel: Linux 6.12.47+rpt-rpi-v8
    Architecture: arm64
pi@rpizero2w-trixie:~ $ cat /etc/rpi-issue
Raspberry Pi reference 2025-12-04
Generated using pi-gen, https://github.com/RPi-Distro/pi-gen, 4997bf4e4e49bc3305eb182a4a08bd023529da04, stage2
pi@rpizero2w-trixie:~ $ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:    Debian GNU/Linux 13 (trixie)
Release:        13
Codename:       trixie

[lurch]

BUT it booted to the desktop, then flashed a black screen and rebooted again.

I've got no idea what could cause that. Are you sure that your power supply and/or power cable aren't faulty? Could you please try using h2testw to very that your microSD card is fully-functional? You've mentioned that you've tried using different SD cards; are you also able to test using a different USB SD card-reader?

[Cybergrany]

@lurch

Are you using RPi Imager to apply any OS customisations?

Yes, WiFi, SSH and user creds, I can try without later to see if the behavior matches @pelicanmedia

Have you got the "Eject media when finished" option enabled in RPi Imager's settings? [...] Have you got the "Eject media when finished" option enabled in RPi Imager's settings?

Yes, I'm extra paranoid and also make sure the media's ejected in the windows tray too.

Are you sure that your power supply and/or power cable aren't faulty? Could you please try using h2testw to very that your microSD card is fully-functional? You've mentioned that you've tried using different SD cards; are you also able to test using a different USB SD card-reader?

In my case, the only variable is the image from RPI imager; legacy images work + a known-good image of Trixie from a few weeks ago. Have run h2testw on all my SD cards and no issues

[pelicanmedia]

Are you sure that your power supply and/or power cable aren't faulty?

I always use the official Raspberry Pi power supplies. For the Pi 4, I use the 3A 15W one, and for the Pi 5, I use the 5A 25W one. I have tried both on the Pi 4, neither of which is faulty.

Could you please try using h2testw to very that your microSD card is fully-functional?

This passed on the 'failed-to-boot' cards.

You've mentioned that you've tried using different SD cards; are you also able to test using a different USB SD card-reader?

I am using microSD adaptors directly in the SD slot of my MacBook Pro, I have tried multiple adaptors too.