another linux question

Home can be done as a separate mount. And the setup screen may include mention of it.

Be aware there is the concept of "merging" or "selective updates". This would be, if you assume the OS version is different or the DE version is different, and the settings files have more or fewer entries.

The difference between empty and populated, is a sign of how things are going.

If you wanted to mount a "different" /home on top, you could unmount the original /home and mount a different one.

With regard to a /home partition, there will be "dot files" or "dot directories". Your file manager (or your command line commands) need to be adjusted so dot items are displayed. The purpose of the dot is to hide them.

ls -a # show everything

The file manager may also have a setting, to display dot items. This is very helpful if merging materials into a /home.

Since I do not use this method, I have no further advice regarding the particulars of merging or what to watch out for.

My preferred method would be to just clone the drive and carry on.

Journaled file systems have a small amount of repair capability, and that could be why you're still able to boot right now.

Paul

You need /etc/passwd and /etc/group to preserve passwords, but if you recreate yourself with the old password should be as above (copy /home)

I would backup the whole of /etc and /home.

I'd also run dpkg --get-selections >> <somefile> as root, if you're not going to clone the drive, then this at least will tell you what you've forgotten to install later.

There are other things you could save, but the law of diminishing returns applies. /etc and /home will get the important stuff. Don't just restore the old /etc, use it as a reference when you find something configured wrong.

/etc/shadow actually - but this is the login password for the account, not logins and passwords for websites etc which live in your browser profile in your home directory. If you do a fresh install it'll set your account password anyway.

Once you have a new user on the new install, I'd do:

$ rsync -av /oldssd/home/fred/ /home/fred/

to copy everything in your account over from the old SSD to the current home directory, preserving permissions etc. You can do it from the GUI but you need to make sure all the hidden files are transferred, which rsync will do (and if it gets interrupted half way through, just run the command again and it'll pick up from where it left off)

It won't affect anything set up system-wide - those are typically things that ask for a password to change something, like installing packages - but better to set those up again from scratch.

Theo

When I upgrade my linux mint laptop I just use the backup tool that comes with the OS. So a clean install of mint, then restore my Home folder and software selection. I think Thunderbird needs to be backed up separately unless you are happy to just restore what is on the email servers.

Tim W

Am 28.02.2024 schrieb ajh snipped-for-privacy@loampitsfarm.co.uk>:

Your personal program settings and credentials are in your home.

The system accounts/passwords are in /etc/passwd and /etc/shadow. /etc/group is also relevant.

System-wide program settings are in /etc and I recommend only moving those files you intentionally customized.

Another handy tip when rebuilding such systems is to document every change you made to a vanilla system in order for it to be 'what you want'.

This changelog will be your guide to doing it next time.

It seems to me that is the way it is going, has already gone.

This changelog can be a script used to provision new machines/compute engines. A very good idea for a number of reasons:

But I never really liked hardware, I'm much happier with everything as code.

You can do that with a tool like Ansible. But it's not really something I'd recommend for a beginner, because you are probably making random changes based on blog posts or StackOverflow or whatever - and you don't know what those changes actually do, let alone how to transcribe them into an Ansible definition.

If you are maintaining a fleet of servers then sure, but I wouldn't do it for a single desktop machine.

Another tool is 'etckeeper', which makes a git repo with a commit for every time something changed in your /etc (including via package installs). That's more like an automating the 'changelog' side of things rather than scripting applying the changes (which you could still do from the repo if you really wanted).

Theo

I was amazed when my server died last week, that simply changing the disks over to a spare PC chassis simply worked.

The *only* issue was that the Ethernet card interface cane up with a different name on the new hardware, and I had to re-configure it for a static IP address.

Oh and a couple of tweaks to the hardware monitoring configuration, since it now had 4 cores, not two..

I worked for large companies and this is how the systems guys dealt with the desktops. From the user perspective, we weren't using something like Ansible, we made changes via a company mechanism which recorded the change for us. They started doing this 30 years ago, by 15 years ago all new software had to be packaged so we could install it via the company mechanism. Any problem with your desktop and support would just give you a new machine. They also took away our local admin rights, common changes needed to be performed via the company setup software.

Servers tend to be docker hosts and have very little customization. Docker containers hold all the system setup.

Mentioning source code control and automated recording is interesting in that SCC systems tend to store state as deltas, changes between one version and the next (even git does this eventually), to save storage space. This is what is happening to systems, rather than backup an entire systems drive you just record how it has changed from a base system.

Am 28/02/2024 um 18:10 schrieb ajh:

One word: rsync.

For some reason I used to know, Linux began creating "random" names for network cards a while back from a fresh install. Probably to make it harder to look for a known value in scripts.

Or puppet.

However the trend towards containerisation means we are running quite a lot of systems on Docker. Which makes the host OS and it's configuration moot.

Are you referring to the "systemd" naming scheme for hardware ?

"lspci -s 01:00 01:00.0 Ethernet controller: Intel Corporation I350 Gigabit Network Connection (rev 01) 01:00.1 Ethernet controller: Intel Corporation I350 Gigabit Network Connection (rev 01)

This card happens to sit on PCI bus 1 (enp1), slot 0 (s0). Since it’s a dual-port card, it has two function indexes (f0 and f1). That leaves me with two predictable names: enp1s0f1 and enp1s0f0 "

Whereas if I run a VM, it lists this:

Network: Device-1: Intel 82540EM Gigabit Ethernet driver: e1000 IF: enp0s3 state: up speed: 1000 Mbps duplex: full mac: 08:00:27:d5:ba:39 Device-2: Intel 82371AB/EB/MB PIIX4 ACPI type: network bridge driver: piix4_smbus Device-3: ASIX AX88179 Gigabit Ethernet type: USB driver: ax88179_178a IF: enx3c8cf8ff86e9 state: down mac: 3c:8c:f8:ff:86:e9

enp0s3 only has one port, and is on a PCI/PCIe virtual bus while enx3c8cf8ff86e9 is using its MACADDR as a name.

I plugged in the USB3 to GbE adapter (ASIX), knowing it would offer some sort of contrast. It was not what I expected.

It's not exactly "eth0".

Paul

Am 01/03/2024 um 05:29 schrieb Paul:

Are you sure it's die to systemd and not udev?

One supposes so. If anything that used to work is now broken, it's generally systemd.

$ lspci | grep Ether

No, that would make it just *too* easy, wouldn't it?

Related to this, I recently dicovered the "newusers" command which was handy when matching a fresh install to the previous one, whilst also avoiding copying any legacy users I no longer needed...

#Paul