Yes, same for me. Setting back to confirmed.
bind9-host 1:9.10.3.dfsg.P2-5, not sure why out package numbers differ.
** Changed in: bind9 (Ubuntu)
Status: Fix Released => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed
Correction 1: Stefan not Stephan, sorry.
Correction 2: Things broke down about another 1/2 day after the lease times
changes to 1 hour. The client didn't seem to release this and resorted to
broadcast type discover stuff. Then it was getting leases for 5 minutes, and
the cycle continued until I
>From Stephan comment 14:
"Hm, of course, if one starts dhclient in debug mode (foreground) by
adding a "-d", everything does work."
Yes, that does seem to work, but only for about another day, at least in
my case. Thereafter, my ISP stopped returning my domain name, host name
and some other
1:9.10.3.dfsg.P2-5 has the same issue, but the apparmor issue is fixed.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to bind9 in Ubuntu.
https://bugs.launchpad.net/bugs/1549788
Title:
bind9 9.10.3.dfsg.P2-4 crash on exit
To manage
Same for me:
Feb 29 14:45:51 DOUG-64 named[1202]: connection refused resolving
'19.82.133.155.in-addr.arpa/PTR/IN': 37.59.161.64#53
Feb 29 15:35:01 DOUG-64 systemd[1]: Stopping BIND Domain Name Server...
Feb 29 15:35:01 DOUG-64 named[1202]: received control channel command 'stop'
Feb 29 15:35:01
Yes, isc-dhcp - 4.3.3-5ubuntu8 fixes the issue with the dhclient stuff
that caused this:
Feb 26 14:05:21 DOUG-64 kernel: [ 17.518717] audit: type=1400
audit(1456524321.220:10): apparmor="DENIED" operation="open"
profile="/sbin/dhclient" name="/etc/ssl/openssl.cnf" pid=483
comm="dhclient"
** Changed in: pm-utils (Ubuntu)
Status: Incomplete => Invalid
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to pm-utils in Ubuntu.
https://bugs.launchpad.net/bugs/1493156
Title:
pm-suspend aborts if highest numbered CPU
I think, but am not sure, this bug report is the root issue for failure
of the daily server 64 iso installation when "samba server" is selected.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to samba in Ubuntu.
As of kernel 4.4-rc1 this bug becomes invalid, as the kernel was patched such
that this issue no longer occurs.
I'll wait until kernel 4.4 is finished, check again, then set the status of
this bug report to invalid.
--
You received this bug notification because you are a member of Ubuntu
Public bug reported:
Kernel 4.2 includes a significant commit
(87549141d516aee71d511138e27117c41e8aef68), after the patch the files
and directory are present even if the CPU is offline. If the CPU is
offline, writing to those files isn't allowed and so the echo in
94cpufreq fails.
If the failed
, just use primitive
commands and not these higher level utilities (that I neither use or
know anything about). For example use:
grep MHz /proc/cpuinfo
to observe CPU frequencies.
The commit that, I think, fixes this issue is:
commit 6c1e45917dec5e7c99ba8125fd8cc50f6e482a21
Author: Doug Smythies
Chad wrote:
Xavier wrote that this needs to be moved somewhere else.
Does anyone know how to do that?
If someone can explain to me what needs to happen,
I changed the trusty target from 14.04.2 (which is in the past) to
14.04.3 (which is in the future, albeit, not far off)
** Changed in:
@Coeur: I entered this bug report over 11 months ago, and have simply
ignored the error ever since. I haven't had any problems.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to samba in Ubuntu.
https://bugs.launchpad.net/bugs/1257186
It is the configuration file that is incorrect, not the serverguide, so I am
setting this one to invalid for the serverguide.
However, I also checked the trusty and utoptic master files, and they are O.K.
References:
are you connecting to a vncserver service running within the guest VM?
Or are you connecting to the qemu VNC head on the server which hosts the
virtual machines?
I connect to the host server IP address port 5900.
Also, on which host and environment are you seeing the 'low graphics
mode' dialog
By the way, if I do the opposite: On an new Ubuntu 14.04 server installation
with a newly installed guest Ubuntu dekstop; Use virsh edit and change the
machine type to pc-1.0, then the quest VM has the same issues upon login.
The information requested above:
doug@s15:~$ dpkg -l | egrep
I agree with the summary change to pc 1.0 machine type regressed with
-vga vmware:
And confirm via two new VM desktop guest installations. One was on a
14.04 server host upgraded from from a 12.04 server. The other was on a
new 14.04 server. In both cases the machine type was forced on the
Serge,
Thanks for the information and the link to even more useful information.
So, specifying vram size doesn't work, that is both good to know and
explains some things.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to qemu in Ubuntu.
My comment may not apply to this, but I'll make it anyhow:
I upgraded my host server from ubuntu 12.04 to 14.04. Afterwards, none
of my desktop VM's worked (I haven't even tried the server VM's yet). I
made a new guest VM using the exact same virst-install command I had
used for the original VM
Public bug reported:
I upgraded my host server from ubuntu 12.04 to 14.04. Afterwards, none
of my desktop VM's worked (I haven't even tried the server VM's yet).
During login the VM's complained about being unable to detect the
graphics card (screenshot will be posted). Proceeding results in a
** Attachment added: screen shot of low graphics message box
https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1308756/+attachment/4085756/+files/1404-vm-low-graphics.png
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to qemu in
** Attachment added: screen shot of resulting jibberish screen
https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1308756/+attachment/4085757/+files/1404-vm-jibberish.png
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to qemu in
** Attachment added: a typical .xml file
https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1308756/+attachment/4085765/+files/desk_tt.xml.txt
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to qemu in Ubuntu.
** Attachment added: a typical xml file, installed under a 12.04 host.
https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1308756/+attachment/4085766/+files/desk_ss.xml.txt
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to qemu in
All the differences in xml files, one from installing a new guest VM on
a 12.04 server as the host and one installing the same guest again from
the same server upgraded / updated to a 14.04 server host.
** Attachment added: All differences between 12.04 and 14.04 host xml file
The update of yesterday fixes issues I was having with vmvga.
qemu-keymaps 2.0~git-20140317.2bda660-0ubuntu1 all
QEMU keyboard maps
qemu-kvm 2.0~git-20140317.2bda660-0ubuntu1 amd64
QEMU Full virtualization on x86 hardware
Public bug reported:
This message appears a lot as of a recent update to samba (Trusty
development branch):
no talloc stackframe at ../source3/param/loadparm.c:4831, leaking memory
From this upstream bug report, I am lead to believe the issue is in
libpam-smbpass, but I don't really know for
27 matches
Mail list logo
