y0din
probably the disk UUID has changed because of the path to the NVMe vs SSD. If you use partition UUID, they will be exactly the same, but the UUID of the physical disk is not cloned, as it is a identifier of the physical device and not it’s content.
change it to partition UUID and it will boot.
sorry for the late reply, the command ‘lsblk’ can output it:
“sudo lsblk -o +uuid,name”
check “man lsblk” to see all possible combinations if needed.
there is also ‘blkid’ but I’m unsure whether that package is installed by default on all Linux releases, so that’s why I chose ‘lsblk’
if ‘blkid’ is installed, the syntax would be:
“sudo blkid /dev/sda1 -s UUID -o value”
glad you got it fixe, and hope this answers your question
(edit pga big thumbs and autocorrect… )
also, remember that the old drive now share the UUID with the NVMe drive (which is why I recommended using partition UUID and not disk UUID), so you will have to create a new GPT signature on the old drive to avoid boot issues if both drives are connected at the same time during boot, otherwise you might run into boot issues or booting from the wrong drive.
not to be that guy . but have you tried to search for an answer?
https://github.com/flatpak/flatpak/issues/4435
first hit on “flatpak question marks”… it’s due to the font you use in the terminal does not support or not fully support Unicode characters or your locale settings are not correct.
hope this helps and answers your question :)
(edit, lost part of a sentence)
Might be conflicts due to several routers using the same subnet… could cause some interesting ARP issues for the switches, and also DHCP conflicts if something is wrongly cabled / configured.
I would try disconnecting everything from after the first switch, connect a computer there to see if it works ok, then reconnect and test behind each step to see where it breaks instead of checking in the end where the problem could be agitated from a issue earlier in the network…
also, if the router has a firewall/nat you will not be able to reach anything behind it, even if there are different subnets being used… to be able to reach devices behind a router, the network would need to be routed and not nat’ed as nat combines all network traffic into the IP of the router before sending the traffic away, so clients on the other side has no way of knowing who or where the traffic came from after the nat’ed router.
I suggest you read up about this if you are not familiar with difference between NAT and routed traffic.
anyway, this is just my theory, hope you find your problem and get it sorted :)
(edit added part about nat)
replying to myself here, but also, if this where supposed to work, which I doubt it will because it’s not feasible with tcpip, your second router would need to have the first router as gateway, but that is not possible when they are on the same subnet, and also your router will most likely not allow it because nat/routing will break, but if this was possible, devices behind your second router would not be able to connect to the devices before and vice versa, because since they have the same subnet, the traffic is considered local and not going through the router, and therefore the will not see each other as the NAT provides a separation between the networks…
you cannot use a router as a switch without using routing and different subnets … so … you might want to reconsider your design
Haven’t tried it myself, but there is cheap converters available on AliExpress:
https://a.aliexpress.com/_EwYtdeV
Might be worth it to avoid using it as a paperweight?
sorry if I misunderstood, but wasn’t his drive sas, and he needed to go to sata connections? this does that.
sas hdd => sata controller connetions
the converter is not the culprit, the drive needs a sata logo on the label for it to work the other way, which is mentioned on the sales page.
if the drive had that logo or not is not mentioned as far as I can see
(edit, thought it was OP replying at first, so changed that, and added requirements for the adapter)