Posts made by Adam Taylor

I am getting ipxe screens (but had to tweek spanning-tree even for that) becuase iPXE was not waiting long enough for the DHCP request to come through (ipxe waits 15 seconds…with full spanning-tree, it takes from 13-20 seconds to respond). We enabled fast learning for spanning-tree and it now responds in about 9-12 seconds which makes iPXE happy. But once it boots the kernel and starts (for a task or a registration), it does the above with the discover statements and then gives up. We timed it and it is only giving that process 10 sec max and then gives up and the task just hangs with a blinking cursor which slowly moves everything off the screen.

I am the network person on our campus so i can test but we cannot turn off spanning tree (nor would be want…it keeps people from incorrectly connecting network cables and taking down the entire network). I tried turning if straight off for a test and it was happy and all worked. That last “Sending Discover” process however just will not give the network enough time to “turn on”.

Any enterprise type network would have this issue and i can’t see me being the only one here

On .32 though, the PXE part would wait as long as needed and when the kernel booted and it did it’s things, it also waited as long as needed. It just seems to be something with this kernel/tools combo that refuses to wait more then 10 sec…

Also, no, the USB is PCIe 1x based, not USB and are standard intel branded 1G chips.

As far as type, Dell Optiplex 755,760,780,790,990,9020,9030 all show this problem. The less “switches” between the computer and the network core, the better chance of success…the further away…the more likely spanning-tree won’t start fast enough for it because there are more switches in which spanning-tree must calculate before allowing traffic on that port.

Does that help…lol

We found out the main issue. The kernel switch alieavated it some but the issue remains.

Spanning-tree on the network here is interfering with DHCP in FOG. It’s not allowing the port up fast enough for the latest kernel/tools and dies at discovery.

Can the timeout please be lengthened for the DHCP discover requests in the latest tool? Is there any way that i can set it…can you point me where to go?

Thanks,

Adam

Well…i found the issue.

When i updated FOG from the SVN to fix the resize partition issue, it installed a new kernel also. This kernel seems to be the source of the issue here. I reverted back to the original 1.2.0 package kernel and now it is able to boot correctly.

What was changed between the 1.2.0 default kernel and then current SVN kernel?

Thanks,

Adam

Hey guys,

I am having a problem where some machines are not receiving dhcp address within the allowed time once the kernel boots and it tries to do a task.

PXE boot get a lease and starts iPXE (gives DHCP enough time)
iPXE then gets a lease and loads the correct action (gives DHCP enough time)
The kernel starts, abunch of info goes by and then the following happens in exactly 10 seconds:

Starting network…
udhcpc (v1.22.1) started
Sending discover…
Sending discover…
Sending discover…
No lease, failing
ssh-keygen…etc, etc, etc

Doesn’t give the DHCP enough time!

Is there a way to increase the timeout on the dhcp requests? Our server runs the whole campus, wireless, etc… It always responds…just never within the 10 seconds that it is given in fog on this step. If the timeout was 20 seconds, I’m pretty sure this issue would go away.

Any thoughts?

Adam

I was wondering about that. We saw the start boundry shift from 63 to 2048 and figured it was something with that but wasn’t sure how.

I’m willing to give SVN a shot. This is a feature we have been really wanting to use. Got a lot of people ready to upload new resizable images

Thanks for the help!

Adam

All of our images are from .32 but i am not trying to “re-upload” to an existing image. I’m trying to create a new one for the resize feature.

The thing is, I created a brand new image entry for the resizable feature and uploaded off our master machine to FOG. When i try to deploy that image, that’s where the problem happens. Here is the process i have tried.

.32 non-resizable image sent to dell 755 master
Create new 1.2.0 resizable image in FOG
Upload Dell 755 master to 1.2.0 resizable image
Once finished, download 1.2.0 resizable image to other Dell 755s
Not one of them will boot with the issue above.

We went back and fourth an tried a non-resizable 1.2.0 image and it works fine. It’s just when downloading the resizable image does it break something.

Adam

GPT fdisk (gdisk) version 0.8.6

Partition table scan:
MBR: MBR only
BSD: not present
APM: not present
GPT: not present

---

Found invalid GPT and valid MBR; converting MBR to GPT format.

---

Disk /dev/sda: 156250000 sectors, 74.6GiB
Logical sector size: 512 bytes
Disk identifier (GUID): FB90AD12-7961-4862-A2E3-B10D08EC4769
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 156249966
Partition will be aligned on 1-sector boundaries
Total free space is 17871 sectors (8.7 MiB)

Number Start (sector) End (sector) Size Code Name
1 63 156232124 74.5 GiB 0700 Microsoft basic data
[root@10 /]# _

Hey All,

We have just finished migrating to 1.2.0 and everything is working well except for one issue.

On any image we attempt to pull (windows 7 is what we have tested with), We create an image (single disk resizable) and upload the image and it uses PartClone and it uploads the image without any error messages. However, when we deploy the image…it sends it, says “done” for all steps and then “task complete”. The system then boots and hangs with “cmain()…” If you press F12 and tell it to boot manually from the SATA drive…black screen…nothing…will not boot at all. If we enter debug mode and mount the partition however, everything is there.

As far as we can tell, the bootloader/mbr is getting hosed with a resizable disk.

I’m just double checking as to if resizable is now working in FOG. I know it didn’t work in version .32 with 7 but i thought that it was working in this version.

Thanks,

Adam

Hello all,

I have been using FOG now where i work and we are running into a usage problem in the fact that multicast is a crap shoot and we have about ~600 machines to image in a two week time frame before the begining of each semister. We have started to run over each other in the queue department and we really needed more queue space. So we set up a Storage Node on a seperate box.

Our config is as follows:

Storage Group ‘default’ has storage node ‘Default’ on the main FOG server and set to Master

“New” Storage Group ‘Classrooms’ has storage node ‘Classroom Storage’ on the Storage Node and not Master

We basically want 10 queue spots for the ‘Campus’ and 10 queue spots for ‘Classrooms’ with one storage node for ‘Campus’ and one storage node for ‘Classrooms’.

We then copied just the classrooms images from the ‘Default’ storage node loation to the ‘Classroom Storage’ /images folder on the new Storage Node box.

Now, all that worked correctly as the classrooms pulled from the new Storage Node and the rest of the campus pulled from the Default node. 10 queue spots for ‘Default’ group and 10 queue spots for the ‘Classroom’ group.

The problem arose however when attempting to upload a client into the new Storage Node to update the image on it. When i try to queue the task i get “Create task failed. Unable to located master node from storage group”.

So my question is this. Do you have to have a ‘Master’ node selected per Storage group or per complete FOG install? I’m just confused as i can’t seem to find a clear answer on the fog wiki/fourms with a setup like mine. I don’t want the two storage nodes to replicate because the ‘Default’ node/group has 3.8Tb and the ‘Classroom’ node/group only has about 200Gb of storage space.

I’m hoping i just have to check the master box for the ‘Classroom’ storage node and that will fix my problem but i figure i would throw it out here before i break something or end of replicating something and wiping our images out.

Thanks in advance!

Adam