Image Deployment Failure
-
I bought new computers and the image deployment fail. The message at the end of the deployment right before it finishes, “An error has been detected” “could not resize /dev/sdas2” “please run e2fsck -f /dev/sda2 first” “Args Passed: /dev/sda2 1”. Any idea why I have this issue?
-
@sebastian-roth I successfully built image from the type of computer that don’t work on image deployment. It seems to me that there must be some kind of hardware config that prevents the image deployment to expand the disk properly
-
@zfeng Thanks for the picture. Unfortunately there is no obvious explaination jumping at me.
You said one PC deploys fine but the other one runs into this problem. Can you please tell us about those two PCs. Are they exactly the same hardware/disk drive or do the have different hardware?
-
@sebastian-roth I cannot update the image here as the platform keeps saying it is too large. Here is the link for it
https://drive.google.com/file/d/1J8FarpqD-0dhHdWd0BCSairqnL84e5Wa/view?usp=sharing
-
@zfeng Probably best if you can provide a picture of the actual error on screen. More often than not we get valuable information from the picture that is missing if you just type the error message from memory.
From what you posted initially I would imagine this is happening within the expandPartition function in funcs.sh (line 242). But as you see in the code a e2fsck is done right before it tries to expand the filesystem using
resize2fs. So the error message “please run e2fsck -f /dev/sda2 first” actually comes from theresize2fstool itself and is not something being proposed by the FOS script code.I can’t give you an answer on why this fails on one of your systems but not on the other. Though I can imagine a picture with the error on screen might shed a light on this.
@zfeng said:
… used the instruction u provided on both computer that works and computer that does not.
As well you might give us some more details on those two computers. Are those very similar or do they have totally different specs like different size disk?
-
@george1421 Sorry for this late message. Just want to rephrase what we discuss little. The capturing task works fine that it allows me to capture the image properly. The problem is the deployment of image.I just tried deploying image and used the instruction u provided on both computer that works and computer that does not. The outputs from both computers are:
Computer that does not work with image deployment:
Pass 1: Checking inodes, blocks, and sises
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/sda2: {certain number}/{certain number} files (0.3% non-contiguous)Computer that works with image deployment:
Pass 1: Checking inodes, blocks, and sises
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/sda2: {certain number}/{certain number} files (0.2% non-contiguous)Basically, the outputs are the same except that percentage of non-contiguous
-
@zfeng well if you are still getting the error in your initial post and you have the latest version of FOG and the FOS Linux kernel then lets do what the error messages tells you because it appears your disk structure seems inconsistent.
Schedule a new capture task, but before you hit the schedule task button, tick the debug checkbox. Now pxe boot the target computer. After a few screens of text you need to clear with the enter key. Now you will be dropped to the linux command prompt. Now run that command
e2fsck -f /dev/sda2that is roughly the same aschkdskis to Windows. Report the results here. According to the error there is something wrong with partition 2 on that disk. -
@george1421 when you have a moment, can you look at my previous comment? thanks
-
@george1421 the dev ranch seems not solving the image deployment issue.
-
@zfeng The easiest way to upgrade is if you installed fog using the git method. If yes then do the following.
Change into the directory where the fogproject folder is. Depending on the instructions you followed it may be in /root or /opt. You will need to be root to run the following commands.
Lets assume the fogproject folder is in the /root directory.
cd /root/fogproject git pull git checkout dev-branch git pull cd bin ./installfog.shThe fog installer will use all of the previous answers you provided when fog was installed so it will just upgrade FOG. Once the update is done confirm that FOG is at version 1.5.9.110 or later.
Then I strongly recommend you do the following to bring your fog environment up to get the latest hardware support.
- Upgrade the FOS Linux kernel to the 5.15.x version by using the Web UI -> FOG Configuration -> Kernel update. Download both the 32 bit and 64 bit versions of 5.15.x latest version.
- Upgrade iPXE to the latest release: https://forums.fogproject.org/topic/15826/updating-compiling-the-latest-version-of-ipxe
That will put your fog install in the best position to see new (contemporary) hardware.
Now when FOG 1.5.10 is released you will need to revert your fogproject folder back to the master branch. You simply do the same as before but select the master branch.
cd /root/fogproject git pull git checkout master git pull cd bin ./installfog.sh -
@george1421 when you say the dev branch, I believe you mean in this link.
-
@zfeng said in Image Deployment Failure:
must follow what Microsoft changes, right
Yes Microsoft is the driving force in the computer industry. Where they move the vendors will follow if they want to sell computers.
-
@zfeng said in Image Deployment Failure:
That means I cannot revert the version of fog like 1.5.6 or earlier to resolve the issue?
Correct, its a change that microsoft did to the file system. Only the newer version addresses this change.
For the next release, do you have a timeline for this?
Right now we were hoping before the summer break but it might not happen because the active developers have other projects in the works and then on holiday over the summer. So fall 2022 is probably realistic. Switching to the dev branch is the recommended solution.
-
@george1421 Also, it seems to me that due to the change from Microsoft, the manufactures of computers, motherboard or disk, must follow what Microsoft changes, right?
-
@george1421 That means I cannot revert the version of fog like 1.5.6 or earlier to resolve the issue? Seems that is the case. For the next release, do you have a timeline for this?
-
@zfeng Ok, I can tell you there is a bug in 1.5.9 (well not really a bug but M$ changed the disk structure with (Windows 10 20H2) after FOG 1.5.9 was released). This has been fixed in the dev branch of FOG in version 1.5.9.110 and later. Microsoft marked the recovery partition unmovable and its at the end of the disk, so FOG 1.5.9 can’t expand the drive because that partition is marked unmovable.
So you have two possible fixes.
- Go back to your golden image and remove the recovery partition at the end of the disk and recapture with FOG 1.5.9.
- Upgrade to the dev branch of FOG and then recapture your golden image. The dev branch is stable and the current release will probably become FOG 1.5.10 when its released.
-
@george1421 Thanks for you quick response.
FOG Project: v1.5.9
Ubuntu OS Kernel: v5.4
Target OS: Ubuntu 20.04
Successfully deployed to other computers: yes -
@zfeng Um its powered on is why you have the problem??
You need to be a bit more specific on your details.
What version of FOG?
What version of the FOS Linux kernel are you using?
What specific OS are you deploying?
Has this image been successfully deployed to a different computer?I’m not going to grantee this will solve your problem, but I can tell you the conditions are similar to others that had the same problem appearance.
