That’s a minor issue that can easily be overcome later. Not critical by any means ATM.
Hmmm… Have you tried the reboot to get the file system mounted and then restarted the script?
The issue, I’m pretty certain is that a kernel package is not installed (specific to VPS’) that enables quota support.
However, that’s not even the primary issue here, cause an install will still proceed without quota support.
Then maybe touch /etc/postfix/sasl/smtpd.conf
would get past this point? WM/VM doesn’t create the file if it isn’t there? That’s why I wondered if the file system was mounted. Not that we even know what the file system is at this point.
Those are obviously custom. That’s not from Ubuntu, and it’s not from us.
Something is still going wrong earlier, and we need to see what. As I said above, the install stage (not the configure stage) is where I think things are going wrong, and that’s where you need to be looking. There’s an install log in /root
. Check it for problems installing Postfix (and maybe others).
Don’t do that.
If you’re trying to trick the installer into doing something, you’re just screwing your future self out of a working system. You’ll have to troubleshoot what was actually supposed to happen later.
The goal is a working system, not tricking the installer into looking like it worked.
Peter was so kind to support me via screen share. He had to install Postfix manually (apt install postfix
) and restart the install script to get it working.
However, the quota issue is still remaining. He thinks that the ploop device of the root filesystem might be the root cause.
Thank you very much to all of you for your quick response and outstanding support!
If this is a Virtuozzo container, as your foreign apt repos earlier indicates, you won’t have quotas, I don’t think. They have to be configured at a layer above the container you’re in, so it’s not something the installer or Webmin can do. I’m not overly fond of hosting in Virtuozzo containers.
It’s a little worrying that Postfix did not install during the usual install process, and I suspect there may be other issues. You’ll want to look through the log for anything else out of the ordinary.
One thing to be aware of with Virtuozzo and OpenVZ: Your host can oversell memory, which will inevitably lead to random mysterious failures that don’t make sense and can’t easily be diagnosed. Like, say, a memory-intensive task like installing a big list of packages and its dependencies might just fail for seemingly no reason.
There’s some counter somewhere (beancounters
, I think?) that can tell you about out-of-memory events. Running out of memory is a catastrophic event. Something has to be killed, and Virtuozzo/OpenVZ makes over-selling memory (and thus out-of-memory situations) part of the design to make it more profitable for hosting providers.
Anyway, my gut tells me you don’t have a reliable system, and you probably won’t ever have a reliable system, if memory is oversold.
@Joe
Yes, the Postfix installation issue is somewhat worrying. I’ve sent Peter the log files and he will share it with you.
Thank you for the warning regarding oversold memory on Virtuozzo systems!
OK. I see where my confusion was.
How did the installer make it past this if Postfix was not installed? AND Postix installed from the configured repositories with the apt command with no further intervention?
I had to break a common rule and install the Postfix package manually before running the installer.
Typically this is frowned upon as we recommend letting the installer do the install, but for some reason (likely due to the VPS environment), it just wouldn’t install hence why the configuration couldn’t get modified as it didn’t exist.
The only issue that couldn’t get resolved was quota support as the VPS is using a “ploop” device for storage which doesn’t support quotas.
My suspicion is that apt
was killed due to memory usage (see my prior comments, I thought I’d already explained this), before it could return any value. I’m surprised that wouldn’t show up as an error, but we can’t possibly address every way a system can be unreliable, and the way Virtuozzo handles memory errors is broken by design (they’re hiding that memory is oversold and treating an OOM event where processes are killed as a minor inconvenience instead of a show-stopper bug…this only shows up in the beancounters
file in proc or somewhere). I suspect OP will have similar mysterious failures forever.
In short: We can’t help an unreliable system. Nothing we do in the installer can make an unreliable system reliable.
Installing a large list of packages requires a lot more memory than a small list of packages or just a single package.
If, as I suspect, OP is on a Virtuozzo system with oversold memory, the large memory use during the installation would cause apt or dpkg to be killed, while a single package installation might make it through without being interrupted.
Random processes being killed can’t ever be safe and can’t ever result in a reliable system.
I’ve considered making it an error to install on a Virtuozzo or OpenVZ system, because it seems like the only time I ever hear about these systems is when they’re running into mysterious failures, and it makes me tired. But, I’m sure not all hosts offering Virtuozzo/OpenVZ container-based hosting are overselling memory (at least I hope not). The fact that it’s possible/easy to do is pretty bad, though. Maybe we should detect it and warn about it, even if we don’t halt the installation. At the very least, maybe it can warn someone to watch out for mystery errors like this and what they probably mean (they probably mean “run away from this host”).
+----[SHA256]-----+
[2024/11/12 16:30:51] [INFO] - Succeeded
[2024/11/12 16:30:51] [INFO] - Configuring Procmail
[2024/11/12 16:30:51] [INFO] - Succeeded
[2024/11/12 16:30:51] [INFO] - Configuring Quotas
[2024/11/12 16:30:51] [WARN] - Non-fatal error
[2024/11/12 16:30:51] [INFO] - Configuring SASL
[2024/11/12 16:30:52] [INFO] - Code: 0 Result:
[2024/11/12 16:30:52] [INFO] - Code: 256 Result: adduser: The user `postfix' does not exist.
[2024/11/12 16:30:52] [INFO] - Code: 256 Result: touch: cannot touch '/etc/postfix/sasl/smtpd.conf': No such file or directory
Just going back to try and understand this. Not that I was on the correct path but … I was thinking that the file system maybe got mounted read only because of the error.

Failed to open /etc/postfix/sasl/smtpd.conf for writing : No such file or directory web-lib-funcs.pl (line 10596)
This was after updating from U22 to U24. Strange that both fail at Postfix yet @tpnsolutions was able to install it without changing repositories.
Regardless (not much point continuing to speculate), plenty of U22 and U24 installs where this didn’t happen so I’m going with provider. Mine provided no clear path to a RHEL compatible so I had to install Debian 10 and then upgrade it. That path let/forced me? to by pass the provider repos. Probably a step to far to check if installs are using the official repos instead of the providers? Who knows what they do to their custom image that come preinstalled.
This turned out to be (based on the log that Peter sent me) a custom spin of Ubuntu that was not a freshly installed OS, it had configuration changes that broke the installer. It had apt configured to not install Recommended packages.
We can’t support every random configuration change people want to make on their systems, which is why we insist on a freshly installed, supported OS. I don’t think that’s an unreasonable requirement for something that has to touch a lot of things in order to provide a nice user experience.
Also, there may be other missing packages.

which is why we insist on a freshly installed, supported OS. I don’t think that’s an unreasonable requirement
Completely agree. It is a pity that there is not a big red warning during installation.
This topic was automatically closed 8 days after the last reply. New replies are no longer allowed.