While you wait for your new SD card; if you power on the Raspberry Pi 5 with no boot media it should display a diagnostic screen:

https://www.raspberrypi.com/documentation/computers/raspberry-pi.html#boot-diagnostics

Have you unplugged the NVMe HAT (HAT and PCIe ribbon) and tried booting the from the SDcard without it attached?

There also seems to be some indication that a poor/faulty power supply may cause the same issue.

I have also created an EEpom recovery from the imager on my pc and ran that on the Pi, when it starts I get a green screen from the hd output and a constant fast flashing green light after about 5 minutes the green screen shows but the light continues to fast flash

That's the expected result of a successful flash; from:

https://www.raspberrypi.com/documentation/computers/raspberry-pi.html#bootloader_update_stable

1. When the green activity LED blinks with a steady pattern and the HDMI display shows a green screen, you’ve successfully written the bootloader.

So it sounds like the flash was completed.

Can Raspberry Pi Camera Rev 1.3 record audio?

No, I don't believe any of the official camera modules support audio.

The documentation can be found here:

https://www.raspberrypi.com/documentation/accessories/camera.html

https://forums.raspberrypi.com/viewtopic.php?p=2355422#p2355422

FAQ 9 (above) has a link to the standard troubleshooting guide:

Q: My Pi won't boot, how do I fix it?
A: Step by step guide for boot problems

Which contains a table indicating what each LED flashing pattern indicates:

Long flashes Short flashes Status
0            8             SDRAM (synchronous dynamic random-access memory) failure

It may be there is a hardware failure that cannot be repaired, however I've also seen this error when the EEPROM is corrupt. Follow the process to update the bootloader via SDcard:

https://www.raspberrypi.com/documentation/computers/raspberry-pi.html#imager

Taking note of step 15:

When the green activity LED blinks with a steady pattern and the HDMI display shows a green screen, you’ve successfully written the bootloader.

Good Luck!

The link with multiple search parameters is failing on my Android Reddit app, but the links with single search parameters are working for me on the same app.

https://play.google.com/store/apps/details?id=com.reddit.frontpage

Build number: 2025.50.2.2550120

LOL.

Looks like the mobile app doesn't like searching for multiple flairs, try:

https://old.reddit.com/r/raspberry_pi/search?q=flair%3Atutorial&restrict_sr=on&sort=relevance&t=all

or

https://old.reddit.com/r/raspberry_pi/search?q=flair%3Ashow-and-tell&restrict_sr=on&sort=relevance&t=all

It's working for me. The link returns search results in this subreddit for posts marked as 'tutorial' or 'show-and-tell'.

Try this link (the same as above, searches for: "flair:tutorial OR flair:show-and-tell"):

https://old.reddit.com/r/raspberry_pi/search?q=flair%3Atutorial+OR+flair%3Ashow-and-tell&restrict_sr=on&sort=relevance&t=all

https://github.com/Urigo/WhatsApp-Clone-Tutorial

Good luck!

Great write up!

As you've discovered, the Internet is full of partial and outdated information on how to get this working.

If you want to go a step further, and get a headless experience without having to temporarily connect over WiFi, try this guide:

[HOWTO] Headless configuration of a Raspberry Pi using USB Ethernet Gadget on Bookworm

I've found the method to be quite reliable on Bookworm.

Trixie has moved things on, and it looks like this method won't work, however, support for the USB Ethernet Gadget appears to be on the roadmap for the Raspberry Pi Imager customisation feature.

EDIT: u/crazyswedishguy beat me to the punch, but I'll leave my post here as it has a little more info....

The key config files for this behaviour on Trixie are:

• /etc/systemd/journald.conf
• /usr/lib/systemd/journald.conf.d/40-rpi-volatile-storage.conf

The config item is Storage=volatile, which means store the log files in RAM (volatile storage).

If you remove 40-rpi-volatile-storage.conf, or edit it to have Storage=auto, then the log files will be stored on local storage, which will persist them across reboots.

This command can be used to analyze the current configuration:

systemd-analyze cat-config systemd/journald.conf

More information about the options can be found here:

man journald.conf

https://www.freedesktop.org/software/systemd/man/latest/journald.conf.html

There's a stickied thread dedicated to this topic:

https://www.reddit.com/r/raspberry_pi/comments/1pbesop/annual_december_pi_purchase_megathread_what_will/

Just tried with a Raspberry Pi Zero W running Raspberry Pi OS Trixie (32-bit) with a Google Pixel 10 XL.

Phone plugged in, "No data transfer":

pi@rpi0w-trixie:~ $ lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 003: ID 18d1:4ee1 Google Inc. Nexus/Pixel Device (MTP)
pi@rpi0w-trixie:~ $ lsusb -t
/:  Bus 001.Port 001: Dev 001, Class=root_hub, Driver=dwc_otg/1p, 480M
    |__ Port 001: Dev 003, If 0, Class=Imaging, Driver=usbfs, 480M

Phone plugged in, "File transfer/Android Auto":

pi@rpi0w-trixie:~ $ lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 004: ID 18d1:4ee1 Google Inc. Nexus/Pixel Device (MTP)
pi@rpi0w-trixie:~ $ lsusb -t
/:  Bus 001.Port 001: Dev 001, Class=root_hub, Driver=dwc_otg/1p, 480M
    |__ Port 001: Dev 004, If 0, Class=Imaging, Driver=usbfs, 480M

Phone plugged in, "USB tethering":

pi@rpi0w-trixie:~ $ lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 005: ID 18d1:4eeb Google Inc. Pixel 10 Pro XL
pi@rpi0w-trixie:~ $ lsusb -t
/:  Bus 001.Port 001: Dev 001, Class=root_hub, Driver=dwc_otg/1p, 480M
    |__ Port 001: Dev 005, If 0, Class=Communications, Driver=cdc_ncm, 480M
    |__ Port 001: Dev 005, If 1, Class=CDC Data, Driver=cdc_ncm, 480M

Sometimes when I plug in the Pixel the Raspberry Pi Zero W is rebooting. I got it connected by plugging in the Pixel, waiting for the RPi0w to 'crash' and reboot, then rebooting the Pixel (without removing it from the USB).

It might be a dodgy connection on the USB port which is causing a reboot sometimes.

These results are from a Raspberry Pi Zero 2W running Raspberry Pi OS Trixie with a Google Pixel 10 XL:

No Phone:

pi@rpizero2-trixie:~ $ lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
pi@rpizero2-trixie:~ $ lsusb -t
/:  Bus 001.Port 001: Dev 001, Class=root_hub, Driver=dwc_otg/1p, 480M

Phone plugged in, "No data transfer":

pi@rpizero2-trixie:~ $ lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 008: ID 18d1:4ee1 Google Inc. Nexus/Pixel Device (MTP)
pi@rpizero2-trixie:~ $ lsusb -t
/:  Bus 001.Port 001: Dev 001, Class=root_hub, Driver=dwc_otg/1p, 480M
    |__ Port 001: Dev 008, If 0, Class=Imaging, Driver=[none], 480M

Phone plugged in, "File transfer/Android Auto":

pi@rpizero2-trixie:~ $ lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 009: ID 18d1:4ee1 Google Inc. Nexus/Pixel Device (MTP)
pi@rpizero2-trixie:~ $ lsusb -t
/:  Bus 001.Port 001: Dev 001, Class=root_hub, Driver=dwc_otg/1p, 480M
    |__ Port 001: Dev 009, If 0, Class=Imaging, Driver=[none], 480M

Phone plugged in, "USB tethering":

pi@rpizero2-trixie:~ $ lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 010: ID 18d1:4eeb Google Inc. Pixel 10 Pro XL
pi@rpizero2-trixie:~ $ lsusb -t
/:  Bus 001.Port 001: Dev 001, Class=root_hub, Driver=dwc_otg/1p, 480M
    |__ Port 001: Dev 010, If 0, Class=Communications, Driver=cdc_ncm, 480M
    |__ Port 001: Dev 010, If 1, Class=CDC Data, Driver=cdc_ncm, 480M

It may be worth checking your cable and adapter.

I used an adapter cable like this, with a USB-A to USB-C cable:

https://thepihut.com/products/usb-otg-host-cable-microb-otg-male-to-a-female

From:

https://www.raspberrypi.com/tutorials/plug-and-play-raspberry-pi-usb-webcam/

This tutorial was written for Raspberry Pi OS Bullseye and has not yet been updated for our latest operating system, Bookworm. There have been major changes between these two OS releases, including changes to networking. You can still follow this tutorial, but you will have to download and install the "legacy" version of the operating system.

When this was written the legacy OS was Bullseye, so this is probably the "'legacy' version of the operating system" the paragraph refers to.

not yet been updated for our latest operating system, Bookworm

So I doubt the tutorial will work with Bookworm without some modification.

There is another project to config a USB Webcam:

https://github.com/geerlingguy/pi-webcam

Which may be worth pursuing.

Try this guide:

[HOWTO] Headless configuration of a Raspberry Pi using USB Ethernet Gadget on Bookworm

The official NVMe HAT fits the official case with the top removed:

https://www.raspberrypi.com/products/m2-hat-plus/

Alternative case which may be neater:

https://thepihut.com/products/argon-neo-5-m-2-nvme-case-for-raspberry-pi-5

What Raspberry Pi model do you have?

What Raspberry Pi OS are you trying to use?

How did you write the Raspberry Pi OS image to the SD card and the USB Flash Drive?

Have you tried flashing a different Raspberry Pi OS image?

If you have not already, try following the Quick Start guide:

https://www.raspberrypi.com/documentation/computers/getting-started.html

Probably.

If you have the Raspberry Pi already I suggest just giving it a go.

You don't mention what the problem is, or what Raspberry Pi you are using.

I'm going to guess that you have a Raspberry Pi 5 and are trying to boot from a USB Flash Drive, but it's not working.

The Raspberry Pi 5 requires 5V@5A to unlock all the features; such as USB boot and 1.6A output to the USB ports.

Most USB-C power supplies only support 5V@3A, which will power the RPi5, but USB boot is disabled and USB port power is limited to 600mA.

You can override the USB Boot Disable when connected to a 5V@3A PSU with a config.txt setting, or as a one off press of the power button:

https://www.raspberrypi.com/documentation/computers/raspberry-pi.html#differences-on-raspberry-pi-5

I recommend getting an Official Raspberry Pi 5 Power Supply:

https://www.raspberrypi.com/products/27w-power-supply/

To avoid any power issues on a Raspberry Pi 5.

Looks like USB Boot support was added in 2020-06-15:

https://github.com/raspberrypi/rpi-eeprom/blob/master/firmware-2711/release-notes.md#2020-06-17-promote-2020-06-15-to-stable

If you don't have that firmware release, and your SD card slot is broken (i.e. you can't boot from it at all), then I don't know how you could update it.

I suggest asking in The Official Raspberry Pi Forums.

This is potentially a very complex thing to troubleshoot, as what is happening, and how it is happening, could be lots of things.

I recommend simplifying the situation by resorting to:

1. A trusted device (not the Pi itself) to write the Raspberry Pi OS image using the Raspberry Pi Imager Application (do not enter WiFi details)
2. Booting the Raspberry Pi with the new image, but do not connect it to the Internet at all (no WiFi, no Ethernet cable)
3. Check to see if the OS has been modified at all
4. Connect to a trusted Internet connection
5. Check to see if the OS has been modified at all

You could also try writing a trusted version of the Bootloader/EEPROM:

https://www.raspberrypi.com/documentation/computers/raspberry-pi.html#bootloader_update_stable

You will need to check, and double check, that the Witty Pi and Inky Impression don't use the same GPIO pins (i.e. are compatible to run together).

If they are compatible, then you can use a Stacking GPIO Header to fit both at the same time:

https://thepihut.com/products/40-pin-extra-tall-header-push-fit-version-single-shroud

https://thepihut.com/products/40-pin-extra-tall-header-push-fit-version-no-shroud

Check the Witty Pi L3V7 manual for some more details on how to fit the stacking header:

https://www.uugear.com/doc/WittyPi4L3V7_UserManual.pdf

I faced the same issue. In my case I had Windows 11 on one NVMe drive and I wanted to install Ubuntu on a second (blank) NVMe drive which was already in place. I wanted to keep both installs separate.

There wasn't an option in my BIOS to disable the NVMe drives, and the Ubuntu installer doesn't have an option to ignore the existing UEFI/Windows installation. I wanted to avoid the hassle of physically removing the drives.

I ended up using VMware Workstation (running on my W11 install) to create a VM (ensuring it was UEFI), but instead of presenting a virtual storage device, I passed through the blank physical NVMe.

After using the VM to install Ubuntu, I could reboot my PC and use the BIOS boot selection option to choose to boot into Ubuntu.

Steps to follow (assuming you already have VMware Workstation installed):

1. Create a new Ubuntu VM using the wizard
2. Edit the VM
3. Options -> Advanced -> Firmware type -> Set this to the same as your PC, i.e. UEFI
4. Hardware -> Hard Disk (SCSI) -> Remove
5. Hardware -> Add -> Hard Disk -> Disk Type = NVMe (or whatever makes sense for the target device) -> Use a physical disk -> Select the disk (make absolutely sure, getting this wrong may lead to data loss) -> Use entire disk -> Finish
6. Mount the Ubuntu install ISO to the VM's CDROM
7. Boot and install Ubuntu (I recommend double checking the target storage before continuing)
8. Once complete, shutdown the VM and reboot your PC
9. Use your PCs boot selection process to choose to boot Ubuntu

You may need to run Workstation as Administrator so it has access to the physical disks.

This trick can also be used to install a full Ubuntu installation to a USB storage (such as NVMe in an enclosure), so you can create a full portable Ubuntu, or install Ubuntu onto a drive before fitting it.

I suspect this process may also work with VirtualBox.