Booting my pi 3B+ from Buster on a USB SSD 240G Kingston A400, I now get quick pulsing yellow (green?) activity LED flash bursts, every 1.5 to 2 seconds, during normal operation, even when only the Desktop is running. This is after it has finished booting up to the working Desktop. The Buster is updated. When I was running Buster on a 64G SansDisk Ultra SD card, I never had this repeating drive access when the Desktop alone was running off the SD Card.

My first thoughts, here is what I suspect might be happening. I think, since this image was originally, technically, created and used on/for an SD card, perhaps there is some configuration that is telling the system to go to the SD card (which is no longer available) to get additional code or configuration info, every 1.5 to 2 seconds. If it is only attempting reads of the non-existent SD card, and indicates it by the flashing LED, then at least some of the SSD memory is not being depleted(?) away, but, it is still very misleading and annoying to watch that LED flashing when no user app is running. I'm hoping I do not have to completely redo a Buster config directly to the SSD right away.

Is it only trying to read a now non-existent SD Card, or is it reading and writing the SSD, continually? Why do I ask that? Here is why:

Essential background:

I just updated to the SSD boot setup a few days ago, eliminating the SD card entirely. The last time I was on an SD card, my fully configured Buster Python development SD Card was chewed up by a web page that maxed RAM and Swap usage for twenty minutes, (of course an hour before I was going to backup the entire card). I found myself having to reload and reconfigure everything again on a clean SD card. (I do have older archived images, but I change a lot in a week). After a couple of days of re-doing yet another SD Card (so it was 'cleaner' than the older backup images), I ordered two USB SSD 240G with USB cables. Of course, I realize the SSD would not stop memory hungry web pages from locking the Pi into potentialy damaging swapping again, because I am on a Pi 3B+, and not yet spoiled by a Pi 4 with the spacious 4G Ram.

In order to avoid having to reload and reconfigure all my projects and system config yet again, to a clean Buster SSD this time, I instead, put my working 64G Buster SD card into a card reader, and used w32 imager to make an image of the workng and healthy 64G Buster card.

Next I used Etcher on an ubuntu 18.04 system to write that configured image, with all my configurations and projects, to a new 240G SSD. It took a little over an hour to write and verify. When then moved to the Pi (with no SD Card installed at all), it booted fine (though slower), and then up appeared my pre-configured Buster and python projects. My projects ran fine, and some of them much quicker. My chromium ran fine, and quicker, And I didn't have to update and reconfigure a clean Buster yet again.

So what's the problem? The yellow LED access light. When running off the SD Card, it hardly ever lit, except when I was purposely doing lots of drive I/O, or when some RAM and Swap hungry web page(s) would start chewing it up. I could literally let my Pi sit running for months, 24/7 with hardly any LED activity at all, if I wasn't actively browsing, or running something that would require lots of drive activity. If I'd quit from everything except the Desktop GUI, there would essentially be no LED activity at all, for days, while doing other work in and around the house, except when it would go out and update satellite orbital elements and process them in my python scripts. But now, with the Pi running off the SSD, even with only the Desktop GUI running after a cold boot, the yellow LED on the Pi flashes 5 to 10 fast pulses, every 1.5 to 2 seconds, always. It never stops doing that. There is no SD card in the Pi at all. Everything is booting and running off the SSD. I haven't yet expanded the system to fill the SSD, but the 64G (59G) image now on the SSD, and working, has 30G of the root partition available. With an SSD now, of course I am concerned that this activity will cause premature wear and tear on the SSD. So I am back to the SD Card until I hear wisdom for a solution in some replies.

I can add the results of whatever reports you ask me to provide, but kindly provide the exact syntax for the command/report.

So is there some config on my SSD that still thinks it is on the SD card? And if so, is it a few simple and quick edits in nano to aim it at the SSD location(s) to stop this constant access or attempt at access?

It seemed important to explain how I imaged the SD card and then put that on the SSD, preconfigured and working first as it was on the SD card.

UPDATE 2019-08-20:

I just used etcher (from ubuntu) to flash a clean Buster image on to the second SSD I had bought, instead of using an image I had created from a configured Buster SD card. The new clean Buster SSD booted up, resized the root system to use the remainder of the SSD, and went through the setup settings. However, it too flashes the yellow LED every 1.5 to 2 seconds. I am beginning to think this is some sort of alert rather than indicating SSD reads or writes ... perhaps an alert that there is no SD card installed?

If this is what is happening, anyone know how to tell it to ignore the fact that there is no SD card present, stop the alert(?), and yet continue to flash the LED when there are actual SSD reads or writes?

Thank you for any assistance.


Found the answer elsewhere.


Apparently it is related to there being no SD card inserted. I will try putting a formatted SD Card in tomorrow. If the flashing stops, I will mark my own post as the answer, encouraged that one can easily image a configured SD Card and then flash that to an SSD.


See my answer post below.

1 Answer 1


I purchased a new SanDisk Ultra 32G SD Card (it was the smallest in the store), for around $10 USD. I suppose an 8G SD Card would have been sufficient for this purpose. The 32G was preformatted fat32. With my RPI 3B+ powered off, I put the blank formatted SD Card in the boot slot on the RPI. The usb SSD was also connected. I powered up the RPI. It booted off the SSD quicker and better than before. Previously, without the blank SD Card inserted, I would need to cold power up once, wait about 30 seconds, then power down and immediately power back up. I thought perhaps the SSD drive was not getting itself ready before an RPI boot timeout. With the SD Card inserted, that problem went away. It now finds and boots off the SSD on the first power up. And the constant flashing LED problem even during inactivity, is now gone. Solved.

Although I can not provide a link to an official technical document that explains that this is indeed the official answer to a known official LED flashing state, from a Raspberry Pi 3B+ engineer(s), it does appear that this is what the situation was, and its solution.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.