USB boot drive oddity

[treeHouse]

I've cloned my sd card to an external usb SSD drive. All seemed to go well, and it behaves wonderfully.

But after a reboot, it is right back to what it was initially after the clone. Nothing I do is saved.

So its as if it is write only, but it is not. It confirms things are saved--and I can close and open the files to confirm this--but after a reboot, it is all gone.

I first noticed it trying to tweek config.txt
Repeated it with test files saved to desktop.

Rpi3 with a sandisk ssd plus, in a seagate usb3 exernal case (origianal 3tb conventional drive died).

Does anyone have any clues for troubleshooting this?

[treeHouse]

Seems to be working now. I don't know what was going on before.

Maybe the whole thing was a misperception due to lack of sleep.

So, if your hard drive decides not to do its job, the official technical solution is to walk away for a bit, and then give it another go.

[davidcoton]

So, if your hard drive decides not to do its job, the official technical solution is to walk away for a bit, and then give it another go.

That is a very productive fault-fixing strategy.
The only better one I know is threatening faulty equipment with a hammer.
It is important that the Pi (or whatever) believes you will use the hammer.
It is equally important that you never do.

[treeHouse]

Well, I think I will need to step-up my technical strategy to the hammer.

Once again, a piece of data was fictitiously saved. I know it was not in my head, because my daughter was present. I was providing an impromptu linux lesson, in this case how to get an application only showing in the 'other' category to show up in a more appropriate place.

We used vim to alter the '.desktop' file way down in '/var', rebooted. I know, I could've just restarted the task bar (couldn't remember the command), or logged out/in--but I pressed the wrong button 'cause I'm tired.

And it worked just as expected, moved from 'other' to 'sound and video'. Yay!

Some time later (and a smattering of restarts), we went back to relaunch said app, and it was no longer in its newly appointed proper category.

So I popped open the '.desktop' file and it was in its original state!

I read through debian's notes on using SSDs and thought I hit all the relevant points--including drive firmwares, and incompatable devices. Is there some cacheing behavior that goes on in SSDs that needs to be addressed?

tl;dr: Altered file in '/var', it accepted alteration, proven after 1st restart. Several restarts later it 'reverted' to original state. And I have a witness.

[treeHouse]

Just in case anyone comes to this post looking for answers, I figured I'd do a follow up.

I ended up hosing that particular install (It was a series of ill timed power outages during installs, and I ended up in a fsck/reboot loop -- rather that fix it I just started over).

Rather than back up from my image, I decided to start from scratch, headless, and add my own gui, as per the excellent tutorial in the raspbian thread.

Anyway, I have not experienced the "lost data cache" issue at all in this install, so I'm feeling more confident.