How to Change with CLI the mountpoint of /home in Fedora Silverblue 34

@computersavvy and @guiltydoggy

Thanks really both for your help. Maybe a reminder of my first post in this thread:

The lsblk -f and /etc/fstab of my INITIAL system - which is created from a standard Fedora Silverblue install - without any customization (using Anaconda and automatic partitioning)

You can assess that /dev/sda3 is mounted to /var/home and not /home , so this is standard issue for Silverblue and I’ve check it with constancy, many new installs over.

Furthermore as requested by @guiltydoggy :

$ ls -la /home
lrwxrwxrwx. 3 root root 8 10 août   2021 /home -> var/home
$ ls -la /home/
total 0
drwxr-xr-x. 1 root         root          24 10 août   2021 .
drwxr-xr-x. 1 root         root         262 14 mars  20:49 ..
drwx------. 1 mahdiaqallal mahdiaqallal 354  9 avril 17:44 mahdiaqallal
tail -6 /etc/fstab
UUID=75a22715-dae3-4865-855a-d825b988c892 /                       btrfs   subvol=root,compress=zstd:1 0 0
UUID=caf6bd1f-c66b-4887-b5c7-f086c96ed899 /boot                   ext4    defaults        1 2
UUID=D48D-5DFE                            /boot/efi               vfat    umask=0077,shortname=winnt 0 2
UUID=75a22715-dae3-4865-855a-d825b988c892 /home                   btrfs   subvol=home,compress=zstd:1 0 0

I’have already tried this both ways as specified in my earlier response:

In either case the drive containing the /home subvolume is mounted by the system and recognized as $HOME :

Please see my earlier response:

As you can see UUID for 7e81da8e-7058-44af-8496-695540dd8694 on /dev/sdc (which is where I want /home to be) is indeed correctly pointed in /etc/fstab (see above the result of tail -6 /etc/fstab)

So everything seems to be fine thanks to the steps and hints by you guys @guiltydoggy @computersavvy (and @siosm for his contribution in there ):

The two odd errors reported earlier make me wanting to be sure everything is indeed the way it should be.

  • In command line : this odd comment

Beside this comment I can in command line access all folders and files as if there were no error.

  • In GNOME user interface at reboot I get the correct Gnome Display Manager asking for logging in [with user mahdiaqallal] but then at Gnome main screen the Gnome Tour as if it what the first boot ever…

I really do not understand why…

I am running out of ideas. Here are a few more things though:

I just installed Silverblue 35 in a VM a couple days ago, and the fstab mounts to /home. But maybe this was different in Silverblue 34 - which I don’t have. But as you have tested both, I don’t think it is the issue anymore.

Silverblue 35 screenshot

This is interesting to me. You don’t seem to have a partition (sdc1) on your sdc block device. I think this is what you should try next. Delete and create a new partition map on the drive, and then create a new partition (Linux Filesystem). Then format that partition (sdc1) as btrfs. Then create the new “home” subvolume on that partition.

I tried myself in my Silverblue 35 VM. I’m also seeing this issue:

I don’t have any ideas right now, but I’ll try to investigate later when I have some more time.

This would be because the new file system did not have the proper info to tell the system you had already logged in previously.
At login it starts gnome-tour unless you have previously logged in and the file ~/.config/gnome-initial-setup-done already exists. That file seems to be created whenever a new user is first logged in and the initial setup process runs. (gnome-tour ?)

I think I’ve figured this out. It’s an SELinux issue. When we created the new /home on the new drive, the SELinux context was not set to indicate that this was to be used as a home directory.

You can see here that my new home directory on the new drive I created has an “unlabeled_t” context. In comparison, I’ve mounted the original home directory and it shows the correct context below that line: “user_home_dir_t”.

Screenshot from booting into a Live session and mounting the main and secondary drives for comparison:

I’m far from an expert on SELinux issues, but I found this Q&A that I believe fixes the issue. Booting back into the Silverblue system, I executed:

sudo semanage fcontext -a -e /home /var/home
sudo restorecon -vR /var/home

After which I logged out and logged back in through TTY and that error no longer appeared for me. Again, I’m not very knowledgeable on SELinux at all, so although this worked for me in my VM, you might want to wait to see if anybody here tells you this is a dumb thing to do or something before trying it on your system.

Edit: Here is a screenshot, going back into a Live session and re-mounting the secondary drive and querying the home directory - it shows the correct context for the home directory.

That was the very thing I would have suggested when you said that it was an selinux issue.

If selinux is active and in enforcing mode then the users home directory must have the proper context and only by using restorecon can you reset everything the way the system expects it to be.

I recently encountered a similar error when something with selinux was modified but the update failed to run that exact command and some parts of the tree were left with the older context that interfered with the updated policies. The ‘sudo restorecon -vR /’ command fixed everything across the entire system for me.

1 Like