Posts made by BedCruncher

I’ve got my system setup to try an get this working, but it’s not finding the boot devices properly I think. Below is my DHCP.conf file. I’ve made the relevant changes to mirror Option 1 in Example 1.

# DHCP Server Configuration file\n#see /usr/share/doc/dhcp*/dhcpd.conf.sample
# This file was created by FOG
#Definition of PXE-specific options
# Code 1: Multicast IP Address of bootfile
# Code 2: UDP Port that client should monitor for MTFTP Responses
# Code 3: UDP Port that MTFTP servers are using to listen for MTFTP requests
# Code 4: Number of seconds a client must listen for activity before trying
#         to start a new MTFTP transfer
# Code 5: Number of seconds a client must listen before trying to restart
#         a MTFTP transfer
option space PXE;
option PXE.mtftp-ip code 1 = ip-address;
option PXE.mtftp-cport code 2 = unsigned integer 16;
option PXE.mtftp-sport code 3 = unsigned integer 16;
option PXE.mtftp-tmout code 4 = unsigned integer 8;
option PXE.mtftp-delay code 5 = unsigned integer 8;
option arch code 93 = unsigned integer 16;
use-host-decl-names on;
ddns-update-style interim;
ignore client-updates;
authoritative;
# Specify subnet of ether device you do NOT want service.
# For systems with two or more ethernet devices.
# subnet 136.165.0.0 netmask 255.255.0.0 {}
subnet 192.168.240.0 netmask 255.255.255.0{
    option subnet-mask 255.255.255.0;
    range dynamic-bootp 192.168.240.10 192.168.240.254;
    default-lease-time 21600;
    max-lease-time 43200;
    #option routers 0.0.0.0
    next-server 192.168.240.10;
    class "UEFI-32-1" {
    match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00006";
    filename "i386-efi/ipxe.efi";
    }

    class "UEFI-32-2" {
    match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00002";
     filename "i386-efi/ipxe.efi";
    }

    class "UEFI-64-1" {
    match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00007";
     filename "ipxe.efi";
    }

    class "UEFI-64-2" {
    match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00008";
    filename "ipxe.efi";
    }

    class "UEFI-64-3" {
    match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00009";
     filename "ipxe.efi";
    }

    class "Legacy" {
    match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00000";
    filename "undionly.kkpxe";
    }

}

I’ve restarted the DHCPD service, and all FOG services. When it tries to boot over ipv4 I get PXE-e18 Server response timeout it then boots to Windows as normal. Please let me know what I am missing as I want to make this work with UEFI if possible and not force myself to change all machines BIOS to legacy just to allow imaging. Thanks in advance.

EDIT: Forgot to mention. It’s Centos 7 and FOG 1.4.4

@Tom-Elliott
As always… thank you for your hard work and dedication. It’s helped me tremendously in many aspects of my D2D work.

@Quazz @Avaryan
I tried it with the windows 10 DART iso and that didn’t work for me. Throws an error. I will try the other method.

@Avaryan
I’m special, ignore the last. Still will wait for you to reply so that I can try this out. Seems extremely helpful.

@Avaryan
I was thinking about adding this to my fog menu as well, can you provide me some links on how you got that built? I’ve got the MDOP downloading now, but help from someone who has conquered that particular beast would be much appreciated.

Thanks

@wciws
Just checking to see if there have been any updates on your end of things?

@wciws
I don’t think FOG Client would mess the actual install part…
FOG CLIENT WITH SYSPREP
that is as long as you did the steps in the wiki.

Here is my auto login part of the unattended.xml file

             <AutoLogon>
                <Password>
                    <Value>REMOVED</Value>
                    <PlainText>false</PlainText>
                </Password>
                <Enabled>true</Enabled>
                <LogonCount>3</LogonCount>
                <Username>Administrator</Username>
            </AutoLogon>

and my Copy Profile line

<CopyProfile>true</CopyProfile>

One way you could introduce the net user command would be to add it to the file SetupComplete.cmd located in c:\windows\setup\scripts (I think that’s the right path) and then do net user administrator password /active:yes
that would allow you to get the password injected if the sysprep route still fights with you.

@wciws
Yeah, always best to remove AV from the presysprep images, it causes too many headaches.

@wciws
I also have the copyprofile flag turned on in my images. I will check into your error and see if I can uncover anything.

@wciws
There is a method out there I have seen to get around the sysprep limit. I don’t recall off the top of my head where I saw that, but I know it is out there. One thing I would suggest at least in my case is taking a “PreSysprep” image and a “PostSysprep” image. That way I can always redeploy the “Pre” image, update, then recapture. I then do a “Post” image once I start the sysprep phase so that I can push it out to all clients I have registered.

I have done things both ways(audit mode and normal install). I don’t see a clear advantage of either.

I also recently started doing the audit mode scenario and remember seeing that when updating that way, you need to choose the “Enter Audit Mode” on the sysprep popup and then choose “Quit” so that windows updates will successfully apply.

Below are links to some articles that I used to help guide me. I picked and chose the parts to apply to my scenario, but otherwise they are full of useful info.

Audit Mode 1
Sysprep 1

@wciws @KnightRaven

When you were applying the updates, how did you do that exactly? Did you first go the route of installing windows and then sysprep the machine, or did you go the audit mode route? Let me know and I will offer help in either case if I am able.

@george1421 @Wayne-Workman

I have tested using the Partclone Zstd image compression method on an image under Centos 7 and was able to get it working with one small thing. I had to download ZSTD as it wasn’t native to the base OS.

yum install zstd -y

I was then able to extract and mount the image using the commands

touch /tmp/d1p2_extracted.img
cat d1p2.img | zstd -dcf | partclone.restore -C -s - -O /tmp/d1p2_extracted.img
mount -t ntfs-3g /tmp/d1p2_extracted.img /mnt/

I also added the -f flag to zstd to force it. I don’t think this is necessary, but as a testing scenario it worked.

@george1421

I will look into modifying those instructions to work with the new compression method. Not sure when I will get that accomplished, but I am sure I can get it done within the next little bit. Thanks for letting me know.

@Wayne-Workman

In my case I actually did the following so that I didn’t mess up the working directory or it’s file contents

touch /tmp/d1p2_extracted.img
cat d1p2.img | pigz -d -c | partclone.restore -C -s - -O /tmp/d1p2_extracted.img
mount -t ntfs-3g /tmp/d1p2_extracted.img /mnt

just dumped it to /tmp so that it would be deleted during normal system processes and not fill up my images directory with double images.

@Sebastian-Roth @Wayne-Workman @Junkhacker @george1421 @x23piracy @pr1m0

Sorry to dredge up an old topic, but I went back and tried to redo the steps that I had originally done to restore an image using purely the server. While the steps I listed will work, I did originally mention it, but didn’t specifically include the steps to restore the image on the server. Here is the current working 100% steps to make this all work properly.

Without the touch command below it will error out. So otherwise this works as expected.

cd /images/IMAGENAME/
touch d1p2_extracted.img
cat d1p2.img | pigz -d -c | partclone.restore -C -s - -O d1p2_extracted.img
mount -t ntfs-3g d1p2_extracted.img /mnt

@george1421 @Wayne-Workman
Hey everyone, sorry about not getting back till now. been a hectic few days. I will be glad to help test this as I am always glad to help this project. It’s been good to me over the years. Always useful, helpful, and just simply powerful. Will report back my success/failures.

@george1421
Thanks for that link. Looking over it seems it should be still applicable with 1.3.2. I will try to get it working this evening or tomorrow. Hopefully it still works, but if not, then I will try to play with it as an intellectual exercise.

Server

• FOG Version: 1.3.2
• OS: Raspian
• Hardware: Raspberry Pi 2

Description

I know it’s not technically supported, but I was trying to install FOG on raspbian to see if I could get a portable FOG solution built with hardware I had laying around. I can’t get past the initial setup script execution.

First thing was that it was missing add-apt-repository and that was solved by installing python-software-properties and software-properties-common and was able to continue further. It now fails at the same point, but the message is now

Traceback (most recent call last):
  File "/usr/bin/add-apt-repository", line 167, in <module>
    sp = SoftwareProperties(options=options)
  File "/usr/lib/python3/dist-packages/softwareproperties/SoftwareProperties.py", line 105, in __init__
    self.reload_sourceslist()
  File "/usr/lib/python3/dist-packages/softwareproperties/SoftwareProperties.py", line 595, in reload_sourceslist
    self.distro.get_sources(self.sourceslist)
  File "/usr/lib/python3/dist-packages/aptsources/distro.py", line 89, in get_sources
    (self.id, self.codename))
aptsources.distro.NoDistroTemplateException: Error: could not find a distribution template for Raspbian/jessie

Probably not anything that can be done about this as it isn’t officially supported, but I figured I would ask for help if there is any to be had.

Thanks

@asbenavides
If it might be a NIC issue, then I would try using a USB Nic, you might still be able to PXE boot from it and rule that part out.

@pr1m0
I haven’t tried that sadly. All of the times I’ve had to get files out of images, it’s not been too much of a hassle. Although I would be open to trying it if you might could provide some pointers on getting it going in Centos 7.