Image Store Corrupt Unable to locate MBR.

JimmyJ0516 · Jun 17, 2020, 4:57 PM

Hello Everyone I am having issues with capturing and deploying the image. I am able to pull the image with no issues and no errors but when I try to deploy it to a unit I get the following message “Image Store Corrupt Unable to locate MBR no file found” I am adding as well some pictures to possibly show some troubleshooting steps I may be asked of. https://imgur.com/nXU283k. https://imgur.com/8guERyQ. https://imgur.com/7Bd51th Thank you again for the help.

george1421 · Jun 17, 2020, 5:51 PM

Can we see a screen shot of the actual error? There is information hidden in the text on the error screen we need to see.

Also I did see one image that wasn’t complete in your last screen shot.

Sebastian Roth · Jun 17, 2020, 7:09 PM

@JimmyJ0516 In the picture we see you get the error when deploying the image called OPT7040-2020 and the directory listing for that clearly shows no d1.mbr file. As well I see the files being owned by root instead of fogproject. While the ownership itself is not actually a problem I can see this being a pointer for manual manipulations with this particular image. Where does the image come from? When was it captured? …

JimmyJ0516 · Jun 18, 2020, 7:37 AM

@george1421 this is the error I got. when trying to image a machine that is all that came up. https://imgur.com/7Bd51th

JimmyJ0516 · Jun 18, 2020, 1:47 AM

@Sebastian-Roth it was a fresh OS install from one of my lab machines. I captured the image yesterday on June 16th. Also yes I saw that the image does not have the d1.mbr file I just do not know why.

george1421 · Jun 18, 2020, 1:18 PM

@JimmyJ0516 Missing bits of the captured image is suspicious. Can you recapture that source system again? If it fails to create the d1.mbr file again then we need to dig deeper into why. It should not fail to create this file but create the others. It “should” be all or nothing.

Also I can’t find the answer in the previous posts, what version of FOG are you using?

JimmyJ0516 · Jun 18, 2020, 1:18 PM

@george1421 I have tried capturing the image 2-3 times yesterday and it keeps failing to capture the d1.mbr file

george1421 · Jun 18, 2020, 1:33 PM

@JimmyJ0516 Ok what I want you to do is a capture again, but before you schedule the task, tick the debug checkbox then schedule the task.

Then pxe boot the target computer. After a few screens of text that you need to clear by the enter key. Eventually you will end up at a linux command prompt. At the linux command prompt key in fog This will single step you through the image deployment. Eventually you will get to the point where the d1.mbr should have been captured, but it “should” throw an error. Take a picture of error and post it here. There should be a clue to why its not grabbing that image.

JimmyJ0516 · Jun 18, 2020, 1:57 PM

@george1421 thanks for the steps. So I did as you said and I indeed got an error https://imgur.com/A6QGyJk I took a picture of it.

george1421 · Jun 18, 2020, 2:35 PM

@JimmyJ0516 Ok you didn’t answer me, what version of FOG are you using?

From that error if you hit Crtl-C it should drop you back to the linux command. From the linux command prompt on the target computer lets see the output from these commands.

// sidebar: On the target computer if you give root a password using the passwd command. Give it something simple like hello and then get the IP address of the target computer with ip addr show that will give you enough info so you can connect to the target computer using a windows program like putty. Just connect to it using the IP address you just discovered. Login as root with the password of hello. This will allow you to copy and paste text much easier then having to seen a screen shot. You can continue with the screen shots if you want but the putty route is faster //

lsblk
fdisk -l /dev/sda

Also we need to start identifying this hardware you are using? Have you imaged this type of computer before and this specific computer is the only one that is failing? Or is it a class of computers that are failing? Its possible that you have a bad hard drive in the source computer.

JimmyJ0516 · Jun 18, 2020, 2:38 PM

@george1421 Sorry, I did not see that. I am running 1.5.8. I am going to run those commands now

JimmyJ0516 · Jun 18, 2020, 2:49 PM

@george1421 I posted the results below. Also, this is not the first time using the computer I have captured the image before and never had issues. I also took another computer model and capture the image of that and also had the same issue the d1.mbr file is missing. I have also post the results of the differences.

[Thu Jun 18 root@fogclient ~]# lsblk
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda      8:0    0 465.8G  0 disk 
|-sda1   8:1    0   579M  0 part 
`-sda2   8:2    0 465.2G  0 part 
[Thu Jun 18 root@fogclient ~]# fdisk -l /dev/sda
Disk /dev/sda: 465.8 GiB, 500107862016 bytes, 976773168 sectors
Disk model: ST500DM002-1SB10
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0x0105e8f5

Device     Boot   Start       End   Sectors   Size Id Type
/dev/sda1  *       2048   1187839   1185792   579M  7 HPFS/NTFS/exFAT
/dev/sda2       1187840 976771071 975583232 465.2G  7 HPFS/NTFS/exFAT
[Thu Jun 18 root@fogclient ~]#

This is from the server itself

/images/OPT7040-2019:
total 18393216
drwxrwxrwx  2 fogproject root        4096 Nov 18  2019 .
drwxrwxrwx 26 fogproject root        4096 Jun 18 09:38 ..
-rwxrwxrwx  1 fogproject root     1048576 Jul  1  2019 d1.mbr
-rwxrwxrwx  1 fogproject root   392718467 Jul  1  2019 d1p1.img
-rwxrwxrwx  1 fogproject root 18440862240 Jul  1  2019 d1p2.img
-rwxrwxrwx  1 fogproject root         190 Jul  1  2019 d1.partitions
-rwxrwxrwx  1 fogproject root          15 Jul  1  2019 d1.size

/images/OPT7040-2020:
total 19968056
drwxrwxrwx  2 root       root        4096 Jun 17 12:20 .
drwxrwxrwx 26 fogproject root        4096 Jun 18 09:38 ..
-rwxrwxrwx  1 root       root   424917799 Jun 17 12:14 d1p1.img
-rwxrwxrwx  1 root       root 20022329625 Jun 17 12:20 d1p2.img
-rwxrwxrwx  1 root       root         190 Jun 17 12:13 d1.partitions
-rwxrwxrwx  1 root       root          15 Jun 17 12:13 d1.size

/images/OPT3040-2019:
total 16517136
drwxrwxrwx  2 fogproject root        4096 Jun 28  2019 .
drwxrwxrwx 26 fogproject root        4096 Jun 18 09:38 ..
-rwxrwxrwx  1 fogproject root     1048576 Jun 28  2019 d1.mbr
-rwxrwxrwx  1 fogproject root   382515569 Jun 28  2019 d1p1.img
-rwxrwxrwx  1 fogproject root    13559174 Jun 28  2019 d1p2.img
-rwxrwxrwx  1 fogproject root    11096900 Jun 28  2019 d1p3.img
-rwxrwxrwx  1 fogproject root 16505295550 Jun 28  2019 d1p4.img
-rwxrwxrwx  1 fogproject root         861 Jun 28  2019 d1.partitions
-rwxrwxrwx  1 fogproject root          15 Jun 28  2019 d1.size

/images/OPT-3040-IMG:
total 11964976
drwxrwxrwx  2 root       root        4096 Jun 18 09:38 .
drwxrwxrwx 26 fogproject root        4096 Jun 18 09:38 ..
-rwxrwxrwx  1 root       root   424782473 Jun 18 09:33 d1p1.img
-rwxrwxrwx  1 root       root 11827327909 Jun 18 09:38 d1p2.img
-rwxrwxrwx  1 root       root         190 Jun 18 09:32 d1.partitions
-rwxrwxrwx  1 root       root          15 Jun 18 09:32 d1.size

Sebastian Roth · Jun 18, 2020, 2:50 PM

Possibly those regexp errors are fixed in the latest already… see fix here: https://github.com/FOGProject/fos/commit/80e240dee4c463c6ec62640edbe48d343098de6e (I would think this was after 1.5.8 released… not exactly sure though)

JimmyJ0516 · Jun 18, 2020, 8:55 AM

@Sebastian-Roth Do you think and again I’m just throwing it out there. What if I downgrade to 1.5.7. All of the images I created were on 1.5.7. Now that I am capturing images for the first time on 1.5.8 I am having these issues. If I do downgrade do I just re-run the installer for 1.5.7? As well as you mentioned all of the images before the news created the owner is fogproject and the new ones have root as the owner.

george1421 · Jun 18, 2020, 3:34 PM

@JimmyJ0516 Instead of going backwards, lets take you to 1.5.9RC2. That RC version will probably become the next 1.5.9 GA release. There hasn’t been any bug reports against that RC release so far.

If you used the git method to install FOG change to that directory (typ /root/fogproject) and issue the following commands.

git checkout dev-branch
git pull
cd bin
./installfog.sh

Now when 1.5.9 comes out you will want to switch back to the master branch to get 1.5.9.

git checkout master
git pull
... and so on

JimmyJ0516 · Jun 18, 2020, 3:45 PM

@george1421 I have been using the TAR/GZ archive way of downloading the updates and all of the updates are stored in /opt is that a problem?

george1421 · Jun 18, 2020, 3:46 PM

@JimmyJ0516 With the tarball releases you can only install GA releases of FOG. The git method allows for a bit more flexibility.

JimmyJ0516 · Jun 18, 2020, 3:47 PM

@george1421 Understood so I am moving into my /opt directory where all of the versions of Fog are stored and then I proceed to run the command you gave me correct?

george1421 · Jun 18, 2020, 3:50 PM

@JimmyJ0516 To use the git method you can run this command from the /opt directory (my preference) or from /root

cd to that directory and then issue the following commands.

git clone https://github.com/FOGProject/fogproject.git
cd fogproject

Then issue the commands from the previous post to switch to the dev branch and reinstall FOG.

Note if git is not installed then you will need to use your linux distro’s tools to install git.

JimmyJ0516 · Jun 18, 2020, 4:10 PM

@george1421 I have successfully updated and I am now on 1.5.9-RC2.9. I will try and capture a image now and see where this takes me.

Image Store Corrupt Unable to locate MBR.

213

12.0k

17.3k

155.2k