Unable to boot using SATA to USB

I took out an internal SATA drive from a laptop and put it on my desktop computer, if I connected it internally then it boots up fine with no issues. However if I connected my drive to SATA to USB to my computer then it fails to boot.

If I connected my regular drive internally and booted from it and connected the other drive to SATA to USB, the OS does recognize it and I am able to read and write to it, so the cable is not faulty.

While I am booted using the laptop’s internal drive, inside /etc/fstab this is what is inside of it:

If I then connect that same drive to the SATA to USB, the bootloader does work:

However after booting it is unable to mount the partitions:

I am not too sure as to why this happens? I can try the fallback option in the bootloader but why does it fail to boot

How do you connect “SATA to USB”? What is the device? What type of disk are we taking about? SSD, NVME, etc.

I suspect that when you connect directly, system recognizes properly UUID of disk and can mount it. But when you connect through your setup, UUID will change, because of device.

So in emergency shell try to get UUID of your devices:

Also here are more tips for your setup:
https://wiki.archlinux.org/title/Install_Arch_Linux_on_a_removable_medium

THat might make sense, cause when I go into the boot menu it doesn’t show the drive, instead it shows the device’s (SATA to USB) cable’s name instead so it might have its own thing on it. I could try and modify the /etc/fstab and instead of using UUID I could use /dev/sda1 etc. I will have to try this out when I get back.

But a better thing I might need to do is get a replacement of this cable that doesn’t do weird things like this.

So I managed to get it work, though had to use fallback boot option in the bootloader option as well. Turns out Windows also had issues as well when booting via this cable.

The UUIDs are unique identifiers for the filesystem and are generated when a partitions is formatted.
No matter where the disk is plugged into, they would remain the same.

That is why using UUIDs is recommended as a more robust way of specifying devices in /etc/fstab than naming them by for example /dev/sda1 ( /dev/sdb2 etc.) as they may be assigned arbitrarily.

:eye: https://wiki.archlinux.org/title/Persistent_block_device_naming

1 Like

That is true, but in my case for some odd reason that cable does something weird but anyways its better to replace the cable and continue to use UUIDs

This would suggest a module that is needed for booting through the disk enclosure is missing from the initramfs. It is likely all that is needed will be to boot with the fallback image, then rebuild the initramfs.

sudo dracut-rebuild

Test again after that to confirm you can boot normally with the updated image.

sorry mate but I don’t understand as to why the cable doesn’t work if I connect directly internally in my PC then it works, what module is missing that causes this issue.

But you didn’t explain your setup yet. What device you are using to connect your disk to USB? And what type of disk you have? Why you assume it is cable? You already replaced it?

I have this SATA to USB cable with me.

I tried it on both SSD and HDD.

As @pebcak claims that the UUID changes. And I belive this is the case as when I go into the boot options it doesn’t show the drive. It instead shows the cable’s name, regardless of what drive I connect it to.

I am about to soon, its nothing urgent or anything it was more of a curiosity as to why I wasn’t able to boot from it when I was testing it out but yeah I actually have something planned to buy.

I said the opposite :blush:

Oh lol xD

But in the error anyways it says it couldn’t mount UUID… so I think going through that interface it must have represent it with a different UUID or something (sorry if I don’t make sense) as the device/cable has its own internal processing so not sure what it does there.

Please read the explanation given by @BluishHumility above.

If your fallback entrie boots up, that is indicative that something is missing in the “regular” kernel image to boot up when the disk is connected externally.

Boot up the system with the fallbak when the disk is connected externally and then rebuild your kernels.

This may actually solve the issue.

1 Like

I think I understand now thanks man.