You are not logged in.
Software update makes symbolic link disappear!
I have a laptop that I had not touched in months. Last night I logged in to it and ran pacman to upgrade. So far all normal. Then I rebooted. I was greeted with the lightdm prompt as normal, entered my password, but could not go further. I logged in from my desktop over ssh and was immediately told that my home folder could not be found. Further investigation showed that /home, which previously was a symbolic link to a folder in another partition, had been 'transformed' in an empty folder! I deleted the empty home folder and recreated the symbolic link and all was good, I could log in as normal.
Now some some details.
These are my folders before I recreated the link. Note the timestamp on the home folder (31st May), and that it is a regular folder, not a symbolic link as it was previously.
// ll
total 64
drwxr-xr-x 18 root root 4096 Aug 23 01:03 ./
drwxr-xr-x 18 root root 4096 Aug 23 01:03 ../
lrwxrwxrwx 1 root root 7 May 31 01:39 bin -> usr/bin/
drwxr-xr-x 5 root root 4096 Jan 1 1970 boot/
drwxr-xr-x 21 root root 4380 Aug 23 01:50 dev/
drwxr-xr-x 83 root root 4096 Aug 23 01:51 etc/
drwxr-xr-x 2 root root 4096 May 31 01:39 home/
lrwxrwxrwx 1 root root 7 May 31 01:39 lib -> usr/lib/
lrwxrwxrwx 1 root root 7 May 31 01:39 lib64 -> usr/lib/
drwx------ 2 root root 16384 Jun 1 2020 lost+found/
drwxr-xr-x 2 root root 4096 May 19 2020 mnt/
drwxr-xr-x 2 root root 4096 May 19 2020 opt/
drwxr-xr-x 4 root root 4096 Mar 16 23:35 pool1/
dr-xr-xr-x 246 root root 0 Aug 23 01:49 proc/
drwxr-x--- 8 root root 4096 Aug 23 02:38 root/
drwxr-xr-x 25 root root 640 Aug 23 01:50 run/
lrwxrwxrwx 1 root root 7 May 31 01:39 sbin -> usr/bin/
drwxr-xr-x 4 root root 4096 Jun 1 2020 srv/
dr-xr-xr-x 13 root root 0 Aug 23 01:49 sys/
drwxrwxrwt 8 root root 200 Aug 23 01:50 tmp/
drwxr-xr-x 9 root root 4096 Aug 23 01:17 usr/
drwxr-xr-x 13 root root 4096 Aug 23 01:19 var/
And this is the empty home folder.
// ll home
total 8
drwxr-xr-x 2 root root 4096 May 31 01:39 ./
drwxr-xr-x 18 root root 4096 Aug 23 01:03 ../
I recreated the link and all was good. The ln command was saved in my zsh buffer so no need even to type it. The pool1 folder is defined in fstab as pointing to another partition.
// rmdir home
// ln -s /pool1/home home
So the immediate issue (ability to log in) is solved. If the link disappears again I have a plan B which is to use a bind mount defined in fstab instead of a symbolic link.
What I don't know is what caused the disappearance of the link. More precisely, how could a symbolic link be transformed into a plain folder and the timestamp on it not being changed (still May 31st)! Mind-boggling!
I ran pacman from my desktop over ssh and the output was saved. I looked at it and all looked normal. Because I had not touched this laptop in months (since late May or early June) there were a few gigabytes of updates. What package update caused the issue? No idea, except that I would bet an euro or two on systemd!
Any ideas?
Last edited by archdub (2021-08-23 18:04:03)
Offline
$ pacman -Qo /home
/home/ is owned by filesystem 2021.05.31-1
(Note the "date as version".) Except for files in a PKGBUILD's backup array, you can't just replace files owned by a package, because they will be overwritten during upgrades. I would expect a "conflicting files" error, though, but I see some threads (old, perhaps not accurate anymore -- symlink handling has changed over the years) where pacman deemed it okay to replace a _broken_ symlink with a directory. If the other partition wasn't mounted during the upgrade, that could be it.
To prevent this from happening again: instead of replacing the directory, just bind mount over it.
Offline
Use a bind mount instead of a symbolic link.
Offline
$ pacman -Qo /home /home/ is owned by filesystem 2021.05.31-1
(Note the "date as version".) Except for files in a PKGBUILD's backup array, you can't just replace files owned by a package, because they will be overwritten during upgrades. I would expect a "conflicting files" error, though, but I see some threads (old, perhaps not accurate anymore -- symlink handling has changed over the years) where pacman deemed it okay to replace a _broken_ symlink with a directory. If the other partition wasn't mounted during the upgrade, that could be it.
Thanks, Raynman, you hit the bull's eye. It was the 'filesystem' package. There was no warning of an error despite the partition being mounted (see below). I will mark this thread as solved.
:: Processing package changes...
(1/2) removing qca [######################################################################] 100%
(2/2) removing libcanberra-pulse [######################################################################] 100%
( 1/604) upgrading linux-api-headers [######################################################################] 100%
( 2/604) upgrading iana-etc [######################################################################] 100%
( 3/604) upgrading filesystem [######################################################################] 100%
( 4/604) upgrading glibc [######################################################################] 100%
Last edited by archdub (2021-08-24 05:06:34)
Offline
Use a bind mount instead of a symbolic link.
Thanks, Allan, will do that.
Offline