As I dev terminal stuff it’s useful
Not sure why tmux is helpful but if you like it, good for you 
So, what do you want to do with your 1TB ext4 drive ?
I explained how to mount it at boot, now it’s up to you 
Once permanently mounted, you’ll be able to move data as you like~need and do symlinks if you want,
between your /home/$USER/ and /media/DATA_01/$USER
All these already explained too.
Are you new to Linux ? ( not a crime, just a question )
not really new to linux at all in fact the first time I used a linux type system was in the 1900’s ! tmux allows me to run my terminal apps and use htop/top to see how they affect the machine while running. game servers need to run most of the time so therefore tmux is ideal for starting that application and moving on to the next … please take into account that I am developing for headless servers … I use a gui for the simple reason is vim/nano are not as good as geany or bluefish to develop code !
I would like to point out everything works in v20.04 but fails in 22.04 … this of course maybe a change upstream I’ll run up a vm with ubuntu 22.04 to see if the problem is there also
I’m getting lost with the post - it started off talking about the terminal and has turned into an install issue.
Returning to Ubuntu Budgie 22.04 Terminal - #16 by fossfreedom - did you see that? Thoughts?
Ok so there’s something I don’t get. What is your problem ?
I went down the road of storage/data~organization because I thought your « root » partition was too quickly filled up…
Use ncdu to spot the heaviest elements in your $HOME and /
…maybe too many logs somewhere ? As a consequence of tmux complaining ? Or that complaint is a symptom for something else ?
Occupation for mounted partitions :
df -Thx squashfs -x tmpfs -x devtmpfs
df -ix squashfs -x tmpfs -x devtmpfs
Or maybe something related with owners and rights ?
ok the original issue was this appearing on completion of a script in a tmux/terminal window
bash -c 'sleep 5 && /usr/share/budgie-desktop/gdmcheck/gdmcheck.sh'
which did not cause an issue I simply asked why it why this occurs in 22.04 & not 20.04 . On advice I reinstalled UB on a brand new drive, which in turn did not fix the issue. On the new install the screen no longer blanks and the original issue continues. further from that I was asked what the use of tmux is and my reasons for using it, which in turn split the issue into parts. So after a reinstall the system is in a less stable state that it was before the re install and the original problem is still there. I would say if you don’t want to support multiplexers any more I understand I’ll move on and find a flavor of debian that does. Note everything worked in 20.04 & not 22.04
Just a thought … could there be a change with gnome screen saver which causes the problem ? as the screen now goes dim & does not blank. TBF I wish I had not taken the advice … if I had not I would have a machine that the screen blanked rather than just dimmed. Tmux & gnu screen (multiplexers) have been around for years and if support for such tools is at it’s end so be it !
I’ve already pointed you towards where that command is run. Now we need to figure out why the process is not completing on login - I think that’s why tmux is showing it. If you can help here that would be most helpful.
The screen dim vs blank is a different issue. Lets not confuse this thread even more than it already is.
They are perhaps related but should I open a new topic regarding the screen dimming situation ?
screen dimming has nothing to-do with the terminal message. Please raise a separate thread - details of graphics/drivers and display settings in budgie-control-center needs to be described.
ok no worries will do that … how would you like the data displayed ? screen shots ?
So this ↑ was not your main issue - my bad I took it as it !
But now you know how to leave $HOME onto your « boot drive » while storing visible personal data on another drive
Ok - I have decided to remove the gdmcheck command - it wasn’t working very well anyway.
This will be available as part of the regular updates sometime in the next week or two at a guess.
great … for now I have edited the shell script to silence it
I have switched the home drive away from the OS drive … bear in mind when I started … we had dual 360k floppy machines, so the OS was always on one drive & the data on another … a bit later on I had a 10 mb drive but that was always split OS/Data those early OS had a habit of self destructing so you had to keep your data safe
Ah Ah 
I might be older than you think ( OS/app’s on removable cartridges and data on slow audio cassette tapes and something like 8 or 16Kb RAM… )
$HOME ≠ /home
your own folder /home/$USER hosts 2 kinds of personal data :
⋅ the visible and heavy ones : media and documents, which don’t affect the OS ;
⋅ the hidden ones : config’s, settings, parameters, which are more or less tied to the OS and its components while being related to your $USER.
Visible ( agnostic ) ones can ( and should ) be moved away, separate from OS.
Hidden ( specific ) ones might stay in the /home/$USER, this folder itself inside the OS.
Remind a separate whole /home folder ( including agnostic and specific personal data ) might not be straightaway « compatible » with another OS, or version of that OS because of the hidden personal data.
Drawback with that approach is that if the OS disk goes down you loose all your settings data to other programs I have reformatted & reinstalled the OS disk loads of times in the past, with /home on another drive … when you reinstall an app it reacts in the same way as it did before … no need to set anything up.just means setup once and forget regardless of the amount of OS installs you do… following your advice … I created a ~/home on the OS drive … chrome did not like symlinks dropbox did not like symlinks and so on hence the reverse back
As you see fit in. There’s no one absolute answer.
I saw many cases where the whole /home thing introduced many problems, so… I can assure « and forget regardless of the amount of OS installs you do » is far from true in all context.
I don’t have problems with symlinks and Chrome/Chromium ( and any app’s so far - years long ) - so here I suspect the issue is elsewhere.
Regarding DropBox, I don’t use it but I’d bet it needs the real path to data :
⋅ let’s say you have a symlink into your $HOME for « documents » which targets /media/DATA/you/Documents
⋅ then in DropBox, you’ll need to sync’ /media/DATA/you/Documents ( and not $HOME/Documents )
Or maybe hard set these paths through xdg-user-dirs mechanic.