Hi!
Had a Leap 15.3 on SATA SSD, which I upgraded some days ago to 15.4 with a SATA to eSATA adapter. Now the SSD won’t boot in a SATA to USB3 adapter, I see Grub, it starts booting but hangs for ever at
Reached Target Path Units
Any ideas? 
PS: With the SATA to eSATA adapter the SSD boots just fine…
Boot with plymouth.enable=0 and without “quiet” on kernel command line and say what you see or post photo.
https://paste.opensuse.org/3fa365f2
…not very helpful, I guess… 
OOOOOppppsss:
I let it sit while posting here, and in the meantime it reached a rescue console and in journalctl I get:
https://paste.opensuse.org/8a7a29b5
more helpful?
Educated guess is that initrd does not have usb-storage and/or uas kernel modules. Try
echo 'force_drivers+=" usb-storage uas "' > /etc/dracut.conf.d/usb.conf
mkinitrd
Many thanks! Did you see my edit/second half of my reply above?
Proposal still valid? 
I tried your proposal, now we are one step further, on boot I see
Reached target Remote Fiel system
but then there is
a start job is running for /dev/disk/by-id/ata-Kingston…
and this has no timeout.
Hi
Likely the swap partition UUID changed…
How that? The install boots just fine with the SATA to eSATA adapter…
How to test this hypothesis?
Hi
Boot via the eSATA and check UUID’s with blkid command and cat the output of /etc/fstab, boot alternative way and check, maybe press e at grub and see if the resume= line is present and compare. I would suggest just using /dev/sdX on portable devices rather than UUID.
…removed the “resume=” in Grub and it boots! Will make this permanent in YaST and it should work?!?
Many thanks so far!
Hi
Yes, else use /dev/sdNX for swap.
Better to change to noresume than to remove. The resume= in Grub is an override to a resume= the initrd may contain.
Thanks! But after some hours the Kingston SSD (SMART looked good, not much hours online) went read-only all of a sudden, no idea why. Sigh…
It is not cleat what exactly “went read-only” means, but if filesystem was marked read-only due to some problems detected by driver, you should have at least kernel messages in dmesg (unless you already rebooted).
…I end in the emergency console on every boot, here is the rdsosreport.txt
https://paste.opensuse.org/f2fd438e
Any ideas?
The file system on /dev/sda2 is lousy. That is what I read very clear from that list. And the advice there is: /dev/sda2: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
… I ran fsck on /dev/sda2 without errors, now I did that again and it repaired some stuff
sudo fsck /dev/sdb2
fsck from util-linux 2.37.4
e2fsck 1.46.5 (30-Dec-2021)
/dev/sdb2 contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Inodes that were part of a corrupted orphan linked list found. Fix<y>? yes
Inode 535016 was part of the orphaned inode list. FIXED.
Deleted inode 657239 has zero dtime. Fix<y>? yes
Inode 657245 was part of the orphaned inode list. FIXED.
Inode 657249 was part of the orphaned inode list. FIXED.
Inode 657254 was part of the orphaned inode list. FIXED.
Inode 657255 was part of the orphaned inode list. FIXED.
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Block bitmap differences: -(230912--231386) -(231424--231472) -(235520--236031) -(237056--237209) -(239104--239615)
Fix<y>? yes
Free blocks count wrong for group #7 (10559, counted=12261).
Fix<y>? yes
Free blocks count wrong (2937067, counted=2938769).
Fix<y>? yes
Inode bitmap differences: -657239 -657245 -657249 -(657254--657255)
Fix<y>? yes
Free inodes count wrong for group #80 (2040, counted=2045).
Fix<y>? yes
Free inodes count wrong (983275, counted=983280).
Fix<y>? yes
/dev/sdb2: ***** FILE SYSTEM WAS MODIFIED *****
/dev/sdb2: 240720/1224000 files (0.3% non-contiguous), 1949295/4888064 blocks
…now it boots normal again. But no idea what messed up the file system in first hand! 
This story is a bot confusing. It seems you left out some steps (assuming we are mind-readers?).
Apparently you booted something else and then for got to check what /dev/sda is on that new boot with anonther system. Then you apparently found out and did check the file system on what was then /dev/sdb.
So either you explain completely what you did, or you leave out the mishap. In both cases the story would have been easier to understand.
About the cause. I do not know, but as I understand you work with adapters and thus there are several connectors which you may have pulled on the wrong moment.
In any case, nice it works again.
Proof of grub is the boot. If it doesn’t boot it’s broken. Current initrds are hostonly. Copy and edit the file:
[FONT=monospace]**6700K:~ #** diff /usr/lib/dracut/dracut.conf.d/01-dist.conf /etc/dracut.conf.d/01-dist.conf
7,8c7,8
< hostonly="yes"
< hostonly_cmdline="yes"
---
> hostonly="no"
> hostonly_cmdline="no"
**6700K:~ #**
[/FONT]Run “dracut --force --regenerate-all”. Repair grub: Grub – EFI – Btrfs | Karl Mistelberger