Dell Latitude E5450 Upload Chainload Problem

[pocketdexter]

I updated from FOG 1.2.0. on Ubuntu 14.04 LTS to SVN FOG 6899. I cannot upload the image I made for my Win 10 client. DCHP scopes option 66 & 67 are set to FOG IP address and undionly.kpxe . BIOS has been flashed to the latest and boot order is set to Legacy. Secure boot is turned off. I have played around with GRUB and EXIT types without a change. The host is registered with FOG

[Sebastian Roth]

@pocketdexter You posted a lot of helpful information but the essential info is missing I suppose. Which error do you see when things go wrong?? best if you can post a picture or the exact error string you see.

[pocketdexter]

https://drive.google.com/a/calexico.k12.ca.us/file/d/0B3pGceszE6NxLUxQVjBobVJNYms/view?usp=sharing

This is a picture of the error screen I am observing. The error states, "Could not boot: Input/output error (http://ipxe.org/1d0c6539). My windows 10 client boots from the nic and receives the tcp/ip address info properly. It gets stuck after loading tcp/ip address info.

My other models both hp and dell receive no problems. They all image correctly in legacy mode.

[pocketdexter]

I got further in the process. I updated the fog kernel to Official Published Kernels. I also removed a storage node which is no longer in use. It is now simply 1 default storage node.
Kernel - 4.5.0 TomElliott
Date : March 14, 2016
Version : 4.5.0
FOG Type: TomElliott
I am getting stuck now at Processing Hard Disk: /dev/sda

[Sebastian Roth]

@pocketdexter Well that’s interesting!! I was just going to post a link to this topic where exactly the same issue resolved itself… magic!

The linux kernel you just updated has absolutely nothing to do with this error! At this stage (iPXE loading the boot menu) the linux kernel is not involved yet! Anyhow, good to hear that you got past this issue - hope it will not come back on you. Maybe some weird storage node setting caused this (screwed the boot menu??). Can you try to reproduce this?

To resolve your new issue please cancel the task and schedule a new debug upload task (normal upload task but tick “Schedule as debug task”) and boot up the client. When you get to the shell run fixparts /dev/sda and then fog to start the upload. Step through and see if it works!

[Tom Elliott]

As you’re uploading and in the FOS environment, you may need to run Upload - Debug instead of a normal debug.

You can choose this with -> Host Management -> Choose your relevant host -> Basic Tasks -> Capture

Before clicking the submit button, click the checkbox to “schedule as debug”.

Boot the system.

Try running:
fixparts /dev/sda

If it asks, confirm and save settings (I’m just guessing here man).

Then run fog

[pocketdexter]

@Sebastian-Roth That fixparts! I did as you said. I went into the shell and typed in fixparts dev/sda and it said some partitions were leftover (guess windows does a poor job of deleting partitions). It asked if I wanted to delete some problematic partitions and I typed yes. It is now imaging! No more magic!

[george1421]

I’m still wondering if we can’t just do a gratuitous fixparts /dev/sdX (or some other disc scrubbing operation) as part of the imaging process. Just to blow away an remaining bits left on the hard drive so there aren’t so many one-off issues. These problems aren’t really related to FOG but a machine issue that makes FOG look like it can’t manage the hardware properly.

[pocketdexter]

@george1421 You know I usually do a full wipe on all of my images. This was the only image I did not enforce a full wipe of the drive. I can see why it should be standard practice even though my other images are done as full wipes and installing os on raw partition.

As for the initial chainload issue, it was probably trying to load images from a non-existent storage node. After removing the location plugin and the decommissioned storage node, the chainload issue disappeared. I was informed a storage node died (mobo crapped out).