X41 SSD Boot Error 2010 / Operating System not Found

[Thomas789]

I managed to install an mSATA SSD (Crucial 250 GB) on an IDE-adpater in the drive bay of my X41. The drive is listed in the BIOS but it does not boot. When I press the Esc key after the expected 2010 drive incompatibility warning, I get the message 'Operating System not found, and I can't get any further. Is this the expected behaviour and would it be remedied by updating the BIOS to bypass the 2010 error message, or would the latter not help to be able to boot at all?

The operating system should actually be there as I cloned my drive onto the SSD with exactly the same program (Minitool Partition Wizard) that I used to copy it to an HDD disk that I can boot from without any problems in the Ultrabay caddy (only that I had the SSD in an USB enclosure when doing the clone). But the drive in the Ultrabay is a Fujitsu HDD, and as far as I am aware, all Fujitsu drives are recognized by the X41 BIOS. When I have the cloned SSD in the USB enclosure, I can see in the partition manager that it is correctly partitioned and the partition is active and the correct amount of space used, but when I have it in the main drive bay, it appears completely unpartitioned and unallocated.

I am really a bit at a loss here and would appreciate any advice whether and how this problem could be solved.

Thomas

[ajkula66]

I am really a bit at a loss here and would appreciate any advice whether and how this problem could be solved.

Thomas

I'm about 99% certain that something went wrong during the cloning process.

Your "new" drive (mSATA SSD) should be in the main bay, with the "old" source drive in an USB adapter. You can run Clonezilla from a flash stick drive and clone the OS. That's how I would go about it anyway.

Having said that, a clean install is the way to go in the vast majority of circumstances.

Good luck.

[automobus]

This post contains misleading information, is not relevant to original poster's problem.

I managed to install an mSATA SSD (Crucial 250 GB)
…
I had the SSD in an USB enclosure when doing the clone

Let me guess: you have a Crucial MX200, a brand+product too cheap to have any specification/datasheet/documentation. Its IDENTIFY word 106 is likely 6003H (0x6003), or at least anything other than 0000h or 0400h.

Let me guess: your "USB enclosure" came without documentation. An aspect of its behaviour might be determined by drive identity word 106: SCSI target storage block size might be derived from word 106.

Let me guess: your drive clone/copy program does not draw attention to storage block size ("sector" sizes). It might not prompt, sanity check, flag or highlight, or otherwise alert operator before it breaks boot-ability.

If all three of my guesses are correct, and ASSuming "Minitool Partition Wizard" did not meddle with partition content, then "Operating System will be found" after correcting partition table.



Now I will describe an example, as I imagine the problem. Any resemblance to real discs, rotating or rusting, is purely coincidental.

A disc: of 360 blocks (numbered 0 through 359), block size 512 octet, 180 Kio overall capacity; holds an Operating System (OS) in a partition. This disc happens to be a Hostess Ding Dong-type (HDD). OS volume size is 176 Kio: logical blocks 8 – 359 are portioned out to OS partition. Computer system bootstrap routine reads a partition directory from disc block 0. (Some call it a partition table, a partition record, a partition book, a partition map, a partition index, a partition trunk, whatever. It is a data structure where block numbers are recorded.)

Operator decides to get a different disc. It is not necessarily newer or older, faster or slower, reliable or quiet or heavy, or different from the first one in any notable way, but this one just happens to be a Sweet and Sticky Doughnut-type disc (SSD). Exactly like HDD, SSD consists of: 360 blocks (numbered 0 through 359), block size 512 octet, 180 Kio overall capacity.

Operator gets a fork, sticks fork in SSD, and slides fork handle in computer's Utensile-Side Bay (USB). Operator does not realise, this type of fork hides disc block size from computer. This type of fork discloses/exposes disc to computer as 45 blocks (numbered 0 through 44), block size 4096 octet, 180 Kio overall capacity. HDD blocks 8 – 359 are copied to fork blocks 1-44. A partition directory is written to fork block 0, assigns fork blocks 1-44 to OS partition. Fork block 1 is located at offset 4096.

HDD, fork, and SSD are all removed from computer. SSD is installed in computer. Computer system bootstrap routine reads SSD block 0, reads partition directory, directory directs computer to read first block of partition. SSD block 1 is located at offset 512. Bootstrap routine reads SSD block 1, does not find OS, end routine.

Morals which might (or might not) be found in this story:

• Good forks (ATA to USB storage adapter, or any other storage bridge/controller) cost good money.
• Treat ATA as archaic.
• ATA Advanced Format is an antifeature. So is ATA Security Feature Set.

2016-03-30 edit: correct wrong number
This post contains misleading information. Original poster experiences a problem of ATA-ATA translation bridge, not of block size.

[Thomas789]

Thanks for your reply

I'm about 99% certain that something went wrong during the cloning process.

Your "new" drive (mSATA SSD) should be in the main bay, with the "old" source drive in an USB adapter. You can run Clonezilla from a flash stick drive and clone the OS. That's how I would go about it anyway.

The problem is I can't access the SSD in the main bay, so I can't even copy something to it, let alone boot from it. Something seems to get corrupted as soon as I try to do an operations on it whist in the main bay. and I have to re-initialize the SSD.

The cloning process worked just fine to a HDD in the Ultrabay. I can boot and work from it without any problem (I am working from it as we speak). I tried to clone this in turn to the SSD in the main bay, but as soon as the clone tool (Minitool partition Wizard) goes into boot mode and wants to clone, it shuts down with an error message saying "Can't continue. Disk configuration has changed". This does not happen with the SSD in a USB enclosure. The cloning completes there without issue. Only that afterwards I can't access it anymore when swapping the SSD back in the main bay again.
I first get the 2010 error warning, and when I press Esc "Operating System not found" when I don't have my drive in the Ultrabay attached, otherwise it just boots then from the latter.

Having said that, a clean install is the way to go in the vast majority of circumstances.
.

A clean install is not an option. I don't have any backup for Microsoft Office for instance (I bought the laptop second hand and it was pre-installed), and I can not possible re-install all the Wndows (XP) updates again and all the other programs I have on there.

Thomas

[ajkula66]

The cloning completes there without issue. Only that afterwards I can't access it anymore when swapping the SSD back in the main bay again.

What good is completed cloning process which produces a non-bootable drive?

Secure erase the SSD, and follow the procedure as I've presented it to you. If Clonezilla gives you grief with the drive as well, then you might be looking at a hardware problem.

A clean install is not an option. I don't have any backup for Microsoft Office for instance (I bought the laptop second hand and it was pre-installed), and I can not possible re-install all the Wndows (XP) updates again and all the other programs I have on there.

Thomas

You'll have to go through quite some tweaking for that SSD to play nice with XP...once you've actually managed to properly clone the drive.

Good luck.

[Thomas789]

Thanks for your reply.

Let me guess: you have a Crucial MX200, a brand+product too cheap to have any specification/datasheet/documentation. Its IDENTIFY word 106 is likely 6003H (0x6003), or at least anything other than 0000h or 0400h.

Yes, it is a MX200, but various people here have used Crucial SSDs successfully, and I can't imagine that a newer version of the same make would be that different.

Let me guess: your "USB enclosure" came without documentation. An aspect of its behaviour might be determined by drive identity word 106: SCSI target storage block size might be derived from word 106.

I can at least clone to the SSD in the USB enclosure but not in the main drive bay. This would not suggest that the USB enclosure is the problem here.

Let me guess: your drive clone/copy program does not draw attention to storage block size ("sector" sizes). It might not prompt, sanity check, flag or highlight, or otherwise alert operator before it breaks boot-ability.

As I said, the clone program worked perfectly to the Fujitsu HDD in the Ultrabay (which boots without any issues) In both cases I used actually a dedicated OS migration wizard that includes an option to optimize it for SSDs (by partition alignment)

Now I will describe an example, as I imagine the problem. Any resemblance to real discs, rotating or rusting, is purely coincidental.

A disc: of 360 blocks (numbered 0 through 359), block size 512 octet, 180 Kio overall capacity; holds an Operating System (OS) in a partition. This disc happens to be a Hostess Ding Dong-type (HDD). OS volume size is 352 Kio: logical blocks 8 – 359 are portioned out to OS partition. Computer system bootstrap routine reads a partition directory from disc block 0. (Some call it a partition table, a partition record, a partition book, a partition map, a partition index, a partition trunk, whatever. It is a data structure where block numbers are recorded.)

Operator decides to get a different disc. It is not necessarily newer or older, faster or slower, reliable or quiet or heavy, or different from the first one in any notable way, but this one just happens to be a Sweet and Sticky Doughnut-type disc (SSD). Exactly like HDD, SSD consists of: 360 blocks (numbered 0 through 359), block size 512 octet, 180 Kio overall capacity.

Operator gets a fork, sticks fork in SSD, and slides fork handle in computer's Utensile-Side Bay (USB). Operator does not realise, this type of fork hides disc block size from computer. This type of fork discloses/exposes disc to computer as 45 blocks (numbered 0 through 44), block size 4096 octet, 180 Kio overall capacity. HDD blocks 8 – 359 are copied to fork blocks 1-44. A partition directory is written to fork block 0, assigns fork blocks 1-44 to OS partition. Fork block 1 is located at offset 4096.

HDD, fork, and SSD are all removed from computer. SSD is installed in computer. Computer system bootstrap routine reads SSD block 0, reads partition directory, directory directs computer to read first block of partition. SSD block 1 is located at offset 512. Bootstrap routine reads SSD block 1, does not find OS, end routine.

Morals which might (or might not) be found in this story:

• Good forks (ATA to USB storage adapter, or any other storage bridge/controller) cost good money.
• Treat ATA as archaic.
• ATA Advanced Format is an antifeature. So is ATA Security Feature Set.

Now I don't understand half of this, but maybe you can make something out of the system log entries that I am getting here:

when the clone program unsuccessfully tried to access the SSD in the main drive, this caused the following messages:

Source: disk: The driver detected a controller error on \Device\Harddisk0\D.
Source: LDM: Unspecified error (80004005).
Source: atapi: A parity error was detected on \Device\Ide\IdePort0.

If you want I can give you also the bytes or words for this.

Thomas

[automobus]

Now I don't understand half of this

Forget everything I said, and disregard that post. I did it again: I acted a loudmouth jerk. Critical, know-it-all, does not play well with others. I should have immediately recognised what problem you are experiencing. (Insert "whoosh, right over my head" Smily here.) What I should have said:

Welcome to the realm of double-bridge failure, which ThinkPadders have visited since 2011. You double-dipped the chip!double-bridged the bus. From now on, when you employ ATA-to-ATA translator chips, just take one bridge and end it.

[Thomas789]

I believe now the SSD is being corrupted each time I put in the main bay. I cloned it now with Clonezilla as well (with the SSD in the USB enclosure). When still in the USB enclosure, the partition was OK and I could see all the copied content. The point is I have to put the SSD/adapter combination into the main bay by trial and error as I can't exactly see where the pins are going when inserting it into the bay opening (I can't open the laptop because of stripped screws). So it always takes me about half a dozen insertion and boot attempts before I have the adapter pins in the right holes and the drive appears in the boot list. But by then it is already corrupted, probably because it got power at the wrong pins. It is then completely unacessible and appears as uninitialized in Windows, and I can't even initialize anymore whilst in the main bay, only when I put it in the USB enclosure again

I think I have to give up on the mSATA option (as it does not work in the Ultrabay with a SATA adapter either), so I have ordered already a new SATA SSD drive instead.

Thomas