Citrix Hypervisor – Paravirtualized VM won't boot after upgrade to Hypervisor 7.0

Updated the following files that are used to boot the XS installer to match the current version being installed, on this particular case, files on the TFTP server were from previous Hypervisor version 6.x

mboot.c32

pxelinux.0

These files are needed on a TFTP server according to the Network Boot Installation process described here:

https://docs.citrix.com/en-us/xenserver/7-1/install/network-boot.html

Related:

  • No Related Posts

ipxe -> symantec pxe chain

I need a solution

ipxe -> symantec pxe chain

Hallo all, 

Could someone help us with the following?:

We boot our clients using ipxe, users get a menu to boot from. 
One of the options is symantec.

We chainload using the following command: 
chain tftp://192.168.200.28/BSTrap/x86pc/BStrap.0, this works in BIOS.

For UEFI we use:
chain tftp://192.168.200.28/BTrap/X64/BStrap.efi, this goes wrong.

If i leave out ipxe and directly boot Symantec via pxe in UEFI, it works after setting option 60 PXEClient.

I have already contacted the ipxe developers, they said i need to ask Symantec:

http://forum.ipxe.org/showthread.php?tid=18169

Could someone help me with this i have tried a lot of things but i am not able to resolve it?

Thank you
Wietse

0

Related:

  • No Related Posts

Dell Latitude 5591 bizarre ghost behavior (drive shows as 2 TB but it’s only 256 GB)

I need a solution

Hello,

We received a batch of latitude 5591’s and at first I struggled getting one to boot to PXE / TFTP to pull down the ghost image. Had to change to Legacy boot mode in order to do that. Now, when I boot it pulls down the ghost client fine and runs it. I thought I was going to be fine but then I saw this:

notice the source says “Local drive [1], 244198 MB” but the MB remaining says 2093737 (??)

please help

0

Related:

  • No Related Posts

Action Recommended to Secure the Cisco Nexus PowerOn Auto Provisioning Feature

Cisco Nexus devices support an automatic provisioning or zero-touch deployment feature called PowerOn Auto Provisioning (POAP). This feature assists in automating the initial deployment and configuration of Nexus switches. POAP is enabled by default and activates on devices that have no startup configuration or when Perpetual POAP has been configured using the boot poap enable command.

As with other automatic provisioning technologies, such as Cisco Zero-Touch Provisioning or Cisco Smart Install, some basic assumptions are made about the initial deployment environment. First, that administrators know that the feature exists and is enabled by default. Second, that the Layer 2 (L2) network on which a device initially connects is secure.

By design, the POAP feature leverages several unauthenticated protocols to obtain the initial configuration file for a device. When a device with POAP boots and subsequently fails to locate a startup configuration, such as on the first startup after unboxing or after a restoration of factory defaults, the device enters POAP mode. The device will attempt to locate a DHCP server through a connected management interface1. Then the switch will listen for a DHCP response that includes at a minimum the following:

  • An IP address
  • A default gateway
  • Option 66 (TFTP server name) or Option 150 (TFTP server address)
  • Option 67 (boot file name)

If the Nexus device receives multiple DHCP responses that meet these requirements, the first DHCP response received will be accepted, and POAP will move to the next stage of the device configuration. If no DHCP responses that meet these requirements are received prior to the timeout period, the device will exit POAP mode.

If a DHCP response is accepted, the Nexus device will attempt to connect to the provided TFTP server to retrieve the Python or Tool Command Language (Tcl) POAP configuration script specified within the boot file option. The switch will then execute the script to retrieve the specified software and device configuration. The Nexus device software and configuration may be retrieved using Secure Copy Protocol (SCP), FTP, or SFTP. The downloaded Nexus software will be assigned as the active image, with the configuration file scheduled to be applied when the device restarts.

Several steps in the POAP configuration process rely on a secure network segment to obtain critical startup information. While the POAP feature disables itself after a configurationis applied to a device2, it is critical that customers properly secure the networks in which POAP may be utilized. Some customers may want to disable the POAP feature and use other methods to configure a Nexus device out of the box. To this end, Cisco has added multiple new commands to disable POAP that will persist across a reset to factory defaults and the removal of a configuration. For guidelines on securing a POAP environment, as well as information about disabling the feature, see the Details and Recommendations sections.

This advisory is available at the following link:
https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20190306-info-poap

1On some Nexus chassis-based devices, the DHCP solicitation may also be sent using all front-panel Ethernet interfaces of the installed router processor.

2The POAP feature will not be disabled if Perpetual POAP has been configured using the boot poap enable command and will run on each reload of the device.

Security Impact Rating: Informational

Related:

  • No Related Posts

Cisco Network Convergence System 1000 Series TFTP Directory Traversal Vulnerability

A vulnerability in the TFTP service of Cisco Network Convergence System 1000 Series software could allow an unauthenticated, remote attacker to retrieve arbitrary files from the targeted device, possibly resulting in information disclosure.

The vulnerability is due to improper validation of user-supplied input within TFTP requests processed by the affected software. An attacker could exploit this vulnerability by using directory traversal techniques in malicious requests sent to the TFTP service on a targeted device. An exploit could allow the attacker to retrieve arbitrary files from the targeted device, resulting in the disclosure of sensitive information.

Cisco has released software updates that address this vulnerability. There are no workarounds that address this vulnerability.

This advisory is available at the following link:
https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20190220-ncs

Security Impact Rating: High

CVE: CVE-2019-1681

Related:

  • No Related Posts

iPXE – WinPE – Driveletters

I need a solution

Hi

We have enabled iPXE and it is working great and the speed is great compared to standard PXE/TFTP.

But, when we boot into Winpe with iPXE the driveletters to local disk on the destination computer is not the same at with standard PXE.

In standard PXE we see local drive as C: but with iPXE it is D:  – Our challenge and problem is that we have many scripts, tasks and jobs that expect the local drive to be C: 

Is there any way to change this or is this by design? Does anyone have a clue why this is happening?

0

Related:

  • No Related Posts

Cisco Prime Infrastructure Arbitrary File Upload and Command Execution Vulnerability

A vulnerability in which the HTTP web server for Cisco Prime Infrastructure (PI) has unrestricted directory permissions could allow an unauthenticated, remote attacker to upload an arbitrary file. This file could allow the attacker to execute commands at the privilege level of the user prime. This user does not have administrative or root privileges.

The vulnerability is due to an incorrect permission setting for important system directories. An attacker could exploit this vulnerability by uploading a malicious file by using TFTP, which can be accessed via the web-interface GUI. A successful exploit could allow the attacker to run commands on the targeted application without authentication.

Cisco has released software updates that address this vulnerability. There are workarounds that address this vulnerability.

This advisory is available at the following link:
https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20181003-pi-tftp

Security Impact Rating: Critical

CVE: CVE-2018-15379

Related:

Configuring PVS for High Availability with UEFI Booting and PXE service

Configuring PVS for High availability with UEFI booting and PXE service

Requirements and configuration:

  1. PVS 7.8 or above installed on all servers
  2. PXE service configured to run on multiple PVS servers
  3. User-added image
  4. Option 11 configured on the DHCP server for multiple PVS servers (or option 17 configured with Round Robin DNS entry)
  5. User-added image
  6. Vdisk stores configured with multiple PVS servers serving those stores:
  7. User-added image

Additional information:

We can split a PVS target booting into 4 tasks.

Task 1

PXE client on target device getting an IP address and scope options.

IP address will come from DHCP server.

Scope options there are two options:

  • Scope options for PXE are defined on dhcp server
Options 66 and 67 specify the server name and file name for tftp retrieval of the pxe bootstrap file
  • PXE server (option 60, doesn’t need to be configured)
PXE server responds to DHCP request with PXE information, giving its own server name, and the appropriate file name for tftp retrieval of the pxe bootstrap file

Task 2

PXE client retrieves boot file via TFTP

Option 66&67:

  • PXE client retrieves boot file from TFTP server as specified in scope options, this TFTP address can be load balanced and configured for HA with Netscaler.
Round robin can be used for also load balancing, but not for HA, as there is no recovery if one tftp server is offline

PXE server:

  • The PXE server which responded first is used by PXE client.
PXE server specifies itself as the source tftp server, and provides the appropriate file name
  • In PVS 7.8 and above, PXE service can provide the appropriate boot file, gen1/bios boot file- ardbp32.bin, or gen2/uefi file – pvsnbpx64.efi, depending on the pxe client request

Task 3

PXE client executes boot file which handles further booting, and the boot file contacts PVS login server.

Gen1/bios:

  • Ardbp32.bin has been preconfigured with the addresses of PVS login servers

Gen2/uefi:

  • pvsnbpx64.efi is a signed file and cannot be preconfigured with PVS login servers.
  • Instead it will retrieve the location of PVS login servers from DHCP scope options, using either option 11, or option 17.
  • Option 17 can be used to specify a single PVS login server in the format: pvs:[192.168.0.1]:17:6910
There is no HA for login server in this scenario, when using a single IP address​
  • Option 17 can be used to specify a DNS name, which is round robin list of all PVS servers in the format: pvs:[DNSRRENTRY]:17:6910
As the DNS entry resolves to multiple PVS servers, and non-responsive PVS login servers will be skipped over by the bootstrap, this is HA appropriate.
  • Option 11 can be used to specify a list of up to 32 PVS login servers.
As multiple login servers are specified, and non-responsive PVS login servers will be skipped over by the bootstrap, this is HA appropriate.

Task 4

PVS login server finds vdisk assigned to target device and tells the target device to switch to PVS streaming server

  • Provide multiple PVS servers are configured to stream a vdisk, this will be highly available
  • If a PVS server is offline, a target device will not be instructed to stream from it

Related:

PXE-E55: ProxyDHCP service did not reply to request on port 4011 (happening only at one site of a multiple DHCP/PXE configuration)

I need a solution

Here’s a problem that just started happening last week.

We have GSS, DHCP, and a PXE server installed at our prime location in VLAN 253.
We also have Microsoft DHCP and PXE servers installed on separate servers in VLANs 83, 85, 87, 91, 93, 95, and 97.

At our VLAN 93 location, clients booting through network boot ARE assigned DHCP addresses, but receive the message “PXE-E55: ProxyDHCP service did not reply to request on port 4011”.

All other locations are working properly.

I have verified the DHCP Scope for VLAN 93 contains Option 60 “PXEClient”.
Switching that same client computer to VLAN 85 results in a successful PXE boot menu.
I’ve tried restarting Altiris PXE Services, to no avail.
I’ve tried restarting the DHCP Service, to no avail.
I’ve tried rebooting the DHCP/PXE server for VLAN 93, to no avail.

I’ve attached our PXE Configuration to this post, although it is pretty run-of-the-mill.  MTFTP is disabled.

Any help on resolving this issue would be greatly appreciated!

0

Related: