A simple job, right? My friend was complaining that their Toshiba Kira-102 kept crashing. The diagnosis was a speedy affair. The ‘as shipped’ 250GB Toshiba SSD had only 200MB remaining on the OS partition and Windows just was not coping with this reality. Windows Update was trying to churn through this free space in an endless cycle of “try and fail”.
The Kira-102 has an older-style mSATA connector. Fortunately, as of February, Samsung had the foresight to continue to support mSATA with the release of the new 860 EVO range. This offers 250 GB , 500 GB and 1000 Gb (1 TB) options in the legacy mSATA format. My friend wanted to go all out on it, so it should have been simple.
If you have arrived here seeking a quick answer to whether or not the 500GB or 1TB mSATA 860 EVO is compatible with the Toshiba KIRA. The answer is yes! Please consider using my Amazon links above if you are looking to buy!
The method to do this should be tried and tested to any “IT guy” (or Gal).
- CloneZilla the original SSD to a SMB share
- Swap the 250GB mSATA drive with the 1TB one
- CloneZilla the image back from the SMB share onto the new SSD
- Boot Windows, resize the partition and hand the device back
If you are struggling with any of the same issues. Find a list of issues and (non)resolutions for this machine below.
1. I couldn’t get into the UEFI and the system wouldn’t respond to any of the override key combinations (F2 for setup, F12 for Boot Device Override)
Fix: In Windows Setting, Updates and Recovery, Recovery. Boot into Windows Recovery and follow through on the advanced options until you come across the boot into the UEFI setup option. Once in the UEFI. Disable Intel Fast Boot. The system will now respond to the F2/F12 keyboard shortcuts again.
2. None of my USB Ethernet Dongles allows the presentation of PXE Boot ROM (Network Boot)
Fix: I know that these dongle have OpROM on them. I therefore believe that the Kira-102 doesn’t have UEFI drivers for PXE boot.
3. External USB keyboard wouldn’t work
Fix: In the UEFI enable Legacy USB device support to fix this in everything apart from Windows Setup (where it still would not work).
4. After re-imaging from CloneZilla the 1000GB 860 EVO reported to Windows that it was a 238 GB drive.
Note: This isn’t the partition/volume size, the device itself would only show 238GB. Essentially CloneZilla had mirrored a 250GB SSD onto a 250GB SSD
Samsung Magician showed the SSD drive as functioning correctly, compatible with the system and running as a 1000GB drive with no problems. The firmware was also current. The UEFI did not seem to have any issues seeing the drive – although it has no capacity readout of its size or UEFI shell to root around in. Equally, there was no additional instability.
As a 2015 machine, it certainly shouldn’t be experiencing a software limitation – such as in the aviailable LBA (Logical Block Address) space. Something that historically has limited BIOS system from addressing hard drive space such as with the historic 2GB, 32GB, 146GB and 2TB limits.
Toshiba Service Station reported that there were no updates available for the machine. The BIOS version was 1.40, which reported as current. However, on accidental inspection of the Toshiba support site, I discovered that there was a 2018 revision 1.60 available. The changelog for the release indicates that the 1.50 version contained “improved SSD related system stability” with the 1.60 adding “Enhanced security & Microcode update” i.e. they patched the high profile IMEI exploit from last year and did something to mitigate Spectre/Meltdown.
I patched the BIOS, ever hopeful… to find that nothing had changed in Windows.
Exiting CloneZilla into the shell, allowed me to elevate into the user account and run
parted -l. Parted reported partition errors, however after fixing them, running ‘
print free‘ didn’t show any free space either.
At this point assuming that there was an artificial hardware limit placed on the storage sub-system, I booted into a Windows 10 install UFD and using diskpart via the command prompt de-initialised the entire disk.
sel disk 0
create part pri
format fs=ntfs quick
Low and behold, the entire 930GB volume appeared in diskpart ‘
I clean installed Windows 10 onto the empty drive to confirm this.
There was clearly a software corruption at work. This could be from the amount of crashing that the machine had endured over months of constant crashing. Alternatively, it could very likely be down to Toshiba’s partition schema and OEM imaging process.
5. Recovering the Data from CloneZilla without recovering the entire disk layout
Leaving the test install alone I booted back into CloneZilla. Due the way CloneZilla works, you cannot restore a partition into free space, only overwrite an existing partition. Instead of recovering the disk from image, I used recover partition from image. The intention is to leave the new Windows installation’s boot code, but overwrite its OS data volume with the one from the CloneZilla image.
There were 6 partitions in the repository, none of which had any size data against them. Windows had the main OS partition as the third partition on the drive, however this turned out to be a 138 MB partition of unknown origin (I suspect something hidden in the Toshiba OEM imaging process). Retrying, the large data partition was found in the image at partition 4.
50 minutes later, the partition had restored back onto the 860 EVO. It still showed as being 930 GB in diskpart, but would not boot. Windows blue screened with error code 0xc0000034.
6. Fixing the Boot Code
There was of course no expectation that the system would boot after this process. The system no longer had the correct boot code in place as the OEM install had additional partitions in-situ.
Boot into the Windows Install DVD or Recovery partition. Load the command prompt
Now mount the FAT32 EFI boot partition and repair the boot code.
sel disk 0
Note the volume number of the 100MB System partition. In my case this was “Volume 2”. If your EFI partition is something other than 2, replace the 2 on the next line with that number.
sel vol 2
bcdboot C:\Windows /s V: /f UEFI
Reboot the computer
After going through an ordeal such as this, the question of whether or not it is stable springs to mind. The Windows 10 version was 1803, so after running a
chkdsk c: /f and ensuring that the OS volume was now using the entire 930 GB. I upgraded Windows 10 to version 1809. Something that gives the SSD some exercise and would highlight any serious problems.
The Windows 1809 upgrade went through without incident and I was able to write more than 250 GB of data onto the volume, proving that the SSD could correctly function over the 250 GB marker.