how to properly add a drive as /home to Ubuntu fork?

lleb · 05-04-2020, 04:39 PM

I just installed Pop!_OS (Ubuntu Fork) on to my SSD, during install I just unplugged my HDD (SATA) drive. Now I want to add that drive to /etc/fstab.

It has been many years since I did this, what is the correct way to add that drive using UUID (I think that is the correct name)?

Code:

 df -Th
Filesystem            Type      Size  Used Avail Use% Mounted on
udev                  devtmpfs   16G     0   16G   0% /dev
tmpfs                 tmpfs     3.2G  2.4M  3.2G   1% /run
/dev/mapper/data-root ext4      220G  7.0G  202G   4% /
tmpfs                 tmpfs      16G  175M   16G   2% /dev/shm
tmpfs                 tmpfs     5.0M     0  5.0M   0% /run/lock
tmpfs                 tmpfs      16G     0   16G   0% /sys/fs/cgroup
/dev/sda1             vfat      498M  208M  290M  42% /boot/efi
/dev/sda2             vfat      4.0G  2.4G  1.7G  60% /recovery
tmpfs                 tmpfs     3.2G   76K  3.2G   1% /run/user/1000

Code:

# fdisk -l
Disk /dev/sda: 232.91 GiB, 250059350016 bytes, 488397168 sectors
Disk model: Samsung SSD 850 
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 0C1CC56F-4C18-4B42-8A51-EB2C29190F45

Device         Start       End   Sectors   Size Type
/dev/sda1       4096   1023998   1019903   498M EFI System
/dev/sda2    1024000   9412606   8388607     4G Microsoft basic data
/dev/sda3    9412608 480004462 470591855 224.4G Linux filesystem
/dev/sda4  480004464 488393070   8388607     4G Linux swap


Disk /dev/sdb: 4.56 TiB, 5000981078016 bytes, 9767541168 sectors
Disk model: TOSHIBA HDWE150 
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: F087E637-C873-47D8-874C-6059EE7EA127

Device     Start        End    Sectors  Size Type
/dev/sdb1   2048 9767540735 9767538688  4.6T Linux filesystem




Disk /dev/mapper/cryptdata: 224.39 GiB, 240926252544 bytes, 470559087 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/mapper/data-root: 224.39 GiB, 240925016064 bytes, 470556672 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/mapper/cryptswap: 3.102 GiB, 4294442496 bytes, 8387583 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

/dev/sdb is my /home from my old Fedora 27 install.

Thank you in advance.

agillator · 05-04-2020, 05:31 PM

Code:

 UUID=<partition's uuid>    <mount point>    <filesystem type>    <options>    0 0

Assuming the most probable values from what you describe:

Code:

  UUID=<whatever>  /home/<username>  ext4  defaults  0 0

lleb · 05-04-2020, 07:57 PM

thank you that is what I was looking for.

will there be an issue with the fact the OS already had a /home on the root directory located on the SSD?

sxy · 05-04-2020, 09:40 PM

Quote:

will there be an issue with the fact the OS already had a /home on the root directory located on the SSD?

In fact you cannot mount your device at /home if there's no /home directory at all. What matters is that data stored under /home become inaccessible when a new device has been mounted at /home. I think you can do like this:

Code:

# mv /home /home.bak
# mkdir /home
# mount <new device> /home

agillator · 05-04-2020, 10:07 PM

No, there won't be an issue as far as your system is concerned. What will happen is the new mount will mask the existing data and it will be unavailable as long as the new partition is mounted. The existing data will again be available as soon as the new is unmounted.

michaelk · 05-04-2020, 10:55 PM

The differences between the two operating systems could result in applications failing because user default configurations in your home directory are different.

To be on the conservative side I would not mount the drive as /home.

pan64 · 05-06-2020, 07:54 AM

how is it related to this: https://www.linuxquestions.org/quest...1-4175674514/?

ondoho · 07-22-2020, 05:24 AM

Quote:

Originally Posted by charlly

[link also removed]

WTH? Reported.

rtmistler · 07-22-2020, 07:39 AM

User charlly,

Welcome to LQ.

When posting in technical threads, please avoid possible off-topic, or unclear information and also recommend against posting links to a search engine with no apparent purpose.

User ondoho,

Please avoid using textspeak because it can be unclear and misunderstood by others, and also please avoid quoting links from other users in situations where you are reporting those.

@All: Please keep the thread on topic.

ondoho · 07-22-2020, 11:31 AM

^ The link was "https://google.com".

jmgibson1981 · 07-22-2020, 12:19 PM

Quote:

The differences between the two operating systems could result in applications failing because user default configurations in your home directory are different.

I can't recall who I learned this from but this is a prime example of why a shared /home is a bad idea for multiple os types. Better to mount this new disk at /data or /mnt/data or something. Move your data directories in /home/"$USER" to a folder on that drive, then symlink them to your /home/"$USER"/

This keeps all .* files unique to each os installed, and avoids any potential crossover or corruption issues when there are minor differences to the same file in different OS's. And you maintain full access to your data.

rtmistler · 07-22-2020, 01:07 PM

Quote:

Originally Posted by ondoho

^ The link was

Can I ask the continued purpose of your posting here where it appears to be off topic? Such as clarification that it is instead relevant to this thread?

It was clear from reports that people felt it was potential spam, and the link was removed. Meanwhile it is only a link to a very well known search engine.

I also requested people to remain on topic in this thread.

This has been a continued behavior of yours, which is to continue posting in spite of a request on my part to keep threads on topic. Please refrain from being unclear, and also giving an impression that you wish to continue off-topic discussion when it is inappropriate, and requested to be discontinued in threads.

JeremyBoden · 07-22-2020, 06:45 PM

You will have user(s) and groups currently defined in /etc/passwd & /etc/group together with corresponding UID/GID's in the Pop!_OS install.

There is no particular reason to suppose they will definitely align with your /home [except for root which always has UID=0]
If there is a disparity, you may get some strange file permission issues.

ondoho · 07-23-2020, 02:16 AM

Quote:

Originally Posted by rtmistler

Can I ask the continued purpose of your posting here where it appears to be off topic? Such as clarification that it is instead relevant to this thread?

It was clear from reports that people felt it was potential spam, and the link was removed. Meanwhile it is only a link to a very well known search engine.

I also requested people to remain on topic in this thread.

This has been a continued behavior of yours, which is to continue posting in spite of a request on my part to keep threads on topic. Please refrain from being unclear, and also giving an impression that you wish to continue off-topic discussion when it is inappropriate, and requested to be discontinued in threads.

rtmistler, I simply clarified why it was OK to not edit the link out in this particular case.
How is that a problem for you?
I would have left it at my previous post but now you asked me a question I feel the need to answer.