Posts made by RLane

@fredlwal I’d suggest doing that as that’s a known workaround which takes about 5 minutes to set up.

@fredlwal Have you tried to download the iPXE ISO and use “UNetbootin” to put it on a flash drive like suggested? I tried on an older MacBook Pro using svn 3551 and it worked fine (booting anyway, didn’t have a Mac image).

I had this issue as well when I upgraded my 1.2.0 machine to r3551, however, when I did a fresh install of r3551 by itself, it worked fine. Perhaps a funky issue with permissions when it upgrades from one revision to another? Just a hunch…

@DevinR For what it’s worth, I’ve had r3540 running since it’s been out. I’ve taken images, imaged devices, etc. with no trouble. A hair quicker too than 1.2.0 over my 10/100 clients.

The biggest thing I’m worried about and I know @Wayne-Workman said it should be no problem, is installing client 0.8.4 on my images (using r3540) and relying on the automatic update to patch them when 1.3.0 is finalized.

@MRCUR If you’re rebuilding every image that you have (like I do each summer) for specific labs/buildings, I would suggest rebuilding it fresh. Do you have to? No. But it’s easy enough to do that.

If not, I would suggest setting BitSync up to your ‘old’ 1.1.2 machine and have it update that way.

@Wayne-Workman Recommendation taken - I’ll start looking around tomorrow. I could careless which flavor of Linux I’m using - I’m going for longevity and stability. I’m more than comfortable enough with a CLI based OS if I have to use it. There’s plenty of documentation out there on how to install FOG on nearly every distro. Thanks again for the suggestions + clarification!

@Wayne-Workman said:

@RLane That is more clear.

Images built with the current FOG Trunk version will work with the future FOG 1.3.0.

The new fog client is being developed by @Jbob and he’s integrated automatic updating for the new client on host machines. Meaning, the client should always be able to check with your FOG server for a newer version, and if there is one, grab it & install it, removing the old one.

Also, I’m positive that Jbob would like some more beta testers… I missed it this summer because it didn’t work for me when I was building the images for this summer.

Plus, there are some UI changes in FOG Trunk, it’s got a different look, and major performance improvements, and more features. Things like setting time zone and adding items to the boot menu via the UI, vs the old 1.2.0 way of editing PHP files (yuck). It’d always be beneficial to test things out while they are in beta, and see if it works in your environment, and let the developers know BEFORE 1.3.0 is released!!

Also, you can upgrade the FOG Trunk build to 1.3.0 when it’s released - that’s easy.

Exactly what I was looking to hear, thanks a lot. To save my sanity further down the road, I’ll start fresh. Ubuntu 14.04 still okay or is the general recommendation still 12.02? A past coworker of mine auto-updated our current FOG box from 12.02 to 14.04 and made me panic before I found I had to change the /fog/ directory… phew.

@Wayne-Workman said:

I’m actually in the process of building a WiKi article for “best practices with FOG”.

But at the moment, I’m tackling a wiki article for adding ISOs to the fog boot menu… and I’ve sorta had a small disaster with the servers at home… and I’m crazy busy at work during the summers…

But, it’ll get done…

A lot of the best practices stuff have to do with meaningful naming conventions, meaningful descriptions, security, automated backup procedures using Cron, and every-day usage of FOG.

Ultimately though, you should do things in a way that not only makes sense to you, but will make sense to any person that comes in behind you. Making things crazy complex with abbreviated names and no descriptions and all this other jazz for “Job Security” would give me a reason to look for reasons to get rid of you (if I were your boss)… and it’s lame to make things overly complex anyways.

Perhaps I wasn’t clear enough (and forgive me if you understood me and I’m too exhausted to make sense of it)

Basically, I’ve used FOG for imaging for last couple of years. I’m a proficient user, everything is documented, maintained, updated, etc. My question though is:

Since summer is usually the time we (school sys/network admins) have time to do things, should I build a new Ubuntu VM to run a developmental version of FOG on?

Normally I would go ahead with it, however, with the new client - I’m not sure whether or not it’ll be changed from it’s current state to the final release when that comes. Basically, I don’t want to have to do something similar to this again and build images on a developmental version if I’d have to move off it to the stable release.

Hopefully that makes a bit more sense

Hi -

So I’ve been a member here for a long time and been using FOG since 0.32. I love it, love the community and environment. I also appreciate all of the work and effort that the dev’s put into it.

I’ve noticed one of the key organizations that use FOG are those of you in the educational sector. As a network admin, I’m responsible for the imaging of machines over the summer. I do this every year to keep everything fresh and up to date, along with making changes that the teachers request in labs.

Now that summer is approaching (students have a day left here) – what is the ideal setup for FOG?

• I’m running 1.2.0 right now - Ubuntu 14.04

• I am not using any trunk releases

• After reading about the trunk speeds being so much quicker for gig server and gig client imaging, I’m convinced I should upgrade

• The client seems promising and should be available soon – another reason I’m convinced I should upgrade

Obviously Tom already said that the next stable release will be soon, however, should I rebuild my FOG server (export users, client, etc.) and rebuild it fresh and use the trunk builds?

Should I wait until later in the summer for an upcoming stable reason?

I’m curious to see what everyone thinks.

Thanks!

[quote=“Jarli, post: 35121, member: 24756”]A nightly image report of this would be wonderful.

Something I’ve been toying with (idea anyways) is to image a set of machines on a nightly basis, so that any casual employee changes become undone during the nightly restart.

And having my machines grouped, with an email notification of Success / Fail and percentages would be an extremely useful tool.[/quote]

Regarding the first part of your e-mail, there is a much more efficient way of doing this that doesn’t involve imaging. Look into Deep Freeze. It resets any changes made every reboot or logoff.

In previous versions of FOG, there was a limit (10 by default) where when you multicast for active PCs. Now, using 1.1.2, is that setting or default changed? I had a group with 32 computers in a lab and started them today assuming only specified number (figured 10 as default) would start, but all of them started. Sadly I have 10/100 switches to the class rooms and a Gb backbone. Has this changed or am I just missing the setting?

I figured something like this would be displayed when I started my multicast:

[url]http://www.fogproject.org/wiki/images/3/3d/Queue.jpg[/url]

Edit: I guess reading the wiki further states this was only for [I]ten[/I] unicast tasks, but multicast is considered one task itself. Is there a way to break the multicast down into parts other than making a separate group? I don’t know why 32 multicasts would be significantly slower than 8.

After troubleshooting my environment more than I wanted for multicasting problems, what is the configuration to your vlans, multicast on routers, etc?

Maybe I sound ignorant by asking, but what if you actually just tried to use your existing DHCP server? Perhaps adding options 66/67 to a ‘sandbox’ scope or a scope that is easily accessible in your building. This would point to the Proxy DHCP service setup.

Also, I’ve experienced the whole PXE-M0F error if you’re not using the legacy PXE boot option. Would this happen to be a UEFI device? I know we’ve had to revert some of the newer laptops we deploy in our schools because it refuses to PXE boot.

After hours of troubleshooting, I really feel like a moron. We established the problem being a core switch/VLAN issue. Existing VLANs when I inherited the environment had ‘ip multicast-routing’ enabled - right… but when I added new VLANs, consequently the “Server” VLAN, I didn’t re-add ‘ip pim sparse-dense-mode’ and ‘ip cgmp’ commands to get the multicasts on the same broadcast. Disappointing I spent a good week on this but didn’t check it. Thanks Tom for the help – obviously not a FOG issue. Worked fantastic afterwards.

I have upgraded to FOG 1.1.2 and also updated the kernel again. I’m having the same results in the building where multicast works on laptops. Would you happen to have any suggestions? Also, if you would like to look at the logging, please let me know specifically what log you would like and I’ll post it. Thank you

We haven’t had to try any other desktops, yet. I can give it a shot after the long weekend. I did VPN in though to check the switch configurations. The only difference between the working environment in building A verse building B is that I have “[B]mls qos trust dscp” [/B]set on the ports. I highly doubt this has anything to do with it? Also - if you think of something, let me know and I can certainly try it Monday when I’m back to work. I could swing by there this weekend if needed. I’m also using your latest kernel for what it’s worth.[B][/B]

Yep – I first made a multicast group of 5 machines. I rebooted those five, network booted them and they went right into the grey screen. I waited a good 10 minutes and they just sat there. Online, it says they were “in progress” but that’s only because it had technically ‘started’ the process (I’m assuming).

From there, I went ahead and deleted the group. I remade a new group and added just two hosts. Both different hosts, same device types. Again, booted in just fine and sat on the grey screen. (This is the section of the log I C+P)

I ended up having to do a group unicast which was significantly slower obviously for about 80 of them, so I know it worked that way. Multicast would just be nice to speed the process up to avoid congestion. Like you said, really odd. I have no clue why it would work on three laptop models but not a desktop. I figured if anything with all of the eth0 and eth1 wireless/NIC problems we had previously it would be the other way around. I appreciate the effort.

• Restarted multicast services
• Verified UDP status on server, everything looks fine. Permission is fine.
• Rebooted.

Runs great in unicast – I can actually multicast in a different building (connected to the same core) – with laptops. It worked well with 3 different laptop models. HP ProBook 4520s, 30s and 40s and multicast great. It’s just these desktops that hang. Network isn’t blocking any of the UDP packets.

The machines are getting the tasks, but once to the multicast grey screen (same error as my OP), they hang. I did verify that they do have the task and I see that it’s running on the server itself. I tried with a single multicast host, 2, and upwards of 8. All booted into the grey screen and hung.