[flagged]
Cloning a Laptop over NVMe TCP
71–80 of 181 posts
Re: Cloning a Laptop over NVMe TCP
#72Earlier quoted context omitted.
I expected Windows to panic as well but Win 10 handles it relatively gracefully. It says Windows detected a change to your hardware and does a relatively decent job.
Yeah, I've done several such transplants of disks onto different hardware.. maybe even from an AMD to an Intel system once (different mainboard chipsets), and of Windows 7. As you say, it will say new hardware detected and a lot of the times will get the drivers for them from Windows Update. There are also 3rd party tools to remove no-longer existing devices from the registry, to clean the system up a bit.
Windows will, however, no longer acknowledge your license key. At least that is what happened when I swapped a Windows installation from an Intel system into an AMD system.
Re: Cloning a Laptop over NVMe TCP
#73In the author's scenario, there are zero benefits in using NVMe/TCP, as he just ends up doing a serial block copy using dd(1) so he's not leveraging concurrent I/O. All the complex commands can be replaced by a simple netcat. On the destination laptop: $ nc -l -p 1234 | dd of=/dev/nvme0nX bs=1M On the source laptop: $ nc x.x.x.x 1234 The dd on the destination is just to buffer writes so they are faster/more efficient…
[flagged]
> Hdjrnrhf Fhjrnrjg Cnn3nrmf Нос3uejr Нирш Юни до края шллш
Is this some new form of Russian Ops here on HN?
Re: Cloning a Laptop over NVMe TCP
#74I haven't actually "installed" an OS on my desktops/laptops in decades, always just copy over the files and adjust as needed. Usually just create a new filesystem though to use the opportunity to update the file system type / parameters (e.g. block size), encryption etc. and then rsync the files over.
Still, if I was the planning ahead kind then using something more declarative like NixOS where you only need to copy your config and then automatically reinstall everything would probably be the better approach.
Re: Cloning a Laptop over NVMe TCP
#75I recently had to copy around 200gb of files over wifi. I used rsync to make sure a connection failure doesn't mean I have to start over and so that nothing is lost, but it took at least 6 hours. I wonder what could I have done better. Btw, what kinds of guarantees do you get with the dd method? Do you have to compare md5s of the resulting block level devices after?
> I wonder what could I have done better.
6 hours is roughly 10MB/s, so you likely could have gone much much quicker. Did you compress with `-z`? If you could use ethernetyou probably could have done it at closer to 100MB/s on most deviceds, which would have been 35 minutes.
Re: Cloning a Laptop over NVMe TCP
#76Or just use Clonezilla? Then you also copy only the actual data blocks, and it can autoresize your partitions as well. That's how I always do it.
True, I do always just take the NVME disk out of the laptop and put it in a highspeed dock.
Re: Cloning a Laptop over NVMe TCP
#77Couldn’t they have just used netcat ?
Re: Cloning a Laptop over NVMe TCP
#78Earlier quoted context omitted.
Those are pseudo-filesystems though, they aren't part of the install.
Not sure where I said they were part of the install, but I meant that if you don’t exclude them bad things would happen to the cloning process Edit: or backup process
With a block device copy approach like in TFA you don't need to worry about that because those filesystems do not exist on the block device.
When copying files (e.g. with rsync) you need to watch out for those, yes. The best way to deal with other mounts is not to copy directly from / but instead non-recursively bind-mount / to another directory and then copy from that.
Re: Cloning a Laptop over NVMe TCP
#79In the author's scenario, there are zero benefits in using NVMe/TCP, as he just ends up doing a serial block copy using dd(1) so he's not leveraging concurrent I/O. All the complex commands can be replaced by a simple netcat. On the destination laptop: $ nc -l -p 1234 | dd of=/dev/nvme0nX bs=1M On the source laptop: $ nc x.x.x.x 1234 The dd on the destination is just to buffer writes so they are faster/more efficient…
Seems awesome. Can you please tell us how to use gzip or lz4 to do the imaging?
If you search for “dd gzip” or “dd lz4” you can find several ways to do this. In general, interpose a gzip compression command between the sending dd and netcat, and a corresponding decompression command between the receiving netcat and dd.
For example: https://unix.stackexchange.com/questions/632267
Re: Cloning a Laptop over NVMe TCP
#80Earlier quoted context omitted.
Did it ‘just work’? Serious question since last time I tried a direct non-Ethernet connection was sometime in the 90s ;)
I assume that those USB-C connectors were USB 4 or Thunderbolt, not USB 3. With Thunderbolt and operating systems that support Ethernet over Thunderbolt, a virtual network adapter is automatically configured for any Thunderbolt connector, so connecting a USB C cable between 2 such computers should just work, as if they had Ethernet 10 Gb/s connectors. With USB 3 USB C connectors, you must use USB network adapters (up…
USB C is perfectly capable of connecting two equals, even with USB-2.
It merely requires one side to be capable of behaving as a device, with the other side behaving as a host.
I.e., unlike PCIe hubs, you won't get P2P bandwidth savings on a USB hub.
It just so happens that most desktop xhci controllers don't support talking "device".
But where you can, you can set up a dumb bidirectional stream fairly easily, over which you can run SLIP or PPP. It's essentially just a COM port/nullmodem cable. Just as a USB endpoint instead of as a dedicated hardware wire.