Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
 iVentoy 1.0.16 instantly crashing during iPXE boot attempt (before selection)
#1
I want to deploy iVentoy in my labs to streamline my VM deployment and automate the installation. I've set up a completely new Ubuntu 22.04 new VM:
Code:
root@deipxe:/opt/iventoy# lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 22.04.2 LTS
Release:        22.04
Codename:      jammy

I have configured iVentoy, added a few ISOs, the webinterface is launching, configured it with `ExternalNet`, prepared the DHCP accordingly and everything seems to be pretty much working for now.

iVentoy is also running:
Code:
# ps -ax | grep -i iventoy | grep -v grep
  52829 ?        Ssl    0:01 /opt/iventoy/lib/iventoy

Then I start my VM (in a different subnet), it is then booting just fine:
[Image: 2023-07-21_01-04-02-GtXdmCQL.png]

Just after this screen finishes, the entire VM crashes on ESXi 7.0 U3:
Code:
2023-07-21T00:08:56.817Z In(05) vcpu-0 - Msg_Post: Error
2023-07-21T00:08:56.817Z In(05) vcpu-0 - [msg.efi.exception] The firmware encountered an unexpected exception. The virtual machine cannot boot.

In the iVentoy logs I can only see:
Code:
2023/07/21 00:08:55.412 [TFTP] Parse tftp option(tsize,0)
2023/07/21 00:08:55.412 [TFTP] Parse tftp option(blksize,1468)
2023/07/21 00:08:55.412 [TFTP] TFTP RRQ client 192.168.200.181:1968 download <iventoy_loader_16000_uefi> start ...
2023/07/21 00:08:55.412 [TFTP] DHCP ExternalNet client 192.168.200.181 should use loader ipxe.x64.snponly.efi.0
2023/07/21 00:08:55.412 [TFTP] Start send file iventoy_loader_16000_uefi to 192.168.200.181:1968 with blksize 1468, has oack 1
2023/07/21 00:08:55.412 [TFTP] Recv an ERROR opcode pkt from client 192.168.200.181:1968.
2023/07/21 00:08:55.412 [TFTP] Parse tftp option(blksize,1468)
2023/07/21 00:08:55.412 [TFTP] TFTP RRQ client 192.168.200.181:1969 download <iventoy_loader_16000_uefi> start ...
2023/07/21 00:08:55.412 [TFTP] DHCP ExternalNet client 192.168.200.181 should use loader ipxe.x64.snponly.efi.0
2023/07/21 00:08:55.412 [TFTP] Start send file iventoy_loader_16000_uefi to 192.168.200.181:1969 with blksize 1468, has oack 1
2023/07/21 00:08:55.450 [TFTP] Finished send file to 192.168.200.181:1969 with blksize 1468 blks 206

Interestingly, also iVentoy crashes:
Code:
# ps -ax | grep -i iventoy | grep -v grep
-no output-

Very odd part: I booted up like 30 times now, it worked once until the boot menu (where I can pick the ISO file):
Code:
2023/07/21 00:13:46.891 [TFTP] Start send file iventoy_loader_16000_uefi to 192.168.200.181:1704 with blksize 1468, has oack 1
2023/07/21 00:13:46.925 [TFTP] Finished send file to 192.168.200.181:1704 with blksize 1468 blks 206
2023/07/21 00:13:50.916 [HTTP] DHCP external subnet mode notify discovery client 192.168.200.181 ipxe/01-00-50-56-af-cd-8b/uefi
2023/07/21 00:13:50.916 [PXE]  Client 00-50-56-af-cd-8b start PXE install in UEFI X64 mode.

Booting via SCCM has been working fine, and the 1 attempt worked - so I'd rule out ESXi as the root-cause here.

But it crashes like 99% of my attempts, reproducible. If there're any specific logs I can provide, let me know.

I'd appreciate any assistance here. Thanks!
Reply
#2
Unfortunately I'm not sure where to get more logs, to get any idea where it's failing. When attaching via strace and reproducing the issue, I can just see:
Code:
$ strace -p 1327
strace: Process 1327 attached
futex(0x219ff00, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x219fef0, FUTEX_WAKE_PRIVATE, 1) = 1
rt_sigtimedwait([TERM],




<unfinished ...>) = ?
+++ killed by SIGSEGV +++

I don't find any real pattern. It fails sporadically at:
- During initial PXE network boot (before any ISO file selection) when pulling any files from the HTTP server
- When selecting ISO file and then just seeing "Connection reset" (because the iVentoy service crashed)

Things I tried or might be noteworthy:
- When I clear my ISO and user folders, the behavior remains identical.
- This is a very fresh installation. No update of iVentoy was ever done.
Reply
#3
Update: 1.0.17 does not seem to fix the issue.
Reply
#4
only one cpu?
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)