After a dnf update to kernel 5.18.18, my video driver no longer worked, so, after trying a few other things, I reinstalled F36, being sure to save /home in the blivet-gui menu.
First time I’ve done a btrfs reinstallation, so I saved a copy of /home first.
That mostly worked, but the files in /home were only those created before May 14th, the day I installed F36 for the first time.
For example, I download daily crossword puzzles. My backup has them all from May through August 22; my new /home//Downloads directory has only the first 14 in May.
So there must be something I don’t understand about btrfs, blivet-gui, or Fedora’s installation process.
By default, /home is a subvolume of / on the same partition, so it’s possible that if the partition for / were reformatted, that /home might have gotten blown away with it. If that’s the case, then the Blivet UI needs to be more obvious that this is the likely result. As always, I strongly recommend you backup your data before attempting a reinstall like this with any filesystem.
Thanks – but I would have understood having all of /home blown away. What I’m puzzled by is the way only those files in /home which were created after the last full install were deleted; all the files older than the initial Fedora 36 installation are still there.
And, yes, backing up is a good idea – even if you’re not attempting a reinstall.
Oh, sorry I misunderstood. Any chance you may have restored from snapshot to some point around that time?
Nope. I don’t use snapshotting. I probably should do something more sensible that simply copying everything to a backup HD – but that’s simple and works without having to learn anything new …
And, in this case, I’m completely covered: No data has been lost.
I should probably read up on the inner workings of brtfs and its subvolumes.
Any chance you might have done an rsync from that backup at some point but included the
--delete flag? That would do it.
No; I never use rsync on my personal data – just work. But that was a good idea.
I have a very large .bash_history limit (100k), so I can be sure of that.