A "No home directory" error after relocating /home means the new partition is not being mounted at boot. The step that failed was the fstab edit: with no line mapping the data partition to /home, the system boots with /home as an empty folder on the root disk, so /home/peter does not exist. Adding one entry to /etc/fstab — and testing it before rebooting — fixes the problem.
Why login breaks when the mount is missing
Your user account lives in /etc/passwd on the root filesystem, and it points to a home directory of /home/peter. At boot, the system reads /etc/fstab and mounts everything listed there. If the file only describes the root filesystem and swap, the freshly created /home directory stays empty — the data partition is never attached. The graphical login then cannot change into a home directory that does not exist and reports the error. This is purely a mount problem: the account is intact, and your files are almost certainly still sitting on the data partition, just not visible where the system expects them.
Confirm the diagnosis
Before editing anything, gather three facts: what partitions exist, what fstab currently says, and what is actually mounted.
lsblk -forsudo blkidlists every partition with its filesystem and UUID. Note the data partition's UUID.cat /etc/fstabshows the mount table. If nothing maps that UUID to/home, that is the fault.findmnt /homeanddf -h /homeshow what is mounted there right now. If the output points at the root disk rather than the data partition, the diagnosis is confirmed.
Add the missing line
Open the file with sudo nano /etc/fstab and add one line for the data partition, using its real UUID:
UUID=611a33a4-d985-4a3d-b550-5550f12c3023 /home ext4 defaults 0 2The six fields are, in order: the device (by UUID), the mount point, the filesystem type, the mount options, the dump frequency (always 0 on modern systems), and the fsck pass number. Writing /dev/disk/by-uuid/... instead of UUID=... is equivalent — both survive reboots, unlike /dev/sda4, which can be renumbered.
Two details worth correcting while you are in there. First, the fsck pass number: the root filesystem should be 1, and other local filesystems conventionally 2, so they are checked after root. A 1 on /home boots fine but checks both filesystems in the same pass; 2 is the safer habit. Second, if a fumbled edit left a duplicated /swap.img line, delete the extra copy — one line per device keeps the file readable.
Test before rebooting
This is the check that would have caught the mistake the first time. In the same session, run:
sudo mount -a
findmnt /home
ls /homemount -a mounts everything fstab describes, immediately. Any typo in the UUID or options prints an error now instead of producing a broken boot. findmnt /home should report the data partition, and ls /home should show your user's folder.
If /home mounts but is empty, the earlier copy went to the wrong destination — a common trap when data is rsynced into /mnt while nothing is mounted there. The originals are usually still in /home_backup. With the partition mounted, re-copy them:
sudo rsync -aXS /home_backup/ /home/If you cannot get past the login screen
You do not need a rescue disk. Press Ctrl+Alt+F3 (or F2/F4 depending on setup) to reach a text console and log in with your normal username and password — that works because text login only needs /etc/passwd, not a home directory. Edit /etc/fstab there, run sudo mount -a, and reboot. Alternatively, pick the recovery mode entry in the GRUB menu to get a root shell.
Do you also need the /boot/efi line?
No. Every fstab line is independent: one device, one mount point. The /boot/efi line seen on another machine exists to mount that machine's EFI system partition. If your machine boots, its firmware path is already handled; adding a line with someone else's UUID accomplishes nothing and can stall boot. Never copy fstab lines between computers — add only lines whose UUID matches a partition on your own disk and whose mount point you actually need. To check whether the EFI partition is mounted, findmnt /boot/efi answers it, but that is a separate topic from /home.
Avoiding this next time
- Back up the file first:
sudo cp /etc/fstab /etc/fstab.bak. - Take UUIDs from
lsblk -forblkid, never from memory. - After every edit, validate with
sudo findmnt --verifyor a plainmount -abefore rebooting. - Keep the working session open until the new arrangement has been confirmed with a reboot.
- If the disk might sometimes be absent, add
nofailto the mount options so a missing device cannot stall boot.
Frequently Asked Questions
What do the two numbers at the end of an fstab line mean?
The fifth field is the legacy dump frequency; leave it at 0. The sixth is the fsck pass order: the root filesystem gets 1, other local filesystems conventionally 2, and 0 means the filesystem is never checked automatically at boot.
Is UUID=... different from /dev/disk/by-uuid/...?
No — they are two syntaxes for the same thing. Both identify the partition by its stable UUID. Avoid /dev/sda4-style names in fstab, since device letters can change between boots.
/home mounts now, but it is empty. Where did my files go?
The original rsync probably wrote into a directory that had nothing mounted, leaving the data on the root disk. Check /home_backup; with the partition mounted at /home, re-copy it with sudo rsync -aXS /home_backup/ /home/.
Can I delete /home_backup?
Only after a fresh reboot confirms the data partition mounts at /home and your files and applications all work. Until then it is your only fallback copy.
Is a duplicated swap line in fstab harmful?
Usually harmless — the kernel generally tolerates it — but remove the duplicate. One line per device keeps the file predictable and easier to debug.
Should the last field for /home be 1 or 2?
2 is the conventional choice: it checks /home after root and allows parallel checking with other non-root filesystems. 1 also boots but checks it in the same pass as root; 0 skips automatic checks entirely.