I see you ran it in your comment above, but was it immediately after the
error happened or some time later?
--
tgtd target will not start unless it's configured with allow-in-use yes
https://bugs.launchpad.net/bugs/605721
You received this bug notification because you are a member of Ubuntu
Hmm looking at the code I think its buggy. I'm not sure what it is
actually trying to do but it doesn't seem to be doing it right in any
case. It appears to be 8 bit shifting left, and then checking for 0. If
the device is in use lsof returns 0 if it is not then it returns 1, at
least as best as I
It appears to be a bug caused by using this:
system(lsof $backing_store /dev/null);
instead of:
system(lsof $backing_store /dev/null 21);
--
tgtd target will not start unless it's configured with allow-in-use yes
https://bugs.launchpad.net/bugs/605721
You
I was confused earlier about the direction of bitshift since the wrong
calling convention was causing it to always return 0.
--
tgtd target will not start unless it's configured with allow-in-use yes
https://bugs.launchpad.net/bugs/605721
You received this bug notification because you are a
Forgot the # in the closes line in the upload. It was fixed in tgt
1:1.0.4-1ubuntu3
** Changed in: tgt (Ubuntu Maverick)
Status: Triaged = Fix Released
--
tgtd target will not start unless it's configured with allow-in-use yes
https://bugs.launchpad.net/bugs/605721
You received this bug
The fix from upstream appears to work. This bug can be closed out once
the fix goes into Maverick and will be in a ppa for alpha-2 testing from
what Tim has said on IRC.
Thanks for all the help Tim!
--
pad block corrupted error when trying to register an image with 2.6.34 kernel
won't fix per hallyn
** Changed in: libvirt (Ubuntu)
Status: New = Won't Fix
--
Please stop disabling the VMware ESX driver
https://bugs.launchpad.net/bugs/565771
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to libvirt in ubuntu.
sendfile is used by openjdk-6 directly in the following file:
http://pastebin.com/tceugS7r
--
pad block corrupted error when trying to register an image with 2.6.34 kernel
https://bugs.launchpad.net/bugs/588861
You received this bug notification because you are a member of Ubuntu
Server Team,
During test of the following kernel it prints the following to dmesg
once for each pass:
ae0f36f0b964caf916c2ffc9f84b28c0f91c18a2-maverick
[ 365.268713] /home/rtg/kern/maverick/kern-64/ubuntu-
maverick/fs/read_write.c:849 should this happen?
--
pad block corrupted error when trying to
0a87a0c1b12f56bd556fd4506041966717c87fb1-maverick
failed as expected
[ 129.980324]
/home/rtg/kern/maverick/kern-64/ubuntu-maverick/fs/read_write.c:849
816256e0 (null)
[ 178.931445]
/home/rtg/kern/maverick/kern-64/ubuntu-maverick/fs/read_write.c:849
816256e0 (null)
[
Works with 23eb3b64b5e44680c867e165fe1cd18e57fba255 (required compile
fix, probably the same one as Tim mentioned earlier).
--
pad block corrupted error when trying to register an image with 2.6.34 kernel
https://bugs.launchpad.net/bugs/588861
You received this bug notification because you are a
He appears to have made another update related to sendfile on May 26.
However, I am not sure if it fixes this problem or that it has been
applied to mainline yet.
http://marc.info/?a=119980668900012r=1w=2
--
pad block corrupted error when trying to register an image with 2.6.34 kernel
Tracked down to occurring in 2.6.33rc1, so will be checking between that
and 2.6.32-15.5
--
pad block corrupted error when trying to register an image with 2.6.34 kernel
https://bugs.launchpad.net/bugs/588861
You received this bug notification because you are a member of Ubuntu
Server Team,
After changing my test to just be registering the images per Dave's
recommendation I was able to come up with this list:
I tested the following kernels, 10 times each:
Passed:
v2.6.32 (10/10)
v2.6.32.15.5-lucid (10/10)
Failed:
v2.6.33 (10/10)
v2.6.34-rc3-maverick (10/10)
v2.6.34-lucid (09/10)
Should this bug be reopened, since we reverted the patch? It seems
incorrect to leave it marked Fix Released as least, either Triaged or
Won't Fix seem better.
--
[SRU] euca-get-console-output gives first 64k of output, not most recent
https://bugs.launchpad.net/bugs/566793
You received this bug
works:
Linux beagle 2.6.32-020632-generic #020632 SMP Thu Dec 3 10:09:58 UTC 2009
x86_64 GNU/Linux
Linux beagle 2.6.32-0206321505-generic #0206321505 SMP Wed Jun 2 19:09:40 UTC
2010 x86_64 GNU/Linux
bad:
Linux beagle 2.6.33-020633-generic #020633 SMP Thu Feb 25 10:10:03 UTC
2010 x86_64
Hmm I tried 2.6.33 again just to be certain and now it is working on
2.6.33, hmm :-\
--
pad block corrupted error when trying to register an image with 2.6.34 kernel
https://bugs.launchpad.net/bugs/588861
You received this bug notification because you are a member of Ubuntu
Server Team, which is
I now can't get it to crash anymore. I am upgrading from maverick alpha
1 to current and then will do further testing.
--
pad block corrupted error when trying to register an image with 2.6.34 kernel
https://bugs.launchpad.net/bugs/588861
You received this bug notification because you are a
I tried upgrading to current and now I can't see my nc anymore. :-\
--
pad block corrupted error when trying to register an image with 2.6.34 kernel
https://bugs.launchpad.net/bugs/588861
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to
** Description changed:
Eucalyptus versions:
ii eucalyptus-common 1.6.2-0ubuntu30.1
ii eucalyptus-java-common1.6.2-0ubuntu30.1
ii eucalyptus-sc 1.6.2-0ubuntu30.1
Bug 430846 and bug 498174 partially dealt with this issue. But, on an SC
This appears to have worked for me up to 50 1GB volumes (actually
allocated 52) then it started failing giving me the error in the log
file:
Your proposed upload exceeds the maximum allowed object size.
(edu.ucsb.eucalyptus.cloud.EntityTooLargeException)
I have plenty of space on my physical
The above issue was caused by having my UEC set to 50GB limit for
volumes. I changed it to 200GB under Configuration - Clusters - Disk
space reserved for volumes and it allowed me to create 194 of them.
It then started having problems from what appears to be a different but
related bug of not
My removal errors are probably related to 517086, but the creation error
appears to be new according to C de-Avillez, it is failing at vgcreate,
example follows:
12:32:54 DEBUG [SystemUtil:pool-10-thread-4] Running command:
///usr/lib/eucalyptus/euca_rootwrap dd if=/dev/zero
I manually ran:
# /usr/lib/eucalyptus/euca_rootwrap vgcreate vg-6E6tMQ.. /dev/loop93
Volume group vg-6E6tMQ.. successfully created
So I am not sure what is going on.
--
SC: Maximum number of loop devices should be configurable
https://bugs.launchpad.net/bugs/586134
You received this bug
Actually my volume removal errors seem to be different than the other
bug at least in several of the cases I have looked at. They are also
lvremove issues like the vgcreate ones.
---
12:53:57 DEBUG [SystemUtil:pool-10-thread-5] Running command:
///usr/lib/eucalyptus/euca_rootwrap lvremove -f
Public bug reported:
When testing out bug 586134 I found another issue and although similar
to bug 517086 appears not to be the same issue.
If you create for example 200 1GB volumes like this:
for i in `seq 1 200` ; do euca-create-volume -z cluster1 -s 1 ; done
You will end up with quite a few
This might actually be a problem with lvm, but even if it is caused by
lvm it should still be properly caught by eucalyptus so that if the
delete volume failure happens it will show up in euca-describe-volumes
** Also affects: eucalyptus (Ubuntu Lucid)
Importance: Undecided
Status: New
So this bug regarding loop devices seems to be fixed but there is a new
bug 590929 opened about the problems with creating/deleting volumes
having problems with lvm.
--
SC: Maximum number of loop devices should be configurable
https://bugs.launchpad.net/bugs/586134
You received this bug
This appears to be caused by eucalyptus not checking the return values
it gets.
--
eucalyptus create and delete volumes sometimes fail on lvm commands
https://bugs.launchpad.net/bugs/590929
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to
And to top it off lvm does not document its return codes, at least not
in the man pages anyway.
--
eucalyptus create and delete volumes sometimes fail on lvm commands
https://bugs.launchpad.net/bugs/590929
You received this bug notification because you are a member of Ubuntu
Server Team, which
It appears lvm always returns error code 5 on failure... for any kind of
failure. So I'm not sure exactly what we should do here to fix this
problem. Often the problem is actually just a can't get lock issue like
the following, but without having a useful error code we can't know when
to retry or
http://fedoraproject.org/wiki/LVM/liblvm
--
eucalyptus create and delete volumes sometimes fail on lvm commands
https://bugs.launchpad.net/bugs/590929
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to eucalyptus in ubuntu.
--
It appears the liblvm library is in newer lvm2 source which is in Debian
unstable. Whether converting eucalyptus to it is actually needed and/or
if it would be enough to help fix these sorts of issues is still
unknown. From a cursory look it appears it may be useful.
--
eucalyptus create and
It seems its not so much the not checking for the return code as not
doing the right thing afterwards. If it receives an error it appears to
just throw an exception and does not clean up after itself, at least for
the createLogicalVolume case.
--
eucalyptus create and delete volumes sometimes
** Changed in: samba (Ubuntu Lucid)
Status: New = Invalid
** Changed in: samba (Ubuntu)
Status: New = Invalid
** Changed in: samba (Ubuntu Lucid)
Milestone: ubuntu-10.04.1 = None
** Changed in: samba (Ubuntu)
Importance: High = Undecided
** Changed in: samba (Ubuntu Lucid)
I didn't use ctrl-c vm-builder just bombed out probably due to other
bugs and didn't clean up the resulting mess, and I couldn't figure out
how to clean it up later without rebooting.
--
vm-builder 0.12.3-0ubuntu1 crashes and causes loop devices to be stuck
https://bugs.launchpad.net/bugs/583530
Public bug reported:
The vmbuilder manpage mentions a --tmp option to allow using other than
/tmp but it does not actually work when you try to use it with vmbuilder
kvm ubuntu, this is probably for similar reasons to bug 536940.
** Affects: vm-builder (Ubuntu)
Importance: Undecided
Public bug reported:
Binary package hint: samba
This doesn't affect me directly but I maintain OpenOffice.org for
Ubuntu.
It appears after getting numerous reports that OOo does not save
properly to cifs mounted filesystems that the cause is due to the fact
the 'nobrl' option is not being used.
** Attachment added: CifsVersion.txt
http://launchpadlibrarian.net/48733924/CifsVersion.txt
** Attachment added: Dependencies.txt
http://launchpadlibrarian.net/48733925/Dependencies.txt
** Attachment added: SambaInstalledVersions.txt
I found that we do have a way to disable locking entirely for cifs in
OOo that we can use if this bug isn't considered good or safe to fix by
enabling nobrl.
--
OOo needs mount.cifs to default to nobrl if possible
https://bugs.launchpad.net/bugs/582925
You received this bug notification because
The workaround for OOo required updating coreutils to detect cifs which
I have added a patch for in bug 582980.
--
OOo needs mount.cifs to default to nobrl if possible
https://bugs.launchpad.net/bugs/582925
You received this bug notification because you are a member of Ubuntu
Server Team, which
This appears to be some sort of KVM issue, or at least it isn't
reproducible anywhere else.
** Summary changed:
- oosplash.bin crashed with SIGSEGV in splash_create_window()
+ oosplash.bin crashed with SIGSEGV in splash_create_window() under KVM
** Package changed: openoffice.org (Ubuntu) = kvm
42 matches
Mail list logo
