Posts made by mkstreet

Ooops. Shame on me. I spoke too soon. Neither value of Sanboot nor Grub for EXIT TO HARD DRIVE TYPE works.

However, I did get it to work if I choose NO MENU on that same iPXE boot menu configuration page… hmmm???

Sorry it took so long. We’ve been on new year’s holiday here for a couple weeks. But this week its blazing hot – like 40+ degrees – so we all want to stay inside with aircon and work.

Thanks for your reply. Uncle Frank has pointed out ProxyDHCP to me… I will look into that.

Thanks. I will use the “Hidden Menu” option.

In the past, we just resolved this through user training. When we weren’t running FOG (99.9% of the time), users just knew to hit ESC during the client BIOS search for PXE…and then they’d boot into some Pacific Northwest USA O/S. Even if they didn’t hit ESC, then after about 30 seconds it would give-up and go to the local HDD to boot.

That fixed it, thanks. There are only two options, sanboot and grub. Grub worked.

Sorry for the delay… here is the tracert.

I believe the configuration is like this…

my pc (192.168.1.xxx) --> our gateway (192.168.1.1) --------> long cable ----> ISP’s box (1.179.130.137)

That 1.179.130.137 is the first box, our connection, at the ISP’s site.

[url=“/_imported_xf_attachments/1/1901_tracert.jpg?:”]tracert.jpg[/url]

I know this is probably the opposite of what everyone else asks for and wants… but here is the scenario.

Before:
I was using Fog V0.3x on Ubuntu 12.xx which was on a dual-boot box. This box was only booted into Ubuntu when we wanted to use Fog. Otherwise it was turned off or booted into the other, dual-boot, O/S. In effect then, Fog was only running when I was actively, explicitly, using Fog.

Now:
I’m trying to migrate to Fog V1.2.0 on Ubuntu 14.xx. This box is not dual-boot, and we use it for other things besides Fog, so it is always booted in Ubuntu and “on”. The problem is, when this box is powered on, all the computer lab computers see it on the network and then they will hook to the PXE menu when they are starting up. I don’t want ordinary users to get to that menu etc. So, is there a way I can explicitly shutdown Fog and/or tell Fog not to automatically startup when that Ubuntu box boots? I only want Fog to run when I am explicitly using Fog…and other times, I don’t want it running.

Thanks

I am not sure I am putting this in the correct forum, so I apologize if I have placed this incorrectly.

I’ve just gone to Fog V1.2.0 and I haven’t deployed yet to the whole lab.
I’ve built my one Windows 7 machine that I will upload to Fog to be my master image for the lab.

I’ve noticed the following situation:

1. If the client PC starts to boot, I can hit the escape key and the BIOS will stop looking for PXE. It will then boot as normal into Windows 7 from the HDD. All good and happy.

2. If Fog is running and I don’t press escape for BIOS to exit its PXE boot attempt, then the Fog PXE menu comes up. The first option is boot from the hard disk and there is a countdown timer until it takes that default action. If I just wait and let the timer run out, the PXE menu gets cleared off the screen and it goes to black. The cursor stays in the upper left hand corner of the screen and blinks. And nothing further happens, ever. No Windows startup, no error. End of the line.

3. No, I haven’t manually chosen option 1 from the PXE menu to see if manually choosing menu option 1 (boot from HDD) has a different effect than letting the countdown timer run out.

So, I’m not sure what to do to investigate this or resolve it.

Thanks much in advance!

[quote=“Wayne Workman, post: 44051, member: 28155”]I think that Uncle Frank is planning on helping you configure your router & switches to block their DHCP altogether. It’s easily doable. Then, you can just set your own up (or let FOG handle it).

Also, you can upgrade from one SVN revision to another without any issues. I do it sometimes at my work.

Also, one more thing… Just want to see how far away your DHCP server is; out of pure curiosity…
[CODE]tracert 1.179.130.137[/CODE]
That will tell you how many routers are between your host & the DHCP server.[/quote]

Hi Wayne,

I will run the tracert when I get back to the office in the morning, but I can pretty much tell you from memory what it will say.
It’s like this… the PC on my desk (for example) is 192.168.1.32.
Our LAN has a router box at 192.168.1.1 and that is local to me, though I cannot really do anything or affect it.
192.168.1.1 connects directly to 1.179.130.137 which is at the ISP’s central office for our area.

[quote=“Uncle Frank, post: 44034, member: 28116”]Well, that’s a whole new story but would you be interested to get rid of this dependency from your ISP? I don’t say that you should change your ISP but you could do DHCP yourself (using the exact same addresses) and ignore the external DHCP traffic completely. Feel free to start a conversation on this with me and we should be able to set this up for you…[/quote]

Tom, the SVN version seems to be working. I haven’t done a truly scientific analysis, but I think we are consistently not having the problem. The few times it has blown past to Windows I think are due to a loose or bad Ethernet cable. If I remain on this SVN version, will I be cut off (orphaned) from regular product updates to Fog?

Uncle Frank, I am interested in the idea of running my own DHCP. From my perspective, I wouldn’t feel like I needed to use the exact same IP addresses, unless that is a requirement for your plan? I wouldn’t be able to shut down the ISP’s DHCP. So, whatever we did would have to be something I could completely affect / setup / configure from my side, on my own. The ISP is staff and service are worthless, at best.

[quote=“Wayne Workman, post: 44027, member: 28155”]Actually, I read further into this thread (should have from the start)…

Why would an ISP control your internal DHCP? Are you [B]sure[/B]?

Or, is it just the home office that is running DHCP?

On a windows client, you can find out exactly where DHCP is coming from:

[CODE]ipconfig /all[/CODE]

There is a line item just for the DHCP server:

[IMG]http://i.stack.imgur.com/5ikMH.jpg[/IMG]

You can then take that IP and do a reverse lookup to give you a [U]name[/U].

[CODE]nslookup x.x.x.x[/CODE]

Sample output:

[IMG]http://files.cyberciti.biz/uploads/faq/2010/12/windows-nslookup-reverse-lookup.png[/IMG][/quote]

Hi Wayne,

My DHCP is run at the ISP’s site and under their control. Yes, I am sure. I know it seems odd and strange. It is.
You have no idea how much I don’t like this. Every time our connection to the ISP goes down (which is often in a third world country), I can’t even print on a printer on my LAN because the routing can’t be figured out anymore.

Per your suggestion, I have done the ipconfig and so forth.

The address shown for the DHCP is not on my network. It is the ISP’s domain. Really, it is.

Screen prints here:
[ATTACH=full]1790[/ATTACH]

[url=“/_imported_xf_attachments/1/1790_dhcp info.jpg?:”]dhcp info.jpg[/url]

[quote=“Tom Elliott, post: 43969, member: 7271”]If you could be so willing, maybe svn/trunk of fog will work? In 1.2.0 and prior I had iPXE always re initialize to get dhcp. I learned how to get Ipxe to use the PXE requested dhcp which should keep the reinitialization down to when it’s actually needed vs every time.[/quote]
Hello. Sure, I am willing to try that. How do I set about doing that?

[quote=“Uncle Frank, post: 43959, member: 28116”]Would you be able to record this with a camera and re-play it in slow motion (or pause/play through) to get to see the error message?

It’s very interesting that with internet connection being hooked up still all clients seam to load iPXE because the DHCP server had to be involved to make this work already! Maybe it’s because the local FOG DHCP server is faster in that very first step…

To give you a little more insight on how this works (and what might be different in FOG 1.2.0):
[LIST]
[]PC boots up
[]BIOS is configured to boot from network so it sends a DHCP request (broadcast)
[]DHCP request is answered (including options for ‘next-server’ and ‘filename’)
[]PC loads boot image from tftp://<next-server>/<filename> (e.g. tftp://192.168.1.1/undionly.ipxe)
[]iPXE boot image is loaded and executed on the PC
[]iPXE sends another DHCP request to get an IP address (before being able to load things via HTTP, TFTP or other protocols)
[*]…
[/LIST]
I guess this is where things go wrong from time to time… In FOG 0.32 pxelinux was used instead of iPXE. As far as I could find out pxelinux does not request an IP from the DHCP server (because it is less capable of loading things).

Not sure if this helps!?[/quote]

Your description sounds spot-on.
First, I agree that my FOG DHCP is likely faster in that first step. The FOG server is on the same router as the PC’s I want to load. Whereas the “real” DHCP is offsite, several kilometers away.

Second, I agree that the “iPXE” sending another (second) DHCP request to load things via HTTP is where things are going wrong. This would be new behavior with Fog 1.2.0, over Fog 0.32, as you noted.

I did get a screen shot of what happens when it loads, though the image appears a little jumbled, I have attached that frame here. What would follow this frame would be booting Windows from the local HDD.
I had to do this twice when making the video. The first time the Fog DHCP was “fast enough” on both DHCP requests and it went to the PXE menu. The second attempt is what led to the opportunity to capture this screen shot.

Um… so… what are my options to fix this situation?

[url=“/_imported_xf_attachments/1/1789_ipxe error.png?:”]ipxe error.png[/url]

What I mean is…I think the PXE boot sequence has changed under Fog 1.2.0 such that the DHCP has a bigger role now.
This is different than Fog 0.32. The only thing that has changed in the picture is attempting to upgrade from Fog 0.32 to Fog 1.2.0.

Unfortunately, in our network, DHCP has always been run by a server at the ISP’s office. This has always been the case.
I guess technically that is still our private network, logically speaking, but it is offsite and unmanaged (at least by us).

I don’t have any control over the other DHCP (though you have no idea how much I wish I did!).

I’m not sure how to block the DHCP messages… suggestions?

This must be something that is working very different under Fog 1.2.0? I didn’t really have any problems like this with Fog 0.32.

I must be having the same or similar problem with DHCP. I’m not exactly sure how to fix it the best way.

At first, when I booted, the clients would find DHCP and load iPXE. However, after that load was done, there was about a 50-50 chance that it will go to the Fog PXE menu or an error message would flash by and it boots from the clients local disk.

After reading this thread, I unplugged the lab from the external (Internet) connection so that the Fog server and clients are all isolated together now on the LAN. After that, the problem disappears and the clients consistently get to the PXE menu.

In my environment, I don’t control the “real” DHCP server. It runs externally at the ISP office. If this seems bizarre to you, then you feel the same as me. But that doesn’t change the fact that I cannot affect the “real” DHCP server’s settings.

Is the answer changing the Fog settings to say that the Fog server is the only DHCP server?

This won’t really work very well to have the Lab cut off from the Internet while loading. Because some machines I need to load are wired outside that LAN and I cannot isolate them.

Thanks!

[quote=“Bcundiff, post: 31717, member: 22232”]This is where sysprep can be useful-- we use a master image with a ~40GB Windows install partition and then use ExtendOSPartiiton in the answer file to extend the C:\ drive to fill the remaining space in whatever drive the image is deployed to. The same answer file can also be used to make partitions, but that seems a bit riskier.
Sysprep’s generalize flag could also help with other hardware issues-- I’ve spent a few months working with Fog 0.32, Ubuntu 12.04, and W7 Pro x64 clients, and I’ve been able to get away without sysprep on occasion while testing, but, in my experience, sysprep /generalize really helped us deal with varying hardware, including things as trivial as getting an image from a 120GB drive to a 128GB drive.[/quote]

Hi, and thanks for your input.

I started to “play” with creating an image and sysprep last week.

I followed these instructions:
[url]http://fogproject.org/forum/threads/windows-7-deployment-fog-sad2-driver-tool.380/[/url]

and did this on a virtual box.

It went fine until “Step 8” (Drivers- SAD2). I did the suggestion at the end of Step 8 which says “you might want to try the tool out manually”. I did this and it updated a lot of drivers in the image on the virtual box. When it was all done, my network adapter was gone (i.e. without a driver) and several other critical path components too. I didn’t have more time to play with this, so I wiped it out and got a fresh image.

Do you follow these same procedures? Has this situation with drivers ever happened to you?

[quote=“Tom Elliott, post: 31064, member: 7271”]Same is is respective. Many times, drives are not Identical from one make or model. For example, a Seagate 80GB Hard drive and a Western Digital 80GB Hard Drive may not be of the “exact” same size. I’m not saying this is or isn’t the case for your situation, and I don’t know exactly what’s going on.

I only intended to give you information, not tell you your methods were wrong or anything.

FOG 0.32 had issues with non-initialized Drives in the past, and possibly still does under 1.x.x though I’ve made many things to try to thwart that.[/quote]

I understand, and thanks for your answers and also the efforts on 1.x.x.

I think I was kind of spoiled with Fog in my first experience of it, two months ago. At that time, we used it to deploy to 35 machines which were purchased together for a computer lab. So, they are 100% the same. Once we got Fog setup, the issues with those were minimal.

Now, because of the success with those 35 in that lab, we’ve been tapped to work that Fog magic with the library and resource rooms, where we have a more rag tag situation of 3 different hardware configurations, purchased at various times.

So now when things happen – like this HDD deploy issue mentioned here – we don’t know if we are doing something wrong, or what the cause of the difficulty is because the lab deploy was so smooth and easy.

[quote=“Tom Elliott, post: 30893, member: 7271”]
This is wrong. The mbr file contains the Partitioning layout. In Multi-part (single or all) disk images, the MBR is backed up with the image. It is this MBR that get’s written to the hard-drive. The MBR contains the partitioning layout, and as such, the specified HDD Partition Sizes, this is where the image “fails” because the Partition is larger than the disk can handle. If the drive is the same or larger size as what the partitions are based on, things run fine, if the drive is smaller, it doesn’t know how to deal with the data.
[/quote]

FYI. I had this situation again on Friday. A PC with the same size HDD as the image was created with… I tried to deploy and it stopped right away. It tried to reboot and wouldn’t saying “missing operating system”. So something was attempted and erased something important. I then had to re-PXE boot in deploy-debug. I used fdisk to setup the partitions exactly the same as the machine the image was made on, typed FOG and the deploy happened without any further complaints or issues.

[quote=“Matt Harding, post: 8912, member: 1207”]If anyone is interested, I’ve put together a snapin to change the resolution on a PC. It uses 12noon’s Display Changer which is free for personal and educational use. I’m happy to share the information with anyone needing a windows 7 solution.[/quote]

I am interested in this snap-in. I am using Fog v.32.

How can I get this?