Live data from Hacker News

Cloning a Laptop over NVMe TCP

copyninja.in

111–120 of 181 posts

Re: Cloning a Laptop over NVMe TCP

#111
post #108

Earlier quoted context omitted.

You just need a single Ethernet cable really, if the devices are reasonably modern. With Auto MDI-X the days of needing a crossover cable or a switch are over.

I'm not sure, first off the precision doesn't have an ethernet port at all! Secondly, I'm not sure if a crossover cable setup will autoconfigure the network, as the poster above says, it has been since the 90s when I bothered trying something like that!

Right, that plan is somewhat foiled by most laptops not having ethernet ports anymore.

You don't need crossover cables anymore. You can just connect a regular patch cable directly between 2 devices. Modern devices can swap RX/TX as needed.

As for auto-configuration, that's up to the OS, but yeah you probably have to set up static IPs.

Re: Cloning a Laptop over NVMe TCP

#112
post #72

Earlier quoted context omitted.

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.

With Windows 10, I have unplugged the primary storage from an old laptop, and plugged it into a new one, without issue. The system booted, no license issues.

Likely because on a laptop there's usually a Windows license embedded in an ACPI table. As long as you weren't moving a Pro edition installation to a machine that only had a key for Home edition, it would silently handle any re-activation necessary.

Re: Cloning a Laptop over NVMe TCP

#113
post #5

In 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…

> That said I didn't know about that Linux kernel module nvme-tcp. We learn new things every day :) I see that its utility is more for mounting a filesystem over a remote NVMe, rather than accessing it raw with dd. Aside, I guess nvme-tcp would result in less writes as you only copy files in stead of writing the whole disk over?

Not if you use it with dd, which will copy the blank space too

Re: Cloning a Laptop over NVMe TCP

#114
post #5

In 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…

> That said I didn't know about that Linux kernel module nvme-tcp. We learn new things every day :) I see that its utility is more for mounting a filesystem over a remote NVMe, rather than accessing it raw with dd. Aside, I guess nvme-tcp would result in less writes as you only copy files in stead of writing the whole disk over?

Not if you use it with dd, which will copy the blank space too

Re: Cloning a Laptop over NVMe TCP

#115
post #5

In 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…

Would be much better to hook this up to dump and restore. It'll only copy used data and you can do it while the source system is online.

For compression the rule is that you don't do it if the CPU can't compress faster than the network.

Re: Cloning a Laptop over NVMe TCP

#116
post #6

So this just bit for bit dumps a NVMe device to another location. That’s clear. So all encryption just is transferred and not touched. But doesn’t the next machine go into panic when you boot? There are probably many changes in the underlying machine? (Okay, now I read the other post. The author really knows the way. This is at least intermediate Linux.)

A Linux install is often remarkably hardware agnostic. Windows would panic, certainly (because so much drivers & other state is persisted & expected), but the Linux kernel when it boots kind of figures out afresh what the world is every time. That's fine. The main thing you ought to do is generate a new systemd/dbus machine-id. But past this, I fairly frequently instantiate new systems by taking a btrfs snapshot of m…

Unless you're doing a BIG jump, like from legacy to UEFI, or SATA to NVMe, Windows will generally just figure it out.

There may be an occasional exception for when you've doing something weird (iirc the 11th-13th gen Intel RST need a slipstreamed or manually added drivers unless you change controller settings in the BIOS which may bite on laptops at the moment if you're unaware of having to do it).

But even for big jumps you can usually get it working with a bit of hackery pokery. Most recently I had to jump from a legacy C2Q system running Windows 10 to run bare metal on a 9th gen Core i3.

I ended up putting it onto a VM to run the upgrade from legacy to UEFI so I'd have something that'd actually boot on this annoyingly picky 9th gen i3 Dell system, but it worked.

I generally (ab)use Macrium Reflect, and have a copy of Parted Magic to hand, but it's extremely rare for me to find a machine I can't clone to dissimilar hardware.

The only one that stumped me recently was an XP machine running specific legacy software from a guy who died two decades ago. That I had to P2V. Worked though!

Re: Cloning a Laptop over NVMe TCP

#117
post #9

I usually set up an initial distro and then copy over my /home. Later, I just need to install the debs I'm missing, but this has the benefit of not installing stuff I don't need anymore. That said, I didn't know you could export NVMe over TCP like that, so still a nice read!

~/oldhome/oldhome/oldhome ...

Re: Cloning a Laptop over NVMe TCP

#118
post #95
post #23

I 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?

> 200gb of files over wifi […] took at least 6 hours > I wonder what could I have done better. Used an Ethernet cable? That’s not an impressive throughput amount over local. WiFi has like a million more sources of perf bottlenecks. Btw, just using a cable on ONE of the device => router ~> device can help a lot.

Yeah, I did that. One of the devices didn't have an ethernet port though.

Re: Cloning a Laptop over NVMe TCP

#119
post #6

So this just bit for bit dumps a NVMe device to another location. That’s clear. So all encryption just is transferred and not touched. But doesn’t the next machine go into panic when you boot? There are probably many changes in the underlying machine? (Okay, now I read the other post. The author really knows the way. This is at least intermediate Linux.)

A Linux install is often remarkably hardware agnostic. Windows would panic, certainly (because so much drivers & other state is persisted & expected), but the Linux kernel when it boots kind of figures out afresh what the world is every time. That's fine. The main thing you ought to do is generate a new systemd/dbus machine-id. But past this, I fairly frequently instantiate new systems by taking a btrfs snapshot of m…

To me the most complicated thing would be to migrate an encrypted disk with the key stored in TPM. The article doesn't try to do that, but I wonder if there is a way.

Re: Cloning a Laptop over NVMe TCP

#120
post #108

Earlier quoted context omitted.

I'm not sure, first off the precision doesn't have an ethernet port at all! Secondly, I'm not sure if a crossover cable setup will autoconfigure the network, as the poster above says, it has been since the 90s when I bothered trying something like that!

Right, that plan is somewhat foiled by most laptops not having ethernet ports anymore. You don't need crossover cables anymore. You can just connect a regular patch cable directly between 2 devices. Modern devices can swap RX/TX as needed. As for auto-configuration, that's up to the OS, but yeah you probably have to set up static IPs.

They would receive APIPA (169.254.0.0/16) address for IPv4 and link-local for IPv6, if the interface would be brought up. Now, that second part is a question; windows would do it, but linux probably not.
Post reply on HN