Linux Mint: Moving the /home Folder to a Separate /home Partition

As described in a separate post, I was in the process of reinstalling Linux Mint 17.3 Xfce on an old Dell laptop. I had already installed it once. In that installation, I had allowed only for root and swap partitions. So there was a /home folder, viewable in File Manager as a top-level folder within File System, but there was no separate /home partition. This post summarizes key points, learned through several failed attempts, in the process of moving the /home folder to a separate /home partition. (Too late for this post, I discovered a different approach suggested in a Linux Mint community tutorial.)

A Separate Home Partition

The chief advantage of having a separate /home partition was that it would make it easier to preserve various adjustments that I had made. In the previous installation, for example, among other things I had configured Wine to run IrfanView, a Windows program; I had adjusted my screensaver settings; and I had saved a list of the programs that I had installed via Synaptic Package Manager (Start > System > Package Manager > File > Save Markings > 2016-04-23_Synaptic_Packages). I planned to restore that list (File > Read Markings) after reinstalling the system; hopefully that would reinstall the whole list of packages I had added to this current installation.

The separate /home partition would help because it was reportedly possible to preserve that sort of partition through the Linux installation process, or at least to restore a saved backup of that partition after reinstallation. So my settings could remain unchanged, even if I had to reinstall or upgrade the Linux system. Sources had indicated that all I had to do was to mount the /home partition, and not format it, during the installation, though I wasn’t sure whether that was an option in Mint. There were indications that this would also be possible with a /home folder, but that was apparently more complicated. I had viewed comments from one or two people for whom this had not worked: their /home folder, on the root partition, had gotten wiped out when Linux was reinstalled to the root partition.

It seemed wise to preserve the /home contents on a separate partition. In Windows, it took much longer to install and configure programs than to install the basic operating system. People seemed to say the same about Linux. If I could save the tweaks, and could also automate the downloading and updating of software via Synaptic, a future reinstallation or upgrade would be much easier.

My /home folder contained a username subfolder. In this case, the only user I had set up during installation was called m1210. (I chose that name because this was a Dell XPS M1210 laptop.) In File Manager, within that m1210 user subfolder, I could see folders for .wine and .xscreensaver, among other things, containing the settings that I had created when working out the IrfanView and screensaver issues.

So I had to create that separate /home partition; I had to reinstall Mint; I had to get the saved contents of the previous /home folder into that separate /home partition; and I had to persuade Mint to consider that separate /home partition to be its true /home source.

The separate /home partition might thereafter be mounted at the /home folder within the root partition. But this did not mean that the contents of that partition were actually at that physical location. To a Windows user, the mount point was actually more like a shortcut: it was just a logical point of connection between the root file system and the physically separate /home partition. Similarly, external drives would typically have mount points within /media. For example, I had a SDHC card that I had named SAMSUNG. When I put it into the Linux machine, it was mounted as /media/m1210/SAMSUNG.

I could create a separate /home partition during the Linux installation process, or by using a partitioning program. At this point, GParted seemed to be the most commonly used Linux partitioner. It was available as a standalone program, as a program available on some Linux live CDs (or USB drives), and as an ISO file that could be added to a multiboot drive. I used a YUMI multiboot USB drive, with the convenience of having a number of boot tools available on one drive. On my YUMI drive, I didn’t bother installing GParted separately; it was already a part of Parted Magic, which also offered a file manager and some other handy tools. My YUMI drive also had an Ubuntu ISO. Ubuntu didn’t come with GParted installed, but YUMI would allow extra space for changes in the Ubuntu live CD (or USB) setup, so I could add GParted there if desired. When working with NTFS (i.e., Windows) partitions, I tended to prefer MiniTool Partition Wizard, also available in ISO.

(Note: if I did reboot with an Ubuntu live ISO, or something like it, I would want to be aware of yet another /home folder. In addition to the /home partition and /home folder that might appear on my computer’s internal hard disk drive (HDD), there would be a /home folder in the Ubuntu ISO. That Ubuntu /home folder would have nothing to do with what I was trying to accomplish with a /home partition or folder on my own system.)

Since reinstallation in Mint appeared likely to delete anything in the existing /home folder, I copied its contents to an external USB drive. In one of my failed efforts, I made the mistake of doing this copying in an administrator session of Mint’s File Manager, called Thunar. I opened that administrative session by opening a Terminal (Ctrl-Alt-T) and typing “sudo thunar.” (Note: this post uses standard English punctuation. So in that example, the user would type the words “sudo thunar” without the quotation marks and without the ending period.)

I doubted that this copying would convey any details of file ownership if I was copying to an NTFS drive. But if an administrator copied to a partition formatted as ext4, it appeared that those files would be owned by that administrative account. That could (and did) create problems when an ordinary user session tried to gain access to those files, which were necessary for system operation.

The files I copied to the external drive included the contents of the /home partition. I saved those in a folder called TempHome. I created another folder, TempDesktop, and there I saved copies of everything on the Mint desktop. Also, from the /etc/apt folder, I saved the sources.list file and the sources.list.d folder. I also saved the list of Synaptic packages mentioned above. Before copying I made sure to toggle Ctrl-H, in File Manager, so that hidden files would be visible and thus could be copied and pasted. Then I proceeded with reinstallation, specifying the size and arrangement of the partitions that I wanted to create, as described in the other post.

Configuring the Separate Partition

The reinstaller finished, and the system rebooted. Linux Mint started successfully. I rebooted into the YUMI drive and ran Parted Magic, planning to use its Partition Editor (i.e., GParted) and also its file manager utility. (An Ubuntu live CD would have worked as well, though I might have had to install GParted before proceeding. Some other multitools also included GParted. The GParted live CD itself apparently included a file manager.)

I started with GParted. There was a stray 1MB unallocated space between the /boot and root partitions, so I revised the partition list to enlarge the /boot partition and eliminate that. I also divided the large unallocated space between the desired DATA and BACKROOM partitions — the former for saving user data, the latter for storing system images, program caches, and other materials that did not need to be backed up — both in NTFS format. GParted stated that it would take two hours for my last task of resizing BACKROOM to use up miscellaneous space, so I rebooted into MiniTool Partition Wizard and finished it in a few seconds. I rebooted into the installed Linux, and ran a few programs, to make sure these partition edits had not harmed it, though I did not think they would.

Back in Parted Magic (i.e., the live CD), I used the file manager to look at the /etc/fstab file on the root partition. Note that this was, again, the root partition for the new Linux installation, not the root partition on the live CD. In this particular file manager, as in some others, the left-hand panel showed the various volumes that were available. It saw a 251MB volume, which was presumably the newly created /boot partition; it saw a 30GB volume, presumably the root partition; it saw a 20GB volume, presumably /home; and it saw others (i.e., DATA, BACKROOM, and the YUMI USB drive).

The /etc/fstab file was in the 30GB volume. According to Wikipedia,

The fstab file typically lists all available disk partitions and other types of file systems and data sources that are not necessarily disk-based, and indicates how they are to be initialized or otherwise integrated into the larger file system structure.

(See also the Ubuntu documentation.) Fstab listed four partitions, each with its own Universally Unique Identifier (UUID) number. It listed them in system order, as distinct from the order in which I had created them or their order on the partition: that is, it started with the / (root) partition, which was fundamental to the operating system, even though the root partition was sda6 and /boot was sda5. It did state that /home was on a separate partition, sda7, and that it was being mounted as /home. So apparently I did not have to engage in any of the partition moving or fstab editing that would have been required if I had been migrating from a previously used /home folder to a newly created /home partition (see MakeTechEasier). In fstab, I did not try to alter the options for any of these partitions.

Restoring Saved Files

I plugged in the external USB drive (actually, an SDHC card) on which I had saved a copy of the previous installation’s /home folder, my list of installed Synaptic packages, and my desktop files. In the live CD’s file manager, this external drive appeared as SAMSUNG, which was what I had named it.

I went into that SAMSUNG drive and began copying the files I had saved there. First, I copied the sources.list file and the sources.list.d folder to /etc/apt on the 30GB (i.e., root) volume. Next, I copied the list of Symantec packages, and the files from the SAMSUNG drive’s TempDesktop folder, back to the desktop of the installed system (i.e., not the desktop of the live CD). That installed desktop was in the /m1210/Desktop folder, on the /home partition (i.e., on the 20GB volume, not the 30GB volume).

Finally, and perhaps most important, the SAMSUNG drive had the TempHome folder. In this was the m1210 user folder, and that contained 10 items — and, as I saw on the status bar at the bottom, 32 hidden items. I found that copying the entire m1210 folder from the TempHome folder succeeded in bringing along those hidden items. I copied that m1210 folder from SAMSUNG/TempHome to the top level of the 20GB volume, where of course there already was an m1210 folder. This triggered a question as to whether I wanted to replace existing files. I told the file manager to overwrite all existing files.

That took care of the files that I had backed up onto the SAMSUNG drive. Now I tried to reboot into the installed Linux Mint system. Unfortunately, during reboot, I got this message:

User’s $HOME/.dmrc file is being ignored. This prevents the default session and language from being saved. File should be owned by user and have 644 permissions. User’s $HOME directory must be owned by user and not writable by other users.

Instead of clicking OK, I hit Ctrl-Alt-F3. This brought up a command prompt. The prompt said “m1210 login:.” That turned out to be a request for my username. Kind of odd: it already said m1210. Then I remembered; I had also named the computer m1210. So, OK, I typed m1210 again, since that was my username. Then it asked for my password; and when I successfully entered that, it gave me a green prompt: m1210@m1210. It seemed I should change the computer name for clarity. I believed the green prompt meant I was running as myself (i.e., an ordinary user), not as an administrator. That was good, because in a previously fubared installation, I had done things as an administrator, and then those turned out not to be available to me as an ordinary user. Which was perhaps what I had done in this case as well, by using the Parted Magic file manager; perhaps it was able to do things so smoothly because it was running as an administrator.

Anyway, now that I was at the command prompt, I had advice on how to fix that error message, quoted above, regarding the User’s $HOME/.dmrc file. The advice was to enter these two commands:

sudo chown m1210:m1210 ~/.dmrc
sudo chmod 644 ~/.dmrc

Other users would apparently replace “m1210” with their own usernames. For me, those two commands seemed to work, or at least I received no error messages. I typed “sudo reboot” and hoped that, this time, the system would boot properly. It did. And there were early signs of success: the items that I had moved from SAMSUNG to /home/m1210/Desktop were visible on the desktop. One of those desktop items was an icon to open the screensaver utility. I double-clicked on that icon and saw that my screensaver settings had been preserved.

Things did not seem to be going so well in the Wine area. As described in another post, I had used Wine to get IrfanView, a Windows program, to run on Linux. But now the desktop icon for IrfanView was not doing anything. In File Manager, I went to /home/m1210/.wine/drive_c/Program Files/IrfanView. There, I double-clicked on i_view32.exe, the IrfanView executable. It did not run. Then it occurred to me that perhaps Wine had not yet been installed or updated via Synaptic. So I turned my attention in that direction.

Updating Synaptic Packages

As mentioned above, I had saved a list of “markings” that hopefully indicated which packages I had downloaded during the first installation of Linux Mint Xfce. Now I wanted to restore that list, and hopefully that would automate the downloading and updating of all those programs. As advised by Ubuntu Geek and Free Software Magazine (Richmond, 2012), all I had to do was to go into Synaptic Package Manager (Start > System > Package Manager and select File > Read Markings. I did that, and tried to point Synaptic toward the Desktop folder indicated on its left panel, but for some reason it would not stay there. So instead I clicked Computer on the left panel and chose /home/m1210/Desktop. That worked: I was looking at the desktop.

From the desktop, I selected the 2016-04-23_Synaptic_Packages file that I had saved (above) and clicked Open > Mark > Apply. That gave me an error message: “Could not apply changes! Fix broken packages first.” I closed that and looked at the Synaptic status bar (i.e., bottom line). It indicated that three packages were broken. I went to Edit > Fix broken packages. I got “Unable to correct problems, you have held broken packages.” A search inspired me to click on Synaptic’s Status button and select Broken Dependencies. That produced a list of three packages: inkscape, lsb-core, and python-libtorrent. I right-clicked on each and looked at Properties. Each confirmed that the exclamation mark in a red box meant Broken. Then I learned that I could get the same thing a bit more easily by clicking Synaptic’s Custom Filters button > Broken.

Sites found in that search tended to use command-line solutions. I used Ctrl-Alt-T to open Terminal. One recommendation was to run “dpkg –get-selections | grep hold” for a list of “held broken packages.” That produced nothing. Likewise “apt-mark showhold.” Some suggested using aptitude, which could be installed via “sudo apt-get install aptitude,” and some said that worked, but others expressed concern that aptitude could mess up a system. The aptitude command would have been “sudo aptitude -f install [package],” where the command would be less cautious without the -f and where [package] would be the name of the broken package. Alternately, there was the option of running three commands sequentially:

sudo apt-get upgrade
sudo apt-get update
sudo apt-get update –fix-missing

But I was not sure whether upgrading and updating outside of Synaptic would confuse Synaptic’s list of which programs had been upgraded, updated, or fixed. Ultimately, in Synaptic, I right-clicked on each of the three broken packages and chose Unmark. When I unmarked one of them, I got an indication that Google Earth would also be unmarked. After approving all of those unmarkings, I tried again with Synaptic’s Apply button. It warned me that I was applying software that was Not Authenticated. But when I expanded that list, there was nothing. I wondered whether this was triggered by Google Earth, which I might have installed outside Synaptic, and which was now off the list.

I clicked apply, but now I had another error message: “Resolve generated breaks, this may be caused by held packages.” This time, Synaptic offered no custom list. I poked around for a bit, trying to see where I could find a display of the problematic programs, and then clicked Apply again. This time, there was no “Not Authenticated” warning. So maybe Synaptic just had to clear its head? I clicked the Apply button, and Synaptic ran without further problems.

When that update was done, I searched for google-earth. I marked google-earth-stable, and tried to install it, but it came back up as broken again. A search led to a Linux Mint forums suggestion to use “sudo apt-get update -f” to repair broken packages. Now that I had updated everything else in Synaptic, I thought this command might not hurt. I unmarked google-earth in Synaptic, closed Synaptic, and typed that command in Terminal. I got an error: “Command line option ‘f’ [from -f] is not known.”

I reverted to the three commands quoted above, starting with “sudo apt-get upgrade.” That one ran OK. But the second one, “sudo apt-get update,” resulted in a lot of “Failed to fetch” messages with “404 Not Found” and ended with “Some index files failed to download.” It seemed my preferred mirror might be dysfunctional. I went into Start > System > Software Sources > Official Repositories and changed the mirror that was generating those messages, by clicking on that mirror, waiting for some speed results to appear, and then choosing one of the fastest nearby mirrors. Then (still in Software Sources) I clicked the Update the Cache button and closed Software Sources.

Back in Terminal, I used the Up Arrow key to repeat the previous command. This time it ran quickly. Then I ran the third command (above): “sudo apt-get update –fix-missing.” This produced another set of warning messages: First “GPG error” and then “The following signatures couldn’t be verified because the public key is not available.” A search led to instructions to run this command:

sudo apt-key adv –keyserver –recv-keys 40976EAF437D05B5

replacing that long last number with whatever number actually appeared in the error message. I had two of these error messages, one for and one for Google, so I had to repeat that command with the other number. Each of those two commands resulted in an indication that one public key had been processed and imported, so it looked like it worked. Someone explained that either I had lost the keys for launchpad and Google, or I never had them. I wasn’t sure whether this was something that apt-get could see but Synaptic wouldn’t mention.

I re-ran the third command (“sudo apt-get update –fix-missing”). It completed without GPG errors and without 404 Not Found — indeed, without any errors. To be sure, I ran “sudo apt-get check.” No problems reported. I went back into Synaptic and tried again. I searched for google-earth, marked it for installation, approved the additional required changes, and clicked Apply. It finished without problems.

I wanted to test whether Google Earth was actually going to run. Unfortunately, there did not appear to be an icon in the Start menu. A search led to advice inspiring me to right-click on the Start button and choose > Edit Applications. That opened a window in which I chose Accessories > + (i.e., the Plus button at the top left corner) > Add Launcher > enter “google-earth” as the Command > click on the icon next to the New Launcher title > search for Google > choose a Google Earth icon (albeit a poor imitation of the ones available in Windows, or perhaps someday import your own) > click on the New Launcher title > rename to Google Earth > click the Enter button at the right end of that line > click Save Launcher (i.e., the button next to + near the upper left corner) > close the New Launcher window. I tested it: my Start > Accessories menu did run Google Earth, albeit only temporarily: as the program started, it gave me a warning that this graphics card did not support Google Earth, and then the program closed.

Now I returned to the question of whether I had needed to run Synaptic in order to get Wine back into service. On the desktop, I double-clicked again on the IrfanView icon. It still didn’t run. Neither did i_view32.exe. I searched for Wine in Synaptic. For some reason, it was not installed. I marked wine, and also winetricks, for installation, and clicked Apply.

But since Wine had turned out to be missing in action, now there was a question as to how successful my Synaptic process had been, for purposes of reinstalling the software I had installed previously. I opened the 2016-04-23_Synaptic_Packages file that I had used to tell Synaptic what to reinstall. It did have Wine and Winetricks marked for installation, along with other packages (e.g., gecko) named in my previous post on installing IrfanView via Wine in Linux Mint. Had the other recently encountered Synaptic problems (above) somehow prevented full implementation of the list in 2016-04-23_Synaptic_Packages?

To find out, in Synaptic, I repeated the process described above: File > Read Markings > navigate to /home/m1210/Desktop/2016-04-23_Synaptic_Packages. Well. When I opened that file, Synaptic said there was a whole long list of packages to be installed. I thought this was taken care of, but I was wrong. Maybe this needed to happen in several waves — maybe I needed to keep rerunning Synaptic until there was no more action? Not sure. I clicked Mark > Apply. It ran.

When it was nearly done, it gave me a question: “Replace configuration file ‘/etc/issue’?” I looked at the details. There seemed to be just two operative lines. The first one had a minus sign in front of Linux Mint, and the second had a plus sign in front of Ubuntu. Was Synaptic proposing to replace something about Mint with something about Ubuntu? A search led to very few results, suggesting that this was an unusual issue. Between the two somewhat relevant webpages I found, one advised against and the other advised in favor. I decided to approve the change. This triggered a couple other similar questions; I approved those too.

Synaptic then proceeded to do a bunch of installing. When it was done, I clicked Reload. It reported nothing else broken or to be installed, upgraded, or removed. To be sure, I went again through the process of loading the 2016-04-23_Synaptic_Packages file. Neither that nor a reclick of the Reload button produced anything else. It appeared we were done.

Reviving Wine

So now, at last, did IrfanView run? No. I checked in Synaptic: it seemed that most of the essentials (e.g., wine, winetricks, wine-gecko, wine-mono) were installed. I did still have a Start > Wine > Winetricks menu option, but that didn’t work either.

A search led to a suggestion that seemed to say it might work if I deleted the existing .wine folder and created a new one. Another discussion offered some clarification. What I should do, it seemed, was to delete the .wine folder and then run winecfg to create a new one. Then, possibly, I could copy in the contents of the old .wine folder. If that didn’t work, then apparently reinstalling Linux Mint would mean reinstalling each Wine program as well.

So, OK, in File Manager I went to /home/m1210. There, I saw .wine. I right-clicked > Delete. I got an error message: “Could not delete file ‘system.reg.'” I cancelled. Instead, I opened Terminal and typed these commands:

cd /home/m1210
sudo rm -dfr .wine

That worked; .wine was gone. Now, how to run winecfg? I tried just typing it at the command prompt. That worked, sort of: I got the Wine Configuration dialog, but also several error messages (e.g., “error reading registry key for installroot”). I wasn’t sure whether I had gotten such messages during the original installation of Wine.

Now could I just copy in the previous contents of .wine from my backup, or did I need to go back through the whole Wine and IrfanView installation and configuration process? I cancelled out of the Wine Configuration dialog, went to my external backup drive (using File Manager), used Ctrl-H to make sure everything was visible, copied the files there, and pasted them into /home/m1210/.wine. Surprisingly, that produced no errors or questions about overwriting.

I went back to Terminal and typed winecfg again. This time, it opened the Wine Configuration dialog without any error messages. I closed that dialog and tried the IrfanView icon on the desktop. It worked! Wow, that was really simple. I was fearing the worst, but at least for IrfanView, once the Synaptic issues were out of the way, just creating a new .wine folder was apparently sufficient to get us back on the road.


At this point, it seemed that I had restored my system to pretty much its state prior to the reinstallation of Linux Mint. Things seemed to be working, and the programs that had been working before seemed to be working again. Of course, I could not rule out the possibility that new reinstallation-related problems might arise later.

This restoration process certainly was not as simple as merely clicking a button or running a command to put everything back the way it was. Then again, I wasn’t sure which of these problems were intrinsic to the reinstallation. Regarding Synaptic especially, I could not say whether the foregoing issues were already present within the previous installation. So I could not say whether I would encounter similar problems or complexity every time I reinstalled or upgraded Mint.

Much of what took my time during this restoration process — and it was a considerable amount of time, spanning several days — had to do with my own learning about Linux in general, and especially about the several sections described above (notably regarding the use of the live CD to copy files successfully, and regarding Synaptic). Having gone through all that, it seemed that a future restoration would proceed more quickly.

The difficulty of this restoration process, even with the benefit of additional learning, was such as to make me doubt the original reason for having a separate /home partition. Certainly it did not appear that, in Linux Mint, it would be simple to resume use of my previous settings after a reinstallation. I decided that it might still make sense to keep the separate /home partition, though, because apparently it would be useful if I decided later to abandon Mint in favor of Ubuntu or some other distribution.

This entry was posted in Uncategorized and tagged , , , , , , , , , , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.