Posts made by abos_systemax

Hello, I’d like to use one FOG server on two VLANs. is that at all possible?
Multicast should only be available on one VLAN, the other VLAN will be unicast only anyways.

The RegKey works perfect in Windows, it appears that the REGED program in FogOS is the one having issues with the notation.
I was looking for any documentation on the subject, but Google refuses to think that I really do not wish results for REGEDIT, but for REGED.

That is why I wanted to boot to FogOS without actually deploying an image, so I could actually try to find a manual for REGED

hmm, sadly REGED doesn’t seem to like it.

The error:

import_reg: WARNING: found key <-HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Enrollments> not matching prefix <HKEY_LOCAL_MACHINE\SOFTWARE>
Customer.Script: Line 24: 17695 Aborted reged -C SOFTWARE -I HKEY_LOCAL_MACHINE\\SOFTWARE $RegKey

The code:

mkdir /WinC #create folder to mount C dir to
ntfs-3g -o -force,rw /dev/mmcblk0p3 /WinC #mount windows disk

cd /WinC/Windows/System32/config #here is where the registry is kept
RegKey="RemoveElements.reg" #file that will remove a regkey
touch $RegKey
echo "Windows Registry Editor Version 5.00" >> $RegKey
echo "[-HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Enrollments]" >> $RegKey #notice: The - in front of "HKEY..." is to remove the entry.
reged -C SOFTWARE -I HKEY_LOCAL_MACHINE\\SOFTWARE $RegKey #change the registry (notice the \\ instead of \)
rm $RegKey
umount -l /WinC

Is there something I’m doing wrong? Importing a key this way does work
also: importing this key in Windows does also remove the key; so this might be a REGED related issue?

– On another note:
How can I stop the Script execution and intervene in FOS? (if at all possible), this image takes > 60 minutes to deploy; making troubleshooting quite the struggle

I did not know about the ‘-’ in front of the key… if that works that’d be great!..

I’m trying to remove a regkey during postdeployment; because recreating the image because of one key is kind of ambiguous. I’ll check out your advice, will post back later!

Hello FOG;

I’m trying to remove a Registry key from Windows after the image has been deployed.
I am aware of the REGED utility, however, this one only imports .reg files and I must say that I do not now how to remove a reg key.

Is this even possible?

Love to hear,

Alex

@george1421 Bookmarked!

@george1421 Thnx! I was waiting to crash on a x32 device to check what that arch would be, this helps

@george1421 That is ‘just’ the UUID of the device itself, not of the vendor/all other devices of this type?
I could indeed use the UUID to push a certain ipxe.efi to this device; but the method I use now pushes that efi file to all devices with arch:0007, which also isn’t the real solution, but a working one for now. (the ‘rest’) will receive the normal ipxe.efi

@george1421 I take that you mean the ‘UNDI:003000’ part?

0170  50 58 45 43 6c 69 65 6e 74 3a 41 72 63 68 3a 30   PXEClient:Arch:0
0180  30 30 30 37 3a 55 4e 44 49 3a 30 30 33 30 30 30   0007:UNDI:003000
0190  ff         

this appears to work (Excerpt from dhcp config)

    filename "ipxe.efi";
       
    class "Legacy" {
    	### This is a BIOS client; do not sent en EFI file, that is silly!
    	match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00000";
    	filename "undionly.kpxe";
    }
    
    class "Crappy_UEFI_Firmware" {
    	### This device uses crappy UEFI firmware, send the older ipxe7156.efi that apparently does work.
    	match if substring(option vendor-class-identifier,0,20) = "PXEClient:Arch:00007";
        filename "ipxe7156.efi";
    }

@george1421 We are using ISC.

Other Question; can you chain another efi file after the first one is loaded? (Will test but right now the image is creating :))

@george1421 I.C… is there a way I can determine beforehand which ipxe.efi goes to what device? or can I use 7156 for all other devices as well?

@george1421
oh… that is intresting; the ipxe7156.efi appears to function.

what do those numbers mean?

I am chaining ipxe.efi, which in turn loads default.ipxe (this functions)
Then, boot.php detects the right MAC (it tries to boot to FOG).
It loads bzImage, init.xz (both OK)
then: Could not boot: No such device (2x)

I also tried to chain bzImage32 and init32.xz manually, but they fail with an exec error.

I do not get into the FOG client.

This is a UEFI system
SecureBoot is disabled
FOG iPXE menu loads; but all the options are not working
I manually added the host to FOG because I was unable to boot the device to Quick Registration (everything ends up with an exec error)

It seems that I am chaining a wrong file or something;
DHCP provides my machines with ipxe.efi, which in turn boots to default.ipxe. However, UEFI enabled devices can’t boot anything; not init.xz, not wimboot

I literally tried using all the efi files from the /tftpboot folder; but to no avail… I must be missing something obvious here

The issue also occurs with wimboot

:WIMBOOT || goto ERROR
kernel wimboot || goto ERROR
initrd SubMenu/wimboot/Boot/${bootarch}/Images/BCD	BCD || goto ERROR
initrd SubMenu/wimboot/Boot/boot.sdi	Boot.SDI || goto ERROR
initrd -n boot.wim SubMenu/wimboot/Boot/${bootarch}/Images/${wim}.wim	boot.wim || goto ERROR

this appears to be an issue with the device?
p.s. I just upgraded FOG to Running Version: 1.3.4-RC-2
didn’t resolve the issue

Server

• FOG Version: 1.3.1
• OS: Debian

Client

• OS: Windows 10

Description

Booting an ASUS H101H doesn’t work; I receive a ‘Could not boot: no such device (2c049087)’ error.
Other devices are able to boot.

the boot command is:

set fog-ip 192.168.68.24 || goto ERROR
set fog-webroot fog || goto ERROR
set boot-url http://192.168.68.24/fog || goto ERROR
kernel http://192.168.68.24/fog/service/ipxe/bzImage loglevel=4 initrd=init.xz root=/dev/ram0 rw ramdisk_size=127000 web=192.168.68.24/fog/ consoleblank=0 rootfstype=ext4 mac=00:b5:6d:06:8f:bb ftp=192.168.68.24 storage=192.168.68.24:/images/FOGImages/dev/ storageip=192.168.68.24 osid=9 irqpoll hostname=00b56d068fbb chkdsk=0 img=colorite_ASUS_H101H imgType=mps imgPartitionType=all imgid=18 imgFormat= PIGZ_COMP=-6 hostearly=1 pct=5 ignorepg=1 type=up || goto ERROR
initrd http://192.168.68.24/fog/service/ipxe/init.xz || goto ERROR
boot || goto ERROR

the bzImage and init.xz are loaded correctly
imgstat neatly lists both bzImage (with options) as the kernel, and init.xz as being downloaded.

This device is a Tablet/Laptop; the Network controller is a Lenovo USB-Network device.
The MAC is not being detected by ipxe (displays as 00:00:00:00:00:00)

The FOG Default menu also errors with the same reply; I just changed it to be able to see the error.

@Wayne-Workman
Yes! In fact; I’ll post my exact how to below for future reference…

My Environment:

• Citrix XenServer as a host
• Windows 2012 R2 as WDS Server (named X02, ip 10.0.0.2)
• Linux Debian for DHCP (named X01, ip 10.0.0.1)
• Linux Debian for Fog (named X03, ip 10.0.0.3)

Install the WDS Role onto Windows Server 2012 and configure it to listen to port 66

Settings:
WDS Properties window 
   DHCP --> Do not select the 'Do Not Listen on DHCP Ports'
   BOOT --> Always Continue the PXE Boot, or Require the user to press the F12 key (if so wanted)
   BOOT --> Do set default boot images
   PXE Response --> Respond to all client computers (Known and Unkown)

This will enable the Proxy DHCP for WDS to be enabled, and actually make WDS repond to DHCP requests before DHCP can hand out the ‘Next-Server’.

Also on Windows, launch an administrative prompt or Powershell and use the following commands to change the default boot program:

wdsutil /set-server /N12bootprogram:Boot\Custom\undionly.kpxe /Architecture:x64
wdsutil /set-server /bootprogram:Boot\Custom\undionly.kpxe /Architecture:x64
wdsutil /set-server /N12bootprogram:Boot\Custom\undionly.kpxe/Architecture:x86
wdsutil /set-server /bootprogram:Boot\Custom\undionly.kpxe /Architecture:x86
wdsutil /set-server /N12bootprogram:Boot\Custom\ipxe.efi /architecture:x64uefi
wdsutil /set-server /N12bootprogram:Boot\Custom\ipxe_x32.efi /architecture:x86uefi

This will set the boot program for both the ‘no F12’ and ‘normal’ boot to your own boot program, either undionly.kpxe in this case, and ipxe.efi/ipxe_x32.efi for UEFI environments

Of course you now need to copy the undionly.kpxe, ipxe.efi and ipxe_32 files to the /boot/Custom folder for WDS (where you need to create the Custom Folder)
You can place the files in any WDS Boot folder you wish, just change the commands above to correspond with the new location. Notice that the files must be placed in the WDS root folder ‘/boot’

Now for the DHCP server,
nothing quite special here except for the iPXE options:

  option space ipxe;
  option ipxe-encap-opts code 175 = encapsulate ipxe;
  option ipxe.priority code 1 = signed integer 8;
  option ipxe.keep-san code 8 = unsigned integer 8;
  option ipxe.skip-san-boot code 9 = unsigned integer 8;
  option ipxe.syslogs code 85 = string;
  option ipxe.cert code 91 = string;
  option ipxe.privkey code 92 = string;
  option ipxe.crosscert code 93 = string;
  option ipxe.no-pxedhcp code 176 = unsigned integer 8;
  option ipxe.bus-id code 177 = string;
  option ipxe.bios-drive code 189 = unsigned integer 8;
  option ipxe.username code 190 = string;
  option ipxe.password code 191 = string;
  option ipxe.reverse-username code 192 = string;
  option ipxe.reverse-password code 193 = string;
  option ipxe.version code 235 = string;
  option iscsi-initiator-iqn code 203 = string;
  #// Feature indicators
  option ipxe.pxeext code 16 = unsigned integer 8;
  option ipxe.iscsi code 17 = unsigned integer 8;
  option ipxe.aoe code 18 = unsigned integer 8;
  option ipxe.http code 19 = unsigned integer 8;
  option ipxe.https code 20 = unsigned integer 8;
  option ipxe.tftp code 21 = unsigned integer 8;
  option ipxe.ftp code 22 = unsigned integer 8;
  option ipxe.dns code 23 = unsigned integer 8;
  option ipxe.bzimage code 24 = unsigned integer 8;
  option ipxe.multiboot code 25 = unsigned integer 8;
  option ipxe.slam code 26 = unsigned integer 8;
  option ipxe.srp code 27 = unsigned integer 8;
  option ipxe.nbi code 32 = unsigned integer 8;
  option ipxe.pxe code 33 = unsigned integer 8;
  option ipxe.elf code 34 = unsigned integer 8;
  option ipxe.comboot code 35 = unsigned integer 8;
  option ipxe.efi code 36 = unsigned integer 8;
  option ipxe.fcoe code 37 = unsigned integer 8;
  option ipxe.vlan code 38 = unsigned integer 8;
  option ipxe.menu code 39 = unsigned integer 8;
  option ipxe.sdi code 40 = unsigned integer 8;
  option ipxe.nfs code 41 = unsigned integer 8;
  
#//Basically, this one stops WDS from interfering once iPXE has booted; it disables iPXE 'listen for a DHCP proxy' 
  option ipxe.no-pxedhcp 1;

authoritative;
allow unknown-clients;
option broadcast-address 10.0.0..255;
option subnet-mask 255.0.0.0;
option routers 10.0.0.254;
ddns-update-style none;;
option domain-name-servers 10.0.0.1, 8.8.8.8;
default-lease-time 14400;
max-lease-time 14400;
log-facility local7;

# LAN
subnet 10.0.0.1 netmask 255.0.0.0 {
	dynamic-bootp-lease-length 14400;
	authoritative;
	max-lease-time 14400;
	default-lease-time 14400;
	allow unknown-clients;
	next-server 10.0.0.3;
	range 10.0.0.25 10.0.0.250;
}

Nothing special there, except for the option ipxe.no-pxedhcp 1;
Otherwise, WDS will always inject it’s own next-server reply, looping you back to wdsnbp.com, now you stay in iPXE, where FOG’s default.ipxe can take over.

basically, that’s all there is about it.
This archieves the following:

1. Secure Boot Enabled devices will always boot towards WDS; no control about that
2. UEFI devices will boot to either ipxe.efi or ipxe_x32.efi, depending on the arch
3. Legacy devices will boot to undionly.kpxe

This will enable you to boot towards FOG.

One mayor But:

I haven’t yet got the EFI side of the FOG menu working; so all commands from the default boot.php fail on UEFI enabled devices. of/c this has something to to with the bzimage and init.xz not being able to load… but that is my challenge for today

@abos_systemax said in Question Regarding IPXE Boot Sequence:

Ah! I see where my issue comes from…
the “&& goto proxycheck” part is booting towards WDS. because this is a proxy.

Guess I’ll have to build my own ipxe files then

The solution is even easier…
adding

option ipxe.no-pxedhcp 1;

to the dhcpd config fixed the proxy issue