Posts made by RobertD

I just received this exact same model laptop and I’m having the same problem. I’m using the onboard NIC with the ipxe.efi loader. The onboard NIC is an Intel 1219-V

Here is what I’ve done so far:

• Updated the ipxe.efi manually.
• Updated the BIOS to the latest version.

Using ipxe.efi it gets stuck “iPXE initalising devices…”, however if I set the snp.efi it boots successfully.

We have been using ipxe.efi for all of our devices for years so I’m afraid to change all our DHCP scopes to use this loader for this one problematic model. Any suggestions?

Hey guys,
I think the answer to this is no, however I need to make certain. Under a vanilla install of FOG (Ubuntu), as the title says, is log4s installed/utilized? Should we be concerned about our FOG server running this exploit.

FWIW - We don’t see any trace of it on our server.

@george1421 Understood.

For us it’s just extra steps we try to eliminate. We are a pretty large school district with over 65K students and 10K employees and a lot of machines. We have more then once had to re-image an entire campus because a virus outbreak and being able to push an image to a school and just telling them to reboot has saved us a lot of time in the past. Thankfully this hasn’t been an issue in a long time. Maybe times are changing and UEFI is going to force our hand…

@rankinc FWIW the only thing we did was, disabled secure boot, disabled DMA protection, changed the UEFI boot order to nic first (I also disabled all the other options) and it started working.

We were facing the exact same problem in the screenshots above. We are using ipxe.efi

EDIT: My machine also hangs at “rEFind - Initializing” after the image has been deployed, but we are just going back into the BIOS and setting the HDD as the first boot device after the image has been pushed. I don’t know where to begin troubleshooting this part of the process. Legacy BIOS was so much easier…

Hey guys we just ran into this same exact problem. We found that if you disable DMA Protection in the BIOS it will PXE boot no problem. Just wanted to leave this out there for you to try.

Wow you guys are a great help. We were looking at folder permissions that whole time when it was the share permissions.

So we should be mounting to a sub directory in images/dev…

Export list for 172.31.16.155:
/images/dev *
/images     *

Not sure why it isn’t working.

1. We created a new directory within our /images folder on the fog server called userbackup.
2. We set permissions with chmod 777 on this folder.
3. Booting a host with a deploy debug task.
4. From the host we tried the following

mkdir /userbackup
mount -o nolock,proto=tcp,rw "1.2.3.4:/images/userbackup" /userbackup
touch /userbackup/test.txt
"This is a read-only file system"

Are we missing something in our mount statement?

@Sebastian-Roth We are actually trying that right now, however we are struggling to mount it with write access. It keeps giving us “Read-only file system” when we try something like touch /imagesinit/userbackup/text.txt.

@george1421 - I hate to impose binaries into the inits if no one else has a use for them. I’m just trying to figure out a way to do this without adding additional mechanics to our current process.

@george1421 - I was afraid cifs wasn’t in the FOS which makes sense because it needs to be as lightweight as possible. I’ve looked into USMT, but it adds complexity and time to our re-imaging process in which we have limited time and staff for the size of school district we are.

Our campus techs typically don’t even login to the machine when re-imaging. They shut it off, run through the registration process and walk away. It’s completely finished when they come back. Adding additional steps to this process will prevent us from completing the re-imaging projects over summer due to the sheer number of machines we have to re-image. This is why it’s appealing to let FOG do it as part of it’s process.

I suppose I could always rsync it to the FOG server like /images/profiles/ then move everything off the fog server to an SMB share via FTP, but that seems kind of clunky.

Sorry to necro this thread, but I find myself needing to do the same thing requested here. Our staff is ultimately responsible for their data and making sure they save it to their network drives, but during summer re-imaging we always have someone that returns and have lost their data because they thought they saved it to the network drive, but didn’t.

What I would like to do is have FOG take a quick copy of the C:\Users directory and store it on a SMB share prior to imaging (Not the FOG server due to space restrictions). Can the FOS mount a SMB share from a postinit script so that rsync can be used?

Thanks george,
I was afraid of that. I was just hoping FOG had some sort of post imaging partitioning magic to convert a single partition legacy image into an efi partition structure.

Fog 1.5
Ubuntu 16.04

Hey guys, kind of a stupid question, but we are beginning to roll out support for UEFI for the first time. Is it possible to create a single Windows 10 image that can boot both legacy bios and uefi bios? Or are we going to have to start maintains two windows 10 golden images?

So glad I found this thread. I have been trying to figure out what was going on with our setup. We just upgraded to 1.5 stable and decided to begin building our images from VMs instead of physical machines, however we came across issues with Windows 10 (1709) hyper-v host and getting stuck at initializing devices. Should we move to a different hyper visor?

Also it appears the registration process does not check to see if the image id the user types is a valid ID. It only checks to see if it’s a number.

Maybe the checkAndSet() function inside fog.man.reg can do this in a future release?

Hi all,
We’re building out a new fog server, running 1.4.4. Much has changed since 0.32. I would like to prompt for a username and password immediately after the selection of “Preform Full Host Registration and Inventory”, similarly to Quick Host Deletion or Deploy Image. I don’t want to give users the ability to add or register a host with fog before auth.

Looking at the config Fog menu Configuration page I see “fog.reginput” does not pass parameters like “fog.deployimage”

I tried just guessing with the code below, but manreg does not work.

login
params
param mac0 ${net0/mac}
param arch ${arch}
param username ${username}
param password ${password}
param manreg 1
isset ${net1/mac} && param mac1 ${net1/mac} || goto bootme
isset ${net2/mac} && param mac2 ${net2/mac} || goto bootme

According to the bootmenu.class.php file code there is not a parameter for this menu selection only advLog, delhost, keyreg, qihost, sessionJoin, approveHost, menuaccess, debugAccess

I am aware this menu selection will prompt for a username and password, but this only happens after the registration questions are asked. (I can modify fog.man.reg to move authentication code in the bash, but would like to keep this consistent with all other menu items)

Any suggestions?

Thanks!

Thanks for the suggestions, but now I have more questions =P

We currently have the fog service set to disabled on our images and a script that runs on first boot (which installs model specific drivers) enables this service. It then renames the computer and adds it to the domain. How can the setupcomplete.cmd file add a domain user to the local administrators group if this script is run before the fog client joins the computer to the domain?

Server

• FOG Version: 0.32
• OS: Ubuntu 14.04
  (We will be upgrading once the finial version of 1.3 is released)

Client

• Service Version:
• OS: Windows 7, WIndows 10

Description

I’ve noticed during registration of a computer that one of the questions ask Which user is associated with the computer? (or something along those lines) Does the new fog client have the capability to add domain users to the local administrator group when answering this question during the registration? It would nice if when a computer is reimaged that it’s renamed, put on the domain, and the user of the computer is added to the local administrators group. We are still having to complete this final step manually.

There has been mention of doing this with the unattend file, however I much prefer not having to dynamically change that file prior to first boot. Thanks for any suggestions!

Just wanted to thank everyone for their suggestions( @george1421 @Wayne-Workman). We did install LAPS on a test OU and it works perfectly. We’ll likely be rolling it out in the next week or two. For those machines off the domain, oh well…