Old computer (asus eeeTop all in one touchscreen) mbr fails to restore after imaging task

[JJ Fullmer]

Fog version 7593

The specs of the computer from FOG inventory…

System Manufacturer	ASUSTeK Computer INC.
System Product	ET1602
System Version	QTCEDA90301342

System Type	Type: Desktop
BIOS Vendor	American Megatrends Inc.
BIOS Version	0801
BIOS Date	09/08/2009
Motherboard Manufacturer	ASUSTeK Computer INC.
Motherboard Product Name	ET1602
Motherboard Version	Rev 1.xx

Motherboard Asset Tag	To Be Filled By O.E.M.
CPU Manufacturer	Intel
CPU Version	Intel(R) Atom(TM) CPU N270 @ 1.60GHz
CPU Normal Speed	Current Speed: 1600 MHz
CPU Max Speed	Max Speed: 3800 MHz
Memory	0.97 GiB
Hard Disk Model	ST9160310AS
Hard Disk Firmware	0303
Hard Disk Serial Number	5SV2XYM7
Chassis Manufacturer	Chassis Manufacture
Chassis Version	
Chassis Serial	Chassis Serial Number
Chassis Asset  

So I made a 32 bit Windows 10 image on a VM for legacy devices such as this one and HP dc5100’s (Pentium 4 computers on which the 32 bit image worked without issue). I imaged this eeeTop all in one first and after completing the download task it failed to boot saying that a file was missing. I thought it might have been some special all in one chipset driver. So I manually installed windows 10 via a usb to it and it worked and figured I would just take the drivers from it and add it to the vm image.
But before I tried downloading another image to it, I figured I should back up the working configuration so I uploaded/captured an image from the machine. After the image uploaded, I got the same error again. So I realized that this wasn’t a driver issue, it’s more likely that the mbr isn’t restoring properly on this super old legacy device.

So I booted into the windows 10 usb disk and hit shift+F10 to bring up the command prompt. Then I ran the following

disk part
select disk 0
list partition
#listed system reserved partition as 1/C and main windows partition as 2/E
select partition 2
detail partition
#This revealed that the disk was not active, so I activated it
active
exit
#It is possible that just setting it to active would have brought it back, but just in case I did all this stuff
bcdboot E:\Windows
bootrec /fixboot
bootrec /fixmbr
exit
#restarted the computer

After setting the main partition back to active, recopying the bootfiles, and recreating the boot sector and mbr. The computer booted to the image without issue.

So on at least one 8 year old all in one computer, the mbr is not restoring proper.
The image settings for both the physical machine and the VM were resizable, win 10, with the standard 2 partition install.

[Tom Elliott]

Just a guess but this drive is likely based on 512 sectors expecting to be started at 63 but the image is in 2048 which makes the drive not understand how to use the drive (why Windows showed it as inactive)

[JJ Fullmer]

@Tom-Elliott How would I check this?

[Sebastian Roth]

@Arrowhead-IT said:

After the image uploaded, I got the same error again.

You mean the upload screwed the source? We should definitely have a close look if that’s the case. This should never ever happen I find!

Is this resizable (I guess) or non-resizable image type?? Please boot your (fixed) client into debug upload and run fdisk -l /dev/sda. That should give us sufficient information I suppose. Then if you are really keen, do an upload (command fog) and run the same fdisk -l /dev/sda command when you get back to the shell after uploading. Please post pictures of both.

[Tom Elliott]

Can we get an update on this?

[Sebastian Roth]

@Arrowhead-IT please…

[JJ Fullmer]

Sorry I didn’t see this till just now.
I only have 2 of these and they are currently in production. I will create some downtime and test it out tomorrow if I can.

[JJ Fullmer]

@Sebastian-Roth
Sorry for the delay. I sadly can’t easily upload an image, the thing would probably take an hour or 2 to upload itself and I can’t have it down for that long. So if you need it, it can be done but will require waiting until I can stay a bit late or get in before those that use it.

Attached is the debug output…

[JJ Fullmer]

@Arrowhead-IT @Sebastian-Roth I just re-read my original post remembering the problem and looked at the image logs.
I remember now why you would want to have both. I’ll see if I can just take this down for a little bit to get the debug info.

[Sebastian Roth]

@Arrowhead-IT What is that 500MB first partition for? It’s not marked as bootable and therefore won’t work as windows boot partition I suppose. Maybe this is playing a roll in the issue you have.

Maybe I can gather enough information if you can give me all the stuff you have in your uploaded image directory: d1.minimum.partitions, d1.original.partitions, d1.original.fstypes and if you have d1.partitions - all copy&paste as text here in the forum. Plus upload d1.mbr binary file.

[JJ Fullmer]

@Sebastian-Roth The first 500 MB partition is the system reserved partition that windows creates during install.

So the image I actually use in practice has this in the directory…

ls /images/BaseImgLegacy32/
d1.fixed_size_partitions  d1.original.fstypes    d1p2.img
d1.mbr                    d1.original.swapuuids  d1.partitions
d1.minimum.partitions     d1p1.img

0_1464816757480_d1.zip

The image of the machine itself is still uploading

[JJ Fullmer]

@Sebastian-Roth Here’s the full debug out of the upload with a fdisk -L before and after

[Wed Jun 01 root@fogclient ~]# fdisk -l /dev/sda
Disk /dev/sda: 149.1 GiB, 160041885696 bytes, 312581808 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x25ec63c7

Device     Boot   Start       End   Sectors   Size Id Type
/dev/sda1          2048   1026047   1024000   500M  7 HPFS/NTFS/exFAT
/dev/sda2  *    1026048 312581631 311555584 148.6G  7 HPFS/NTFS/exFAT
[Wed Jun 01 root@fogclient ~]# fog
   +------------------------------------------+
   |     ..#######:.    ..,#,..     .::##::.  |
   |.:######          .:;####:......;#;..     |
   |...##...        ...##;,;##::::.##...      |
   |   ,#          ...##.....##:::##     ..:: |
   |   ##    .::###,,##.   . ##.::#.:######::.|
   |...##:::###::....#. ..  .#...#. #...#:::. |
   |..:####:..    ..##......##::##  ..  #     |
   |    #  .      ...##:,;##;:::#: ... ##..   |
   |   .#  .       .:;####;::::.##:::;#:..    |
   |    #                     ..:;###..       |
   |                                          |
   +------------------------------------------+
   |      Free Computer Imaging Solution      |
   +------------------------------------------+
   |  Credits: http://fogproject.org/Credits  |
   |       http://fogproject.org/Credits      |
   |       Released under GPL Version 3       |
   +------------------------------------------+
   Version: 7961
 * Press [Enter] key to continue

 * Verifying network interface configuration.........Done
 * Press [Enter] key to continue

 * Checking Operating System.........................Windows 10
 * Checking CPU Cores................................2
 * Send method.......................................NFS
 * Attempting to check in............................Done
 * Press [Enter] key to continue

 * Mounting File System..............................Done
 * Press [Enter] key to continue

 * Checking Mounted File System......................Done
 * Press [Enter] key to continue

 * Checking img variable is set......................Done
 * Press [Enter] key to continue

 * Preparing to send image file to server
 * Preparing backup location.........................Done
 * Press [Enter] key to continue

 * Setting permission on /images/002354b5cf4f........Done
 * Press [Enter] key to continue

 * Removing any pre-existing files...................Done
 * Press [Enter] key to continue

 * Using Image: eeeTop
 * Looking for Hard Disk.............................Done
 * Press [Enter] key to continue

 * Reading PartitionTables...........................Done
 * Press [Enter] key to continue

 * Using Hard Disk: /dev/sda
 * Now FOG will attempt to upload the image using Partclone
 * Press [Enter] key to continue

 * Checking for fixed partitions.....................Done
 * Press [Enter] key to continue

 * Getting Windows/Linux Partition Count.............Done
 * Press [Enter] key to continue

 * NTFS Partition count of: 2
 * Press [Enter] key to continue

 * EXTFS Partition count of: 0
 * Press [Enter] key to continue

 * Setting up any additional fixed parts
 * Saving original partition table...................Done
 * Press [Enter] key to continue

 * Saving original disk/parts UUIDs
 * Press [Enter] key to continue

 * Shrinking Partitions on disk
 * Press [Enter] key to continue

 * Clearing part (/dev/sda1).........................Reg file not found
 * Press [Enter] key to continue

 * Mounting partition (/dev/sda1)....................Done
 * Press [Enter] key to continue

 * Not shrinking (/dev/sda1) fixed size
 * Press [Enter] key to continue

 * Clearing part (/dev/sda2).........................Done
 * Press [Enter] key to continue

 * Mounting partition (/dev/sda2)....................Done
 * Press [Enter] key to continue

 * Removing page file................................Done
 * Press [Enter] key to continue

 * Possible resize partition size: 10832399 k
 * Running resize test /dev/sda2.....................Done
 * Press [Enter] key to continue

 * Resize test was successful
 * Press [Enter] key to continue

 * Resizing filesystem...............................Done
 * Press [Enter] key to continue

 * Resizing partition /dev/sda2......................Done
 * Clearing ntfs flag................................Done
 * Press [Enter] key to continue

 * Saving shrunken partition table
 * Press [Enter] key to continue

 * Saving Partition Tables (MBR).....................Done
 * Press [Enter] key to continue

 * Processing Hard Disk: /dev/sda
 * Processing Partition: /dev/sda1 (1)
 * Press [Enter] key to continue

 * Using partclone.ntfs
 * Press [Enter] key to continue

Cloned successfully.
 * Image Uploaded
 * Press [Enter] key to continue

 * Processing Partition: /dev/sda2 (2)
 * Press [Enter] key to continue

 * Using partclone.ntfs
 * Press [Enter] key to continue

Cloned successfully.
 * Image Uploaded
 * Press [Enter] key to continue

 * Restoring Original Partition Layout...............Done
 * Press [Enter] key to continue

 * Not expanding (/dev/sda1) fixed size
 * Press [Enter] key to continue

 * Resizing ntfs volume (/dev/sda2)..................Done
 * Press [Enter] key to continue

 * Clearing ntfs flag................................Done
 * Press [Enter] key to continue

 * Stopping FOG Status Reporter......................Done
 * Press [Enter] key to continue

 * Task Complete
 * Updating Database.................................
Done
 * Press [Enter] key to continue
[Wed Jun 01 root@fogclient ~]# fdisk -l /dev/sda
Disk /dev/sda: 149.1 GiB, 160041885696 bytes, 312581808 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x25ec63c7

Device     Boot   Start       End   Sectors   Size Id Type
/dev/sda1          2048   1026047   1024000   500M  7 HPFS/NTFS/exFAT
/dev/sda2  *    1026048 312581631 311555584 148.6G  7 HPFS/NTFS/exFAT
[Wed Jun 01 root@fogclient ~]#

[JJ Fullmer]

@Sebastian-Roth
And here is the list of files of the image of the actual machine with the zipped mbr binary file

[root@arrowfogSnode images]# ls /images/eeeTop/
d1.fixed_size_partitions  d1.original.fstypes    d1p2.img
d1.mbr                    d1.original.swapuuids  d1.partitions
d1.minimum.partitions     d1p1.img

0_1464818699717_d1.zip

[JJ Fullmer]

@Sebastian-Roth So I just went to check on it after the upload and the problem did not occur this time. And it should be noted that I have updated fog since the original problem. So it no longer occurs after upload.

[Sebastian Roth]

Ok, the d1.mbr you uploaded as ZIP actually shows that sda1 is marked active. So this will be pushed back to the client when “restoring the original disk layout” after uploading the shrinked partitions. I tried to reproduce this in my test VM but was not lucky yet. When I just did a resizable image type upload with second partition marked active it all went fine. Not saying that this is not possible. Just wondering what I did wrong.

Please upload the new d1.mbr and d1.partitions after the upload finished as well as the requested fdisk -l /dev/sda…

[JJ Fullmer]

Since the problem didn’t recur, I should probably test download overnight or something.
I’ll set it to download the universal image that failed before at 1 am tonight and check it in the morning. Then I’ll just restore the image I just made of it to put it back the way it was.

@Sebastian-Roth I did upload the mbr and fdisk -l. I just also put the entire debug console output just in case there was something useful there too. See post 11 for the debug output and post 12 for the mbr of the image from the machine. But again, I gotta note that the problem didn’t recur this time around. I have updated fog since the original problem. 20 days ago it happened on git ver 7593, it did not happen after upload on git ver 7961

[Sebastian Roth]

What about cat /images/eeeTop/d1.partitions?? In the new d1.mbr you uploaded I still see sda1 being marked as active - instead of sda2. Hmmm?!?

[JJ Fullmer]

@Sebastian-Roth
as you requested, d1.partitions says…

[root@arrowfogSnode images]# cat eeeTop/d1.partitions
label: dos
label-id: 0xc461246b
device: /dev/sda
unit: sectors

/dev/sda1 : start=        2048, size=     1024000, type=7, bootable
/dev/sda2 : start=     1026048, size=   311552000, type=7

On a different note, I got in before everybody that uses this in production so I could test this out. It imaged with my original universal legacy image and the problem did happen this time on a download.
So just to review.

• On git 7593 20 days ago upload and download caused disk 2 to go inactive
• On git 7961 upload works fine but download of the original intended image still causes the problem.

I just booted it into a download debug task to download the image I uploaded yesterday from the machine itself.
Here is the fdisk -l output when it is not working…

fdisk -l /dev/sda
Disk /dev/sda: 149.1 GiB, 160041885696 bytes, 312581808 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x9bb2a2a8

Device     Boot   Start       End   Sectors   Size Id Type
/dev/sda1  *       2048   1026047   1024000   500M  7 HPFS/NTFS/exFAT
/dev/sda2       1026048 312581631 311555584 148.6G  7 HPFS/NTFS/exFAT

The d1.partitions content of this image (The original one from a vm, not the machine) in case you need it for comparison is…

[root@arrowfogSnode images]# cat BaseImgLegacy32/d1.partitions
label: dos
label-id: 0xc63d5d20
device: /dev/sda
unit: sectors

/dev/sda1 : start=        2048, size=     1024000, type=7, bootable
/dev/sda2 : start=     1026048, size=    82857984, type=7

Both images, eeeTop from the machine and BaseImgLegacy32 are resizable images grabbing everything.

It is possible that the only problem is that the disk is not active. I have not tested simply setting it to active and rebooting, I have always done the bcdboot and bootrec commands as a safety net. I will test that theory really quick to see if I really need to be recreating boot files and such.

[JJ Fullmer]

@Arrowhead-IT said in Old computer (asus eeeTop all in one touchscreen) mbr fails to restore after imaging task:

It is possible that the only problem is that the disk is not active. I have not tested simply setting it to active and rebooting, I have always done the bcdboot and bootrec commands as a safety net. I will test that theory really quick to see if I really need to be recreating boot files and such.

I just tested this, it is not the case. Simply making it active brings up an error says that the boot/bcd files are missing or corrupt.
So I do still need to run at least bcdboot C:\Windows

I am going to test download with the image that I uploaded from the computer now and see if it still happens. I figure since this image was uploaded on the newer version of fog, if any changes were made, this will let us know that it is fixed, except that it’s working on an image from a 512 sector hdd to a 512 sector hdd. So if I need to, I can also update my legacy image, which I was planning on doing today anyway, and I’ll try it again for funzies.

[JJ Fullmer]

Here is the output from the debug download task of the image from the machine taken yesterday.

In the vardump, I noticed that the mbr file variable isn’t set to anything. Not sure if that’s something or not. Also, note that I did a fdisk -L before and after, but also remember that I had set partittion 2 to be active manually just before this task.

[Thu Jun 02 root@fogclient ~]# fdisk -l /dev/sda
Disk /dev/sda: 149.1 GiB, 160041885696 bytes, 312581808 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x9bb2a2a8

Device     Boot   Start       End   Sectors   Size Id Type
/dev/sda1          2048   1026047   1024000   500M  7 HPFS/NTFS/exFAT
/dev/sda2  *    1026048 312581631 311555584 148.6G  7 HPFS/NTFS/exFAT
[Thu Jun 02 root@fogclient ~]# fog
   +------------------------------------------+
   |     ..#######:.    ..,#,..     .::##::.  |
   |.:######          .:;####:......;#;..     |
   |...##...        ...##;,;##::::.##...      |
   |   ,#          ...##.....##:::##     ..:: |
   |   ##    .::###,,##.   . ##.::#.:######::.|
   |...##:::###::....#. ..  .#...#. #...#:::. |
   |..:####:..    ..##......##::##  ..  #     |
   |    #  .      ...##:,;##;:::#: ... ##..   |
   |   .#  .       .:;####;::::.##:::;#:..    |
   |    #                     ..:;###..       |
   |                                          |
   +------------------------------------------+
   |      Free Computer Imaging Solution      |
   +------------------------------------------+
   |  Credits: http://fogproject.org/Credits  |
   |       http://fogproject.org/Credits      |
   |       Released under GPL Version 3       |
   +------------------------------------------+
   Version: 7961
 * Press [Enter] key to continue

 * Verifying network interface configuration.........Done
 * Press [Enter] key to continue

 * Checking Operating System.........................Windows 10
 * Checking CPU Cores................................2
 * Send method.......................................NFS
 * Attempting to check in............................Done
 * Press [Enter] key to continue

 * Mounting File System..............................Done
 * Press [Enter] key to continue

 * Checking Mounted File System......................Done
 * Press [Enter] key to continue

 * Checking img variable is set......................Done
 * Press [Enter] key to continue

 * Attempting to send inventory......................Done
 * Press [Enter] key to continue

 * Using Image: eeeTop
 * Looking for Hard Disk.............................Done
 * Press [Enter] key to continue

 * Using Disk: /dev/sda
 * Enabling write cache..............................Enabled
 * Press [Enter] key to continue

 * Using Hard Disk: /dev/sda
 * Preparing Partition layout
 * Erasing current MBR/GPT Tables....................Done
 * Press [Enter] key to continue

 * Restoring Partition Tables (MBR)..................Done
 * Press [Enter] key to continue

 * Inserting Extended partitions.....................Done
 * Press [Enter] key to continue

 * Attempting to expand/fill partitions..............Done
 * Press [Enter] key to continue

   +--------------------------------+
   |  Attempting to download image  |
   +--------------------------------+
   |         Using Partclone        |
   +--------------------------------+

 * Processing Partition: /dev/sda1 (1)
 * Press [Enter] key to continue
 * Imaging using Partclone
Cloned successfully.
 * Clearing ntfs flag................................Done
 * Not expanding (/dev/sda1) fixed size
 * Press [Enter] key to continue

 * Processing Partition: /dev/sda2 (2)
 * Press [Enter] key to continue

 * Imaging using Partclone
Cloned successfully.
 * Clearing ntfs flag................................Done
 * Resizing ntfs volume (/dev/sda2)..................Done
 * Press [Enter] key to continue

 * Clearing ntfs flag................................Done
 * Press [Enter] key to continue

 * Resetting UUIDs for /dev/sda
 * Press [Enter] key to continue

 * Resettings swap systems
 * Press [Enter] key to continue

 * Stopping FOG Status Reporter......................Done
 * Press [Enter] key to continue

 * Mounting directory................................Done
 * Press [Enter] key to continue

 * Mounting directory................................Done
 * Press [Enter] key to continue

 * Changing hostname.................................Done
 * Press [Enter] key to continue

 * Task Complete
 * Updating Database.................................Done
 * Press [Enter] key to continue

[Thu Jun 02 root@fogclient ~]# fdisk -l /dev/sda
Disk /dev/sda: 149.1 GiB, 160041885696 bytes, 312581808 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x094905ec

Device     Boot   Start       End   Sectors   Size Id Type
/dev/sda1  *       2048   1026047   1024000   500M  7 HPFS/NTFS/exFAT
/dev/sda2       1026048 312581631 311555584 148.6G  7 HPFS/NTFS/exFAT

After rebooting the problem happened again. So I booted into a windows usb and opened the command prompt.
I confirmed that partition 2 was inactive, but I didn’t set it to active this time. I listed the volumes and saw sda1 to be C:\ and sda2 to be E:
Instead of creating new bootfiles I ran bootrec /rebuildbcd This found the boot files on E:\Windows (The inactive partition) I said yes to restoring the boot options. I confirmed the boot setting with bcdedit which said that the windows bootmgr is on C:\ (sda1 system partition) and it showed windows 10 LTSB on E:\Windows as the default boot option. I checked diskpart again after that and noted that partition 2 was still showing as inactive. I rebooted and it booted like normal.

Trouble is, I now need to do the same bootrec command on the computer after imaging it with the original image and see what happens. Because the E:\Windows boot files were put there by me in this image when I “fixed” it for these devices as described in the original posting. I will have to do that later though, the people need their barcode scanner computer.

Oh and I don’t know if it matters or not and not sure if I already mentioned it, but these are 32bit machines that are using the 32 bit kernel and init.

Hopefully though, this is enough information to do something with.