Having issues with the Surface Laptop 6 for Business. I've had two come through, 13.5 and 15" models and they both don't seem to want to launch any images. They sit on Preparing for boot.. please wait. They never get any further. I'm wondering if/how to troubleshoot. Also the Surface Pro 9 does not boot, sits on Preparing.. it's something to do with the new Surface range of devices. Does it have something to do with the Unsupported Window Size 4 error in the log? I can PXE boot just happily on most everything else. These are using Surface Docks to pxe boot from.

2024/08/06 19:50:58.659 [HTTP] HTTP PXE service starting ...
2024/08/06 19:50:58.659 [TFTP] TFTP service starting ...
2024/08/06 19:50:58.659 [DHCP] DHCP service no need to start in external subnet mode ...
2024/08/06 19:50:58.659 [NBD]  NBD service starting ...
2024/08/06 19:50:58.659 [HTTP] HTTP PXE service is running on x.x.x.x:16000 ...
2024/08/06 19:50:58.659 [PXE]  Now save iventoy config data ...
2024/08/06 19:50:58.659 [HTTP] NBD service is running on x.x.x.x:10809 ...
2024/08/06 19:50:58.660 [PXE]  iventoy config data (data/config.dat) save OK
2024/08/06 19:50:58.660 [PXE]  ===========================================================
2024/08/06 19:50:58.660 [PXE]        iVentoy 1.0.20 [Linux 64] is running now ...
2024/08/06 19:50:58.660 [PXE]  ===========================================================
2024/08/06 19:50:58.660 [TFTP] TFTP service is running ...
2024/08/06 19:50:58.660 [TFTP] TFTP write thread is running 51 ...
2024/08/06 19:50:59.142 [HTTP] API request: <{"method":"query_status"}>
2024/08/06 19:50:59.152 [HTTP] API request: <{"method":"sys_ip_list"}>
2024/08/06 19:50:59.157 [HTTP] API request: <{"method":"get_dhcp_mode"}>
2024/08/06 19:51:53.433 [TFTP] Parse tftp option(tsize,0)
2024/08/06 19:51:53.434 [TFTP] Parse tftp option(blksize,1468)
2024/08/06 19:51:53.434 [TFTP] Unsupported tftp option windowsize 4
2024/08/06 19:51:53.434 [TFTP] TFTP RRQ client x.x.x.x:1827 download <iventoy_loader_16000_uefi> start ...
2024/08/06 19:51:53.434 [TFTP] DHCP ExternalNet client x.x.x.x should use loader ipxe.x64.snp.efi.0
2024/08/06 19:51:53.434 [TFTP] Start send file iventoy_loader_16000_uefi to x.x.x.x:1827 with blksize 1468, has oack 1
2024/08/06 19:51:53.434 [TFTP] Recv an ERROR opcode pkt from client x.x.x.x:1827.
2024/08/06 19:51:53.437 [TFTP] Parse tftp option(blksize,1468)
2024/08/06 19:51:53.437 [TFTP] Unsupported tftp option windowsize 4
2024/08/06 19:51:53.437 [TFTP] TFTP RRQ client x.x.x.x:1828 download <iventoy_loader_16000_uefi> start ...
2024/08/06 19:51:53.437 [TFTP] DHCP ExternalNet client x.x.x.x should use loader ipxe.x64.snp.efi.0
2024/08/06 19:51:53.437 [TFTP] Start send file iventoy_loader_16000_uefi to x.x.x.x:1828 with blksize 1468, has oack 1
2024/08/06 19:51:53.507 [TFTP] Finished send file to x.x.x.x:1828 with blksize 1468 blks 206
2024/08/06 19:51:57.551 [HTTP] DHCP external subnet mode notify discovery client x.x.x.x ipxe/01-70-f8-ae-b2-75-68/uefi/mask:x.x.x.x/gw:x.x.x.x/dns:x.x.x.x
2024/08/06 19:51:57.551 [PXE]  Client 70-f8-ae-b2-75-68 start PXE install in UEFI X64 mode.
2024/08/06 19:51:59.410 [HTTP] 200 HEAD /viso/id/2/mac:x:x:x:x:x:x/busCI:01:80:86:46:1e size 1969795072
2024/08/06 19:52:13.789 [HTTP] API request: <{"method":"sysinfo"}>
2024/08/06 19:52:13.805 [HTTP] API request: <{"method":"sys_ip_list"}>
2024/08/06 19:52:13.809 [HTTP] API request: <{"method":"get_dhcp_mode"}>
2024/08/06 19:52:57.593 [HTTP] Client x.x.x.x:29833 (70) read timeout (close), state=0
2024/08/06 19:52:59.538 [HTTP] Client x.x.x.x:25631 (71) read timeout (close), state=0
2024/08/06 19:53:15.086 [HTTP] Client x.x.x.x:60933 (72) read timeout (close), state=0

I have 2 computer, one with 2G and one with 50G RAM
My Ventoy USB works properly on the one with the less memory.
With the same USB stick, on the one with 50G at least one wimboot fails. With an "out of memory" when asking for 9M.
Has somebody seen this before?
So it seems that the memory available to grub is limited and depend on the computer.
I did not found a related grub parameter or BIOS option. (The mem parameter is for the chosen kernel later)

Here are more details if it helps:
I generated Ventoy to debug with additional debug traces. (Because Ventoy grub console does not display the out of memory)
Both use the same code in the generated grubx64_real.efi

The problem is in ventoy_read_resource (called by ventoy_cmd_locate_wim_patch, ventoy_wimdows_locate_wim, search_replace_wim_dirent, parse_registry_setup_cmdline)
on the line: buffer_decompress = (grub_uint8_t *)grub_malloc(head->raw_size + head->size_in_wim);
grub_malloc return null. SO not enough memory.
At this point one the not working computer cannot allocate the required 10M the other still have 500M available.

The VDI support seems not to work with LinuxMin 22.
I only tested in VM yet

My friend JeanCarloEM posted it, thanks for checking it out

Who doesn't know - build environment ventoy - CentOS 7.8 x86_64.

CentOS 7 has expired, which means that there will be no more security updates or bug fixes provided by the official YUM repositories.
CentOS 7 repositories and mirrors are now disabled, so when running YUM commands, errors occur related to Mirrorlist.centos.org .

GIVEN:
1. MX-Linux installed on a HP Compaq Presario F700 hard drive, with the
  following software downloaded and installed:

      exfat-fuse
      exfatprogs
      forensics-samples-exfat
      Veracrypt-gui

2. Ventoy 1.0.99 installed on a 256Gb usb resulting in:

      Partition 1 - Ventoy  - exfat format - containing .ISO files, and
                                            data a sub-directory.
      Partition 2 - VTOYEFI - fat16 format - Ventoy code

WHEN:
Booting the MX-Linux system natively, I am then able to run Veracrypt
and access the usb Part 1, and select/open a Veracrypt file in the
sub-directory.

SUBSEQUENTLY:
1. Run MX Tools - Snapshot, with resulting <name>.ISO file of the
  current system, and copy to the Ventoy usb Partition 1.

2. Boot the Ventoy usb, selecting the MX-Linux ISO: the desktop
  appears, but with the following problems:

a) Double-clicking the Veracrypt icon yields the following "Attention"
  pop-up:

      The desktop file "veracrypt.desktop" is in an insecure
      location and not marked as executable. If you do not trust
      the program, click Cancel.

  With the choices: Launch Anyway / Mark Executable / Cancel


b) Upon clicking "Launch Anyway" Veracrypt executes and presents its
  GUI.
  However, upon clicking the "Select File..." box, with the resulting
  file-selection screen, and clicking the "Ventoy" partition name in
  the left panel, the following pop-up appears:

                        Unable to access "Ventoy"

      Error mounting /dev/sdb1 at /media/<username>/ventoy: /dev/sdb1
      already mounted or mount point busy

At this point, I have no idea of what to do. My knowledge of Linux is
limited to mostly just following instructions.

Please help!

Hello!

I have been using Ventoy for about 2 years but recently I have encountered problems with its use. I do not know whether this is the fault of the new versions or I simply did not use it on those computers with which Ventoy does not work.
The bootable flash drive is made in GPT mode with Secure Boot support enabled and a second partition in NTFS format (I also tried exFAT). The problems that exist are the following:


1. On old PCs with Intel motherboards (the processor generation is not important) Ventoy does not boot at all and gives a blue screen with an error (see screenshots).
When trying to boot from an external SSD drive blue screen as on screenshots.
Black screen with a blinking white cursor when trying to boot from a flash drive.
Flash drive is 128Gb size and external SSD is 256Gb size but SSD maked with 2 partitions 100Gb and second partition all remaining space by "Workaround 1" from FAQ for MBs with 137Gb legacy BIOS problem.
The external SSD is detected by all PCs as a SCSI device not USB, the flash drive is detected as a USB device but at the same time it does not work in any version from any media on Intel boards. And other external devices (HHDs) which detects as USB (not SCSI) problem are same.

2. The old emergency build for very old PCs diagnostics called STEA Live (https://stop-kadr.my1.ru/load/novye_klju...16-1-0-269) does not boots, although this build is definitely working. If you make a bootable media using Rufus or WinSetupFromUSB everything works but Ventoy cannot boot this and gives a wim file error, I don’t remember which error.

Can you fix something from this problems? Or what I can do for solve these problems. More important problem number 1.

Thank you! And thank you for the wonderful utility!

Attached Files

Thumbnail(s)
       

First of all, please understand that the grammar is not natural as we used a translator.  I was experiencing a dhcp problem, but I solved the problem through Googling, and now I am suffering from a screen garble problem. I've tried every possible resolution, but nothing works. Of course, there is no problem when booting the iso file from USB. Looking at past threads on the forum, I see several people complaining about this issue. Why hasn't the bug been resolved yet?

Attached Files

Thumbnail(s)
   

How do you change the font and text color of the version information in the bottom left hand corner of the main screen? My boot screen image makes it hard to see.

Hi,

Trying to setup iVentoy to PXE boot iso files, but, can't get work. 

I need to use ExternalNet mode, due to multiple vlans.



Tried:

iVentoy 1.0.20 running on  Ubuntu Server. 
iVentoy 1.0.19 running on  Ubuntu Server.

iVentoy 1.0.20 running on  Windows Server.
iVentoy 1.0.19 running on  Windows Server.

External DHCP OK, redirecting to PXE, but, can't find bootfile:


NBP filename is iventoy_loader_16000_uefi
NBP filesize is 0 Bytes
PXE-E99: Unexpected network error.

OR

Filename: iventoy_loader_16000
tftp://x.x.x.x/iventoy_loader_16000.................. Connection timed out



Tried iventoy_loader_16000_uefi  and  iventoy_loader_16000  as filename, but, same results.


SecureBoot DISABLED!

Network OK, can ping from host to PXE server and DHCP server.

Firewall disabled!