I just configured my system for BTRFS snapper snapshots after installation. I created subvolumes, moved stuff to their respective subvolumes, edited fstab reinstalled grub, and now I have booted in fedora and I have GDM showing up, but as I try to login nothing would happen. I even tried the tty, first as my user which would result in nothing just like with GDM, then as root, which gave error ‘incorrect password’
You help will very much appreciated
Thank you
Two things.
- The first thing is a note that the you can create custom subvolumes during the install. You don’t need to do it after the fact.
- Can you describe, specifically, what you did when you “created subvolumes and moved stuff?”
Do you mean, from the installer itself after installation?
I created subvolumes using btrfs subolume create
and used rsync -avzh
(I did this from my Garuda installation) to copy the stuff, and I suppose I didn’t do an mistake in executing the commands.
I was succesful doing the same steps in my void installation.
Thank you
No, during the partitioning phase so everything gets installed in the right place to begin with. As it relates to btrfs, Fedora has one of the most flexible installers around. I have even used it to install into an existing btrfs partition which held another OS.
With Fedora, you don’t need to do the install and then move things around after the fact.
By specifics I meant which subvolumes did you create and where did you mount them?
Also, void and Fedora are very different. If you used rsync -avzh you may have removed all the selinux contexts. I would recommend using something like rsync -aAXHv
for that operation instead.
# <file system> <mount point> <type> <options> <dump> <pass>
UUID=D7C4-586F /boot/efi vfat umask=0077,shortname=winnt 0 2
UUID=53a5d552-cee3-4f38-b4c3-2ada717072f7 / btrfs subvol=/@,defaults,noatime,space_cache,autodefrag,compress=zstd 0 0
UUID=53a5d552-cee3-4f38-b4c3-2ada717072f7 /root btrfs subvol=/@root,defaults,noatime,space_cache,autodefrag,compress=zstd 0 0
UUID=53a5d552-cee3-4f38-b4c3-2ada717072f7 /var/cache btrfs subvol=/@cache,defaults,noatime,space_cache,autodefrag,compress=zstd 0 0
UUID=53a5d552-cee3-4f38-b4c3-2ada717072f7 /var/log btrfs subvol=/@log,defaults,noatime,space_cache,autodefrag,compress=zstd 0 0
UUID=53a5d552-cee3-4f38-b4c3-2ada717072f7 /var/tmp btrfs subvol=/@tmp,defaults,noatime,space_cache,autodefrag,compress=zstd 0 0
UUID=53a5d552-cee3-4f38-b4c3-2ada717072f7 /srv btrfs subvol=/@srv,defaults,noatime,space_cache,autodefrag,compress=zstd 0 0
UUID=53a5d552-cee3-4f38-b4c3-2ada717072f7 /home btrfs subvol=/@home,defaults,noatime,space_cache,autodefrag,compress=zstd 0 0
Will I have to reinstall the fedora now?
That looks…familiar.
You may be able to use restorecon
to restore the selinux contexts but I am not an selinux expert and I have never tried to do it on that scale.
I am not sure, but I read it here:
https://linuxize.com/post/how-to-use-rsync-for-local-and-remote-data-transfer-and-synchronization/
-a
, --archive
, archive mode, equivalent to -rlptgoD
. This option tells rsync
to syncs directories recursively, transfer special and block devices, preserve symbolic links, modification times, groups, ownership, and permissions
There is no perfect “right” way to use rsync. You need to use different options depending on what you are trying to achieve. Given what you are trying to achieve in this specific case I would recommend rsync -aAXHv
because it will create a near identical copy of the files including all the extended attributes.
That being said, I still think it would be easier to just setup the subvolumes the way you want them during the install instead of trying to do it after the fact.
Just tried to match it with our Garuda’s fstab
Yes, I can see that
From my next installation onwards, I will do it like that
Actually I didn’t know much about rsync
so I used it following this post:
https://linuxize.com/post/how-to-use-rsync-for-local-and-remote-data-transfer-and-synchronization/
Next time when I use rsync
I will definitely use the options you have given as per requirements
Thanks, I will check it out some other day and I will let you know
You could also set selinux to permissive for now and see if that will let you login.
Yeah that did the trick!! So now I have to use restorecon to restore Selinux, I suppose?
I guess that tells us that the real problem is likely that the selinux contexts were removed when you copied the files.
I would try using restorecon
to restore the contexts and see if that will allow to fully enable selinux again.
Thanks a lot @dalto, you correctly figured out the problem!! Now I will learn about selinux, check out restorecon, and let you know if it works
Another option to restore SELinux context for the entire disk is to do the following
sudo touch /.autorelabel
The next time you reboot it will scan the entire file system and restore all the security context for you.