Join us on our own very special Reddit on /r/Linuxers.
Reinstall or copy over ("Should I Stay or Should I Go?")
Eike 11 Jan
This is somewhat following up my SSD post...
(@Liam, we've got a Hardware forum, why is there no Software forum?)

So I bought a new SSD, size one TB, to replace my last HDD.
Just for fun I ran basic benchmarks on it to find out, to my surprise, that it's supposed to be five times faster than the existing SDDs in my system.
So now I feel the urge to move over my main system to the new SSD, bringing back an old question:

Should I (the current installation) stay or should I go?

I (being me again) started using Debian as my main system in 1998. After some troubles, I had a stable system which I ran for at least a decade, more like 1 1/2 of them. In the end, after an upgrade, I couldn't start X anymore due to a very old entry in my Xorg.conf (or was it XF86Config?) which the current Debian didn't expect. I reinstalled a fresh version of Debian and copied over my home directory.

Now, my current system might be born in 2016, I don't know for sure. It had several Debian upgrades. I guess that some stuff is just left as it is during upgrades, but would be done differently (in a more modern way) when installing a fresh system with a new version.

So, technical question: What would I be missing by copying the stuff over to the new SDD keeping the upgraded 2016 Debian system?

Philosophical question: To reinstall or not to reinstall?

Technical question again: What's the best way to do either?
damarrin 11 Jan
How about you do a fresh install and see how you like it? Copy some basic stuff, use it for a few hours? If you see no benefit, just clonezilla, or whatever the cool kids do these days, your current system onto the new drive and be done with it.
Eike 12 Jan
I don't expect anything exciting that's actually visible to the user (do you?). What could be different between the two methods is more on the technical side IMHO. I would name 'em if I knew 'em :D , but more like having an old startup system (whatever might be better here), a read-only /usr/ directory, such things.
denyasis 12 Jan
I've struggled with the same question on my Debian stable home server (same install since 2010), when I replaced the hard drive about a year ago.

Philosophical: I think the problem with most rolling type distros like debian and others is old confs and packages. Apt won't automatically overwrite or update confs you've edited, so it's very easy for them to become stale and eventually cause problems when old stuff gets deprecated.

I would assume there are also potential problems with technology changes. I know some time ago, debian switched out MySQL for mariadb. Apt did the switch for me and removed MySQL with no issues, but I do wonder how projects that might not be drop-in would work, like Wayland instead of x11.

I would say there are two things to consider if you are thinking of copying vs reinstallation:

1) How old is the original install? Are you getting to the point where new stuff isn't working because the configuration is too old (assuming packages are up to date)?
2) How custom is your install? Do you have a bunch of modified confs in /etc or tons of stuff in www-data or opt, etc etc? How easy is it to back those up?

Technical: if you want to copy the installed system to the new SSD, it's actually pretty easy. dd does it without a hitch. I took both drives and plugged them into my desktop and dd'd one to the other. Then I used gparted to expand the partitions on the new drive (and mark it bootable). If you don't have a spare computer to plug them into, you can do it in a "live" environment off a USB stick and do the same thing. I think Clonezilla does basically the same thing but with a nice interface.
Cloning: You can clone the stuff from the old drive to the new drive by booting from a live USB environment and dd $OLD_DISK to $NEW_DISK. mount $NEW_DISK and edit /etc/fstab to mount your partition(s) by block device name instead of UUID(both disks will have the same UUID and will cause confusion at boot, possibly hanging the system or alternating which device it boots from)ex: /dev/nvme0n1p1 /

save your fstab changes and reboot your system. disadvantages of this are that if you are using a full UEFI boot, you may have to go thru some extra fiddling to have a correct UEFI boot entry. consult da googles for more info on managing uefi boot entries with linux.

Fresh Install: probably the best way to go. Install the OS and after installation don't reboot yet. mount $OLD_DISK and copy everything from $HOME to (i'm using Ubuntu references here since that's what i'm familiar with) /target/home/$USER


mount -o bind /dev /target/dev
mount -o bind /proc /target/proc
mount -o bind /sys /target/sys
cp /etc/resolv.conf /target/etc
sudo chroot /target

once you've chroot'ed change the ownership of everything under the $USER_HOME directory to the new system's user.

as well, while in the chroot you can do updates and install any packages you want. Also a good idea to install Nvidia drivers if you have an Nvidia GPU and use the proprietary drivers.

once that's done you can reboot into your new OS install.
Eike 8 Apr
Only some months later, I decided to go the reinstall way.

KDE's database service akonadi made problems, but then, it also did the last-but-one upgrade. :-/

The new system feels fresh, but every now and then, I have to copy over something from the old system or install something that's missing (I didn't want to automatically install all packages I had on the old system either).
While you're here, please consider supporting GamingOnLinux on:

Reward Tiers: Patreon. Plain Donations: Liberapay or PayPal.

This ensures all of our main content remains totally free for everyone with no article paywalls. We also don't have tons of adverts, there's also no tracking and we respect your privacy. Just good, fresh content. Without your continued support, we simply could not continue!

You can find even more ways to support us on this dedicated page any time. If you already are, thank you!
Login / Register

Or login with...
Sign in with Steam Sign in with Twitter Sign in with Google
Social logins require cookies to stay logged in.