luciferofastora

Credit: XKCD 3014

My Objective:
Repurpose an obsolete OS Filesystem as pure data storage, removing both the stuff only relevant for the OS and simplifying the directory structure so I don't have to navigate to <mount point>/home/<username>/<Data folders like Videos, Documents etc.>.

I'm tight on money and can't get an additional drive right now, so I'd prefer an in-place solution, if that is feasible. "It's not, just make do with what you have until you can upgrade" is a valid answer.

Technical context:

I've got two disks, one being a (slightly ancient) 2TB HDD with an Ubuntu installation (Ext4), the second a much newer 1TB SSD with a newer Nobara installation. I initially dual-booted them to try if I like Nobara and have the option to go back if it doesn't work out for whatever reason.

I have grown so fond of Nobara that it has become my daily driver (not to mention booting from an SSD is so much faster) and intend to ditch my Ubuntu installation to use the HDD as additional data storage instead. However, I'd prefer not to throw away all the data that's still on there.

I realise the best solution would be to get an additional (larger) drive. I have a spare slot in my case and definitely want to do that at some point, but right now, money is a bit of a constraint, so I'm curious if it's possible and feasible to do so in-place.

Particularly, I have different files are spread across different users because I created a lot of single-purpose-users for stuff like university, private files, gaming, other recreational things that I'd now like to consolidate. As mentioned in the objective, I'd prefer to have, say, one directory /Documents, one /Game Files, one /Videos etc. on the secondary drive, accessible from my primary OS.

Approaches I've thought of:

1. Manually create the various directories directly in the filesystem root directory of the second drive, move the stuff there, eventually delete the OS files, user configs and such once I'm sure I didn't miss anything
2. Create a separate /data directory on the second drive so I'm not directly working in the root directory in case that causes issues, create the directories in there instead, then proceed as above
3. Create a dedicated user on the second OS to ensure it all happens in the user space and have a single home directory with only the stuff I later want to migrate
4. Give up and wait until I can afford the new drive

Any thoughts?

My use case is splitting audio into separate channels in OBS for Twitch Streams so I can play music live without getting my VoDs struck. If my approach is entirely wrong for the use case, I'm happy to scrap the whole thing and sign it off as learning experience.

My solution is to use virtual sinks that I record through Audio Sources in OBS. I've got two loopback-devices (config at the end) with media.class = Audio/Sink, assign my playback streams to the relevant output capture.
The loopback of each is then passed on to the common default (physical) output device, namely my headphones.
So far, this has been working great for me, aside from minor inconveniences:

The first is that I want certain apps or playback streams to automatically be assigned to the capture sinks upon starting the app.
I had a working pulseaudio¹ setup on Ubuntu where I used pavucontrol to set the output once per app and it remembered that setting. Every time I opened that app, it would direct its playback streams to that sink.
I migrated to Nobara and opted to try configuring pipewire (directly)² instead. The devices are created correctly but every time I (re-)start a relevant app I have to go set its capture device again.

The second is that occasionaly upon logging in, one loopback stream will initially be passed to the other sink instead of the default output, which resolves upon restarting pipewire³. Is something wrong with my config?
Both have the same target.object and restarting it fixes it, so I'm guessing it may be some race condition thing where the alsa_output isn't initialised at startup yet, but I don't know how to diagnose or fix that

1: I have since learned that apparently it's actually still pipewire parsing that config, but the point is I configured it through ~/.config/pulse/default.pa

2: ~/config/pipewire/pipewire.conf.d/default-devices.conf

3: Trying to set it in pavucontrol doesn't work and keeps resetting that playback's output to the given sink if I try to select the correct capture device. Repatching them in Helvum does the job, but then pavucontrol just shows blank for the device (doesn't interfere with controlling the volume, but maybe it's relevant for diagnosing)

My current ~/.config/pipewire/pipewire.conf.d/default-devices.conf:

context.modules = [
    {   name = libpipewire-module-loopback
        args = {
            audio.position = [ FL FR ]
            capture.props = {
                media.class = Audio/Sink
                node.name = vod_sink
                node.description = "Sink for VoD Audio"
            }
            playback.props = {
                node.name = "vod_sink.output"
                node.description = "VoD Audio"
                node.passive = true
                target.object = "alsa_output.pci-0000_00_1b.0.analog-stereo"
            }
        }
    }
    {   name = libpipewire-module-loopback
        args = {
            audio.position = [ FL FR ]
            capture.props = {
                media.class = Audio/Sink
                node.name = live_sink
                node.description = "Sink for Live-Only Audio"
            }
            playback.props = {
                node.name = "live_sink.output"
                node.description = "Live-Only Audio"
                node.passive = true
                target.object = "alsa_output.pci-0000_00_1b.0.analog-stereo"
            }
        }
    }    
]