Posts made by george1421

As @phil-dosi said. You need to add ipxe.efi in the uefi field in pfsense. You did fill out the undionly.kpxe for the bios clients and you did see a bios (legacy mode) computer boot just fine. UEFI based computers will not boot with the bios boot loader (undionly.kpxe). PFSense is smart enough to know which kind of target computer you are booting, and if provided the right information to send.

Also what phil mentioned. You must have captured a uefi windows image to be able to deploy that image to a uefi target computer. You can not mix the image styles. A bios (mbr) image can not be deployed to a uefi computer as well the other way around a uefi image will work only on a uefi target computer.

@ldiorio Thank you for the feedback.

FWIW, the config file you started with is not to older, but is a bit out of date. That explains why there are more changes in your config file than from the FOG 1.5.0 kernel. Also noted that the config file for FOG 1.5.0 is 4.15.2 and from your build 4.15.14. So at this point I don’t know if it is the config file with quite a few changes or the newer kernel that solved your issues. I’m still looking into the changed values to understand if they would have an impact.

It would be interesting if you could take the config file from here: https://github.com/FOGProject/fos/blob/master/configs/kernelx64.config

And run it through the 4.15.14 kernel compile without making any changes to see if it is 4.15.14 that addressed the issue or was it you enabling something else.

@ldiorio Thank you. So the PCI bits are probably what was needed.

Can I get you to do one more thing. This is a multipart request. Not a real pain just a few steps.

1. download and install putty if you don’t have a windows ssh program.
2. That that precision register it in FOG and then schedule a capture or deploy it doesn’t matter (we are not going to do either). But before you hit the schedule task button, select the check box for debug. Then schedule the task.
3. PXE boot the Precision. This will boot you into the debug kernel.
4. After after a few enter key presses you will be dropped to a linux command prompt
5. Key in ip addr show to get the IP address of the FOS engine
6. Key in passwd and give root a password like hello. This is only a password for the current instance of fos. When you reboot everything will reset.
7. Now from putty connect to the FOS engine at the IP address you collected in #5. Login as root and the password you defined in step #6.
8. Now here is what I need. Key in lspci -nn It will spew a bunch of text on the screen.
9. Using the mouse and putty drag across all of that PCI info and past it into a post in this thread. That will tell us what kind of disk controller is in use here.

One thing, looking at the config file you sent, did you start with the FOG config file I linked previously or did you start from scratch?

@ldiorio If you have a google drive just post it there and IM me the link, using FOG IM tool.

Also what hardware did this new kernel fix? I know Dell Precision, but what model?

@ldiorio Interesting and confusing at the same time. Can we get your kernel config file so we can compare it to the FOG standard kernel? Once identified we can get those settings part of the FOG kernel so you won’t need to do that on each fog update.

1. What is the model number of the precision? Laptop or desktop?
2. What version of FOG are you running?

I’ve looked through the clonezilla github site but I can’t yet find their kernel build script to see what options they have enabled.

For clarity the FOG kernel build configs are stored here for v1.5.0: https://github.com/FOGProject/fos/tree/master/configs

@jon-fuentes The disk space error message is an incorrect one. The issue is partclone is not passing enough information back to FOG on why it aborted. The answer is probably sprawled across the partclone screen just above the screen shot you provided. The fog service only can tell that partclone aborted for some reason and the “guess” was the hard disk on the fog server is full. Rerun your imaging again and watch what message partclone displays.

Also you might consider upgrading your version of FOG sooner or later. FOG 1.5.1 is waiting for release so you might want to hold off for a bit to upgrade, but you should upgrade once 1.5.1 there are quite a few disk imaging fixes in 1.4.4 with a handful more in 1.5.1. So you should consider upgrading to make your imaging a bit smoother.

@hullabaloo said in Dell OptiPlex 7050 Hard Drive not Found:

I suspect it’s the undionly.kpxe file that I’m using?

Well that IS what I wanted to know. That is the wrong boot loader for uefi. You need ipxe.efi (or any of the .efi) boot loaders. Change your boot loader and the uefi client should boot.

If you were using a windows 2012 or newer dhcp server or a dhcp server that understood the differences between bios (legacy mode) and uefi it could send the proper boot file name based on the pxe booting client. Then you could dynamically switch between uefi and bios target systems.

@joe-schmitt So fog and/or client did not create this self signed certificate? The server is dedicated to FOG. The concern is mainly around the client stopping top communicate with the FOG server for some unexplained reason. This this is not an issue then I’m good with an expired certificate. I just need to explain it during my audit review.

I also did find I need to disable sslv2, v3 and v1 for compliance too. That doesn’t (shouldn’t) impact fog. Its only an awareness.

@fpausp The description field is required if you want the menu item to show up in the menu.

As long as

kernel tftp://${fog-ip}/os/urbackup/vmlinuz
initrd tftp://${fog-ip}/os/urbackup/initrd.img

Files are located in /tftpboot/os/urbackup/ it should work once you add in the Menu title (description)

@Developers @UIDevelopers That field name (Description) probably needs to be change to “Menu Title” or something to show that its a mandatory field.

As part of our internal audit program we are required to scan all internal hosts using a SIEM tool to look for vulnerabilities.

Here are several that our FOG server triggered. Understand I’m not implying or forcing anything here only raising awareness to the developers.

1. SSL/TLS: Certificate Expired

Risk: High
Application: https
Port: 443
The certificate of the remote service expired on 2017-02-04 23:55:05.
Certificate details:
subject ...:
1.2.840.113549.1.9.1=#726F6F744073687675786173303439,CN=localhost,OU=SomeOrganizationalUnit,O=SomeO
rganization,L=SomeCity,ST=SomeState,C=--
subject alternative names (SAN):
None
issued by .:
1.2.840.113549.1.9.1=#726F6F744073687675786173303439,CN=localhost,OU=SomeOrganizationalUnit,O=SomeO
rganization,L=SomeCity,ST=SomeState,C=--
serial ....: 00A6
valid from : 2016-02-05 23:55:05 UTC
valid until: 2017-02-04 23:55:05 UTC

I assume this is the SSL certificate used to communicate between the FOG server and the clients. I guess from the clients perspective they don’t care or aren’t checking the validity dates of the certificate in use. Should fog have a process to update this self signed certificate? Maybe something to consider for FOG 2.0?

2. http TRACE XSS attack

http TRACE XSS attack
Risk: High
Application: http
Port: 80
Protocol: tcp
Vulnerability Detection Result:
Solution: 
Add the following lines for each virtual host in your configuration file :
   RewriteEngine on
   RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK)
   RewriteRule .* - [F]
See also http://httpd.apache.org/docs/current/de/mod/core.html#traceenable
Solution:
Disable these methods.

I’ve added these rules to the /etc/httpd/conf.d/fog.conf file to change the file to this:

    <Directory /var/www/html/fog/>
        DirectoryIndex index.php index.html index.htm
    </Directory>
    RewriteEngine On

    RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK)
    RewriteRule .* - [F]

    RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f
    RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-d
    RewriteRule ^/(.*)$ /fog/api/index.php [QSA,L]

I’ll know after the next scan if this fix resolved the issue.

The rest of the discovered issues were not related to FOG but system management on the FOG server, such as supporting weak SSL and ssh Ciphers and TCP timestamps. Surprisingly using NFS v3 did not set off a violation alert.

@uwpviolator The setupcomplete.cmd runs outside of UAC as does FOG Snap-ins. Running it interactively you will get a UAC prompt.

Realize there is no magic bullet here. MS is making it harder with each release of MS Windows for third party imaging solutions. Soon, I fear, the only game in town will be SCCM.

@dpotesta50 The scripts should work without modification.

You will need to ensure the driver library is setup correctly on the fog server as well as the reference image, more precisely your unattend.xml file needs to tell windows where to look for the drivers.

And now with Win10 1709 it appears that M$ has broken that documented process. A work around for this new MS (broken) feature is to add the following line to your setupcomplete.cmd file before the reference image is captured.

pnputil.exe /add-driver c:\drivers\*.inf /subdirs /install

@dpotesta50 You can deploy with a snap-in then. I’m not sure I would do it that way, but it can be done.

If you are deploying as a .exe file just add in the silent install command switches to make the driver install without having user interaction.

If you are deploying as a .inf package, you will need to create a snap-in pack with a batch file to run the pnputil command with some structure like this:
pnputil.exe /add-driver %~dp0\*.inf /install

Understand I have not, and probably will not deploy drivers using this method, so YMMV on the utility of this information.

@hullabaloo Ok so my initial reaction is this.

1. You have secure boot turned on still.
2. You are sending a boot loader that is incompatible with uefi.

So tell me, what exactly do you have configured for dhcp options 66 and 67?

What device is your dhcp server?

@dpotesta50 The answer is bit more complex than creating snap-ins. Some drivers are needed for the OS to boot from the winpe environment into the full windows environment (like disk controllers and networks). So somethings need to be “in the tin” as it were, before your sysprep the image.

I do have some tutorials on creating a single reference image and deploying it on multiple hardware. It take some time to setup but you CAN have a single OS deploy to different hardware with the proper drivers installed by FOG during imaging.
ref: https://forums.fogproject.org/topic/11126/using-fog-postinstall-scripts-for-windows-driver-injection-2017-ed

@fpausp Please post a screen shot of the fog configuration page used to create the iPXE menu. Also please post the output of this command. Insert the fog server IP in the proper spot and insert it into a browser of your choice.
http://<fog_server_ip>/fog/service/ipxe/boot.php?mac=00:00:00:00:00:00

This url will display the content of the iPXE menu.

@george1421 On our 7050 purchased in fall of last year (skylake) firmware 1.5.2, fog boots correctly in uefi mode. All I changed in the firmware is was turn off secure boot. FOG boots via iPXE into the iPXE menu and runs the fog compatibility without issue (exception of the disk, which I noted previously). I also have FOS (the linux OS that captures and deploys images on the target computer) on a USB stick. That boots without issue.

Please confirm that you have secure boot disabled. Also where exactly does the uefi boot fail?

Realize because of the tone of your post its hard to respond not like a angry bear protecting its young.

I’m not going to debate the windows / linux which is best either or how much did you really pay for FOG vs Ghost (which Symantec has now destroyed).

I can tell you on the FOG horizon there will be options to install FOG on other operating systems. FOG 2.0 is a complete rewrite of the FOG platform to run inside a Node.js container. Any operating system that supports note.js will be able to run FOG. Yes, this means even MS Windows will be able to be the server for FOG. I have seen the beginnings of FOG 2.0 and it looks great. It has a log way to go to even catch up to where FOG 1.x is today. Realize that FOG 1.x relies on a lot of other open source applications to work. The FOG program is the glue that integrates these other applications into a working imaging tool.

I can also see that Microsoft is making it harder for non-Microsoft imaging tools to function with each update to its windows platform. This is making a lot of companies switch from their current imaging tool to SCCM. In general I can see the market for non-Microosoft imaging tools will start to go away.

There are many ways you (even as a MS Windows only speaker) can contribute to either FOG or other open source projects. Many FOSS groups can use help to do many things. Don’t just take from the FOSS community, at some point you should give back.

[Update]
Thinking about it on the commute into work, it is totally possible for FOG to run under MS Windows. FOG is based on the LAMP stack (Linux, Apache, MySQL, PHP). There is a WAMP standard stack for MS Windows. I have already created a proof of concept for using MS Windows as a FOG storage node. https://forums.fogproject.org/topic/10097/setting-up-a-windows-2012-server-as-a-fog-storage-node Connecting that tutorial with a WAMP stack and a few posix utilities from cygwin and a few ported linux application recompiled for MS Windows and you can too could run FOG under MS Windows.

Now I can’t speak for the Developers here, but I would rather see the developers put their efforts into developing FOG 2.0 over working through the details to port FOG 1.x to the Windows platform, which would now require you to burn a MS Windows license just to install FOG. The point being if you are motivated enough YOU COULD port FOG 1.x to MS Windows with a few hours of effort.

@hullabaloo The target system should boot into FOS, but unable to see the hard drive. I have a 7050 in inventory, I’ll grab it in the AM and confirm it boots with FOG. I have FOG 1.4.4 on my production server, but 1.5.0 should be the same, I have just a bit older kernels on 1.4.4.