MSGID: 2:221/1.58@fidonet 0467cde9
REPLY: 825.min_comp@618:250/24 28244caa
PID: OpenXP/5.0.51 (Win32)
CHRS: ASCII 1
TZUTC: -0500
Hello Arelor!

** On Wednesday 11.01.23 - 13:52, you wrote to me:

 >> It's off to a bad start.  :(
 >>
 >>  https://kolico.ca/tmp/ccc.jpg
 >>
 >> Now what?
 >>

 A> Well, the disk is having a bad day and nearing demise.

CHKDSK only reported a total of 14KB of "bad".  I doubt that  
it's an indication of growing doom.


 A> I'd copy the disk over using dd_rescue (which skips bad
 A> sectors) and then run some filesystem check utility on the
 A> transfered filesystems in the destination drive. YOu may
 A> find some file resided in a damaged sector and it is lost
 A> or damaged, though.

I did it another way.  I had a friend on Telegram who aided me  
in using dd.  Apparently, dd performs a byte-by-byte copy.

The end result maintained the "bad" areas, but at only 14KB,  
I'm not worried about space implications on a 1TB SSD.  :D

This is the whole story:

I tried Macrium, but I failed to understand where to look to
create the boot version.  I did not realize that it was laying  
under "Other Tasks".  I also did NOT like how Macrium seemed to  
hijack the pc by remaining resident in memory after killing its  
processes manually; it simply kept reloading on its own! And  
then there was the blasted "30 day Trial" bubble that kept  
popping up on the task bar at random intervals.

Anyway, the whole Macrium process is now moot. I uninstalled it
when I noticed that it preferred to be always running at bootup
and in memory as a couple of processes and popping up with the
"30 day Trial.." bubble on my taskbar.

I did the migration with Clonezilla's Partclone thru the
default (novice) settings with the "auto expand partions
proportionally".

It failed to do my C partion after it encountered some bad
blocks, but it proceeded with H successfully.

Then.. with the help of a friend live on Telegram, I got help
with using the plain old "dd" command from the command line
boot to do a byte by byte copy of the C partition.

Then.. it was a simple matter to use the ntfsresize command to
get the original 35GB C partion to expand to the already
allocated 139GB space that was established when I selected the
"expand proportionally" option when I ran clonezilla.

Then, upon installing the SSD into the T60, Windows did NOT
originally report the C partition as the expanded size of
139GB, but another linux (debian) boot to the command line with
the Clonezilla program, and running ntfsresize -f -b /dev/sda1
FIXED the problem.  That process automatically scheduled a
Windows chkdsk at the next reboot, and *then* I got the
official 139GB size of the C partition.

I have decided not to recover the few small sectors that are
still marked bad.  The bad sectors aren't really real now that
I have migrated C onto the SSD.

In other research, I was reading that ntfstruncate is the
better tool to recover the marked bad sectors on my newly
migrated C partition on the SSD since there are no bad memory
locations on a new SSD.  But chkdsk's report that they only
total up to 14KB, I'm not going to fuss over that.

This whole process was quite a journey.

I *don't* really notice a SIGNIFICANTLY faster boot time in XP,
but [1] maybe coming out of hibernate, the system loads a bit
faster, [2] the fan is running at a slower speed, and [3] there
is NO fan-speed test at boot up on my T60, [4] some web  
browsing performance is a tad smoother and faster as the cache  
previous content gets reused, I guess.


--../|ug




--
  ../|ug

--- OpenXP 5.0.51
 * Origin:  (2:221/1.58)
SEEN-BY: 1/19 123 15/0 16/0 19/10 37 90/1 105/81 106/201 120/340 123/130
SEEN-BY: 123/131 129/305 142/104 153/7715 203/0 218/700 221/1 6 360
SEEN-BY: 226/30 227/114 229/110 111 112 113 114 206 307 317 400 424
SEEN-BY: 229/426 428 452 470 550 664 700 240/5832 266/512 280/464
SEEN-BY: 280/5003 282/1038 292/854 301/1 317/3 320/119 219 319 2119
SEEN-BY: 322/0 757 326/101 342/200 396/45 423/81 460/58 633/280 712/848
PATH: 221/1 320/219 229/426