Posts made by dholtz-docbox

@Wayne-Workman : Oh! Right - that was the other concern of mine I have on my whiteboard. Thanks for bringing that up again. Should I just… delete /var/www/fog and call .foginstall again on the FOG Server? Or what would be the best way to invalidate this?

After discussing what I have, the current issue is as follows…

My system has two (2) drives; the first drive /dev/sda is not formatted or touched, and the second drive /dev/sdb is formatted with Ubuntu 14.04.5 - Server using LVM. There is nothing complex about the LVM partition - other than it being LVM - as it only contains one primary partition currently - along with any of its other typical partitions.

This is where the issue comes into play.

I have the host registered with the FOG server, and all I am trying to do is boot the host into its system through PXE. However, every time it goes to boot into the drive, it either hangs - if using SANBOOT - or hits a chainloading loop - when using EXIT.

I am told the chainloading loop is easier to deal with than the SANBOOT issue.

Since then, I have been trying to narrow down various things, and DHCP configuration was the first to square away.

@george1421 : Haha, okay, let’s start over, knowing what we know now…

Well, the good news there is that we chopped off a pretty huge segment of what I thought to be wrong. Which was certainly a big question of mine initially. So, pending a few screenshots I linked, I don’t think there is much to catch up on

@george1421 : Thank you for clarifying that, that was my suspicion in the end too.

Also, thank you for taking the time to revisit this topic. I know I am close, given what successes I have had so far.

@george1421 : I do get into the FOG iPXE menu, so I guess… that’s good to know. It seems to be related to the kernel then…? Which I believe was a path I was on earlier, but wasn’t sure where I was going with it at the time.

@george1421 : Absolutely - I just want to make sure I put the right information out there in light of that.

Will Wireshark explicitly show options 66 and 67? I guess I don’t know how to validate that “the payload of DHCP 66 and 67” are correct. My assumption is that 66 is the “Next server IP address” and that 67 is “Boot file name”.

@george1421 : Yeah, I noticed that - that PXE won’t boot this way, which makes sense. I reverted the changes. I guess what I have been trying to figure out is what Wayne mentioned, that the, “Duplicate option 66 (next server) from DHCP proxy and DHCP server,” message is present. So far, everyone of my network captures has yielded the aforementioned results. Where the only thing that strikes me as odd is the fact that both 10.1.10.1 and 10.1.10.42 are trying to make an offer. That said, only 10.1.10.1 ACK’s, but it has no boot filename or anything. If everything is setup the way it should be, 10.1.10.1 should be supplying “undionly.kpxe” in its boot filename, right?

Edit> Oh, re-reading your previous post, and reading what I wrote again, something might have clicked. So… 10.1.10.1 is serving the IP and 10.1.10.42 is serving the next-server, which is its IP, 10.1.10.42, correct? So… this would be typical behavior, if that is all correct… Which brings me back to not being sure why there is a duplicate option 66.

@george1421 : I am not sure if our terminology is in sync, but to clarify… the router which handles DHCP is 10.1.10.1 and the FOG Server is 10.1.10.42. When you say “primary DHCP”, from whose point-of-view is that? My current assumption is that the primary DHCP would be the one serving IP’s; where the FOG Server would be the DNSMasq?

Further, I agree, 10.1.10.42 should NOT be offering anything. But when I look at Wireshark, 10.1.10.42 the one with a boot filename, where 10.1.10.1 has no real supporting information.

That said… does my dnsmasq.conf need to be flipped around, such that…

dhcp-boot=undionly.kpxe,,10.1.10.1

and…

dhcp-range=10.1.10.42,proxy

… or something like that? Curious if I had something flipped around incorrectly.

@Wayne-Workman :

Yeah, I was wondering about that line - it has been bothering me. I have never used wireshark, so let me grab it and look around.

You have a lot more output

I have not edited anything though; I have only run the installfog.sh script over the existing installation.

Let me go and determine who else is serving DHCP real quick.

Edit> Which machine should I be using wireshark on? I’m not quite sure how to use the tool in the requested manner.
Edit> Nevermind. Wireshark was starting up with one of its windows resized to its minimum height - the window which lists the packets. I am looking through it now.
Edit>

Am I right in looking at this, in that, both 10.1.10.1 and 10.1.10.42 are serving DHCP, where only, w/ DNSMasq, 10.1.10.1 should be serving it?

Edit> I believe that is right, reading into how DHCP works. There should only be one DHCP Offer, correct? Both 10.1.10.1 and 10.1.10.42 offering would indicate that 10.1.10.42 is setup, somehow, to serve its own DHCP? I guess my next question is, if my dnsmasq.conf is correct, what is lingering that is causing 10.1.10.42 to also serve DHCP.

You had me thinking…

One of the other VM’s on the network I used, at one point, to do an installation, where it setup using FOG’s DHCP. Is it possible something is still lingering on this machine? I am going to shut it off and give it a whack, in the mean time…

Edit> Nope. No difference.

As far as whether I have DHCP setup for FOG and DNSMasq, I should only have DNSMasq? Is there a way to validate this? The .fogsettings for the server are as follows…

## Start of FOG Settings
## Created by the FOG Installer
## Version: 1.3.0-RC-11
## Install time: Fri 30 Sep 2016 05:26:11 PM EDT
ipaddress='10.1.10.42'
interface='eth0'
submask='255.255.255.0'
routeraddress='10.1.10.1'
plainrouter='10.1.10.1'
dnsaddress='#   No dns added'
username='fog'
password='{password}'
osid='2'
osname='Debian'
dodhcp='N'
bldhcp='0'
dhcpd=''
blexports='1'
installtype='N'
snmysqluser='root'
snmysqlpass=''
snmysqlhost='localhost'
installlang='0'
donate='0'
storageLocation='/images'
fogupdateloaded=1
docroot='/var/www/'
webroot='/fog/'
caCreated='yes'
startrange=''
endrange=''
bootfilename='undionly.kpxe'
packages='apache2 bc build-essential cpp curl g++ gawk gcc gzip htmldoc lftp libapache2-mod-php5 libc6 libcurl3 m4 mysql-client mysql-server net-tools nfs-kernel-server openssh-server php5 php5-cli php5-curl php5-fpm php5-gd php5-json php5-ldap php5-mcrypt php5-mysqlnd php-gettext sysv-rc-conf tar tftpd-hpa tftp-hpa vsftpd wget xinetd zlib1g '
noTftpBuild=''
notpxedefaultfile=''
sslpath='/opt/fog/snapins/ssl/'
backupPath='/home/'
php_ver='5'
php_verAdds='-5.6'
sslprivkey='/opt/fog/snapins/ssl//.srvprivate.key'
## End of FOG Settings

Then I have the following dnsmasq.conf…

# Don't function as a DNS server:
port=0

# Log lots of extra information about DHCP transactions.
log-dhcp

# Set the root directory for files available via FTP.
tftp-root=/tftpboot

# The boot filename, Server name, Server Ip Address
dhcp-boot=undionly.kpxe,,10.1.10.42

# Disable re-use of the DHCP servername and filename fields as extra
# option space. That's to avoid confusing some old or broken DHCP clients.
dhcp-no-override

# PXE menu.  The first part is the text displayed to the user.  The second is the timeout, in seconds.
pxe-prompt="Booting FOG Client", 0

# The known types are x86PC, PC98, IA64_EFI, Alpha, Arc_x86,
# Intel_Lean_Client, IA32_EFI, BC_EFI, Xscale_EFI and X86-64_EFI
# This option is first and will be the default if there is no input from the user.
pxe-service=X86PC, "Boot to FOG", undionly
pxe-service=X86-64_EFI, "Boot to FOG UEFI", ipxe

dhcp-range=10.1.10.1,proxy

Edit> I would be led to believe that only DNSMasq should be handled because of…

dodhcp='N'
bldhcp='0'

… no?

@Wayne-Workman :

#!ipxe
set fog-ip 10.1.10.42
set fog-webroot fog
set boot-url http://${fog-ip}/${fog-webroot}
exit

Unfortunately, I have to move forward with the LVM installation for now. Given the time until our next release, it is too risky to greenlight the change to EXT. That said, I had the same issue with both SANBOOT and EXIT w/ the EXT install, so the problem is similar I feel - wild guess.

I was also hopeful that installing EXT would eliminate the extra boot options in my BIOS. It seems that was not the case, so maybe they are related to Server Edition instead? I just find it odd that, when installing Ubuntu to the disk, that I can no longer boot from the disk and must boot from one of those Ubuntu options. Which one also has relevance, as the other one appears to have no operating system on it. Perhaps it’s the swap?

As far as the other information…

• host mac => 08:60:6e:fa:05:af
• server ip => 10.1.10.42

and here’s an image of the boot output…

No problem. Let me re-install the system with LVM - I was trying other things in the interim. I will provide an image as soon as that is complete.

@Tom-Elliott : That’s what I started to think last night, so that makes sense. I wanted EXIT to work as you described, but it throws a chainloading error each time. I am actually going to… just install the drive as EXT4. I mean… /dev/sdb is just /dev/sdb, one way or the other, right? I am hoping the system works fine, and then I can just do single disk targeting the second drive, hoping that it is more reliable.

Yeah, I have to head home for now. I will get this information ASAP tomorrow or tonight if I can.

-Dustin

PS> I think what trips me up is, I am just trying to find one happy path, and I don’t think that has been revealed yet to me (with our hardware, at least). It’s mind boggling to me the things that do work, when they work, and the things that do not work, and for reasons I am not equipped-enough to handle yet. Even now, understanding as much as I do, I circle back and ask simple questions, such as, why does the swap partition fail to image when deploying an EXT formatted drive. Or, why can I set the system up for LVM, capture and deploy the disk, and only then am I able to boot into ‘/dev/sdb’ with the settings I provided; however, fails to do a simple SANBOOT.

Also, here’s an image of the boot drives post-installation of Ubuntu…

@Wayne-Workman : Haha, that’s funny. Reading that, I am like… I think that person was me!

That resolved the issue when I deployed the captured LVM image to the machine. Unfortunately, when LVM installs, I get these wonky boot options in my BIOS and then it’s like the system has no idea how to boot anymore from SAN. I have discussed it with my team, and we are going to nix LVM next release. It’s just not something we can do this release, as it was something I discovered going through FOG and becoming more intimate with the system at this level.

As far as what /dev/sda is, it’s the data drive. I guess the way this machine was setup - hardware wise - its first drive is the data drive and the second drive is the system drive. Upon discovering this, I asked why, since it only seems to complicate matters. The answer I received was that they tried mounting them different, but Linux always wanted to install them as such - mounting the smaller drive to /dev/sdb instead of /dev/sda. This is kind of where I stepped in and said that doesn’t seem right, can’t we just swap the SATA cables or define it differently when we setup the partitions? It hit an expertise-wall after that, as no one has the domain knowledge for any of this - which is a part of why I am so eager to ask so many questions. Knowing what I know now, I am sure we can handle this ourselves, but we know so little surrounding this that I am cobbling it together while building an insane amount of other tools and tech in parallel.

I had issues copying the drive as EXT4 in the past too. The swap drive would always be mis-aligned I believe, and the system would create a new one and then I’d have fstab issues always. I guess at the end of the day, I don’t feel I have successfully captured and deployed an image, given all the little things. Now I just wonder what I am doing right and doing wrong, given all the successes and failures I have had.

Let me dig up the information you requested. It might be a tomorrow-thing as I am going on 12-hours already and need to get home for misc. life things.

-Dustin

@Wayne-Workman : I would love either/both of them as consultants for even a day, haha. Teach me the ways of your land. This is like… the region of software engineering no one ever wants to touch, and you guys seem to have a great handle on it - which is extremely exciting to see. It’s so hard to resist not just opening a chat and asking a million questions in an effort to absorb their brains, heh.

Alright, updated the FOG Server to RC-14. Rebooting the system and seeing if there is any change by chance.

-Dustin