Thanks Jonathan for the work around.
I tried the MAAS install option with a network connected machine, I got the
error.
I tried a server base install, then adding MAAS components (apt-get) with a
network connected machine, I got the error.
But installing from ISO with network card configured and
Public bug reported:
Description:Ubuntu precise (development branch)
Release:12.04
openssh-server-1:5.9p1-4ubuntu1
Not really sure that OpenSSH is the real culprit, but it's what has been
reporting the log spam since I upgraded from 10.10 to 12.04 a day or two
ago:
$ sudo grep
Public bug reported:
Binary package hint: postfix
package postfix 2.7.0-1ubuntu0.2 failed to install/upgrade: le sous-
processus script post-installation installé a retourné une erreur de
sortie d'état 75
ProblemType: Package
DistroRelease: Ubuntu 10.04
Package: postfix 2.7.0-1ubuntu0.2
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to postfix in Ubuntu.
https://bugs.launchpad.net/bugs/799109
Title:
package postfix 2.7.0-1ubuntu0.2 failed to install/upgrade: le sous-
processus script post-installation installé a
Public bug reported:
Binary package hint: postfix
upgrade are not made completely
package postfix 2.7.0-1ubuntu0.2 failed to install / upgrade: subprocess
post-installation script returned error exit status 75
package postfix 2.7.0-1ubuntu0.2 failed to install/upgrade: le sous-
processus
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to postfix in Ubuntu.
https://bugs.launchpad.net/bugs/794994
Title:
package postfix 2.7.0-1ubuntu0.2 failed to install/upgrade: le sous-
processus script post-installation installé a
1. the specific steps or actions you took that caused you to encounter
the problem,
$ man ntptrace
$ ntptrace -v
2. the behavior you expected, and
I expect the man page to be accurate and ideally, useful. Right now
it's mostly neither.
3. the behavior you actually encountered (in as much
1. Is this reproducible?
Since the bug was created so long ago, I don't recall any more detail
than above. Sorry...
Running in VMware Server 1.x VMs under some conditions makes time in the
VM run really oddly. Perhaps the above hit a race condition where:
1) ntpd polled and time was OK
2)
