I installed Rocky 10 on an external usb drive and have been running it this way. I want to move the physical drive to an internal sata port. When I do this, the boot hangs saying it cannot find home.mount. When the boot stops, it says “job dev-disk-by\x2 uuid-a43b….”.
The /etc/fstab uses all UUID, so it seems like it should find everything. Any thoughts?
Thanks, Tim
Yah but the efibootmgr is looking for a specific disk and doesn’t know anything about fstab entries as nothing is mounted. You will have to boot into rescue mode from a RL install image and follow instructions to chroot mount sysimage then use efibootmgr to create a new entry after running lsblk to see what partition boot/efi is on. Look at man efibootmgr to get familiar with commands. I look back at my notes to see if I can find an example entry command.
I’m going to back up here and say that there is not enough information provided for diagnosis.
Are you dual booting?
Are you using RL10 grub menu OR the other distro grub menu?
Or some other means?
The output of lsblk will be helpful. Paste that output in a code block, the </> symbol on edit menu.
Yes, I am using RL10 grub to multiple boot using UEFI. Here is lsblk with the boot drive on external USB:
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 0 476.9G 0 disk
├─sda1 8:1 0 650M 0 part
├─sda2 8:2 0 128M 0 part
├─sda3 8:3 0 475.2G 0 part
└─sda4 8:4 0 990M 0 part
sdb 8:16 0 489G 0 disk
├─sdb1 8:17 0 450M 0 part
├─sdb2 8:18 0 100M 0 part
├─sdb3 8:19 0 16M 0 part
├─sdb4 8:20 0 487.7G 0 part
└─sdb5 8:21 0 767M 0 part
sdc 8:32 1 0B 0 disk
sdd 8:48 0 931.5G 0 disk
├─sdd1 8:49 0 576M 0 part /boot/efi
├─sdd2 8:50 0 1G 0 part /boot
└─sdd3 8:51 0 929.8G 0 part
├─rl_mareba-root 253:0 0 70G 0 lvm /
├─rl_mareba-swap 253:1 0 23.5G 0 lvm [SWAP]
└─rl_mareba-home 253:2 0 836.3G 0 lvm /home
Please put your output in a code block. It makes it more readable,
I’m not going to be able to help with the actual problem because your home and root are on a lvm and I avoid those because they’re and added complexity. But for someone who does know the following information request will be helpful.
After you attach this disk to MB what steps do you take once you start the computer?
AFter the MB logo does the grub menu appear?
If yes then do you allow the default kernel to boot?
Does the error message appear immediately?
If the rl10 boot fails can you reboot and select one of the other ms OS’s and get them to boot?
UEFI (firmware) does load something (bootloader) from some ESP (EFI System Partition).
What UEFI can load is within motherboard, not on any drive. Example:
efibootmgr -v | grep rocky
Boot0000* rocky HD(1,GPT,a1c36011-97a2-45e3-95d1-6c37965770f4,0x800,0x12c000)/File(\EFI\rocky\shimx64.efi)
Boot0001* rocky HD(1,GPT,d7797843-f2d4-40ae-b1c4-2b800d2ae59f,0x800,0x12c000)/File(\EFI\rocky\shimx64.efi)
This tells that there are two “UEFI boot entries” that would load Rocky’s GRUB.
Furthermore, they are on different partitions:
a1c36011-97a2-45e3-95d1-6c37965770f4
d7797843-f2d4-40ae-b1c4-2b800d2ae59f
IIRC, there are partition UUIDs, not filesystem UUIDs. Command blkid does show those, if the lsblk does not have option to show them.
Your UEFI finds a bootloader from the USB (“sdd1”). The UEFI might not have stored entry about it, nor look for vendor-specific *.efi, but it does look for certain “usual suspects” from drives, which Rocky install may have populated too.
If you now make a copy of the ESP from USB to another drive, you have to create an UEFI entry that does point to the shim64.efi on the new partition (with efibootmgr). Then make that the default entry (with efibootmgr or UEFI setup).
The \EFI\rocky\grub.cfg is merely a wrapper that includes grub2/grub.cfg from the partition that has /boot based on UUID. Hence, you have to update that UUID in that wrapper, if you want to use different partition (a copy of “sdd2” on regular drive).
Since partitions and filesystems are referred to with their UUIDs, you cannot simply clone partitions. You have to make the UUID’s unique.
LVM is both more complex and more flexible than “plain” partitions. One could make a partition on drive a PV, add it to the VG “rl_mareba”, and then pvmove extents of LVs from the PV on USB (“sdd3”) to the other PV.
Alas, your USB is 1TB and the other drives are 500GB models with who-knows-what on them. A LV can span multiple PV, but I bet there aint space for the 836.3G LV. The default filesystem used by Rocky is XFS and it is not possible to shrink an existing XFS volume.
Yes, but the OP is not cloning he is just connecting what was the external drive now internally direct to a sata connector to the MB. I would think the disk UUID would remain the same. Until we know what’s happening at boot it’s hard to diagnose.
I did more tests with the two windows drives disconnected to simplify. If I wait long enough, the system drops into emergency mode. I tried to manually mount /home, but the system cannot find the UUID for /home. Where should this information be? I looked around /boot/efi, but couldn’t find anything.
Here is lsblk with Rocky on usb:
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 1 0B 0 disk
sdb 8:16 0 931.5G 0 disk
├─sdb1 8:17 0 576M 0 part /boot/efi
├─sdb2 8:18 0 1G 0 part /boot
└─sdb3 8:19 0 929.8G 0 part
├─rl_mareba-root 253:0 0 70G 0 lvm /
├─rl_mareba-swap 253:1 0 23.5G 0 lvm [SWAP]
└─rl_mareba-home 253:2 0 836.3G 0 lvm /home
Here is lsblk with Rocky on sata:
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 0 931.5G 0 disk
├─sda1 8:1 0 576M 0 part
├─sda2 8:2 0 1G 0 part /boot
└─sda3 8:3 0 929.8G 0 part
├─rl_mareba-root 253:0 0 70G 0 lvm /
└─rl_mareba-swap 253:1 0 23.5G 0 lvm [SWAP]
sdb 8:16 1 0B 0 disk
Here is blkid with Rocky on usb:
/dev/mapper/rl_mareba-swap: UUID="067d28f1-240f-4034-97e5-0b3a11dc30c5" TYPE="swap"
/dev/sdb2: UUID="f37cecc5-855f-49ad-81c0-31f9c6d55297" BLOCK_SIZE="512" TYPE="xfs" PARTUUID="d9bc33cf-7ae5-49f3-b2e7-d2a256bdb2fb"
/dev/sdb3: UUID="e8f60O-1RBM-T8CS-8LtN-0LJ3-W84t-QuBel7" TYPE="LVM2_member" PARTUUID="4849790a-9c7f-482b-8aa2-10ff766b232d"
/dev/sdb1: UUID="66FA-0101" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="EFI System Partition" PARTUUID="33b7c048-7153-440b-b63b-5963c278458b"
/dev/mapper/rl_mareba-home: UUID="a43bd835-5eb9-42c7-848a-08b721674eea" BLOCK_SIZE="512" TYPE="xfs"
/dev/mapper/rl_mareba-root: UUID="48975744-b630-4578-ad06-6be8f2b973e4" BLOCK_SIZE="512" TYPE="xfs"
Here is blkid with Rocky on sata:
/dev/mapper/rl_mareba-swap: UUID="067d28f1-240f-4034-97e5-0b3a11dc30c5" TYPE="swap"
/dev/mapper/rl_mareba-root: UUID="48975744-b630-4578-ad06-6be8f2b973e4" BLOCK_SIZE="512" TYPE="xfs"
/dev/sda2: UUID="f37cecc5-855f-49ad-81c0-31f9c6d55297" BLOCK_SIZE="512" TYPE="xfs" PARTUUID="d9bc33cf-7ae5-49f3-b2e7-d2a256bdb2fb"
/dev/sda3: UUID="e8f60O-1RBM-T8CS-8LtN-0LJ3-W84t-QuBel7" TYPE="LVM2_member" PARTUUID="4849790a-9c7f-482b-8aa2-10ff766b232d"
/dev/sda1: UUID="66FA-0101" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="EFI System Partition" PARTUUID="33b7c048-7153-440b-b63b-5963c278458b"
Thanks for using the code blocks as it makes it easy to see the differences.
I searched this term “xfs volume missing after move to new machine” and got a number of hits. I caution that some of these are raid conditions so while you wait for the expert to answer you can get familiar with the terms.
In terms of the electrical interface, how can you connect an external usb drive to internal sata?
Obviously the order has changed, sdb is now sda, and where has the /home drive gone?
My bad.
There are cheap external enclosures where you can put a regular drive and which connect to the machine with USB. (There were versions that could take PATA or SATA, and connect with USB or eSATA, for convenience.) That could explain case here.
@tch How much data do you have on the drive? That is, what would you lose if you would reinstall Rocky when the drive is in the machine? (You have backups of your data?)
The sdN names can always change. That should be no issue since UUID is used in most places. Could it confuse LVM? Don’t know, but showing 2/3 LVs is not the kind of confusion that I would expect if it does.
Yes, I have thought about redoing the installation internally. Because of the difficultly of re-installing one particular program, this is not something I want to do. But yes, I may have to go this route if I cannot get /home to mount.
First we have to figure out why it does not show. Start by asking from LVM:
pvs
vgs
lvs
The below is what I get from system that does have LV, but not for the system’s own filesystems:
root@r320:~# pvs
PV VG Fmt Attr PSize PFree
/dev/sda5 virt lvm2 a-- <40.00g <20.00g
root@r320:~# vgs
VG #PV #LV #SN Attr VSize VFree
virt 1 1 0 wz--n- <40.00g <20.00g
root@r320:~# lvs
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
c7 virt -wi-a----- 20.00g
and more verbose:
root@r320:~# vgdisplay -v
--- Volume group ---
VG Name virt
System ID
Format lvm2
Metadata Areas 1
Metadata Sequence No 4
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 1
Open LV 0
Max PV 0
Cur PV 1
Act PV 1
VG Size <40.00 GiB
PE Size 4.00 MiB
Total PE 10239
Alloc PE / Size 5120 / 20.00 GiB
Free PE / Size 5119 / <20.00 GiB
VG UUID nwP43e-J4Za-7iF3-4SeM-rMhb-nKLk-SVK0qu
--- Logical volume ---
LV Path /dev/virt/c7
LV Name c7
VG Name virt
LV UUID h6iuEr-ZGuC-EpbD-uCtb-J4Tk-ZfcW-CbAjVl
LV Write Access read/write
LV Creation host, time r320, 2025-07-23 11:11:35 +0300
LV Status available
# open 0
LV Size 20.00 GiB
Current LE 5120
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 8192
Block device 253:0
--- Physical volumes ---
PV Name /dev/sda5
PV UUID 8iV1Lj-sfZF-Flai-W6wX-UNoF-mGwP-yTNITA
PV Status allocatable
Total PE / Free PE 10239 / 5119
We do already know that your rl_mareba-home does not show when the drive is internal, but what other differences do you see (if any)?
Another diagnostics:
fdisk -l /dev/sda
(where sda, sdb, sdc …, whichever the drive shows as)
Internal and external will probably differ somehow, since the external USB enclosure can do tricks.
One can comment out the mount rule for /home from the /etc/fstab. That way system can boot without attempt to mount the /home. Naturally, one cannot login as regular user when homes do not exist.
While you are booted in emergency mode see if you can get more information on the missing mount. Possible commands might be:
dmesg | grep sda3
dmesg | grep rl_mareba-home
There are tools that you then might use to fix the problem in the xfsprogs software like xfs_admin xfs_repair and so forth. But to use these tools the filesystem must be unmounted so you would have to use a rocky install disk w/o chroot mounting root.
“man xfs_repair” is informative.
After a lot more investigation, I think that the problem is somewhere in the lvm configuration. For some reason, the logical volumes are not being set up correctly when the drive is mounted internally.
Rather than spend many hours more figuring the whole thing out, I have decided to reinstall with the drive mounted internally. This time using regular partitions instead of lvm.
Thanks to everyone for their help and guidance.
Tim
Well I recommend ext4. Not for performance reasons but because that file system can be shrunk or expanded. The xfs file system can only be expanded.