Episode: 1567
Title: HPR1567: Multiboot Partitioning with Linux
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr1567/hpr1567.mp3
Transcribed: 2025-10-18 05:09:40

---

This episode of HBR is brought to you by AnanasThost.com.
Get 15% discount on all shared hosting with the offer code HBR15.
That's HBR15.
Better web hosting that's Aniston Fair at AnanasThost.com.
Hello and welcome to Hacker Public Radio.
My name is Matt and I am the Geek Dad in Northern California, USA.
This is my third podcast for HBR and I want to talk today about partitioning schemes
for dual booting or multi booting particularly on systems where you might want to run more
than one distribution of Linux.
So that's going to be my focus today.
I've written a blog post about this for the nightwise.com website and I will link to that
in the show notes.
And I want to talk a little bit about this because I've found a way to make this sort
of an easier thing to do as a geek and someone who likes to participate in the Linux community
and to try out new projects and try out new distributions and new desktop environments
and who wants to try all the different things that are available.
And mostly I want to do this because I want to be able to evangelize when I come across
a person who is tired of Windows crashing or who can't afford a Mac but thinks that
Windows is ugly and that we end up talking about Linux.
I like to be able to say, well, you know, I've tried out elementary OS and I think for
your purposes it would be really good because of this, this, and this or Ubuntu might
be great for you because it's gorgeous and it's well supported and a long-term support
release just came out.
So I like to have a good experience with the different projects and distributions that
are available as a Linux user.
And so to do this, I'm constantly uninstalling, reinstalling, swapping out one distro for
another and I have a laptop, I have a Lenovo laptop which just runs Linux awesome.
It does such a great job.
I have about a 500 megabyte or gigabyte hard drive in it.
So I've got lots of space to do the stuff I want to do and I was doing the traditional
model of a separate home and root partition when I'm setting up my system and that enables
me to just kind of blast away the root partition, install a new distro, point my separate home
partition to slash home in the new FS tab and Bob's your uncle, I'm ready to go with
my new distro.
So that works great.
That's one of the main reasons that I always tell people use a separate home partition
because if you want to upgrade or you want to change something, you've got that added
protection.
Now of course we all do backups, we always backup our data before we do an upgrade or
before we change distros.
Right?
I mean everybody does that, right?
We nobody ever has to worry about losing data because we know that we're supposed to
do backups.
Right?
Yeah.
How many of you are laughing so hard that you almost pulled over the car?
So you know, so many of us use a separate home partition just so that we can prevent
data loss.
And it's great.
It's a great thing to do.
But here's the problem if you decide, hey, I want to install a Ubuntu and open Susa
on my machine and so I can try them both at the same time and do real side by side comparison.
Well now if you have one home partition and you're sharing it between two different
installs of two very different flavors of Linux, you can have some problems and one of
the biggest problems comes with dot config files and not to mention the fact that you've
got two totally separate package types open Susa being an RPM distro and Ubuntu being
a devian based distro.
And when you throw arch in there and you've got package builds and all kinds of things
and then once you get software installed, what if you're running slightly different versions
of your soft Ubuntu as you are in open Susa in our example?
If I'm running Chromium and I've got a slightly different version of Chromium in open Susa
as repositories that I do in a Ubuntu as repositories, then the configuration files
might be slightly different.
And every time I boot into one operating system or the other and I start up Chromium,
my config files being overwritten because it's not the same format or what have you.
I'm not suggesting that Chromium specifically has this problem, but as an example of
a project that many of us know and love, this is the kind of thing that can happen.
It might be audacity, it might be Firefox, it might be any number of open source projects
that have slightly different versions depending on whose repository you pull them out of.
And your config files can be a problem.
So this is the problem that I was noticing and when I did have open Susa and I think it
was Ubuntu 12.04 at the time.
I might have been Linux Mint, I don't remember.
But I do remember that it was a devian based distro and it was open Susa, which is an
RPM distro.
And I was having these conflicts in my home directory with config files so that software
wasn't behaving across the two operating systems the way I had wanted it to do.
So I thought about it and I thought, well, what can I do in order to allow both installs
to have access to common data like documents and downloads and videos and MP3 files and podcasts
without having to duplicate that data across two different operating systems installs.
Because of course, that is the other option.
You can create a home partition for open Susa and a home partition for Linux Mint and
duplicate your data.
But even when the 500 gig hard drive or bigger, you're talking about massive quantities
of data if you watch a lot of videos, if you have a big MP3 collection or if you use
AUG or if you use FLAC or if you use any number of compression formats or codecs that don't
do compression, we're talking about lots and lots of data.
Now how do we have our data in one place, one copy of it per system, per piece of hardware
and yet run multiple operating systems on that hardware.
And I came up with a solution that I think is quite ingenious and maybe you've all figured
this out already, but I was pretty proud of myself.
And it's the simple, the simple, simple solution of symbolic links, of similar links.
So let me explain.
I changed the name of my gigantic home partition to something else.
And I, for example, in my system, I call it share disk, all one word.
And when I install, when I do a new operating system install, I make this a separate FSTAP
entry, a separate mount point in my file system called slash share disk.
And it's readable by me, and all the permissions are my username, my user ID, my group.
So there is a little bit of detail that I have to follow when I set up a new install
of a distribution, because I have to make sure that I use the same username, the same password,
the same user ID, the same groups so that I maintain access to all of my data.
But barring that small little bit of attention to detail, I can install anything I want, mount
this slash share disk to my file system, and then let the operating system create its
own partitions and its own file system for itself.
So let's take this 500 gigabyte hard drive as an example.
Let's say I have 300 gigabytes set aside as my slash share disk partition.
And in it, I have my, whatever my slash home slash username, folder, directory, and underneath
that, I have the typical desktop, downloads, pictures, documents, videos, music, podcasts,
whatever the normal subfolders are, you have subdirectors you have in your slash home slash
user name directory.
So that all lives in this 300 gigabyte partition called slash share disk that gets mounted
to my file system.
Then I have a 200 gigabyte partition that I can carve up into two free spaces of 100
gigabytes each.
And when I want to test a distro, I install it to one of these free spaces.
And I tell that distribution, this is all the space you get.
And I do it an install where I let the distribution create its own slash root, its own root directory,
its own slash home, everything that it wants to do just the way it wants to do it inside
this 100 gigabyte capsule.
And then I go ahead and I install my second operating system in the second 100 gigabyte free
space.
And I let it create its own partitions.
So what I do at that point then is when I boot into whichever distribution I'm installing
for the first time to set it up, I go directly into my home directory into my slash home slash
user name directory.
And I delete documents, pictures, videos, downloads.
These are all empty folders that are in my home directory and I delete them.
And then I create symbolic links from my home directory in the new operating system to
the corresponding folders in slash share disk.
So I'm basically linking the data that's on slash share disk back into the home directory
in the format that the operating system expects to find it in the home directory.
So when I open up shot well, for example, in Linux Mint, it's going to expect to find
slash pictures under my home directory.
Well, it goes and it checks my home directory and it finds a symbolic link called slash
pictures, which it expects to find and it just uses that directory for its data.
Well, what it doesn't realize is that it is linking symbolically back to slash user name slash
pictures underneath my share disk partition.
The nice part about this is that the data stays in one place, but the config files, the dot
config files that are hidden inside your home directory are installed per operating system.
So whichever version of shot well or audacity or chromium or thunderbird or whatever that
I pull out of whichever repository I'm using, it's going to create its own little dot config
file inside of the operating system bubble, but all the data is only in one place linking
back to the slash share disk.
So I will link to my blog post on this.
I will also attempt to link to a drawing that I've done that shows this file tree and
these mount points and try to put a little bit more visual information in the show notes.
So that those of you who may not have followed along to my rambling description of this
will have some other hard info to go look at.
So I want to thank you for taking the time to listen to this episode.
I'm recording this in the car today.
It's June 14th, 2014, and I am going to pick up my eldest child, my first born son.
He's coming out to stay with us.
He lives with his mom during the school areas coming out to stay with me for the summer.
And I'm going to pick him up.
And I am making the long trip through the Central Valley of California to a desert city called
to Hatchapy, which is about halfway between Las Vegas, where my son and my ex-wife live
and the town where I live, so that we can pick him up and bring him back home.
So I decided I would take this opportunity to record an episode.
As Ken Fallon would say, if you have anything, even remotely geek related that you want
to talk about, get on hpr.org, hackerpublicradio.org, go to the contribute link, find out how to
record a podcast, submit it, and share your geekiness with the rest of us.
I've really been enjoying some of the series on different software and on encryption and
privacy that a hookah has been doing.
I've really been enjoying some of the in-depth looks at file systems.
So please know that even if you want to tell the story of how you got into Linux or even
what's in your bag, we want to hear it.
So please, please, please record a show.
Thanks again for listening.
Thank you, hackerpublicradio, and I hope you guys have a great day.
Thanks.
You've been listening to Hackerpublicradio at Hackerpublicradio.org.
We are a community podcast network that releases shows every weekday, Monday through Friday.
Today's show, like all our shows, was contributed by an hpr listener like yourself.
If you ever thought of recording a podcast, then click on our contribute link to find
out how easy it really is.
Hackerpublicradio was founded by the digital dog pound and the Infonomicon Computer Club
and is part of the binary revolution at binrev.com.
If you have comments on today's show, please email the host directly, leave a comment on
the website or record a follow-up episode yourself.
Unless otherwise status, today's show is released on the Creative Commons, Attribution,
Share a Light 3.0 license.