A few notes about ASUS 1201T, F9 recovery and CMOS battery

[jaclaz]

Foreword:
I am notoriously cheap (besides old and grumpy).

The story:
I was gifted a couple (first one and a few months later the second) of non-working ASUS EEE PC model 1201T. both machines, with very little signs on wear on the exterior, clearly not excessively used/abused. showed the same symptom, on power on five leds (more specifically the one of the on/off button on top right, the one of the touchpad on/off button on top left and three on the bottom right, i.e. power, disk and wi-fi) were on, solid blue, the fan spinned, you could hear/sense the hd spinning BUT completely blank/black screen and no video signal on external monitor from the VGA connector.

When I got the first one I thought (from previous experience with older laptops) that the video card/GPU was fried and set it aside, intending to later maybe salvage the hard disk.

When I got the second one, I grew suspicious, two identical machines with the exact same issue?

A few quick searches provided not any confirmation about the video card/GPU issue being common, but a more accurate search led me to this video by a nice Brazilian guy (which I have to thank a lot , not only for the specific solution but also for the idea of wrapping the upper part of the laptop to avoid scratches and fingerprints, simple and effective) :

 

so the whole issue is that if the CMOS battery is exhausted the computer won't boot to BIOS, easily (and cheaply) solved on both machines.

Since the idea, now that the machines worked, was to make them as functional as possible, I got two SATA SSD's (Crucial BX500 240 GB, got them for around 35 Euro each).

Here came the second issue, the original disk inside the machines is 250 GB in size (one had a WD, the other a Seagate), so I couldn't do a 1:1 clone, and had to delve a little deeper to understand how the stuff (F9 recovery partition and boot booster) worked.

Half to three quarters (or more) of the information you can find online about these two features is either partial, incorrect or plainly wrong.

The partition table contains 4 entries:
#0 Normal type 0x07 NTFS partition, active, around 100 GB in size, let's call it "system and boot"
#1 Normal type 0x07 NTFS partition, around 113 GB in size (the exact size of this partition was slightly different on the two disks), let's call it "data"
#2 Hidden type 0x1B FAT 32 partition, 10 GB in size (this is the recovery partition, containing a WinRE wim and a couple other .wims). let's call it "recovery"
#3 "Queer" type 0xEF partition 17.5 MB in size, let's call it boot booster

after the fourth partition there were "a bunch" of unused sectors.

The first two partitions are perfectly normal.

The third one is also pretty much normal, set aside the "hidden" (obtained by adding 0x10 to the normal value) ID.

The last one is "queer".
The Windows (and most info on the Internet) calls it an "EFI partition", though this is completely wrong, it has nothing to do with EFI or UEFI, the good Asus guys simply used this "EF" id to leave on the disk some (17.5 MB in my case, but I have read about other models using different sizes) some "reserved" space to store the *whatever* data is used to "boost" the boot time.

When you go into the BIOS, IF a partition with ID 0xEF is found, then an option to Enable or Disable Boot booster appears, if there is not this partition the option disappears.

From what I understand in these 17.5 MB some info on the specific machine and possibly about its configuration are pre-saved so that they need not to be "discovered" during the BIOS POST, shaving off a few seconds in booting time, surely this info is recreated when you enable the boot booster.

The instruction/manual says that you need to first make sure that Boot booster is disabled, and then you can use F9 at boot time to start the WinRE (and thus use the factory reset/recovery).

It is clear (now) that most of the magic is done NOT in the MBR code (as it is the "standard" Windows 7 one), unlike other OEM's, like, as an example, HP, see:

https://msfn.org/board/topic/131620-hp-notebook-the-recovery-partition-could-not-be-found/

And I found some small evidence (which I had no occasion to actually test) that the functionality of F9 can be restored by making the 0x01B partitition active and (possibly? )  not hidden (i.e. 0x0B) and then, when the WinRE boots and you are given the option to recovery or abort, even if you select abort the partitions are "reset", i.e. first one is made active and the third one is (possibly? ) changed to 0x1B:

https://www.forum-des-portables-asus.fr/forums/threads/touche-f9-ne-permet-plus-dacceder-a-la-partition-recovery.5307/
 

https://www.forum-des-portables-asus.fr/forums/threads/touche-f9-ne-permet-plus-dacceder-a-la-partition-recovery.5307/page-2#post-43132

Anyway, "my" F9 was working on the original hard disk(s), so I simply made some calculation (with the exact size of my SSD's) so that I had:
#0 a clean NTFS volume, active the same exact size as the original
#1 a clean NTFS volume, the exact size depending on the following
#2 a clone of the 10 GB recovery partitions with the "sectors before" adjusted to reflect the new position[1]
#3 only the EF entry in the MBR for the same size (17.5 MB) as the original

1 (one) excess sector after.

Inserted the new SSD, at next boot:

1) disabled Boot Booster
2) pressed F9
3) chose to recovery

and everything was well.

Then I had some troubles to update to SP1 and a few other packages in order to be able to use Windows Update (which took forever), but this is another story.

Conclusion:
I hope that someone in a same or similar situation can find something of use from this report.

The moral of the story (if there is one ) is:

NEVER, and I mean NEVER, give up!

jaclaz

 

 

[1] for the record, I had some initial isssues with the PBR (and its copy, FAT32 stores a copy on sector 6) as (in the original volume) they were different, evidently the good ASUS guys used some tools that changed something (Root Directory cluster) after the initial format without updating the bootsector backup, and my good, invaluable, DMDE noticed it, in the end I verified that the "main" PBR was good and cloned it on sector 6