Note: This is time critical. If I cannot find a solution within the next
couple days, I will have to either rip apparmor out by the roots or
switch to Debian... a week from now I will be 8000 miles from this
machine, so by definition it will be operating properly before then...
--
You received
# virsh dumpxml myhost..org
domain type='qemu'
namemyhost.org/name
uuid6445bf42-7513-985a-7920-9e89a4c42ffe/uuid
memory unit='KiB'524288/memory
currentMemory unit='KiB'524288/currentMemory
vcpu placement='static'1/vcpu
os
type arch='i686' machine='pc-1.0'hvm/type
boot
Oh my. I would call that a bug. True, I can do a workaround to cover my
immediate emergency, I will probably have to change my disk structure
since the root disk is intentionally pretty small... but what if I were
running hundreds or thousands of VM's? And even worse, on another system
(which is
I would worry that my small complaints are the least of your worries. If
someone with a very large farm of VM's happens to update to this
version... you could be hearing from someone with thousands of screaming
customers. It would not be surprising to me if someone with large
systems had their own
Okay, I used the suggested hack and changed my mount point from lib4 to
srv. I have my VM up so I am sorted. But I only have a handful. I would
hate to be in shoes of the person responsible for this change if someone
is so foolish as to upgrade a critical system without lab testing the
upgrade
I have the same issue. I brought up a machine with a de novo install of
Quantal server amd64.
I transferred a VM from the old server that is out of service by moving the
disk containing. Made the one edit
change to the xml of the VM so that path to its main disk was correct in the
new
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/919666
Title:
configuratoin example uses authentication and encryption parameters
which may not be available
To manage notifications about this bug
Public bug reported:
If you uncomment the example for d_net and use the line as is, it will fail:
Error parsing afsocket, syntax error, unexpected LL_IDENTIFIER, expecting ')'
in /etc/syslog-ng/syslog-ng.conf at line 78, column 48:
destination d_net { tcp(127.0.0.1 port(1000) authentication(on)
*** This bug is a duplicate of bug 309656 ***
https://bugs.launchpad.net/bugs/309656
I hit the same bug. Usually if there is a problem I can simply take the
sessionstore.bak file and overwrite sessionstore.js to recover but that
is not working.
I really need to get this all back because I
I hit the same bug in today's update. Usually if there is a problem I
can simply take the sessionstore.bak file and overwrite sessionstore.js
to recover but that is not working.
I really need to get this all back because I have two Firefox windows,
each with about 10-15 open tabs related to my
I have a recovery process for you, but it requires that you have
immediately saved your old sessionstore.bak, or have a way to get one
from your company backup system.
cd .mozilla/firefox/your current profile/
your current profile will probably have a name like
'wzy9plsu.default'. If there are
Same problem in karmic. There are no rc files for udev. I can delete and
do the mknod to correct it but it goes away on reboot. I have gone
through my root .bash* files and removed umask just in case. rm'ing the
file, doing the mknod with 0666 and manually restarting through init.d
scripts gives
I have the same problem here (amongst others). I have both error
messages discussed. The first is in the normal logs from the boot up:
Dec 20 20:57:38 mourne console-kit-daemon[875]: WARNING: Couldn't read
/proc/858/environ: Failed to open file '/proc/858/environ': No such
file or directory
I
13 matches
Mail list logo
