dd cloning a Win10 HDD to SSD

[Tom Buskey]

FWIW, I've created VMs (VirtualBox or libvirt) of WinXP & Win7 to support
old software that doesn't work in newer versions.  I turned off all updates
on them.  If I need to add software to them, I make a copy first.

I'd save a copy of that image somewhere and try to make a VM out of it.  Of
course, it wouldn't have helped in your case.

On Tue, Mar 23, 2021 at 1:48 PM Bruce Labitt <bdlabitt at gmail.com> wrote:

> Worked on the first boot.  Booted in maybe 10 seconds!  Ran
> CrystalDiskMark on the before and after.  It's the random 4k stuff that
> really makes a difference.
> The Samsung EVO860 SSD is a minimum of 77x faster on random write and 100x
> faster on random read as compared to the WD HDD.  (RND4K, Q1T1).  It's like
> a totally different machine.  Hope windows won't complain later.
>
> So... for the record, dd did work to clone a Win10 disk to a SSD.  It
> copied over all 5 partitions, including the MS secret partition and EFI,
> plus whatever nonsense partitions that Dell put on this disk.  Will check
> to see if all this survives a reboot...  Yes!
> Well, hot diggity dog!  At least for this disk pair, dd worked great!  No
> BS, no FUD, it just worked. :)
>
> On Tue, Mar 23, 2021 at 1:00 PM Bruce Labitt <bdlabitt at gmail.com> wrote:
>
>> I was 20 minutes into dd when I noticed that the disks were mounted.
>> Aborted dd.  Unmounted both disks and restarted dd.  I'm at the tail end of
>> the run, and hoping it completed without errors.  If it barfs I may try
>> ddrescue, the gnu version.
>>
>> The old disk has really bad random access rates.  It's like less than 0.5
>> MB/sec for random 4k access.  On Win10 it's incredibly slow.
>>
>> FYI, the only reason I even turned on this sorry excuse of a laptop was
>> the NH VINI website would not render the Covid-19 vaccine registration site
>> correctly in Chromium, Chrome or Firefox in Linux yesterday.  It was
>> impossible to fill out the form.  After 3 hours of really slow windows
>> updating, I could install the latest version of Chrome on Windows 10.  Then
>> and only then could I register.  It took 6 hours to update the laptop to be
>> current.  So despite the fact that I don't use Win10 regularly, it was
>> useful yesterday.  The laptop experience was so painful that I decided to
>> replace the HDD with a spare SSD.
>>
>> The State of NH made the registration forms only work with the latest
>> version of Edge, Chrome and Firefox.  Unfortunately, yesterday, in Linux,
>> the versions were slightly older.  For Firefox the Windows version was
>> 86.0.1, and in Linux it was 86.0.  Today I noticed that 86.0.1 is available
>> for Linux.
>>
>> Any ways, that's why I'm attempting this.  If for some odd reason I have
>> to use the Win10 laptop again maybe it won't be so painful.  20 minute boot
>> times are just awful.  An SSD should bring it to 20 seconds at least
>> according to a disk benchmark tool I ran.
>>
>> Personally, I hope my real laptop gets repaired.  It croaked after a
>> couple of months.  Brand new.  In the interim, I am dd'ing with a RPI4, as
>> that's all I have.  The RPI boots direct from SSD and is overclocked to
>> 2Ghz, so it's tolerable, but not speedy.
>>
>> On Tue, Mar 23, 2021, 12:19 PM Joshua Judson Rosen <
>> rozzin at hackerposse.com> wrote:
>>
>>> On 3/23/21 9:07 AM, Bruce Labitt wrote:
>>> > On Tue, Mar 23, 2021 at 8:52 AM Dan Jenkins <dan at rastech.com <mailto:
>>> dan at rastech.com>> wrote:
>>> >
>>> >     In my experience dd works. Make sure the destination disk is
>>> larger than
>>> >     the source. I've had problems sometimes when they were the exact
>>> same
>>> >     size. Any other issue was due to issues on the source disk, in
>>> which
>>> >     case ddrescue, has worked.
>>>  >
>>> > In my case the disks report to be the same size in lsblk.
>>> > fdisk -l reports the hdd is 1000204886016 bytes, and the sdd
>>> is 1000204886016 bytes or exactly the same size.
>>> > Guess I will try dd.  Fingers crossed...
>>> If the destination disk does end up not being big enough,
>>> you can probably shrink the data on the source disk a little
>>> (and then fix up the GPT on the destination disk, if you're using GPT--
>>>   because GPT wants to keep a `backup table' at the _physical tail end_
>>>   of the disk and some implementations of GPT will refuse to read
>>>   the partition table if the disk doesn't pass that sniff-test).
>>>
>>> Just be sure that you don't have the source filesystem mounted writeably
>>> when
>>> you're trying to copy it like that...: it's pretty important
>>> that nothing be actively using a filesystem and causing the data/metadata
>>> stored within it to change as you try to dd a copy of its underlying
>>> storage.
>>>
>>> And, since I don't think anyone mentioned this: be sure to us a big
>>> enough blocksize
>>> with dd, because the default 512-byte bs will be incredibly slow
>>> (and I guess *could* in theory cause a lot of extra wear on the SSD
>>>   due to write-amplification, though I guess the Linux block layer
>>>   should protect against that?).
>>>
>>> For the rest of my response, I'm going to mostly ignore the "Windows 10"
>>> part of the question and provide guidance to people looking through the
>>> list archive
>>> for guidance doing the same sort of data-migration but for Linux disks
>>> (though I suspect that the underlying rationales port to other operating
>>> systems)...:
>>>
>>> There are theoretically reasons to make a fresh filesystem / LVM PV /
>>> RAID / whatever
>>> structure, with its configuration tuned to the native block-size of the
>>> underlying
>>> flash controller..., but in practice it never seems to matter enough to
>>> make it worthwhile
>>> to even bother figuring out what any of those numbers are.
>>>
>>> There are however real + very practical reasons to initialize storage on
>>> different physical disks
>>> with different *IDs* if you want to be able to use them together at the
>>> same time, e.g.:
>>> different ext filesystem UUIDs, or different PV IDs if you want to be
>>> able
>>> to use them both with LVM. You can also change those IDs after the fact.
>>>
>>> If I understand your use case, you really just have a partition table
>>> with
>>> one two filesystems + maybe swap space, and you're going to discard the
>>> data on
>>> the old disk (and maybe even discard the old disk) once the transfer is
>>> done.
>>> Taking both disks out of use and just dd-ing from one to the other
>>> should be
>>> fine for that--though, when doing such a migration for Linux systems,
>>> you might want
>>> to consider setting the new disk up with LVM (and then dd'ing from the
>>> _partitions_
>>> on the source disk into the _Logical Volumes_ on the destination disk),
>>> so that things like this are easier next time.
>>>
>>> (one of the many nice things about LVM, even if you're only going to
>>> have one disk `right now',
>>>   is that it makes disk-migrations like this *really easy*: you just
>>> plug the new
>>>   disk in, ensure that it has been initialized as a PV, run "pvmove",
>>> and then pull
>>>   the old disk out when it's done--and you can keep using the filesystem
>>> while
>>>   the migration is in progress--and LVM makes it pretty straightforward
>>> to even
>>>   do things like convert a single disk into a RAID setup at some future
>>> point,
>>>   like when you're about to throw the old disk out and decide that it'd
>>> be more useful
>>>   as a hot spare than as landfill).
>>>
>>> --
>>> Connect with me on the GNU social network: <
>>> https://status.hackerposse.com/rozzin>
>>> Not on the network? Ask me for an invitation to a social hub!
>>> _______________________________________________
>>> gnhlug-discuss mailing list
>>> gnhlug-discuss at mail.gnhlug.org
>>> http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
>>>
>> _______________________________________________
> gnhlug-discuss mailing list
> gnhlug-discuss at mail.gnhlug.org
> http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.gnhlug.org/pipermail/gnhlug-discuss/attachments/20210323/6877766d/attachment.html