Posts made by george1421

@dureal99d The live boot bits that didn’t work for centos was from a fedora pxe boot guide. That is all I did and then just translated what was needed for the structure that fog uses. You will get much faster boot speed with http over ftp, or tftp that is why I kept everything in the same protocol by specifying http:// when making an object reference.

Also from my instructcions I moved the files out of the fog directory where they will get clobbered when you update FOG. By putting them on the web server in a different root folder (i.e. not /fog) the fog installer scripts will not touch them. It would be very depressing if you created this monster boot menu and then have a fog upgrade eat all of your hard work.

OK lets step back and regroup here. Lets do the following

1. Insert the Centos 7 dvd into your FOG server’s cdrom drive
2. Key in the following commands into your fog server’s console as root:

# we are going to put all of our boot images into the web server and issue the files
# with apache and cut out all of this NFS crud
mkdir /var/www/html/bootimg

# connect to the centos dvd to the /mnt directory
mount -o loop /dev/cdrom  /mnt

#show me there is content there
ls /mnt

# Create a destination directory for the centos installer files
mkdir /var/www/html/bootimg/centos7x64

# Copy the content of the dvd to the proper location
cp -r /mnt/*  /var/www/html/bootimg/centos7x64

# Change the access level for world read
chmod -R 755 /var/www/html/bootimg/centos7x64

# Unmount the dvd drive since we already have the files
umount /mnt

3. Now in the FOG Configuration->iPXE New Menu Entry enter the following:
   Menu Item: Centos7PXEInst
   Description: Install Centos x64
   Parameters:
   initrd http://${fog-ip}/bootimg/centos7x64/images/pxeboot/initrd.img
   chain http://${fog-ip}/bootimg/centos7x64/images/pxeboot/vmlinuz initrd=initrd.img method=http://${fog-ip}/bootimg/centos7x64/ devfs=nomount ip=dhcp
   boot || goto MENU
   Menu Show with: All Hosts
4. Now pxe boot your target computer and select the Install Centos x64 menu item.
5. You should see the installer boot and run.

This process can be replicated to other linux distributions. I just tested this, this morning on my dev fog server running 1.3.0-rc8 and it works.

As for a live boot, these settings don’t work, the installer still runs. I don’t have time right now to figure out why the live boot bits are not working.

Live OS boot

initrd http://${fog-ip}/bootimg/centos7x64/images/pxeboot/initrd.img
chain http://${fog-ip}/bootimg/centos7x64/images/pxeboot/vmlinuz initrd=initrd.img root=live:http://${fog-ip}/bootimg/centos7x64/LiveOS/squashfs.img ip=dhcp rootflags="loop" rootfstype=auto ro rd.live.image quiet rhgb rd.luks=0 rd.md=0 rd.dm=0 
boot || goto MENU

@dureal99d I guess I’ll start with a simple statement wow, that’s quite an nfs export.

I would (personally) collapse them down to this
/var/www/fog/service/ipxe *(ro,sync,no_wdelay,insecure_locks,no_root_squash,insecure)

Actually if it was me I would move my files out of the fog directory all together to avoid them from being clobbered during an upgrade.

I might put them into some place like /opt/bootimgs and then export that location. You should be able to map a directory below your mount (share) point. So if you share /opt/bootimgs you should be able to mount /opt/bootimgs/Centos I would test this from another linux server by using the following command mount -t nfs <fog_server_ip>:/opt/bootimgs/Centos /mnt just to make sure it mounts over correctly with only sharing the /opt/bootimgs

Your advanced menu code for fedora looks spot on. You have to be sure that the vmlinuz file you use is capable of network booting via nfs. Not all of them are. I personally would start with live media for all platforms you want to pxe boot. The distributions should give you guidance on what you have to configure for kernel parameters to pxe boot the target computer.

@lukebarone yes manually register the failing system and then schedule a debug deploy.

once you get to the command line it would be interesting to check out the logs in /var/logs (either messages or dmesg) to see if there is any helpful errors with the nic adapter.

@Tom-Elliott any idea about the tg3 unable to map registers?

@lukebarone it would be interesting if you manually register one of these 2 computers and then schedule a debug deploy. That should drop you to a command prompt on the target computer. From there we should run a few commands to inspect the hardware.

I’m working under the assumption this is not a spanning tree issue since you imaged the same model on the same network port.

The tg3 line looks interesting since that is the name of the Broadcom nic driver. The rest of the messages are not as exciting.

@lukebarone Is there any chance you can take a picture of the error screen on a mobile phone and post it in the forum here? That would give the developers an exact placement of the error in the startup code.

@Developers any idea about what might trigger /testcase-data/phandle-tests/consumer-a: could not <extra info> to be thrown on the FOS client?

@lukebarone While this isn’t an answer, if you pick quick registration or quick image (or what ever it was changed to just recently) does it work correctly. I’m questioning if there is a bug in the full registration code (which I suspect) and/or are these systems having an issue getting an ip address that is being caused by the first error.

And just to confirm these to 5520s have the same bios version as the ones you did earlier (trying to explain the differences other than time of day)?

@Tom-Elliott said in Impossible start ISO image after update Fog to 1.3.0:

@george1421 personally that makes the most sense considering the fog directory will be overwritten on any update.

Voice of experience: Already been hit by that upgrade bus a few times.

@jflanagin Ok just a few more questions (I forgot to ask)

6. Since these are different physical locations, what is the bandwidth you have between these locations and HQ.
7. How many workstations do you have total at allocations? And at your largest remote location?
8. How do you deploy your images, do you have a single image that is deployed across all locations or do you have unique images for each location?

While these questions might seem mundane it does add value to get you the best solution.

I wrote a tutorial on this a while ago for pxe booting a winpe iso image https://forums.fogproject.org/topic/6284/booting-mdt-2013-litetouch-with-fog

At that time I referenced http://${boot_url}/isoimg/LiteTouchPE_x86.iso

Where my iso images are stored in /var/www/html/isoimg (hint: not in the fog url directory)

First lets collect some intel on your setup.

1. Are your subnets all at the same location?
2. What version of FOG are you running
3. If your 4 fog servers, are they individual fog servers or do you have one master FOG server and 3 slave (or as known in FOG as storage nodes)?
4. Do you know about the location plugin?
5. Are you willing to redesign things a bit if it makes your deployments work a bit better?

@Tom-Elliott said in HP 250 G4 and HP 450 G3 Network connectivity issues.:

Mind you I suspect it’s how the nic is loaded initially on the ipxe side vs an issue with kernels or Windows though successfully booting to Windows would fix the nic issue initially.

Right that is what I’m thinking, but correct me if I’m wrong. Any changes that he linux kernel might make to the system would not survive a power reset. I have seen where when the linux kernel exits and the next OS takes over, that the next OS doesn’t properly init the nic (or what ever hardware device) assuming it was default when booted.

In the OPs case, when the system is image and restarted and (I assume OOBE is run) that the NIC isn’t picking up an IP address. And to my point if you power off the computer and reboot it there should be no remnants of linux left behind.

@jdd49 While I don’t believe its a linux issue because if you turn off the computer and back on any “bad stuff” that linux might do to these machines should be gone. The FOS engine (kernel) doesn’t (AFAIK) update any firmware so there is nothing to leave behind.

If you re-image one of these machines with the windows DVD does it work correctly? I would still like the 5 questions I asked answered too. They will help the developers understand your current landscape too.

@Developers Do you have any ideas here?

@ragarces Lets just recap here since its been a few days.

You have 2 system specific images one for a HP 450 G3 and one for a HP 250 G4. Both are notebooks. Once imaged neither one of these computer models pick up an IP address once the system has been imaged with FOG.

So to the questions:

1. Does the reference image work fine before its captured with FOG image capture?
2. On the deployed image, if you manually remove the network adapter and then reboot does the target computer re-identify the network adapter and recreate the network interface?
3. What happens if you download the latest network drivers from HP site and manually/force upgrade the network drivers on these target computers?
4. Is this just an ethernet issue or are you having problems with both ethernet and WiFi connections?
5. Where these systems sysprep’d or did you just power them off and imaged them?

If I understand the above I have two thoughts

1. At this time I can’t see how this is a FOG issue, or something that FOG would do/care about. So I unless there is something else I’ve missed we can rule out FOG as being a culprit here.
2. I have see issues with driver shadowing in the past. Where there is a built in windows driver that closely resembles a hardware device and that gets loaded over/before an more appropriate vendor driver. (while this is a bit off point, I saw this with a sound driver on a Dell 780. If the windows native sound driver was used the sound driver worked perfectly with external speakers, but the internal speaker did not work. Once we loaded the proper dell audio driver both the internal and external speakers worked perfectly. This is the kind of driver shadowing I’m talking about).

@juice381 If you have tcpdump installed on your fog server you can collect the dhcp boot of the target computer. That dump file should contain the server that is sending the duplicate dhcp option 66.

This is the tcpdump command you need: tcpdump -w output.pcap port 67 or port 68 or port 69 Start the tcpdump program running then pxe boot the target computer until the error then abort tcpdump. You can (and should) inspect the pcap file with wireshark. You will see the dhcp request from your target computer as well as the replies from the dhcp server and any dhcp proxy servers. I do have to say, for this to work, your fog server, dhcp server and pxe booting client computer must be on the same subnet. If so, then you can capture the dhcp broadcasts in this manner.

@MattPayerle I’m just throwing this out there… You don’t “need” the fog client to change the target computer’s name. You can do the name change via a FOG post install script. This script runs just after the image has been deployed to the target computer and before the first oobe boot. A quick sed script will replace the computer name value in the unattend.xml file with the host name defined in FOG. But to use this method you do have to sysprep the image and use an unattend.xml file. This way the computer name is set the way it should be on the first oobe boot. You can also adjust the target OU and have the unattend.xml file connect the system to AD too. I’m not saying this is the best for your case, only an alternative that is pretty quick to setup and then forget about.

@juice381 Its still perplexing why the installfog.sh file is not creating the .fogsettings file. I think if you uncover that reason the rest will fall into place.

Did you disable selinux and the firewall?

Are you launching the fog install script with sudo? Does it run through and ask you all of the questions it should? Then it just doesn’t do anything? It almost sounds like selinux is blocking the installer script from writing to the places it needs to.

In regards to your error screen below, do you have another dnsmasq server running that is sending out the legacy ip address? It is saying that you are getting a duplicate option 66 {next-server} from dhcp.

@juice381 said in Making Fog Portable:

@Wayne-Workman I’m familiar with dnsmasq however bash not my strong point here. My career hgas taking me the Microsoft path need me to write a powershell script, vb, batch i’m your man. I’m sure I can figure out bash just might take me some time to understand the syntax.

You will find the roots of batch, vb and powershell in bash (actually the unix command shell). The unix shell has been around for a really long time and is the mother of them all. With that said, if you know programming concepts then what you are missing is the syntax. That is where google will fill in the gaps. Bash programming is not as cryptic as perl programming, but is much more powerful than batch. Now that I have to totally confused, don’t worry. Work with it a bit and you will get the hang of the power it has.