I just installed Garuda sway on my machine. Before I was using EndeavourOS with XFCE/i3. I do have a standalone home partition, which is mounted to /home which works for the most part.
Now what I noticed immediately, the dotfiles of the live environment were not getting copied over after the install. For now, I just grabbed (at least sway, swaylock, waybar) off the live environment and copied them over. But I guess thats not the way things should work here? Never had to do that in the past before…
Any suggestions on this? Is this a thing only with the sway edition? Not sure about keeping that though, as I am running this on a Intel iGPU/Nvidia Optimus laptop.
Hi there, welcome to the forum.
This topic has been discussed several times in the forum.
I’d like to mention this one: the solution is OK, but especially good to explain “the context”. Also the suggestion two posts after to use symlinking is a very very common approach to this “issue”.
That does make a lot of sense with the background, thanks. Of course I searched for issues with the dotfiles, not with the home partition.
So in my current state, the /home partition is formatted in BTRFS, but not as a subvolume. Is there a best practice how to handle that? I could go and convert it to a subvolume (thats something I also found in my search), but the symlinks also make sense.
Im asking out of the perspective of very possible distro-hopping, as I would want to avoid as much issues there as possible. In sense of BTRFS, I guess coverting it to a subvolume would be the way to go?
Great, than my thought was not that bad Well currently Im settling in, but I really like some of the Garuda approaches, as a bit of a “quality of life” improvement over the more stock arch EndeavourOS.
But, there still is the issue with my device having that Nvidia GPU and the struggle to set that up in combiantion with wayland. So maybe I get back to i3, but definitely will try Garuda for now
Edit: I just looked through my current BTRFS volumes, and I think as I mounted the /home partition right in the installation, there was no @home created on / or am I missing something?
❯ sudo btrfs subvolume list /
[sudo] password for daniel:
ID 256 gen 170 top level 5 path @
ID 257 gen 164 top level 5 path @root
ID 258 gen 45 top level 5 path @srv
ID 259 gen 138 top level 5 path @cache
ID 260 gen 169 top level 5 path @log
ID 261 gen 170 top level 5 path @tmp
ID 262 gen 113 top level 256 path .snapshots
ID 263 gen 99 top level 262 path .snapshots/1/snapshot
ID 264 gen 104 top level 262 path .snapshots/2/snapshot
ID 265 gen 110 top level 262 path .snapshots/3/snapshot
ID 266 gen 112 top level 262 path .snapshots/4/snapshot
~ took 2s
I agree with Filo, I think this is going to be the best/easiest option for getting set up but still making it easy to hop to another distro if you want to. If you are not to deep in already I would reinstall first.
Reinstall, leaving the extra disk with the “mobile” /home out of it altogether. Don’t even touch that disk in the installer, just pretend it isn’t there.
After the installation is complete, make a mount point for the extra disk. It doesn’t matter where you mount it. Add it to /etc/fstab so it will be automatically mounted at boot.
Delete the (empty!) directories in the new installation that you have on the extra disk. For example:
rmdir ~/Documents ~/Pictures ~/Videos
Set up symlinks to point to your extra disk wherever you mounted it, so the directories there appear to be in your normal home directory. Make the directory target ~, for example:
This way your separate drive won’t be cluttered with dotfiles and such from the Garuda installation (in case you want to hop), but you can still get to all your stuff and interact with normally while using Garuda Linux.
That sounds like the way to go, thanks a lot. The /home is on the same drive, but not mounting it in the installer should do the trick.
Yeah I also planned for re-install as I did not really configure anything anyway until now. I guess I switch to hyprland also at the same time, as my research so far regarding sway and NVIDIA drivers looks everything but good.
Getting proprietary Nvidia drivers working on Sway is more complicated than with any other spin. I have a wiki doc for how to do it drafted, but the doc refers to changes made to the Sway spin that aren’t in the ISO yet due to an ongoing issue with the Calamares installer (since December now).
So a new Sway ISO and a wiki doc for Nvidia drivers are both Coming SoonTM.