This video was released early for patrons. patreon.com/thelinuxcast Also, I'm now aware of not needing the bios-grub portion if you do MBR, as it appears to do it for you. You do need to do the EFI partition/Boot partition if you use UEFI and GPT.
Good video, a friend of mine explained this to me years ago for Xubuntu 16.04 Lts, it was great because I was able to upgrade to 18.04 and to 20.04 Lts without to many issues. Thanks again.
great tutorial Matt....as a new self-taught Linux user this was one aspect of jumping ship from Windows I wish I had have researched more thoroughly....although I'm very happy with my MX Linux build it could have been better. Cheers!
My home directory lives on my root partition. But my true documents, music, video, et. al directories are on a separate partition, and are symlinked to my home directory. This allows me to share my data across multiple OSs, but configs are unique to each OS.
Great video. Watched it after watching your distro hopping video. Unfortunately neither video shows how to install a new distro later down the line. If I distro hop, how do I take advantage of the partitions this video taught me how to create? How do I install a new distro and keep my /home partition? What partition options do I need to choose on that distro hopping install? Would love a follow up video that walks through using manual partitions to save time and effort when distro hopping. Thanks again for the great video!
Excellent tutorial, due to laziness I have not attempted this in the past but now having taken notes I am going to give this some well warranted experimentation so that it can become my de-facto installation standard.
You only need the bios_grub partition if you set up an mbr system on a GPT disk. Not necessary if you go with a standard dos partition table. For uefi, you just need an esp partition plus your root partition. The size of the esp depends on where you are mounting it. If you mount it directly on /boot, you need enough storage for all your kernels. Personally I don’t like my kernels sitting on a fat32 partition so I mount the esp on /boot/efi. You could equally mount it on /efi. In any of those cases you could get away with 100mb but I tend to create a 500mb esp out of habit, and /boot/efi is my preference. Just saying 😀
Excellent advice. I personally have a whole 1TB SSD as /home. So, like you pointed out, distro hopping (or just a rebuild of my current distro) is a pretty simple proposition.
These days a swap file is preferred to a swap partition, at least for SSD and NVMe drives. As for the size of swap it is recommended to be the square root of total RAM nowadays.
squareroot only on computer. because you need atleast the amount of ram as swap to hibernate on linux, so on a laptop its differnt, or is there another way?
My D: drive got corrupted into a RAW so I lost quite a bit of data, but I had most of the stuff I wanted to keep backed up in case that happened and it was just a HDD so no harm done. That being said, DO NOT change ANY of your partitions native unless you're managing your Windows partitions on Windows. Either use the installer to make your partitions manually with free space or use GParted to manage all of your partitions (Also make sure you have a backup for any existing distro you have or have restore backups for your Windows partitions, preferably on a drive)
I have my /home on a separate partition on my current system. The only issue I’ve had was VirtManager creating the in the root partition, which filled that partition up pretty quickly
If anyone has suggestions or can point me in the right direction on info/walk thru for partition allocations for a distro you plan to use for long term use that would be helpful. For example thought root GB allocation should be double the /home but wanted to know a general recommendation or go by for allocating between efi/swap/root/home. Have 1 TB SSD/64GB ram and was thinking of 250gb to 350gb for main distro. Wanted to leave other space for distro hoping
Very good tutorial, well done. On my installations I always use 520 MB for the EFI partition. It's probably way too large on most systems, but one time I ran into a weird issue with a PC not booting if the EFI partition was smaller than 512 MB. Stuff like that is probably different on every motherboards/uefi bios which makes uefi installations sometimes confusing.
Great tute - thank you! 👌🏻 I'm learning Linux (again) and have been manually partitioning installs as I've been distro hopping. I was advised by several people that when creating the swap partition it should be located at the end of the drive - is this correct - if so is there a reason - or doesn't it matter? Thank you! 😊
Been separating /home since i started using linux as my main OS, saved me countless times when i fucked my system, just reinstalled, did a little touch on the fstab and vuala, everything is there again
If there is one thing I learned in my 40 years in the computer world it's this ...... 1) Enter data or make the desired change. 2) REMOVE HANDS FROM KEYBOARD! 3) Review what you have requested. 4) Then, and only then, hit "Enter".
@@Wolverine_3 Then 50 is probably where you want to go. 25 is probably okay, but you'll need to be cautious about apps that store data in root. Most don't, they just store the binaries there. The rest goes in HOME. The best bet is to try what you can reasonably allocate, and ensure you have backups if it isn't enough. There's no one right answer
I do the let Linux do it's thing all the time. I always back up my data. So my externals and my cloud storage is kind $Home away from $Home. You mount or access the cloud and your back at /home. I only move things back to the new install Linux /home if I'm going to use it often. If now it stays on my backup $Home(/home).
I always disable or disconnect all drives I'm not going to install on. This way it's impossible to make a mistake. In my BIOS/UEFI, I can disable all hard drives. Still I have no problem unplugging them if need to. You also can name/label your drives or even partitions. That's how I determine what's what. You can tell by size or brands of each hard drive with commands as well. Think before moving on and double check everything before committing to anything. But always go the route that you can't make a mistake or very little chance of making a mistake.
(Comment previously disappearing because I tried to be sneaky and link a blogpost called "Pack Your Bags - Systemd Is Taking You To A New Home") I feel like a lot of people opt to this when they should use systemd-homed: homeD solves the issue of home directory portability, as well as allowing encryption by itself if desired, and this sounds relevant from the reasons you mentioned in "Why do this?" - More control over where data is stored (moves all user-related info into a file called ~/.identity) - Given that you back up regularly, which is recommended, it shouldn't be a disaster if your distro goes wonky imo its only downsides are - If you distrohop frequently in a way that wipes out your original distro (since it'd be a waste of writes to your drive), - It's harder to keep track of how many gigabytes of programs and whatnot are installed in comparison to what's just files in your /home folder, if you want to always be below XX gigabytes - Slight pain in the ass to transition users that were made without homeD into homeD - last time I checked, remote logins via SSH don't work yet - You can't name your home partition I guess - Doesn't make porting to other init-system distros easier (but at least doesnt make it harder either) However if you run mainly VMs, or want to run a distro alongside your current, first downside shouldn't be an issue, nor should it be an issue if you've actually tested out the distro you want to replace it with to a satisfactory extent (whether via vm or liveusb) second downside could be solved by a script calculating away your homedir gb from your overall system's size third downside, at least you have the arch-wiki on your side (or a blogpost that they link) which should help as long as you have systemD If you just don't do backups it'd probably be good to have the separate partition, probably, but even then I'd recommend homeD just for how it puts all the files in more relevant positions on your system Good backup programs i've been using are FreeFileSync for drives connected to the same computer and Syncthing for talking to other computers Sorry for shit formatting
I disagree. I think systemd-homed is a solution looking for a problem. The home directory decryption/encryption on login/logout/screen lock might be nice to have, but with no support for SSH logins the whole thing is completely worthless to me. One of the problems I have with it is having all user-related information in a single folder inside the user home directory. Is that going to store group membership? What about sudo access? Those are both user-related and can permit elevated access. Some things should not be user mutable. I don't think systemd-homed addresses that concern very well, if at all. SystemD does have redeeming characteristics. I generally like using unit files for services. Timers feel clumsy compared to cron jobs, but they're easy enough. What I don't like is how it seems like SystemD is trying to wedge itself into every single Linux subsystem. It's taken over logging, cron, network configuration, logins, time synchronization, device management, DNS resolution, date and time, hostnames, and now it wants user home directories, too. I wouldn't be surprised if we eventually see systemd-desktopd and systemd-shelld and maybe throw in systemd-browserd and systemd-texteditd for good measure! I'm acutely aware that SystemD is modular by design. I don't give a toss about that. It may be modular, but it spreads thoughout the system like mycellium. Part of the blame lies with the distributions, but as time goes on I see tighter and tighter coupling. SystemD started out as a new init system but is slowly turning into a microkernel running on top of the Linux kernel. Do an image search for "microkernel architecture" and compare some of those diagrams to the similar diagram for SystemD. I particularly like the one hosted by ResearchGate. You'll see what I mean.
@@gtak-welder You're right that it doesn't support SSH login, but it does store group membership (though not groups themselves, and therefore not sudo access, so I think the concern is well addressed) Like I tried mentioning in my post as well, it's not that it *wants* your homedirectory, it isn't forcing you to only have this way, it just makes it easier to port between SystemD systems. If the concern is that you want to switch but that now all the files are in the homedir, so your new system doesnt know what they are, you already wiped that part of the system anyway to get the new system (the non-homedir part of the system) There's a far step from sorting out your files to be in more modern/relevant positions (homeD), logging, hostnames, yadayada, to then be making a DE or a brower lol. imo you bit the talkingpoints of the online community a bit too hard there Also, is systemd a microkernel? Why not compare it to other relevant initsystems of today, that at least sounds like it would get the point across clearer though I'm having a hard time finding comparison images At the end of it all I do wanna say I hardcore agree that systemD does seep into a lot unnecessarily, though to me, the main concern is other programs relying on systemD, because it makes it a pain in the ass/sometimes impossible to use those things that's literally supposed to be its own project But I don't think any of that takes away from "use homeD if you want your user to be more portable" as it literally doesn't affect non systemD distro, given that you are going to wipe or not use non homedir part of the former system, and that the other initsystem wont really bother to find out what those files are, while it at all times makes it easier to port around systemD distros And Matt doesn't even give a shit about the whole "systemD taking over" talkingpoint last time I checked so I feel like it's even less relevant in this channel
This video was released early for patrons. patreon.com/thelinuxcast
Also, I'm now aware of not needing the bios-grub portion if you do MBR, as it appears to do it for you. You do need to do the EFI partition/Boot partition if you use UEFI and GPT.
WOW Matt! As a newbie to Linux this is the best presentation I found explaining the manual partitioning installation process. Thank you.
This is by far the BEST video explanation on this process. Great job and wish I had this when I first started learning about this process
Good video, a friend of mine explained this to me years ago for Xubuntu 16.04 Lts, it was great because I was able to upgrade to 18.04 and to 20.04 Lts without to many issues. Thanks again.
you should show an example of migrating to a new linux distro and how to use the separate home partition you just created
great tutorial Matt....as a new self-taught Linux user this was one aspect of jumping ship from Windows I wish I had have researched more thoroughly....although I'm very happy with my MX Linux build it could have been better. Cheers!
My home directory lives on my root partition. But my true documents, music, video, et. al directories are on a separate partition, and are symlinked to my home directory. This allows me to share my data across multiple OSs, but configs are unique to each OS.
How did you do that? Can you explain?
@@TomeOfKnowledge74 where do you keep your false documents then?
Thanks!
this video was so valuable for me brother , thank you so much for the content ! keep it up
Great video. Watched it after watching your distro hopping video. Unfortunately neither video shows how to install a new distro later down the line. If I distro hop, how do I take advantage of the partitions this video taught me how to create? How do I install a new distro and keep my /home partition? What partition options do I need to choose on that distro hopping install? Would love a follow up video that walks through using manual partitions to save time and effort when distro hopping.
Thanks again for the great video!
Excellent tutorial, due to laziness I have not attempted this in the past but now having taken notes I am going to give this some well warranted experimentation so that it can become my de-facto installation standard.
I really enjoy your channel and hope you do or how to series in the future. I value your experience on “best practices”.
You only need the bios_grub partition if you set up an mbr system on a GPT disk. Not necessary if you go with a standard dos partition table. For uefi, you just need an esp partition plus your root partition. The size of the esp depends on where you are mounting it. If you mount it directly on /boot, you need enough storage for all your kernels. Personally I don’t like my kernels sitting on a fat32 partition so I mount the esp on /boot/efi. You could equally mount it on /efi. In any of those cases you could get away with 100mb but I tend to create a 500mb esp out of habit, and /boot/efi is my preference. Just saying 😀
Excellent advice. I personally have a whole 1TB SSD as /home. So, like you pointed out, distro hopping (or just a rebuild of my current distro) is a pretty simple proposition.
These days a swap file is preferred to a swap partition, at least for SSD and NVMe drives. As for the size of swap it is recommended to be the square root of total RAM nowadays.
squareroot only on computer. because you need atleast the amount of ram as swap to hibernate on linux, so on a laptop its differnt, or is there another way?
Top class walktrough!
My D: drive got corrupted into a RAW so I lost quite a bit of data, but I had most of the stuff I wanted to keep backed up in case that happened and it was just a HDD so no harm done. That being said, DO NOT change ANY of your partitions native unless you're managing your Windows partitions on Windows. Either use the installer to make your partitions manually with free space or use GParted to manage all of your partitions (Also make sure you have a backup for any existing distro you have or have restore backups for your Windows partitions, preferably on a drive)
Very well explained, thank you!!
FAT32 /EFI
Your installer should tell you when you click next.
If it's systemD, it wants at least 500MB
Great video.
I have my /home on a separate partition on my current system. The only issue I’ve had was VirtManager creating the in the root partition, which filled that partition up pretty quickly
Why did you not include terminal commands? For arch install btw... ;)
How do we do this for void linux?
If anyone has suggestions or can point me in the right direction on info/walk thru for partition allocations for a distro you plan to use for long term use that would be helpful. For example thought root GB allocation should be double the /home but wanted to know a general recommendation or go by for allocating between efi/swap/root/home. Have 1 TB SSD/64GB ram and was thinking of 250gb to 350gb for main distro. Wanted to leave other space for distro hoping
Very good tutorial, well done.
On my installations I always use 520 MB for the EFI partition. It's probably way too large on most systems, but one time I ran into a weird issue with a PC not booting if the EFI partition was smaller than 512 MB. Stuff like that is probably different on every motherboards/uefi bios which makes uefi installations sometimes confusing.
You forgot to show how to use that home partition in some other distro. I waited for that till xerolinux bug then you did a clean install.
Great tute - thank you! 👌🏻
I'm learning Linux (again) and have been manually partitioning installs as I've been distro hopping.
I was advised by several people that when creating the swap partition it should be located at the end of the drive - is this correct - if so is there a reason - or doesn't it matter?
Thank you! 😊
I don't know if it matters. I know the boot partition has to be at the beginning. But my home is always at the end.
Been separating /home since i started using linux as my main OS, saved me countless times when i fucked my system, just reinstalled, did a little touch on the fstab and vuala, everything is there again
I miss Debian 12 instruction creating separate home and root partitions on Linux
How to reinstall linux without overwriting the separate home directory partition?
If there is one thing I learned in my 40 years in the computer world it's this ......
1) Enter data or make the desired change.
2) REMOVE HANDS FROM KEYBOARD!
3) Review what you have requested.
4) Then, and only then, hit "Enter".
how much size root partition should have?
Depends on the distro, but 50-100GB will for sure be enough.
@TheLinuxCast i think its too much for me. I only have 512gb SSD in there 😅
@@Wolverine_3 Then 50 is probably where you want to go. 25 is probably okay, but you'll need to be cautious about apps that store data in root. Most don't, they just store the binaries there. The rest goes in HOME. The best bet is to try what you can reasonably allocate, and ensure you have backups if it isn't enough. There's no one right answer
@@TheLinuxCast Alright thanks!
My home and root are on the same partition. But I mount specific folders like videos and games from different drives.
How can I do it?
@@bzizmza With fstab file.
Thanks
I do the let Linux do it's thing all the time. I always back up my data. So my externals and my cloud storage is kind $Home away from $Home. You mount or access the cloud and your back at /home. I only move things back to the new install Linux /home if I'm going to use it often. If now it stays on my backup $Home(/home).
I always disable or disconnect all drives I'm not going to install on. This way it's impossible to make a mistake. In my BIOS/UEFI, I can disable all hard drives. Still I have no problem unplugging them if need to. You also can name/label your drives or even partitions. That's how I determine what's what. You can tell by size or brands of each hard drive with commands as well. Think before moving on and double check everything before committing to anything. But always go the route that you can't make a mistake or very little chance of making a mistake.
Pull out (or disconnect) all your drives before you do the target
Update to the 2001 UEFI.
You look like a discord mod...
And you look like lowly piss boy
(Comment previously disappearing because I tried to be sneaky and link a blogpost called "Pack Your Bags - Systemd Is Taking You To A New Home")
I feel like a lot of people opt to this when they should use systemd-homed:
homeD solves the issue of home directory portability, as well as allowing encryption by itself if desired, and this sounds relevant from the reasons you mentioned in "Why do this?"
- More control over where data is stored (moves all user-related info into a file called ~/.identity)
- Given that you back up regularly, which is recommended, it shouldn't be a disaster if your distro goes wonky
imo its only downsides are
- If you distrohop frequently in a way that wipes out your original distro (since it'd be a waste of writes to your drive),
- It's harder to keep track of how many gigabytes of programs and whatnot are installed in comparison to what's just files in your /home folder, if you want to always be below XX gigabytes
- Slight pain in the ass to transition users that were made without homeD into homeD
- last time I checked, remote logins via SSH don't work yet
- You can't name your home partition I guess
- Doesn't make porting to other init-system distros easier (but at least doesnt make it harder either)
However if you run mainly VMs, or want to run a distro alongside your current, first downside shouldn't be an issue, nor should it be an issue if you've actually tested out the distro you want to replace it with to a satisfactory extent (whether via vm or liveusb)
second downside could be solved by a script calculating away your homedir gb from your overall system's size
third downside, at least you have the arch-wiki on your side (or a blogpost that they link) which should help as long as you have systemD
If you just don't do backups it'd probably be good to have the separate partition, probably, but even then I'd recommend homeD just for how it puts all the files in more relevant positions on your system
Good backup programs i've been using are FreeFileSync for drives connected to the same computer and Syncthing for talking to other computers
Sorry for shit formatting
I disagree. I think systemd-homed is a solution looking for a problem. The home directory decryption/encryption on login/logout/screen lock might be nice to have, but with no support for SSH logins the whole thing is completely worthless to me. One of the problems I have with it is having all user-related information in a single folder inside the user home directory. Is that going to store group membership? What about sudo access? Those are both user-related and can permit elevated access. Some things should not be user mutable. I don't think systemd-homed addresses that concern very well, if at all.
SystemD does have redeeming characteristics. I generally like using unit files for services. Timers feel clumsy compared to cron jobs, but they're easy enough. What I don't like is how it seems like SystemD is trying to wedge itself into every single Linux subsystem. It's taken over logging, cron, network configuration, logins, time synchronization, device management, DNS resolution, date and time, hostnames, and now it wants user home directories, too. I wouldn't be surprised if we eventually see systemd-desktopd and systemd-shelld and maybe throw in systemd-browserd and systemd-texteditd for good measure!
I'm acutely aware that SystemD is modular by design. I don't give a toss about that. It may be modular, but it spreads thoughout the system like mycellium. Part of the blame lies with the distributions, but as time goes on I see tighter and tighter coupling. SystemD started out as a new init system but is slowly turning into a microkernel running on top of the Linux kernel. Do an image search for "microkernel architecture" and compare some of those diagrams to the similar diagram for SystemD. I particularly like the one hosted by ResearchGate. You'll see what I mean.
@@gtak-welder You're right that it doesn't support SSH login, but it does store group membership (though not groups themselves, and therefore not sudo access, so I think the concern is well addressed)
Like I tried mentioning in my post as well, it's not that it *wants* your homedirectory, it isn't forcing you to only have this way, it just makes it easier to port between SystemD systems. If the concern is that you want to switch but that now all the files are in the homedir, so your new system doesnt know what they are, you already wiped that part of the system anyway to get the new system (the non-homedir part of the system)
There's a far step from sorting out your files to be in more modern/relevant positions (homeD), logging, hostnames, yadayada, to then be making a DE or a brower lol. imo you bit the talkingpoints of the online community a bit too hard there
Also, is systemd a microkernel? Why not compare it to other relevant initsystems of today, that at least sounds like it would get the point across clearer though I'm having a hard time finding comparison images
At the end of it all I do wanna say I hardcore agree that systemD does seep into a lot unnecessarily, though to me, the main concern is other programs relying on systemD, because it makes it a pain in the ass/sometimes impossible to use those things that's literally supposed to be its own project
But I don't think any of that takes away from "use homeD if you want your user to be more portable" as it literally doesn't affect non systemD distro, given that you are going to wipe or not use non homedir part of the former system, and that the other initsystem wont really bother to find out what those files are, while it at all times makes it easier to port around systemD distros
And Matt doesn't even give a shit about the whole "systemD taking over" talkingpoint last time I checked so I feel like it's even less relevant in this channel