It looks like my ssd is having problems, very occasionally failing to
boot into the rootfs and staying in initramfs, reporting discrepancies
(widows and orphans), in sda2. Easily sorted but...

So I have bough a bigger ssd and will do a fresh install but cannot
remember if I simply have to copy Home from the old ssd to the new
operating system such that all my logins, passwords and preferences are
preserved.

Any pointers to seamlessly make the move?

On 2/28/2024 1:10 PM, ajh wrote:
> It looks like my ssd is having problems, very occasionally failing to boot into the rootfs and staying in initramfs, reporting discrepancies (widows and orphans), in sda2. Easily sorted but...
>
> So I have bough a bigger ssd and will do a fresh install but cannot remember if I simply have to copy Home from the old ssd to the new operating system such that all my logins, passwords and preferences are preserved.
>
> Any pointers to seamlessly make the move?

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.

https://forums.linuxmint.com/viewtopic.php?t=392148

In the example, you can see /home is separate from / .

https://forums.linuxmint.com/download/file.php?id=85029&t=1

The way that works, is first / is mounted, then /home is
mounted on top of / . If /home is NOT mounted for example,
there is an empty directory owned by root, at /home on the /
partition. That is the mount point which the /home mount
goes on top of. Once /home is mounted, then the "contents"
of /home, match the contents of the /home partition.

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

On 28/02/2024 18:10, ajh wrote:
> It looks like my ssd is having problems, very occasionally failing to
> boot into the rootfs and staying in initramfs, reporting discrepancies
> (widows and orphans), in sda2. Easily sorted but...
>
> So I have bough a bigger ssd and will do a fresh install but cannot
> remember if I simply have to copy Home from the old ssd to the new
> operating system such that all my logins, passwords and preferences are
> preserved.
>
> Any pointers to seamlessly make the move?

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)

--
When plunder becomes a way of life for a group of men in a society, over
the course of time they create for themselves a legal system that
authorizes it and a moral code that glorifies it.

Frédéric Bastiat

On Wed, 28 Feb 2024 19:45:26 +0000
The Natural Philosopher <tnp@invalid.invalid> wrote:

> On 28/02/2024 18:10, ajh wrote:
> > It looks like my ssd is having problems, very occasionally failing
> > to boot into the rootfs and staying in initramfs, reporting
> > discrepancies (widows and orphans), in sda2. Easily sorted but...
> >
> > So I have bough a bigger ssd and will do a fresh install but cannot
> > remember if I simply have to copy Home from the old ssd to the new
> > operating system such that all my logins, passwords and preferences
> > are preserved.
> >
> > Any pointers to seamlessly make the move?
>
> 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.

--
Joe

The Natural Philosopher <tnp@invalid.invalid> wrote:
> On 28/02/2024 18:10, ajh wrote:
> > It looks like my ssd is having problems, very occasionally failing to
> > boot into the rootfs and staying in initramfs, reporting discrepancies
> > (widows and orphans), in sda2. Easily sorted but...
> >
> > So I have bough a bigger ssd and will do a fresh install but cannot
> > remember if I simply have to copy Home from the old ssd to the new
> > operating system such that all my logins, passwords and preferences are
> > preserved.
> >
> > Any pointers to seamlessly make the move?
>
> 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)

/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

On 28/02/2024 18:10, ajh wrote:
> It looks like my ssd is having problems, very occasionally failing to
> boot into the rootfs and staying in initramfs, reporting discrepancies
> (widows and orphans), in sda2. Easily sorted but...
>
> So I have bough a bigger ssd and will do a fresh install but cannot
> remember if I simply have to copy Home from the old ssd to the new
> operating system such that all my logins, passwords and preferences are
> preserved.
>
> Any pointers to seamlessly make the move?

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 <news@loampitsfarm.co.uk>:

> It looks like my ssd is having problems, very occasionally failing to
> boot into the rootfs and staying in initramfs, reporting
> discrepancies (widows and orphans), in sda2. Easily sorted but...
>
> So I have bough a bigger ssd and will do a fresh install but cannot
> remember if I simply have to copy Home from the old ssd to the new
> operating system such that all my logins, passwords and preferences
> are preserved.

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.

On 29/02/2024 09:14, Marco Moock wrote:
> Am 28.02.2024 schrieb ajh <news@loampitsfarm.co.uk>:
>
>> It looks like my ssd is having problems, very occasionally failing to
>> boot into the rootfs and staying in initramfs, reporting
>> discrepancies (widows and orphans), in sda2. Easily sorted but...
>>
>> So I have bough a bigger ssd and will do a fresh install but cannot
>> remember if I simply have to copy Home from the old ssd to the new
>> operating system such that all my logins, passwords and preferences
>> are preserved.
>
> 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 is dangerous to be right in matters on which the established
authorities are wrong.”

― Voltaire, The Age of Louis XIV

On 29/02/2024 09:50, The Natural Philosopher wrote:

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

1 If there is a hardware problem. You can switch systems, without the
need for costly investigation.
2 Runtime environments are reproducible, good for testing.
3 An audit trail to explain when and why something broke.
4 You no longer need to back up system partitions.

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

Pancho <Pancho.Jones@proton.me> wrote:
> On 29/02/2024 09:50, The Natural Philosopher wrote:
>
> > 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:
>
> 1 If there is a hardware problem. You can switch systems, without the
> need for costly investigation.
> 2 Runtime environments are reproducible, good for testing.
> 3 An audit trail to explain when and why something broke.
> 4 You no longer need to back up system partitions.
>
> 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

On 29/02/2024 10:26, Pancho wrote:
> On 29/02/2024 09:50, The Natural Philosopher wrote:
>
>> 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:
>
> 1 If there is a hardware problem. You can switch systems, without the
> need for costly investigation.
> 2 Runtime environments are reproducible, good for testing.
> 3 An audit trail to explain when and why something broke.
> 4 You no longer need to back up system partitions.
>
> But I never really liked hardware, I'm much happier with everything as
> code.

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

--
The New Left are the people they warned you about.

On 29/02/2024 11:07, Theo wrote:
> Pancho <Pancho.Jones@proton.me> wrote:
>> On 29/02/2024 09:50, The Natural Philosopher wrote:
>>
>>> 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:
>>
>> 1 If there is a hardware problem. You can switch systems, without the
>> need for costly investigation.
>> 2 Runtime environments are reproducible, good for testing.
>> 3 An audit trail to explain when and why something broke.
>> 4 You no longer need to back up system partitions.
>>
>> 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 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:
> It looks like my ssd is having problems, very occasionally failing to
> boot into the rootfs and staying in initramfs, reporting discrepancies
> (widows and orphans), in sda2. Easily sorted but...
>
> So I have bough a bigger ssd and will do a fresh install but cannot
> remember if I simply have to copy Home from the old ssd to the new
> operating system such that all my logins, passwords and preferences are
> preserved.
>
> Any pointers to seamlessly make the move?

One word: rsync.

--
Ottavio Caruso

On Thu, 29 Feb 2024 11:40:03 +0000, The Natural Philosopher wrote:

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

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.

On Thu, 29 Feb 2024 11:07:21 +0000, Theo wrote:

> Pancho <Pancho.Jones@proton.me> wrote:
>> [quoted text muted]
>
> You can do that with a tool like Ansible.

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.

On 2/29/2024 2:10 PM, Jethro_uk wrote:
> On Thu, 29 Feb 2024 11:40:03 +0000, The Natural Philosopher wrote:
>
>> 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.
>
> 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.
>

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 referring to the "systemd" naming scheme
> for hardware ?

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

--
Ottavio Caruso

On 01/03/2024 05:29, Paul wrote:

>
> Are you referring to the "systemd" naming scheme
> for hardware ?
>
One supposes so. If anything that used to work is now broken, it's
generally systemd.

> "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
> "
>
$ lspci | grep Ether
03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 0c)
$ ifconfig -a
enp3s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500

[,,,]

> It's not exactly "eth0".

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

--
"First, find out who are the people you can not criticise. They are your
oppressors."
- George Orwell

Theo <theom+news@chiark.greenend.org.uk> wrote:
> /etc/shadow actually

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