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:
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.
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.