Posts made by Jamie Rozek

No problem, you guys helped me quite a bit here, so now it’s my turn!

Creating the answer file for Sysprep is really not that time-consuming. I could send you a sample of mine if you want.

[quote=“user 1111122222, post: 29316, member: 24492”]Thanks to all of you for helping me out.
I have to disagree with the person who said SYSPREP does not mess with activation. It certainly does. when you generalize, it forces you through the OOBE (out of box experience) and you have to put a key in again unless you have an OEM liscense. Granted, you can create an answer file to put that number in, but I don’t want to mess with that.
Furthermore, While I do have the OEM license number off the bottom of the machine, I don’t have OEM media with which to install. I have the Volume licensing media with our campus site license agreement. OEM numbers do not work in volume media and Vice-Versa

As I wrote that post yesterday, I was waiting for a RAW image upload to finish.
Now that is has completed I pushed it back to the client computer and it works exactly as I want it to.
NO SYSPREP required. No changes to the BIOS that I would have to make on 900 laptops. Something must be different there.
I’ll just use RAW until FOG supports UEFI
The upload of the image takes 5 hours, but the download is reasonable at 45 minutes.
I can live with that.
Thanks again for all of your input.
I am very grateful.[/quote]

Got it to work after researching things you’ve placed in the forums and what not. Here is the run down:

1. Disable Secure Boot
2. Enable the Legacy Boot Option (You may have an option in Advanced Boot Options to Enable Legacy ROMS. You want to check this, as well to allow the legacy PXE to appear)
3. Restart and register the machine in Fog.
4. Create the upload task in the Web GUI.
5. Restart and upload your image.
6. On the machines to be imaged, repeat steps 1-3.
7. Create the download task in the Web GUI, if you aren’t using Capone.
8. Restart the machines and download the image.
9. Re-enable Secure Boot. (You will probably have to disable legacy boot option and legacy ROMS in order to do this.)
10. Reboot, BAM! It’s been FOGGED!

As SuP3R_Ch1cKeN said, if you have an OEM license you should not have this problem. I HAVE in some instances had situations where my OEM has asked to be REACTIVATED, which is a quick and painless process. This can happen if there is a major hardware difference, etc.

Alright, Tom—I followed your instructions:
(This is for a test machine—so I’m uploading the image with one drive, removing it, and downloading the image with a clean drive on the same machine.)
-I disabled SecureBoot, leaving UEFI alone.
-Uploaded the image
-Swapped the hard drive.
-Downloaded the image.
-Enabled SecureBoot

I get the “Windows needs to be repaired” screen, with error 0xC0000225.
“A required file is missing or contains errors.”
It points to the \windows\system32\winload.efi file.

Alright, so here’s the story:

We had that rogue DHCP server. It was our secondary DC, which was VLAN-d to a network that no one else could access anyway, so it really wasn’t causing problems. I disconnected the NIC, anyway.

I was just ignoring the comments about portfast, because myself and the other network engineer were under the impression it was already enabled on our switches. Ignorance will be the death of all IT.
Portfast was NOT enabled. We spent about an hour discussing WHY Cisco would not enable this by default, since the default setting will ignore any port that is in switchport-access trunk mode to begin with.

Whatever. That puppy grabbed a DHCP reservation right away, and brought the Fog Menu up less than 5 seconds later.

It’s now imaging, and hopefully we will have it all done testing, etc…by the time our new laptops get here so we can just image and deploy.

Thanks, all! You’re great!

Welp… I do have some DHCP issues, it appears. One of my DC’s is showing as both authorized and “rogue.” I’m going to have to figure out what’s going on there. We had set this up at one point to be a DHCP server for a VLAN that would be for virtual servers, which never came to fruition. I’m wondering if something from that is mucking things up somewhere.

So is there a solution you can think of for this? I could make the Fog server a DHCP server, but I don’t want to complicate things with the other DHCP servers on the network.

Here we go. Here’s video of what I’m seeing.

[url]https://drive.google.com/file/d/0B3UE8CMNi1taMGJ3Ymdqcks4WHc/edit?usp=sharing[/url]

Need, the problem is that I am currently booting in Legacy, and it is still doing it. I’m going to try to get some video of the problem.

[quote=“Tom Elliott, post: 28909, member: 7271”]Are you running 1.1.0 or 1.0.1?[/quote]

1.1.0

Alright, I prepped the image and stuff, turned off Secure Boot, PXE booted with legacy. However, now i’m having that issue that some others have been happening where it gets an IP address, and then gets an error which flashes too quickly to see before it reboots.
I know these 5540’s have been problematic devices, however I did have the thing booting and loading the fog image at one point. (It was previous to installing 1.1.0) Is there any changes in 1.1.0 that could be causing this issue?

Good morning, all.

So, here’s the situation:

I know that UEFI currently does not work. I know there are workarounds. I’ve seen stuff using boot disks, CloneZilla, etc, etc…however—this stuff is old (Pre-1.0.0), so a lot of it doesn’t work when trying it out.

Does anyone have a workaround for UEFI that will work without having to use legacy boot?

We are getting a bunch of Dell E5540’s in this week which will be Windows 8.1 with UEFI. Since these will be going to mobile users, we need to be able to image them quickly. We would like to keep the UEFI if at all possible.

Thanks!

I’ve now created and deployed a few images using 13.10 with 1.1.0. It is working very well. Thank you, everyone–for your help!

Now, I need to start a new thread about another problem…

[quote=“Junkhacker, post: 28515, member: 21583”]btw, the pxe files used for 1.0.1 and 1.1.0 are identical in functionality, they just use slightly different code to do it. if one works for you and another doesn’t, there is no need to do any kind of “downgrade,” just swap the file for the one that works. that said, i recommend you try the undionly.kpxe file currently in the svn trunk release if you are having issues.[/quote]

I am doing the boot using the undionly. I’ve been using that since updating to 1.0.1, and that gets me a lot more hits than I was getting with the pxelinux method. I’m still doing some testing with the 13.10 and 1.1.0. So far it seems to be working quite well. I just have a few little issues that I’m trying to work out, which are most likely my fault.
I’m going to work on this throughout the day, and hopefully be able to close out this thread a bit later.

[quote=“Junkhacker, post: 28502, member: 21583”]unfortunately, any failure in pxe booting typically means no way of logging anything to file or even to screen. often, the best you can hope for is hitting the “pause/break” key at the right moment.[/quote]

That’s what I figured. Unfortunately, I haven’t a quick enough “draw” when it comes to that.

Darn.[quote=“Tom Elliott, post: 28471, member: 7271”]If you want, when you upgraded to svn trunk (1.1.0) I’ve moved the plugins location from management/plugins to lib/plugins.

What this meant, is I had to forcibly make sure the systems updated to …/lib/plugins in the FOG_PLUGINSYS_DIR of FOG Configuration->FOG Settings->Plugin System. When you retrograded to 1.0.1, it did not make this dir change back for you. To have recovered, you could’ve just changed the field to point at ./plugins Just so you know I wasn’t leaving you in the dust or anything.[/quote]

Darn. Well, that’s okay. The more times I install linux, the more understanding I “get” of it, so that’s more than fine. If I hadn’t been lazy and stupid, I should have thought to look and see if that directory was still there. Now at least I know what to look for.

I’m going to try the 13.10 with 1.1.0 and see what happens. We have a pretty wide mix of machines — (HP 2540P, 2570P, 8470P, Z400, 6005, 6005 small, and are about to get in some Dell E5540’s.) so, if 1.1.0 goes back to throwing whatever error I can’t see, at least I’ll know what to do when I downgrade to 1.0.1.

Since I’m not overly versed on PXE and the process—is there a log somewhere that I can check to see what is going on when these things are booting? I would guess there’s nothing in the Apache logs. I would like to at least grab a PXE error code or something that I can send your way, in case this issue comes up again somewhere.

It’s most likely Operator error…

Thanks guys, have a great day. i’ll let you know how this works out.

I didn’t have any problems running under 12.04 previously. It wasn’t until I upgraded to 1.1.0 that I had PXE boot issues. I’m not even positive it is TFTP at this point, because it displays the error quicker than I can read it.
Another developer suggested 13.04 or 13.10 with the latest release, so I’m going to try that to see if it resolves the issues. I’ve completely uninstalled Fog at this point, and working on the OS upgrade.

I’m going to try to re-install my server using Ubuntu 13.10 along with Fog 1.1.0. I’m currently running it on 12.04, which from browsing the forums appears to have some issues with TFTP.
I’ll report back when I’ve done this.

I’m sorry to report that after reinstalling 1.1.0 – it is back to doing the same thing. It begins the PXE boot process, but the errors out and boots to the operating system.
It does so quickly, and I am unable to get the error code. However, previously it was throwing DHCP errors under the old version, which after looping through a few times, it would load.