You are not logged in.
My root disk is lvm on luks and everything unlocks and mounts fine at boot with grub. My current /home is on a separate disk that is ext4 on luks and I unlock this after root with /etc/crypttab. I manually type passwords for both and this all works fine.
uname -a
Linux firefly 6.7.0-arch3-1 #1 SMP PREEMPT_DYNAMIC Sat, 13 Jan 2024 14:37:14 +0000 x86_64 GNU/Linuxcryptsetup -V
cryptsetup 2.6.1 flags: UDEV BLKID KEYRING KERNEL_CAPIlsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 0 931.5G 0 disk
└─sda1 8:1 0 931.5G 0 part
└─home 254:3 0 931.5G 0 crypt /home
sdb 8:16 0 3.6T 0 disk
└─sdb1 8:17 0 3.6T 0 part /mnt/Store
sr0 11:0 1 6.1G 0 rom
nvme0n1 259:1 0 931.5G 0 disk
├─nvme0n1p1 259:3 0 300M 0 part /boot
└─nvme0n1p2 259:4 0 931.2G 0 part
└─cryptlvm 254:0 0 931.2G 0 crypt
├─vg1-swap 254:1 0 16G 0 lvm [SWAP]
└─vg1-root 254:2 0 915.2G 0 lvm /That sda is now old and too small, so I bought a new disk and I am trying to migrate all my data from that to my new nvme1n1.
nvme1n1 259:0 0 1.8T 0 disk
└─nvme1n1p1 259:2 0 1.8T 0 part
└─newhome 254:4 0 1.8T 0 cryptHere's the entire process for how I setup the new disk which is identical to how I setup the old one at least as far as I can remember:
1. cfdisk /dev/nvme1n1, create gpt label, create primary partition on whole disk
2. cryptsetup luksFormat /dev/nvme1n1, enter password
3. cryptsetup open /dev/nvme1n1p1 newhome
4. mkfs.ext4 /dev/mapper/newhome
5. mount /dev/mapper/newhome /mnt/tmp
6. rsync -av /home/* /mnt/tmp
7. ls -al /mnt/tmp/sando, verify everything is there, permissions and ownership are right
8. umount /mnt/tmp
9. cryptsetup close newhome
10. edit /etc/cryptab
# OLD
# home /dev/sda1 none
#NEW
home /dev/nvme1n1p1 none11. edit /etc/fstab
# OLD HOME
# UUID= *uuid* /home ext4 rw,realtime,discard 0 2
# NEW HOME
/dev/mapper/home /home ext4 rw,realtime,discard 0 2
# UUID= *uuid* /home ext4 rw,realtime,discard 0 2* doesn't matter if I use device id or uuid, doesn't work either way
12. reboot
Now what happens is I unlock root and the new disk, but it fails to mount /home and I get thrown to recovery shell. When I look at journalctl -xb the error is:
mount: /home: wrong fs type, bad option, bad superblock on /dev/mapper/home, missing codepage or helper program, or other error.At this point if I type "mount /dev/mapper/home /home" it mounts and all the files are there and fine. I can unmount and fsck it finds no issues. If I mount it by hand and check df -T it's ext4. I am at a complete loss. What does this error actually mean? Did I miss something? Does rsync do shenanigans? Is there some other way to achieve what I am trying to do? I've done this 3 times, blkdiscard -f -z the new disk each time in between to make sure I start with a blank slate and I'm either missing something stupid or this process does not work for reasons I don't understand.
Last edited by cptgrok (2024-02-06 00:29:33)
Offline
# OLD HOME # UUID= *uuid* /home ext4 rw,relatime,discard 0 2 # NEW HOME /dev/mapper/home /home ext4 rw,realtime,discard 0 2 # UUID= *uuid* /home ext4 rw,realtime,discard 0 2
Is that relatime or realtime? Typos or invalid mount options will cause problems with mounting disks.
Last edited by spiffeeroo (2024-01-29 01:04:37)
Offline
Is that relatime or realtime? Typos or invalid mount options will cause problems with mounting disks.
That's a typo here, I didn't cut and paste fstab, and it's the commented out entry for the hold /home on the old ssd. That one works fine via fstab. The other entry for the new nvme drive does not work. Again, I can manually mount that partition after unlocking with cryptsetup and the files and directories are there with all the right permissions.
I checked mount -av, but it's the exact same error "wrong fs type, bad option, bad superblock on /dev/mapper/home, missing codepage or helper program, or other error." and nothing more.
Offline
Alright, this is interesting. I zeroed the drive and did not setup luks but just created a primary gpt partition, made an ext4 system, rsync my files and I can manually mount the partition like expected but it will not mount automatically via fstab with the same error. But, if I change the options from "rw,realtime,discard" to "defaults" , it DOES mount via fstab and mount -a. I think I can work around this but I'd like to understand why the presence or absence of certain options makes this disk/partition/filesystem not mount when the same setup on a different physical disk works fine. I'm baffled. Even if someone just has a link to a deep dive on fstab or filesystems I'll happily go read on my own.
Offline
"rw,realtime,discard" to "defaults"
Is this just a typo on your post or is it actually realtime. Should be relatime.
Never argue with an idiot, they will drag you down to their level and then beat you with experience.
It is better to light a candle than curse the darkness.
A journey of a thousand miles begins with a single step.
Offline
I sort of hate this, but it works now and I do not know why. I did an update and I don't know what all changed but cryptsetup is now 2.7.0, so maybe there was a bug in 2.6.1. I have no idea.
Offline