Open jamess60 opened 1 year ago
Looks like iVentoy loads the web interface, but you need to configure DHCP and click go before it starts serving. By default, the server only (:26000 web interface) only listens on 127.0.0.1. You can use iventoy.sh -A start to listen on all, but the container isnt doing this meaning the web interface is never accessible
Looks like it forces you to use its inbuilt DHCP server. In theory we can have 2x DHCP servers on the same subnet offering different pools that dont overlap (in my case, router is serving .101-.240, ventoy has .241-.254)
I guess we need a way to retain these settings and click that go button somehow automagically (so that ventoy comes up when the container starts)
The documentation is really poor on the iVentoy side but it seems like exporting /data should hopefully retain the settings.
Honestly I started to play with this but didn't get much testing done as I had to then fiddle with DNSMASQ on my Edgerouters and i decided to have a beer instead. I'll do some testing this weekend to look at adding this.
In terms of networking - agreed I add a docker network on the same subnet as my lan with a carved out smaller CIDR which makes apps that don't really play with containers a little easier (Samba AD-DC etc).
Did you configure your external DHCP Server with this?
Set next-server to the iVentoy IP address and set bootfile as iventoy_loader_16000
Note that the suffix 16000 is the iVentoy http server port, if you change it on the page then the bootfile should match it. (For example: iventoy_loader_17000).
I was unable to get external DHCP working. When it first launched, it didnt support it at all, so I think either the .8 version this container is based on or this mornings .9 update are the first to implement it.
Im currently letting ventoy do DHCP as well as my router. My router has .100-.240 Ventoy has .241 - 254
While playing around, I also found the log file was useless. There are SOME isos that randomly cause it to just die - these predominantly seem to be WIM & ESD based windows images - the logs give zero indication as to which isos are problematic and why - the server process just simply silently dies. I found myself adding isos 1 or 2 at a time...
I also tried symlinking the iso dir to my file server iso collection - it doesnt like that either.
Currently testing it with a Debian 12 vm
I've just updated the latest and image to 1.0.09 going to do a bunch of testing this week.
Hi GarySounds good - I’m still running with the VM for now, but happy to do some testing for you as I’d really like to have this containerised. I heard back from iventoy support, apparently the -R argument will start the server automatically without needing to click the green button we should therefore run with -A and -RCheersOn 10 Jul 2023, at 08:11, Gary Bowers @.***> wrote: I've just updated the latest and image to 1.0.09 going to do a bunch of testing this week.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>
I've added them to the supervisor script but my localtesting shows it doesn't actually seem to do anything. I'm just on the train to London and wifi is patchy so will test properly this evening.
I need to create a bash script with a loop to run iVentoy to surpress errors in the output.
Note to self - looks like emailing a reply doesnt end well 😜
I had a look at the iventoy.sh script, looks like it just checks if the process is running, refuses to start it if it is, otherwise does a start stop. I dont see any reason why we cant interact with the iventoy binary directly
No rush with any of this btw :)
Hey Gary
I managed to get some more info from support.
I raised an issue where the start/end ip addresses for the DHCP pool wouldnt be saved when the server process crashed. I suggested that an argument be added to override the DHCP addresses in combination with -R. Apparently if you run the process once, click the green button, stop it then close the process gracefully, it should get saved. While this isnt something we can gracefully handle with a container (at least as far as Im aware), we could at least work our way around it with a decent README.
I also reported an issue where some ISOs were causing crashes with no useful log events (it was primarily Windows WIM/ESD based ISOs that had been modified, eg AIO images, adding drivers, adding updates etc). This is a known issue, but the fix is not yet work in progress.
Hi
I am using the following compose config: iventoy: container_name: iventoy image: garybowers/iventoy:1.0.08 restart: always privileged: true network_mode: host volumes:
I have network mode as host (negates the need for opening up the ports, figured this would be more reliable too) and I have used privileged as PXE will needs ports below 1024.
I have a single Debian 12 netboot iso in /containerstorage/iventoy/iso
This the error I get when trying to PXE boot (same VM/config boots into windows deployment services fine)![Screenshot 2023-07-09 at 13 07 04](https://github.com/garybowers/iventoy_docker/assets/126415249/4f000e64-78f2-4bed-b727-3e1fa44c3073)
Any tips?