[Bug 908856] Re: Error: Unpack requires a string argument of length 4
I've since updated from F16 to F18 (and all the kernel/driver updates that entails) on the same hardware, and it appears the problem no longer occurs for me. I verified it works with or without the workaround in place. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/908856 Title: Error: Unpack requires a string argument of length 4 To manage notifications about this bug go to: https://bugs.launchpad.net/disper/+bug/908856/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 908856] Re: Error: Unpack requires a string argument of length 4
Same problem on F16 (x86_64) with Thinkpad W520 (set to discrete, using 2 external and internal off)... After playing around a bit I found in my case decode (in minx.py) is getting down to the unpack call with s0I format and 4 null bytes of data, but the sz is being set to 1. So, the unpack fails since it's only getting 1 byte worth of data (data[:sz]) when it needs 4. So, for a q -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/908856 Title: Error: Unpack requires a string argument of length 4 To manage notifications about this bug go to: https://bugs.launchpad.net/disper/+bug/908856/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 908856] Re: Error: Unpack requires a string argument of length 4
Er, so, for a quick workaround I stuck a sanity check to reset sz to the necessary format size if it was too low, and then things seem to consistently work for me (sorry, not a python guy)... --- /usr/share/disper/src/nvidia/minx.py2012-01-17 14:13:47.0 -0700 +++ /usr/share/disper/src/nvidia/minx.py2012-04-26 17:27:43.909106422 -0600 @@ -124,6 +124,8 @@ asz = rdict[arg.size] sz = asz * fsz + if sz struct.calcsize(structcode): + sz = struct.calcsize(structcode) if asz == 1: rdict[arg.value] = struct.unpack( structcode, data[:sz] )[0] -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/908856 Title: Error: Unpack requires a string argument of length 4 To manage notifications about this bug go to: https://bugs.launchpad.net/disper/+bug/908856/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 908856] Re: Error: Unpack requires a string argument of length 4
Now, that's not a proper solution (should check the data length is long enough), but hopefully it helps identify the issue of why sz isn't getting set properly. (And sorry for the comment spam, as edit would be nice.) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/908856 Title: Error: Unpack requires a string argument of length 4 To manage notifications about this bug go to: https://bugs.launchpad.net/disper/+bug/908856/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 580184] Re: Instance without public ip fails reading metadata with separate CC CLC
Sorry, I haven't worked with Eucalyptus since so don't know if this issue was ever resolved. Unless the designed changed somewhat, however, I would have expected it to be a problem for everyone using separate CC CLC with private addressing and managed mode, as the metadata service keys off public IP. If it's not a general issue then most must be avoiding that set of conditions, or it was addressed. -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to eucalyptus in Ubuntu. https://bugs.launchpad.net/bugs/580184 Title: Instance without public ip fails reading metadata with separate CC CLC To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/eucalyptus/+bug/580184/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 580184] Re: Instance without public ip fails reading metadata with separate CC CLC
Sorry, I haven't worked with Eucalyptus since so don't know if this issue was ever resolved. Unless the designed changed somewhat, however, I would have expected it to be a problem for everyone using separate CC CLC with private addressing and managed mode, as the metadata service keys off public IP. If it's not a general issue then most must be avoiding that set of conditions, or it was addressed. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/580184 Title: Instance without public ip fails reading metadata with separate CC CLC To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/eucalyptus/+bug/580184/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 566792] Re: metadata service returns empty data with 200 OK
Scott Moser wrote on 2010-05-20: (MANAGED modes). In order for the meta-data service to work, the VM needs to be assigned a public IP, and it looks like this operation is failing (indicated by the fact that the public/private IPs being reported are both from the private IP subnet). That is interesting. Does that mean the meta-data service would not work for instance started with --addressing private? I happen to from experience that it does work for addressing private. My guess is that Eucalyptus especially takes care of the case where '--addressing private' was used. Scott, were the CC CLC the same host when it worked for you? I don't see how it could ever work with --addressing-private if they're separate, and Daniel's comment seems to confirm. Since it doesn't inject the key using the non-MANAGED way when in MANAGED mode, it seems we need add a fix for private IP instances. It seems this specific bug may be around the fact that a host with a public IP isn't getting it nat'd properly by the CC. But the issue of a private-only IP instance not being able to get metadata may be separate (see bug 580184). -- metadata service returns empty data with 200 OK https://bugs.launchpad.net/bugs/566792 You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to eucalyptus in ubuntu. -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 580184] Re: Instance without public ip fails reading metadata with separate CC CLC
Indeed, I've never had it work with separate CC CLC for an instance without a public IP (see my comment #28 in bug 566792). -- Instance without public ip fails reading metadata with separate CC CLC https://bugs.launchpad.net/bugs/580184 You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to eucalyptus in ubuntu. -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 566792] Re: metadata service returns empty data with 200 OK
Scott Moser wrote on 2010-05-20: (MANAGED modes). In order for the meta-data service to work, the VM needs to be assigned a public IP, and it looks like this operation is failing (indicated by the fact that the public/private IPs being reported are both from the private IP subnet). That is interesting. Does that mean the meta-data service would not work for instance started with --addressing private? I happen to from experience that it does work for addressing private. My guess is that Eucalyptus especially takes care of the case where '--addressing private' was used. Scott, were the CC CLC the same host when it worked for you? I don't see how it could ever work with --addressing-private if they're separate, and Daniel's comment seems to confirm. Since it doesn't inject the key using the non-MANAGED way when in MANAGED mode, it seems we need add a fix for private IP instances. It seems this specific bug may be around the fact that a host with a public IP isn't getting it nat'd properly by the CC. But the issue of a private-only IP instance not being able to get metadata may be separate (see bug 580184). -- metadata service returns empty data with 200 OK https://bugs.launchpad.net/bugs/566792 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 580184] Re: Instance without public ip fails reading metadata with separate CC CLC
Indeed, I've never had it work with separate CC CLC for an instance without a public IP (see my comment #28 in bug 566792). -- Instance without public ip fails reading metadata with separate CC CLC https://bugs.launchpad.net/bugs/580184 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 585207] [NEW] Error: getAll is not defined Source File: http://espn.go.com/sportsnation/polls Line: 515
Public bug reported: Binary package hint: firefox problem occurs in lucid lynx not in windows xp its been going on since I downloaded lynx ProblemType: Bug DistroRelease: Ubuntu 10.04 Package: firefox 3.6.3+nobinonly-0ubuntu4 ProcVersionSignature: Ubuntu 2.6.32-22.33-generic 2.6.32.11+drm33.2 Uname: Linux 2.6.32-22-generic i686 NonfreeKernelModules: nvidia Architecture: i386 CheckboxSubmission: bea4239f8bb40f266031fd5edbc6cf03 CheckboxSystem: abf102d6ef41328208f5c1554651535a Date: Mon May 24 21:32:03 2010 FirefoxPackages: firefox 3.6.3+nobinonly-0ubuntu4 firefox-gnome-support 3.6.3+nobinonly-0ubuntu4 firefox-branding 3.6.3+nobinonly-0ubuntu4 abroswer N/A abrowser-branding N/A ProcEnviron: LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: firefox ** Affects: firefox (Ubuntu) Importance: Undecided Status: Incomplete ** Tags: apport-bug i386 lucid -- Error: getAll is not defined Source File: http://espn.go.com/sportsnation/polls Line: 515 https://bugs.launchpad.net/bugs/585207 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 585207] Re: Error: getAll is not defined Source File: http://espn.go.com/sportsnation/polls Line: 515
** Attachment added: Dependencies.txt http://launchpadlibrarian.net/49050297/Dependencies.txt ** Attachment added: ExtensionSummary.txt http://launchpadlibrarian.net/49050298/ExtensionSummary.txt ** Attachment added: profile_default_pluginreg.dat.txt http://launchpadlibrarian.net/49050299/profile_default_pluginreg.dat.txt ** Attachment added: profiles.ini.txt http://launchpadlibrarian.net/49050300/profiles.ini.txt -- Error: getAll is not defined Source File: http://espn.go.com/sportsnation/polls Line: 515 https://bugs.launchpad.net/bugs/585207 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 556511] Re: evince crashed after opening an encrypted pdf
Confirmed I also see this seg fault on passworded docs which opened fine on 9.10 but now fail after upgrade to 10.4... -- evince crashed after opening an encrypted pdf https://bugs.launchpad.net/bugs/556511 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 580184] [NEW] Instance without public ip fails reading metadata with separate CC CLC
Public bug reported: With separate CC and CLC, when an instance without a public address (in MANAGED[_NOVLAN] mode) attempts to contact the metadata service to get its ssh key, the CC reroutes the request to the CLC and masquerades the requestor's address. So the CLC appears to get the metadata request from the CC address and doesn't properly respond (how can it identify which instance is asking?), whereas a request from an instance with a public ip shows up as coming from that public ip (since the CC nat's the public/private address and doesn't masquerade it). For example: CC+SC: 10.0.0.1 CLC+WALRUS: 10.0.0.2 VNET_MODE=MANAGED_NOVLAN VNET_SUBNET=172.16.0.0 VNET_CLOUDIP=10.0.0.2 A private instance (no public ip) is created as 172.16.1.1. On boot it queries (in /etc/rc.local) to http://169.254.169.254/latest/meta-data /public-keys/0/openssh-key for it's ssh key. The 169.254.169.254 address is bound on the CC (10.0.0.1), which has a DNAT rule redirecting HTTP to the CLC (10.0.0.2:8773). The CC masquerades the instance's private IP as itself (as it must, since the CLC isn't on the private network) and forwards the request. The CLC then gets the request, but the source IP address is 10.0.0.1 (the CC's address) and it doesn't reply with the key. Without the ssh key you then can't ssh to the private instance (either from the CC or another public/private host in the subnet). In contrast, a public instance is created as 172.16.1.2 with public ip 10.0.0.3. It makes the same HTTP request which gets redirected through the CC to the CLC. The CC, however, applies SNAT and DNAT rules which make the request appear as coming from 10.0.0.3 (the instance public IP) and the CLC properly responds to the request since it can identify the source instance. And there was much rejoicing... ** Affects: eucalyptus (Ubuntu) Importance: Undecided Status: New -- Instance without public ip fails reading metadata with separate CC CLC https://bugs.launchpad.net/bugs/580184 You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to eucalyptus in ubuntu. -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 580184] [NEW] Instance without public ip fails reading metadata with separate CC CLC
Public bug reported: With separate CC and CLC, when an instance without a public address (in MANAGED[_NOVLAN] mode) attempts to contact the metadata service to get its ssh key, the CC reroutes the request to the CLC and masquerades the requestor's address. So the CLC appears to get the metadata request from the CC address and doesn't properly respond (how can it identify which instance is asking?), whereas a request from an instance with a public ip shows up as coming from that public ip (since the CC nat's the public/private address and doesn't masquerade it). For example: CC+SC: 10.0.0.1 CLC+WALRUS: 10.0.0.2 VNET_MODE=MANAGED_NOVLAN VNET_SUBNET=172.16.0.0 VNET_CLOUDIP=10.0.0.2 A private instance (no public ip) is created as 172.16.1.1. On boot it queries (in /etc/rc.local) to http://169.254.169.254/latest/meta-data /public-keys/0/openssh-key for it's ssh key. The 169.254.169.254 address is bound on the CC (10.0.0.1), which has a DNAT rule redirecting HTTP to the CLC (10.0.0.2:8773). The CC masquerades the instance's private IP as itself (as it must, since the CLC isn't on the private network) and forwards the request. The CLC then gets the request, but the source IP address is 10.0.0.1 (the CC's address) and it doesn't reply with the key. Without the ssh key you then can't ssh to the private instance (either from the CC or another public/private host in the subnet). In contrast, a public instance is created as 172.16.1.2 with public ip 10.0.0.3. It makes the same HTTP request which gets redirected through the CC to the CLC. The CC, however, applies SNAT and DNAT rules which make the request appear as coming from 10.0.0.3 (the instance public IP) and the CLC properly responds to the request since it can identify the source instance. And there was much rejoicing... ** Affects: eucalyptus (Ubuntu) Importance: Undecided Status: New -- Instance without public ip fails reading metadata with separate CC CLC https://bugs.launchpad.net/bugs/580184 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
