If you upgrade by doing a reinstall, can you take several user accounts with you?

Support & Help Requests
, ,
1

Each of my two Linux machines has two user accounts, one admin account for me and one non-admin account for someone else. In each case, there’s a partition for the / directory, including everything except the /home directory, and another partition for the /home directory.

Suppose I want to upgrade to Questing by reformatting the / partition and doing a clean install of Questing on it. Could I, then, keep both the admin account and the non-admin account through the process, or at least somehow recreate the non-admin account after the upgrade, and still log into the non-admin account and access the files there after the upgrade?

Thank you in advance!

2

BEFORE you do the install/upgrade, you should "detach" the /home partition, by

  • create a minimalist version of you admin HOME directory under /home2 (i.e. containing only the profile files and empty directories that you would see from fresh install)

  • from a Live boot session,
          mv /home to /homegood
          mv /home2 to /home

  • perform your install/upgrade, affecting only the ROOT disk or partition,

  • manually update your /etc/fstab to have /home point to your secondary partition,

  • swap the 2 HOME directories,
          mv /home /home2
          mv /homegood /home

  • reboot and you are good to go!

BUT ... you will encounter a race condition unless you do the following ...

After you've done the install/upgrade on the primary partition (/) with a "dummy" definition for the default user (usually uid 1000, namely your usual admin-capable account), you can then modify your

  • /etc/fstab

to specify the drive/partition that will be the mountpoint for

  • /home .

BUT ... you need to define some constraints for the login and user session processes. That is done by defining constraints within targets for specified elements under systemd control.

In the following discussion, I outlined what I had to do to prevent the race condition that you will encounter if you do not define such "pre-requisites" as targets.

In my case the "HOME" partition is at /DB001_F2, referenced in the following discsussion:

1 Like
3

Thank you for putting in the work to work all that out and post it, @ericmarceau . Unfortunately, I have some questions and some doubts.

First of all, my Linux skills are only good enough to understand about half of what you write. Second, I don’t really understand how the half of your instructions where I do understand what you want would help me with my underlying problem. And third, as far as I can see, some of your instructions would have very bad consequences if I would follow them, except that I wouldn’t be able to follow them in the first place.

On point 1: I have no idea how to manually update my /etc/fstab to have /home point to my secondary partition. I have no idea what a race condition is. I have no idea how to define constraints for the login and user session processes. I have no idea how to define constraints within targets for specified elements under systemd control.

On point 2: As far as I can see, the underlying problem is that every fresh install starts out with only one user - the admin - and if you then try to create additional users, the system will, because the designers didn’t think this through properly, refuse to connect these additional users to existing user directories within the /home directory. I don’t see how following any of your directions would get me around that problem.

On point 3: As I said, my /home directory is in one partition, whose mount point is /home, and all my other directories (except for some highly technical ones about which I know nothing) are on another partition, whose mount point is / . So, if I would follow your instructions and do

`mv /home to /homegood`
`mv /home2 to /home`

this would mean that each of these two directories would have to be moved to a different partition. Which would mean that it would have to be copied. First, in the case of my initial /home directory, that would take an extremely long time. Second, it would mean that, as soon as I would reformat my / partition for the fresh install, everything that had been in my initial /home directory would be lost. Which would be extremely bad. And third, it wouldn’t work anyway, because my / partition isn’t nearly big enough for all the files in my /home directory. Or do you mean that I should do those things to the user directories within /home ? In that case, you should clearly say so.

1 Like
4

Please understand that I took 4 different stabs at composing a reply, each one using a different approach. In the end, the below will be my only and considered response ...

Please note that the fact that @Bombilla has "liked" my post indicates a basic "vetting" of what I put forth as an "appropriate response".


Have you read one of the many "Intro to Linux" books ... and ... one of the many Intro to Linux Admin" books ... and ... used a Live (or not) session to practice the exercises that were being offered to perform various actions?

If NOT ... I strongly suggest that you first take a step back to do those as foundational preparation before coming at this again, because some of the comments/questions raised indicate, in my opinion, possibly erroneously, that you don't have what I would consider a sufficient awareness of "how things work" in Linux to have understood my above outline of the necessary steps ... which implied other steps not explicitly outlined.


To give you a sense of the expected knowledge ...

  • expectation that all actions performed from a Live ISO session ... because the mountpoint for /home would be busy and not moveable if the rename was attempted if you simply booted up your system.

  • because you are working from Live, the /home is not pointing to the physical location of where your second partition is located. It is only an empty directory!

The above would be understood by anyone with "basic", not even complete, knowledge of admin skills.


"Race conditions" is referring to any situation where correct functional execution is depending on the events being performed in a proper sequence which ensures that required tasks are performed before subsequent dependant tasks call upon the results of those earlier tasks.

The entire architectural design of systemd was to provide fine control of the distinct various kernel/os elements by providing a mechanism whereby the specification of pre-requisites, before initiating those dependant tasks, were confirmed as having been met.

If the "dependent" has "raced" past the "provider", starting before the provider has put the dependency in place for usage, that is what is identified as a race condition.

A basic summary of what is involved is available from the below:


I would also ensure that you have a full backup of /home by itself, but more importantly, to protect the contents of /home, if that is a separate disk, simply unplug that disk, leaving only the root disk exposed to actions performed by an ISO-based install process. After the install, you can

  • recreate the "dummy" directory for the other non-admin users, making sure you use the same USERNAME and UID and GID which they had for the earlier configuration;

  • re-connect the drive for /home then complete the final tweaking of /etc/fstab for the drive/partition that has the proper /home;

  • reboot, and the contents of the pre-boot /home on root partition will disappear since the /home is being re-mapped to the /home on the secondary disk/partition.