Installer shouldn't replace bashrc

I’m an experienced Linux user, having used Arch before, and after installing the latest EndeavourOS got really surprised when I found out that the installer simply replaced my ~/.bashrc without any warnings or backups that I could find.
Yeah I know I should have backups and etc. but I strongly believe this should be considered a bug, the installer should either not touch existing home files or at least backup them.
I’m also really surprised no one noticed this before.


Just out of sheer curiosity… what installation option did you choose? Also what kind of partitioning scheme do you have? Do you have your root and home in separate partitions?

what kind of installation options did you choose?

Online Gnome install, with systemd-boot. Not sure what other options do you mean.

Also what kind of partitioning scheme do you have? Do you have your root and home in separate partitions?

I have a separated home partition, when installing I chose manual partitioning, mounted root on my “root partition” with formatting it, and mounted may “home partition” on /home without formatting. AFAIK, the only thing “wrong” that happened was the replacement of my bashrc. Which btw, seems to be the liveiso version of it, since it contains stuff to change PS1 if the user is “liveuser”, and it’s not the same as the one in /etc/skel/

Just to confirm, everything else inside your .config is still there, right?

Yes. My .profile is fine too. I checked the last modified dates of the files in my home, and the only unintended change is .bashrc

This is certainly interesting.

If you’d chosen a different user name during the reinstall, you’d still have your original .bashrc file, since there would be an additional directory (with the name of your old user name) under the new /home/ containing all your personal data before the re-install.

But if you choose the same user name as before, the directory structure remains the same, so the generated .bashrc file will have the same path as the previous file and be overwritten.

You should bring this to the attention to Calamares’ authors so that they modify the code to skip the generation of the .bashrc if a file with that path name already exists.

The installer does install a .bashrc into the newly created user. If the user you choose is to create in the installer is the same as a username in an existing partition it will be overwritten currently.

Well, IMHO this should not be done so carelessly. At least a backup should be done if the file already exists. I can open a bug report in a more suitable place if needed, just point me where (this forum is the pointer I got from EndeavourOS web site)

1 Like

Reporting it here is fine.

Yeah, that seems like an oversight to me. It definitely shouldn’t do that. Welcome to the forum, @rcoacci, thanks for the report.

1 Like

Maybe i don’t get it, but why it should not do that? It’s always how skel worked and designed to work.

It’s a feature, not a bug…It’s what /etc/skel is created for - a template for creation of new user, so any files inside that dir will create / replace files in your new / existing user’s home directory when new user gets created.

If for some reason user decides that it’s wise to create same user name during installation process, especially without backup (:face_with_raised_eyebrow:) - than it’s exactly correct expected behavior of how Linux system should work.

At best what we can do on installer level, is have a hand-holding notification, something like that perhaps:

/home/<username> already exists, so some files will be overwritten with /etc/skel, please make a backup of your /home/<username> before proceeding next.


Perhaps we should take a deeper look into the use case. Why, for instance, would a user be compelled to use an existing directory as the home directory for the new installation? The most likely explanation for such a use case is that perhaps the user would like to retain everything inside his previous home directory. If the user is interested in a clean slate, they most likely would format all partitions to begin with. The installer should therefore take that into consideration and choose not to overwrite the files inside the directory.

Bash package itself is using skel too for it’s default bashrc.

And installer does not have a /home reuse option.
There is request for this upstream for a long time but nothing to implement.

Would be impossible to this k of every possible way to install… as the installer can be used in a very open way…

Not to say that we will not take care of it… there are may better ways to handle skel other custom files we want to ship.
Could be a custom useradd config p.e. and if we include home reuse option it would never overwrite existing files.

The recommended way to reuse home is to backup and manually replace after first boot.
Or in the case we see here move the users home to something like username.bak by renaming the folder before the reinstall so you can keep files untouched and replace from installed system.


Peeping into the .bashrc of an experienced rider, Erik Dubois:

 #moving your personal files and folders from /personal to ~
 alias personal='cp -Rf /personal/* ~'

 #create a file called .bashrc-personal and put all your personal aliases
 #in there. They will not be overwritten by skel.

 [[ -f ~/.bashrc-personal ]] && . ~/.bashrc-personal

Yes, there are two different options here.
the access control of /personal should be changed IMHO

drwxr-xr-x   2 root root  4096 nov   24 09.57 personal
1 Like

Definately NO!

Check Archwiki for how configuration is done, and also man useradd.
skel contents are only copied for a newlly created new user, with useradd -m.
Even if useradd user creation overwrites existing files (too long from the last time I used it in such a case), in no way should a system activity touch a user’s $HOME (it’s an assylum! :smile: ). That’s the general rule that is used, when no other more specific directive exists :person_shrugging: .

It’s for each distro to decide how to treat cases like OP (and other users’). This case is at least as old as I remember Linux, since re-using a home dir is the usual way to retain previous configuration.
Of course, there may be issues when moving from non-Arch to Arch-like distros, but this is what should be dealt of, and not a re-installation/distrohop from an Arch-like to Arch-like distro home dir.

It’s about opinions on how to handle it, so it is up to the distro team/devs .
AFAIK, (Arch)Linux and systemd have too many ways and utilities to handle difficult cases, so IMHO, it’s a matter of desire and knowledge :smiling_face: .

1 Like

I never did such thing with using existing home dir with same user name, but i was under impression that:

useradd -m

should overwrite existing files…Should test in vm, just to make sure :upside_down_face:

It doesn’t. When useradd detects the directory already exists, it doesn’t copy files from skel.


Exactly, and so is for myself, but it is a personal precaution/workaround, because each distro can (and should) have its own way to do it, and until we learn about it, we (or anyone with some Linux experience) have to safeguard our preferences/configs. :wink:

if, during installation, it is run in the chroot part :wink: , instead of outside (or however) and later cp the home contents to the new $HOME.

I don’t know about that…

Maybe we should just

sudo rm -rf /

Instead :rofl:

P.S. Do NOT!!! run this command kids.

1 Like