Submitted by lexo_ch on Tue, 11/20/2018 - 15:06 Pro Licensee
This is the problem and we managed to come around the bug:
https://www.virtualmin.com/node/58781#comment-805366
The software cannot be installed on a fresh Debian 9.5 or 9.6. The install.sh script does not work. Please fix.
Kind regards LEXO, Marcus Fleuti
Status:
Closed (fixed)
Comments
Submitted by andreychek on Tue, 11/20/2018 - 15:52 Comment #1
So, there are multiple different things happening on Debian with regard to networking. The post you've pointed to is probably its own issue and may be related to running under ESXi (I'll try to reproduce it). But...there's also the issue with the new network configuration system (which I don't think is the cause of the problem in the post you've linked, but might be, I haven't had time to work on a system using the new networking config tools on Debian, since we've been busy working out the new Ubuntu stuff).
Anyway, Debian recently added a new network configuration system that we don't yet support in Webmin (this is similar to the issue we had supporting Ubuntu 18.04, but it's yet another different system, so the new support for netplan in Ubuntu doesn't help us with the new systemd network system in Debian).
In short, we're working on it, but it's going to be a while. In the meantime, you'll need to use the old Debian network configuration system, which should work without problem. But, there may be other issues with detecting network interfaces and addresses, even when using the old network config system (but, if so, they're new to me). I'll try to reproduce this kind of problem ASAP.
Submitted by lexo_ch on Wed, 11/21/2018 - 02:47 Pro Licensee Comment #3
Hi Joe Thanks a lot for your quick response. As I wrote in the issue I could solve it by manually ifup the eth0 in a second console and then telling the script the name of the interface. As far as I can see Debian 9.6 uses the very same network configuration /etc/network/interfaces.
Since I can simply ifup eth0 on a second console I doubt it to be an ESXi related issue. The "hardware" is working fine. To me it seems as if the script is kind of restarting the network subsystem and fails on doing it and then can't find a valid network interface to bind the services on to.
I hope this helps you in applying some optimizations.
The good part (for you) is: I thought it's an issue with the GPL version so we bought (subscribed to) the professional version. So this incident lead to a sale ;)
Thank you for following up with your solution. It helps me understand what's going on, and will probably allow me to reproduce the problem and fix it. There's so much flux in how networking works on Debian and Ubuntu right now (and they're both switching to different systems) it's pretty overwhelming. I'm particularly grouchy with Debian because they're making such a major change in a minor version...I would really have preferred they put it into 10.0 rather than shoving it in during the 9.0 lifecycle...it just throws any promise of compatibility out the door.
And, we're happy to have you as a customer!
I'll leave this open as a way to track the problem, even though it's resolved in your case. I guess I've got more work to do on detecting the interfaces and addresses on Debian, even with the old network config system.
So far, I'm unable to reproduce the problem. I just did tests on a couple of VPS providers' (vultr and Digital Ocean) Debian images (both 9.5, but people have reported problems going back to 9.4, so...), and the install went without a hitch.
I guess I'm gonna need to follow up with some folks to figure out how/why it's going wrong in each specific case, because it's not universal.
So, when you said previously you changed the network name to eth0, how did you do that exactly? I can imagine that causing problems if network config using the old interface name still exists somewhere. We should be able to detect any interface name, I think, as long as you don't have multiple IPv4 interfaces (we even try to detect it correctly if there are multiple interfaces, but, it's probably error-prone). That hasn't always been the case, but has been for at least a year or two.
Submitted by lexo_ch on Tue, 11/27/2018 - 03:38 Pro Licensee Comment #6
Little bit of history:
I installed Debian 9.5 from scratch (netinst, minimal install, only SSH). After Install I logged in, downloaded the install.sh script and issued it as explained on your website. It went through until the end where it could not detect the network interface. Errors about network problems displayed and services were not bound to the static IP address that was set during installation. IFCONFIG showed only LO interface. IFUP ENSxxx (I don't quite remember the name now) worked and the interface was back online. Thought the script failed and I did not trust the installation. I did not have more time so I let it be for 3 weeks.
Debian 9.6 came out so I did the same thing again with Debian 9.6 (fresh install, minimum netinst setup). Very same problem. So I reinstalled 9.6 once more and renamed the interface from ENSxxx to ETH0 like this:
sudo nano /etc/default/grubGRUB_CMDLINE_LINUX="net.ifnames=0 biosdevname=0"
sudo grub-mkconfig -o /boot/grub/grub.cfg
And of course I changed the network config in /etc/network/interfaces
Then I issued the script again. Same error. Again reinstall (actually I reverted back to a snapshot I made earlier in ESXi) but this time, as the script told me that it cannot find a network interface, I switched to second console, enabled it manually with IFUP eth0, switched back, entered "eth0" where the script asked for network interface name and then it worked.
I hope this helps you further in your investigation.
Submitted by scotwnw on Tue, 11/27/2018 - 15:33 Pro Licensee Comment #7
The "auto eth0" line is what brings it up on boot. Be sure your interfaces file has that line. Or one to match your actual interface name. Should also have "auto lo".
Only time I've ever tried debian was recently and thats what I had to fix. Unsure if it was like that or if webmin did it once it was installed.
Submitted by lexo_ch on Wed, 11/28/2018 - 09:16 Pro Licensee Comment #8
Hmm... indeed the Debian installer did not add "auto eth0" respectively "auto ensXX" to /etc/network/interfaces. That might have been the problem. "auto lo" was set correctly. I did not notice this thank you!
Question remains now: why does the Debian installer not set "auto INTERFACENAME" and is that really the cause for this problem?
Because on boot - despite this parameter is being absent - the network stack enables the primary interface automatically. The problem only occured upon Virtualmin installation. Perhaps the install.sh script should check the /etc/network/interface file if this parameter is present for all listed interfaces and give a warning if not and cancel the installation if it's missing?
Submitted by lexo_ch on Tue, 10/15/2019 - 09:28 Pro Licensee Comment #9
It works in Debian 10 so... I don't care anymore :)