Re: Trying to figure out if I have a bad NVME device

[Bruce Labitt]

It would seem there was an issue with the socket on the nvme enclosure -
actually the WD NVME connector is slightly differently dimensioned than the
Samsung.  I swapped housings and I got the WD NVME to be recognized.  Now
it can be partitioned.
I'm in the midst of partitioning with gparted and selected gpt over MBR.
Now to create a new partition.  I'd like to use the whole 1TB as a
partition.  It's defaulting to free space preceding = 1MiB, free space
following = 0MiB.

What does one use as a Partition name?  What is a standard convention?
What about label?  I am selecting EXT4 as the file system.  Any advice?
Thanks.

On Sun, Mar 21, 2021 at 11:05 AM Bruce Labitt  wrote:

> I have a USB3.2-PCIE NVME adapter (actually have 3 of them) using the
> JM583 chip.  I also have a Samsung 970 EVO Pro 1TB NVME and recently bought
> 2 WD 1TB NVME cards.
>
> I cannot get a WD NVME to be recognized by the OS.  I haven't tried the
> second WD NVME as I am leaving the package unopened.
>
> lsusb reveals the JMicron adapter so I have the ID
> fdisk -l and lsblk do not show the WD device, nor the JM adapter
> The WD disk has never been partitioned or formatted.
>
> sudo dmesg | tail -n 50 shows some sort of issue.
> [ 4015.843758] usb 2-2.1.2: USB disconnect, device number 10
> [ 7180.940213] usb 2-2.1.4: USB disconnect, device number 5
> [ 7186.023443] usb 2-2.1.2: new SuperSpeed Gen 1 USB device number 11
> using xhci_hcd
> [ 7186.054656] usb 2-2.1.2: New USB device found, idVendor=152d,
> idProduct=0583, bcdDevice= 2.09
> [ 7186.054671] usb 2-2.1.2: New USB device strings: Mfr=1, Product=2,
> SerialNumber=3
> [ 7186.054684] usb 2-2.1.2: Product: USB to PCIE Bridge
> [ 7186.054695] usb 2-2.1.2: Manufacturer: JMicron
> [ 7186.054706] usb 2-2.1.2: SerialNumber: 0123456789ABCDEF
> [ 7186.069481] scsi host1: uas
> [ 7186.070909] scsi 1:0:0:0: Direct-Access JMicron  Generic
>  0209 PQ: 0 ANSI: 6
> [ 7186.072283] sd 1:0:0:0: Attached scsi generic sg1 type 0
> [ 7194.231709] sd 1:0:0:0: [sdb] Unit Not Ready
> [ 7194.231728] sd 1:0:0:0: [sdb] Sense Key : 0x4 [current]
> [ 7194.231744] sd 1:0:0:0: [sdb] ASC=0x44 <>ASCQ=0x81
> [ 7194.233639] sd 1:0:0:0: [sdb] Read Capacity(16) failed: Result:
> hostbyte=0x00 driverbyte=0x08
> [ 7194.233657] sd 1:0:0:0: [sdb] Sense Key : 0x4 [current]
> [ 7194.233673] sd 1:0:0:0: [sdb] ASC=0x44 <>ASCQ=0x81
> [ 7194.235281] sd 1:0:0:0: [sdb] Read Capacity(10) failed: Result:
> hostbyte=0x00 driverbyte=0x08
> [ 7194.235297] sd 1:0:0:0: [sdb] Sense Key : 0x4 [current]
> [ 7194.235313] sd 1:0:0:0: [sdb] ASC=0x44 <>ASCQ=0x81
> [ 7194.236113] sd 1:0:0:0: [sdb] 0 512-byte logical blocks: (0 B/0 B)
> [ 7194.236129] sd 1:0:0:0: [sdb] 0-byte physical blocks
> [ 7194.237556] sd 1:0:0:0: [sdb] Test WP failed, assume Write Enabled
> [ 7194.238118] sd 1:0:0:0: [sdb] Asking for cache data failed
> [ 7194.238133] sd 1:0:0:0: [sdb] Assuming drive cache: write through
> [ 7194.239724] sd 1:0:0:0: [sdb] Optimal transfer size 33553920 bytes not
> a multiple of physical block size (0 bytes)
> [ 7194.284844] sd 1:0:0:0: [sdb] Unit Not Ready
> [ 7194.284866] sd 1:0:0:0: [sdb] Sense Key : 0x4 [current]
> [ 7194.284881] sd 1:0:0:0: [sdb] ASC=0x44 <>ASCQ=0x81
> [ 7194.286398] sd 1:0:0:0: [sdb] Read Capacity(16) failed: Result:
> hostbyte=0x00 driverbyte=0x08
> [ 7194.286415] sd 1:0:0:0: [sdb] Sense Key : 0x4 [current]
> [ 7194.286430] sd 1:0:0:0: [sdb] ASC=0x44 <>ASCQ=0x81
> [ 7194.288145] sd 1:0:0:0: [sdb] Read Capacity(10) failed: Result:
> hostbyte=0x00 driverbyte=0x08
> [ 7194.288166] sd 1:0:0:0: [sdb] Sense Key : 0x4 [current]
> [ 7194.288183] sd 1:0:0:0: [sdb] ASC=0x44 <>ASCQ=0x81
> [ 7194.293600] sd 1:0:0:0: [sdb] Attached SCSI disk
>
> However, the same adapter works fine using the 970 Pro NVME device.  On
> the 970 I have the complete backup to my laptop.  The 970 auto mounts.
> Is it possible that UAS doesn't work for the WD NVME?  Or is the WD NVME
> defective?  Or the WD NVME hasn't been prepared properly?   My google-fu
> seems to be weak - it's been difficult to find appropriate information.
> Hope it's just that I missed a step...
> I have heard of blacklisting the UAS driver, but it seems odd the adapter
> works reliably for the 970 but not the WD.
>
> I'd greatly appreciate a hint.  Currently running on an RPI4B-4GB
> Raspberry Pi OS 32bit since my new laptop bit the dust.  The laptop has
> been sent back for repair.
> Thanks for your patience...
>
>
>
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

Re: dd cloning a Win 10 HDD to SSD

[rixter]

I wrote this back when the world was much younger. I hope I haven't
stepped on anyones' toes by posting such a fat file, all 6k.  Since
it's so old the benchmarks should be way off but I doubt the command
line info has changed much if at all. I hope it inspires some ideas, I
used to use those commands when building FAX/paging servers for call
centers.  ...Back to lurking...


RCM Aug 10 '06

CLONING DRIVES WITH LINUX   
==

To ghost to a drive (clone, if you will) of the same size or larger:

 EIDE: sudo dd if=/dev/hda of=/dev/hdb
 SATA: sudo dd if=/dev/sda of=/dev/sdb

A Debian 3.1 system was able to clone its 80 gig SATA drive to another
SATA drive in 98 minutes
of realtime, reporting 20 minutes of system time used for the process,
while simultaneously functioning
as a fax/paging engine and supporting SSH logins and file transfers.


Ghost a partition to another partition:

 sudo dd if=/dev/hda1 of=/dev/hdb1

Create an image on a drive that you have locally mounted as /mnt/images:

 sudo dd if=/dev/hda of=/mnt/images/backup050824.img


The following example uses sdd instead of dd and adds a call to pv for
a progress display.
If you need to use it on a knoppix system use dd and remove the '-'
from the '-bs=1024k' statement.
A Debian system stored its 80g drive to a 13g compressed image file in
93 minutes with this command line.

Create a gzipped image file of an 80g SATA drive on a locally mounted
IDE drive, with progress display:

sdd if=/dev/sda -t -bs=1024k|pv -s 80g -r -b|gzip -c
-9>/mnt/hdc1/pinnfax-1.05-060208.imz


Create an image across an SSH pipe:

 sudo dd if=/dev/hda | ssh somevaliduser@10.0.0.69
"cat>/mnt/hugedrive/bigbackup.img"

Create a compressed image across an SSH pipe:

(-c says send to stdout; -9 says use max compression)

 sudo dd if=/dev/hda | ssh someuser@10.0.0.69 "gzip -c
-9>/mnt/fatdrive/bbbackup.gz"

Duplicate a drive across an SSH pipe:

Note: In doing this with the target machine booting knoppix 3.91 from
CD-ROM, I had to use root as the user.

 sudo dd if=/dev/hda | somevaliduser@10.0.0.69 "cat>/dev/hda"

A more specific example, adding pv to show a progress meter, required
3 hrs 15 minutes for an 80 gig drive.

 dd if=/dev/sda |pv -s 80g -r -b|ssh root@10.0.0.51 "cat>/dev/sda"

Dupe to a compressed image across SSH with the 'pv' progress meter running.

 dd if=/dev/hda |pv -s 15g -r -b|ssh faxuser@10.0.0.245 "gzip -c
-9>/somedir/debian-051017img.isz"

The prior command line stored an 80 Gb drive with approx 5 gigs of
data to a 4 Gb file.  Drives with more data would of course yield less
extreme ratios.


Duplicate a drive while compressing on the fly to limit LAN bandwidth needed:

Note in this case the '/dev/sda' denotes a serial ATA drive.  The source was
a Debian system, the target an unformatted system botting Knoppix on which
a root passwd had been previously set up by invoking su to root and then
passwd to set a password.  We compress before sending out with gzip, and then
uncompress before writing with zcat. Note also that if you're in a hurry, this
is not the method for you.

 sudo dd if=/dev/sda|gzip -c -9|ssh root@10.0.0.41 "zcat|dd of=/dev/sda"

Duplicate a drive, piping through the PV progress meter, compressing
on the fly, across an SSH pipe using the Blowfish algorithm to
increase throughput.

dd if=/dev/hde bs=512k|pv -s 160g -r -b|gzip -c -9|ssh -c blowfish
faxuser@10.0.0.41 "cat>/mnt/hdc1/debcti-v1.00-060213.imz"

This prior command line was able to store an image of a 160 gig drive
across the network in 66 minutes on a fast 2.8 GHz Intel Xeon board to
a 13 gig file, with both source and target machines running Debian..

Restore a compressed image across SSH:

Boot Knoppix on target, start service SSH.  On Target machine, su to root
and invoke passwd.  Set password to knoppix.  Drive must be same size or
larger as source.

 dd if=debian-051017img.isz|ssh root@10.0.0.57 "zcat|dd of=/dev/hda"

Note that zcat (or gunzip if you'd rather) is run on the target before
piping to DD instead of at the source drive.  This limits the network
traffic needed to transport the image.  The combination of compressed
images and end-point decompression is the fastest and most efficient
way I've found to serve a ghost image to a target drive without resorting
to special software.  A 13g compressed image restores to an 80g drive in
about 90 minutes or less.

In some cases this method appears to be a faster way to restore when
network bandwidth is not an issue.  The source image is expanded on
the image server and then sent across the network requiring vastly
more bandwidth.

zcat ./cti-mb.intel.se7520jr2-v0.30-060331.imz|pv -s 2g|ssh
root@10.0.0.68 "dd bs=8192k of=/dev/sda"


Here are some command lines to expand later, to describe writing to a
secondary drive on a system for which
we cannot set up incoming root log ins through SSH.

11:34:11 root@pinnfax:~# scp
rixter@10.0.0.64:/mnt/hdc1/pfx-deb-etch-aidan-v2.50-090304.bz2
./pfxpipe

Re: 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  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  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 <
>> roz...@hackerposse.com> wrote:
>>
>>> On 3/23/21 9:07 AM, Bruce Labitt wrote:
>>> > On Tue, Mar 23, 2021 at 8:52 AM Dan Jenkins >> d...@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 

Re: dd cloning a Win10 HDD to SSD

[Bruce Labitt]

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  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 
> wrote:
>
>> On 3/23/21 9:07 AM, Bruce Labitt wrote:
>> > On Tue, Mar 23, 2021 at 8:52 AM Dan Jenkins > d...@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 

Re: dd cloning a Win10 HDD to SSD

[Bruce Labitt]

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 
wrote:

> On 3/23/21 9:07 AM, Bruce Labitt wrote:
> > On Tue, Mar 23, 2021 at 8:52 AM Dan Jenkins  d...@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 

Re: dd cloning a Win10 HDD to SSD

[Joshua Judson Rosen]

On 3/23/21 9:07 AM, Bruce Labitt wrote:
> On Tue, Mar 23, 2021 at 8:52 AM Dan Jenkins  > 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: 

Not on the network? Ask me for an invitation to a social hub!
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

Re: dd cloning a Win10 HDD to SSD

[Bruce Labitt]

Thanks for the update.  The HDD is a WD.  If dd fails, I may try the
Acronis.

On Tue, Mar 23, 2021, 11:33 AM Greg Kettmann  wrote:

> I used Acronis True Image. It's free but only works if one of the drives
> is Western Digital.  It worked great for my brother as well.
>
> I believe I've also used EaseUS, further in the past. Even  further back I
> think I used Partition Magic (to clone a boot drive) but I don't think
> that's free anymore.
>
> I've cloned boot drives (mostly Windows, I usually rebuild Linux machines)
> quite a few times and have had excellent luck with the utilities.  They're
> flexible with (larger) drive or partition sizes. I've not had multiple
> other partitions to contend with but copying them shouldn't be difficult.
> It's the MBR that is the challenge and having all the boot pointers
> pointing to the right locations.
>
> Good luck.  It's well worth it.  On an old machine the boot time was
> reduced by a factor of ten. Your mileage may vary but I've done this at
> least 6 times and never been disappointed.  Now I always make my boot drive
> is an SSD.
>
> Greg
>
> Get TypeApp for Android 
> On Mar 23, 2021, at 7:33 AM, Bruce Labitt  wrote:
>>
>> I'd be grateful to learn what worked.  No need to waste my time more than
>> necessary.
>>
>> On Tue, Mar 23, 2021, 8:30 AM Greg Kettmann < g...@kettmann.com> wrote:
>>
>>> I don't know if dd works. I've done this several times using freely
>>> available utilities.  In one case I tried and it failed.  I simply used a
>>> different utility and it worked.  I was impressed with the results,
>>> particularly with dramatically improved boot times.
>>>
>>> Sorry to be vague. You were asking about dd.  If you're interested in
>>> which utility(s) I used just let me know.  I should have records.  The last
>>> time was a year ago.
>>>
>>> Greg
>>>
>>> Get TypeApp for Android 
>>> On Mar 22, 2021, at 10:19 PM, Bruce Labitt < bdlab...@gmail.com> wrote:

 Have this excruciatingly slow Win10 HDD I'd like to clone to SSD.
 Reading about how to do this leads me to dd as a way to clone the disk.
 The disks are close in size.  According to lsblk, the HDD sdb is 931.5GB,
 and the SSD sdf is 931.5GB.

 sdb has 5 partitions on it.
 1) EFI  500MiB
 2) MS reserved partition  128MiB
 3) OS "basic data" partition 918.07GiB
 4) WINRETOOLS 852MiB
 5) Image   11.56GiB

 sdf has stuff on it, which I presume will be wiped out by dd.

 Since the sizes are "equal", can I just # dd if=/dev/sdb of=/dev/sdf
 bs=1M status=progress and be done with it?  Is there anything else that I'd
 need to do to get it to boot?

   --

 gnhlug-discuss mailing list
 gnhlug-discuss@mail.gnhlug.org
 http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/


___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

Re: dd cloning a Win10 HDD to SSD

[Greg Kettmann]

I used Acronis True Image. It's free but only works if one of the drives is 
Western Digital.  It worked great for my brother as well.

I believe I've also used EaseUS, further in the past. Even  further back I 
think I used Partition Magic (to clone a boot drive) but I don't think that's 
free anymore.

I've cloned boot drives (mostly Windows, I usually rebuild Linux machines) 
quite a few times and have had excellent luck with the utilities.  They're 
flexible with (larger) drive or partition sizes. I've not had multiple other 
partitions to contend with but copying them shouldn't be difficult.  It's the 
MBR that is the challenge and having all the boot pointers pointing to the 
right locations.

Good luck.  It's well worth it.  On an old machine the boot time was reduced by 
a factor of ten. Your mileage may vary but I've done this at least 6 times and 
never been disappointed.  Now I always make my boot drive is an SSD.

Greg

⁣Get TypeApp for Android ​

On Mar 23, 2021, 7:33 AM, at 7:33 AM, Bruce Labitt  wrote:
>I'd be grateful to learn what worked.  No need to waste my time more
>than
>necessary.
>
>On Tue, Mar 23, 2021, 8:30 AM Greg Kettmann  wrote:
>
>> I don't know if dd works. I've done this several times using freely
>> available utilities.  In one case I tried and it failed.  I simply
>used a
>> different utility and it worked.  I was impressed with the results,
>> particularly with dramatically improved boot times.
>>
>> Sorry to be vague. You were asking about dd.  If you're interested in
>> which utility(s) I used just let me know.  I should have records.
>The last
>> time was a year ago.
>>
>> Greg
>>
>> Get TypeApp for Android 
>> On Mar 22, 2021, at 10:19 PM, Bruce Labitt 
>wrote:
>>>
>>> Have this excruciatingly slow Win10 HDD I'd like to clone to SSD.
>>> Reading about how to do this leads me to dd as a way to clone the
>disk.
>>> The disks are close in size.  According to lsblk, the HDD sdb is
>931.5GB,
>>> and the SSD sdf is 931.5GB.
>>>
>>> sdb has 5 partitions on it.
>>> 1) EFI  500MiB
>>> 2) MS reserved partition  128MiB
>>> 3) OS "basic data" partition 918.07GiB
>>> 4) WINRETOOLS 852MiB
>>> 5) Image   11.56GiB
>>>
>>> sdf has stuff on it, which I presume will be wiped out by dd.
>>>
>>> Since the sizes are "equal", can I just # dd if=/dev/sdb of=/dev/sdf
>>> bs=1M status=progress and be done with it?  Is there anything else
>that I'd
>>> need to do to get it to boot?
>>>
>>> --
>>>
>>> gnhlug-discuss mailing list
>>> gnhlug-discuss@mail.gnhlug.org
>>> http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
>>>
>>>
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

Re: dd cloning a Win10 HDD to SSD

[Bruce Labitt]

It would seem clonezilla requires linux x86* to run.  Unfortunately I'm on
a RPI4, as my "real linux laptop" is being repaired.  Seems I'm stuck with
dd or gddrescue.
At the moment it has taken 6571s to copy 677GB...  hope this works.  Less
than an hour to go, I hope.

On Tue, Mar 23, 2021 at 11:13 AM Tom Buskey  wrote:

> I've used https://clonezilla.org/ in the past with great success.
> Windows 7 & Server 2008 were the last windows systems I've used it on.
>
> I always connected via ssh to a machine with storage to place the images.
> You can restore to the same size drive or larger.
> The image is created with partclone so it's smaller, but it will fall back
> to dd if needed.
>
>
>
> On Tue, Mar 23, 2021 at 9:09 AM Bruce Labitt  wrote:
>
>> 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...
>>
>>
>>
>>
>> On Tue, Mar 23, 2021 at 8:52 AM Dan Jenkins  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.
>>>
>>> On 2021-03-23 08:33, Bruce Labitt wrote:
>>> > I'd be grateful to learn what worked.  No need to waste my time more
>>> than
>>> > necessary.
>>> >
>>> > On Tue, Mar 23, 2021, 8:30 AM Greg Kettmann  wrote:
>>> >
>>> >> I don't know if dd works. I've done this several times using freely
>>> >> available utilities.  In one case I tried and it failed.  I simply
>>> used a
>>> >> different utility and it worked.  I was impressed with the results,
>>> >> particularly with dramatically improved boot times.
>>> >>
>>> >> Sorry to be vague. You were asking about dd.  If you're interested in
>>> >> which utility(s) I used just let me know.  I should have records.
>>> The last
>>> >> time was a year ago.
>>> >>
>>> >> Greg
>>> >>
>>> >> Get TypeApp for Android 
>>> >> On Mar 22, 2021, at 10:19 PM, Bruce Labitt 
>>> wrote:
>>> >>> Have this excruciatingly slow Win10 HDD I'd like to clone to SSD.
>>> >>> Reading about how to do this leads me to dd as a way to clone the
>>> disk.
>>> >>> The disks are close in size.  According to lsblk, the HDD sdb is
>>> 931.5GB,
>>> >>> and the SSD sdf is 931.5GB.
>>> >>>
>>> >>> sdb has 5 partitions on it.
>>> >>> 1) EFI  500MiB
>>> >>> 2) MS reserved partition  128MiB
>>> >>> 3) OS "basic data" partition 918.07GiB
>>> >>> 4) WINRETOOLS 852MiB
>>> >>> 5) Image   11.56GiB
>>> >>>
>>> >>> sdf has stuff on it, which I presume will be wiped out by dd.
>>> >>>
>>> >>> Since the sizes are "equal", can I just # dd if=/dev/sdb of=/dev/sdf
>>> >>> bs=1M status=progress and be done with it?  Is there anything else
>>> that I'd
>>> >>> need to do to get it to boot?
>>> >>>
>>> >>> --
>>> >>>
>>> >>> gnhlug-discuss mailing list
>>> >>> gnhlug-discuss@mail.gnhlug.org
>>> >>> http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
>>> >>>
>>> >>>
>>> >
>>> > ___
>>> > gnhlug-discuss mailing list
>>> > gnhlug-discuss@mail.gnhlug.org
>>> > http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
>>>
>>> ___
>>> gnhlug-discuss mailing list
>>> gnhlug-discuss@mail.gnhlug.org
>>> http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
>>>
>> ___
>> gnhlug-discuss mailing list
>> gnhlug-discuss@mail.gnhlug.org
>> http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
>>
>
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

Re: dd cloning a Win10 HDD to SSD

[Tom Buskey]

I've used https://clonezilla.org/ in the past with great success.  Windows
7 & Server 2008 were the last windows systems I've used it on.

I always connected via ssh to a machine with storage to place the images.
You can restore to the same size drive or larger.
The image is created with partclone so it's smaller, but it will fall back
to dd if needed.



On Tue, Mar 23, 2021 at 9:09 AM Bruce Labitt  wrote:

> 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...
>
>
>
>
> On Tue, Mar 23, 2021 at 8:52 AM Dan Jenkins  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.
>>
>> On 2021-03-23 08:33, Bruce Labitt wrote:
>> > I'd be grateful to learn what worked.  No need to waste my time more
>> than
>> > necessary.
>> >
>> > On Tue, Mar 23, 2021, 8:30 AM Greg Kettmann  wrote:
>> >
>> >> I don't know if dd works. I've done this several times using freely
>> >> available utilities.  In one case I tried and it failed.  I simply
>> used a
>> >> different utility and it worked.  I was impressed with the results,
>> >> particularly with dramatically improved boot times.
>> >>
>> >> Sorry to be vague. You were asking about dd.  If you're interested in
>> >> which utility(s) I used just let me know.  I should have records.  The
>> last
>> >> time was a year ago.
>> >>
>> >> Greg
>> >>
>> >> Get TypeApp for Android 
>> >> On Mar 22, 2021, at 10:19 PM, Bruce Labitt  wrote:
>> >>> Have this excruciatingly slow Win10 HDD I'd like to clone to SSD.
>> >>> Reading about how to do this leads me to dd as a way to clone the
>> disk.
>> >>> The disks are close in size.  According to lsblk, the HDD sdb is
>> 931.5GB,
>> >>> and the SSD sdf is 931.5GB.
>> >>>
>> >>> sdb has 5 partitions on it.
>> >>> 1) EFI  500MiB
>> >>> 2) MS reserved partition  128MiB
>> >>> 3) OS "basic data" partition 918.07GiB
>> >>> 4) WINRETOOLS 852MiB
>> >>> 5) Image   11.56GiB
>> >>>
>> >>> sdf has stuff on it, which I presume will be wiped out by dd.
>> >>>
>> >>> Since the sizes are "equal", can I just # dd if=/dev/sdb of=/dev/sdf
>> >>> bs=1M status=progress and be done with it?  Is there anything else
>> that I'd
>> >>> need to do to get it to boot?
>> >>>
>> >>> --
>> >>>
>> >>> gnhlug-discuss mailing list
>> >>> gnhlug-discuss@mail.gnhlug.org
>> >>> http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
>> >>>
>> >>>
>> >
>> > ___
>> > gnhlug-discuss mailing list
>> > gnhlug-discuss@mail.gnhlug.org
>> > http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
>>
>> ___
>> gnhlug-discuss mailing list
>> gnhlug-discuss@mail.gnhlug.org
>> http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
>>
> ___
> gnhlug-discuss mailing list
> gnhlug-discuss@mail.gnhlug.org
> http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
>
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

Re: dd cloning a Win10 HDD to SSD

[Bruce Labitt]

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...




On Tue, Mar 23, 2021 at 8:52 AM Dan Jenkins  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.
>
> On 2021-03-23 08:33, Bruce Labitt wrote:
> > I'd be grateful to learn what worked.  No need to waste my time more than
> > necessary.
> >
> > On Tue, Mar 23, 2021, 8:30 AM Greg Kettmann  wrote:
> >
> >> I don't know if dd works. I've done this several times using freely
> >> available utilities.  In one case I tried and it failed.  I simply used
> a
> >> different utility and it worked.  I was impressed with the results,
> >> particularly with dramatically improved boot times.
> >>
> >> Sorry to be vague. You were asking about dd.  If you're interested in
> >> which utility(s) I used just let me know.  I should have records.  The
> last
> >> time was a year ago.
> >>
> >> Greg
> >>
> >> Get TypeApp for Android 
> >> On Mar 22, 2021, at 10:19 PM, Bruce Labitt  wrote:
> >>> Have this excruciatingly slow Win10 HDD I'd like to clone to SSD.
> >>> Reading about how to do this leads me to dd as a way to clone the disk.
> >>> The disks are close in size.  According to lsblk, the HDD sdb is
> 931.5GB,
> >>> and the SSD sdf is 931.5GB.
> >>>
> >>> sdb has 5 partitions on it.
> >>> 1) EFI  500MiB
> >>> 2) MS reserved partition  128MiB
> >>> 3) OS "basic data" partition 918.07GiB
> >>> 4) WINRETOOLS 852MiB
> >>> 5) Image   11.56GiB
> >>>
> >>> sdf has stuff on it, which I presume will be wiped out by dd.
> >>>
> >>> Since the sizes are "equal", can I just # dd if=/dev/sdb of=/dev/sdf
> >>> bs=1M status=progress and be done with it?  Is there anything else
> that I'd
> >>> need to do to get it to boot?
> >>>
> >>> --
> >>>
> >>> gnhlug-discuss mailing list
> >>> gnhlug-discuss@mail.gnhlug.org
> >>> http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
> >>>
> >>>
> >
> > ___
> > gnhlug-discuss mailing list
> > gnhlug-discuss@mail.gnhlug.org
> > http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
>
> ___
> gnhlug-discuss mailing list
> gnhlug-discuss@mail.gnhlug.org
> http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
>
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

Re: dd cloning a Win10 HDD to SSD

[Dan Jenkins]

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.

On 2021-03-23 08:33, Bruce Labitt wrote:
> I'd be grateful to learn what worked.  No need to waste my time more than
> necessary.
>
> On Tue, Mar 23, 2021, 8:30 AM Greg Kettmann  wrote:
>
>> I don't know if dd works. I've done this several times using freely
>> available utilities.  In one case I tried and it failed.  I simply used a
>> different utility and it worked.  I was impressed with the results,
>> particularly with dramatically improved boot times.
>>
>> Sorry to be vague. You were asking about dd.  If you're interested in
>> which utility(s) I used just let me know.  I should have records.  The last
>> time was a year ago.
>>
>> Greg
>>
>> Get TypeApp for Android 
>> On Mar 22, 2021, at 10:19 PM, Bruce Labitt  wrote:
>>> Have this excruciatingly slow Win10 HDD I'd like to clone to SSD.
>>> Reading about how to do this leads me to dd as a way to clone the disk.
>>> The disks are close in size.  According to lsblk, the HDD sdb is 931.5GB,
>>> and the SSD sdf is 931.5GB.
>>>
>>> sdb has 5 partitions on it.
>>> 1) EFI  500MiB
>>> 2) MS reserved partition  128MiB
>>> 3) OS "basic data" partition 918.07GiB
>>> 4) WINRETOOLS 852MiB
>>> 5) Image   11.56GiB
>>>
>>> sdf has stuff on it, which I presume will be wiped out by dd.
>>>
>>> Since the sizes are "equal", can I just # dd if=/dev/sdb of=/dev/sdf
>>> bs=1M status=progress and be done with it?  Is there anything else that I'd
>>> need to do to get it to boot?
>>>
>>> --
>>>
>>> gnhlug-discuss mailing list
>>> gnhlug-discuss@mail.gnhlug.org
>>> http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
>>>
>>>
>
> ___
> gnhlug-discuss mailing list
> gnhlug-discuss@mail.gnhlug.org
> http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

Re: dd cloning a Win10 HDD to SSD

[Bruce Labitt]

I'd be grateful to learn what worked.  No need to waste my time more than
necessary.

On Tue, Mar 23, 2021, 8:30 AM Greg Kettmann  wrote:

> I don't know if dd works. I've done this several times using freely
> available utilities.  In one case I tried and it failed.  I simply used a
> different utility and it worked.  I was impressed with the results,
> particularly with dramatically improved boot times.
>
> Sorry to be vague. You were asking about dd.  If you're interested in
> which utility(s) I used just let me know.  I should have records.  The last
> time was a year ago.
>
> Greg
>
> Get TypeApp for Android 
> On Mar 22, 2021, at 10:19 PM, Bruce Labitt  wrote:
>>
>> Have this excruciatingly slow Win10 HDD I'd like to clone to SSD.
>> Reading about how to do this leads me to dd as a way to clone the disk.
>> The disks are close in size.  According to lsblk, the HDD sdb is 931.5GB,
>> and the SSD sdf is 931.5GB.
>>
>> sdb has 5 partitions on it.
>> 1) EFI  500MiB
>> 2) MS reserved partition  128MiB
>> 3) OS "basic data" partition 918.07GiB
>> 4) WINRETOOLS 852MiB
>> 5) Image   11.56GiB
>>
>> sdf has stuff on it, which I presume will be wiped out by dd.
>>
>> Since the sizes are "equal", can I just # dd if=/dev/sdb of=/dev/sdf
>> bs=1M status=progress and be done with it?  Is there anything else that I'd
>> need to do to get it to boot?
>>
>> --
>>
>> gnhlug-discuss mailing list
>> gnhlug-discuss@mail.gnhlug.org
>> http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
>>
>>
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

Re: dd cloning a Win10 HDD to SSD

[Greg Kettmann]

I don't know if dd works. I've done this several times using freely available 
utilities.  In one case I tried and it failed.  I simply used a different 
utility and it worked.  I was impressed with the results, particularly with 
dramatically improved boot times.

Sorry to be vague. You were asking about dd.  If you're interested in which 
utility(s) I used just let me know.  I should have records.  The last time was 
a year ago.

Greg

⁣Get TypeApp for Android ​

On Mar 22, 2021, 10:19 PM, at 10:19 PM, Bruce Labitt  wrote:
>Have this excruciatingly slow Win10 HDD I'd like to clone to SSD.
>Reading
>about how to do this leads me to dd as a way to clone the disk.  The
>disks
>are close in size.  According to lsblk, the HDD sdb is 931.5GB, and the
>SSD
>sdf is 931.5GB.
>
>sdb has 5 partitions on it.
>1) EFI  500MiB
>2) MS reserved partition  128MiB
>3) OS "basic data" partition 918.07GiB
>4) WINRETOOLS 852MiB
>5) Image   11.56GiB
>
>sdf has stuff on it, which I presume will be wiped out by dd.
>
>Since the sizes are "equal", can I just # dd if=/dev/sdb of=/dev/sdf
>bs=1M
>status=progress and be done with it?  Is there anything else that I'd
>need
>to do to get it to boot?
>
>
>
>
>___
>gnhlug-discuss mailing list
>gnhlug-discuss@mail.gnhlug.org
>http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

Re: dd cloning a Win10 HDD to SSD

[Curt Howland]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Tuesday 23 March 2021, Bruce Labitt was heard to say:
> Is there a compelling reason to use ddrescue over dd for this?  Is
> gnu ddrescue the preferred choice of the ddrescues?

Until now I'd never even heard of ddrescue. Reading the gnu page for 
it seems like a good tool for the second try, in case dd ran into 
problems.

At least you'll get the majority of the data off, even if it doesn't 
make a bootable ssd

> Or is this a fool's errand?

It's always worth trying, and if it doesn't work you haven't lost 
anything.

- -- 
You may my glories and my state dispose,
But not my griefs; still am I king of those.
 --- William Shakespeare, "Richard II"

-BEGIN PGP SIGNATURE-

iHUEAREIAB0WIQTaYVhJsIalt8scIDa2T1fo1pHhqQUCYFncbAAKCRC2T1fo1pHh
qUfwAP9e4gRBJ478jmrnSsRJ+83XhOfRX8KhrWD0Gj3D5+FNSwD/S+ElwtpiB+QR
J55PlO5huC8IdQ1mJD5PIQSnPOt5XcE=
=kbdI
-END PGP SIGNATURE-
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

Re: dd cloning a Win10 HDD to SSD

[Bill Freeman]

Probably only if you're getting read errors on the old device.  But I'm not
a particular expert.

Re: using dd at all, the target drive must be at least as big as the source
partition.  (I'm assuming that everything uses LBA (logical block
addressing) these days.  In the bad old days we had to worry about the
number of heads and sectors: dd would make the copy, but various OSes might
not be able to find things.)


On Tue, Mar 23, 2021 at 8:01 AM Bruce Labitt  wrote:

> Is there a compelling reason to use ddrescue over dd for this?  Is gnu
> ddrescue the preferred choice of the ddrescues?
>
> Or is this a fool's errand?
>
> On Mon, Mar 22, 2021, 11:14 PM Curt Howland  wrote:
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>>
>> On Monday 22 March 2021, Bruce Labitt was heard to say:
>> > Since the sizes are "equal", can I just # dd if=/dev/sdb
>> > of=/dev/sdf bs=1M status=progress and be done with it?  Is there
>> > anything else that I'd need to do to get it to boot?
>>
>> Since using dd to copy boot .iso images works, I would assume the boot
>> record of a hdd would be copied over as well.
>>
>> Just an assumption, since that's not something I've ever tried.
>>
>> So long as your sdf has nothing on it of consequence, the worst thing
>> that could happen is failure and you go back to your existing sdb.
>>
>> Do say what happens, curiosity abounds.
>>
>> Curt-
>>
>> - --
>> You may my glories and my state dispose,
>> But not my griefs; still am I king of those.
>>  --- William Shakespeare, "Richard II"
>>
>> -BEGIN PGP SIGNATURE-
>>
>> iHUEAREIAB0WIQTaYVhJsIalt8scIDa2T1fo1pHhqQUCYFlc9gAKCRC2T1fo1pHh
>> qZKzAP4xMjt0ZsdN1EMdxijarCGTIVLLe1R1b19pifL+lrf51AEA45dOzCreHmw1
>> 80x1evx+s4p6piUHjlONFkgcoDjKgXE=
>> =I2Q8
>> -END PGP SIGNATURE-
>> ___
>> gnhlug-discuss mailing list
>> gnhlug-discuss@mail.gnhlug.org
>> http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
>>
> ___
> gnhlug-discuss mailing list
> gnhlug-discuss@mail.gnhlug.org
> http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
>
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

Re: dd cloning a Win10 HDD to SSD

[Bruce Labitt]

Is there a compelling reason to use ddrescue over dd for this?  Is gnu
ddrescue the preferred choice of the ddrescues?

Or is this a fool's errand?

On Mon, Mar 22, 2021, 11:14 PM Curt Howland  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On Monday 22 March 2021, Bruce Labitt was heard to say:
> > Since the sizes are "equal", can I just # dd if=/dev/sdb
> > of=/dev/sdf bs=1M status=progress and be done with it?  Is there
> > anything else that I'd need to do to get it to boot?
>
> Since using dd to copy boot .iso images works, I would assume the boot
> record of a hdd would be copied over as well.
>
> Just an assumption, since that's not something I've ever tried.
>
> So long as your sdf has nothing on it of consequence, the worst thing
> that could happen is failure and you go back to your existing sdb.
>
> Do say what happens, curiosity abounds.
>
> Curt-
>
> - --
> You may my glories and my state dispose,
> But not my griefs; still am I king of those.
>  --- William Shakespeare, "Richard II"
>
> -BEGIN PGP SIGNATURE-
>
> iHUEAREIAB0WIQTaYVhJsIalt8scIDa2T1fo1pHhqQUCYFlc9gAKCRC2T1fo1pHh
> qZKzAP4xMjt0ZsdN1EMdxijarCGTIVLLe1R1b19pifL+lrf51AEA45dOzCreHmw1
> 80x1evx+s4p6piUHjlONFkgcoDjKgXE=
> =I2Q8
> -END PGP SIGNATURE-
> ___
> gnhlug-discuss mailing list
> gnhlug-discuss@mail.gnhlug.org
> http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
>
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/