[Bug 1434760] [NEW] package openstack-dashboard-ubuntu-theme 1:2014.2.2-0ubuntu1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1
Public bug reported: Running ubuntu studio... ProblemType: Package DistroRelease: Ubuntu 14.10 Package: openstack-dashboard-ubuntu-theme 1:2014.2.2-0ubuntu1 ProcVersionSignature: Ubuntu 3.16.0-31.43-lowlatency 3.16.7-ckt5 Uname: Linux 3.16.0-31-lowlatency x86_64 ApportVersion: 2.14.7-0ubuntu8.2 Architecture: amd64 Date: Fri Mar 20 22:40:37 2015 DuplicateSignature: package:openstack-dashboard-ubuntu-theme:1:2014.2.2-0ubuntu1:subprocess installed post-installation script returned error exit status 1 ErrorMessage: subprocess installed post-installation script returned error exit status 1 PackageArchitecture: all SourcePackage: horizon Title: package openstack-dashboard-ubuntu-theme 1:2014.2.2-0ubuntu1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1 UpgradeStatus: No upgrade log present (probably fresh install) ** Affects: horizon (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-package utopic -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to horizon in Ubuntu. https://bugs.launchpad.net/bugs/1434760 Title: package openstack-dashboard-ubuntu-theme 1:2014.2.2-0ubuntu1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/horizon/+bug/1434760/+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 1434760] Re: package openstack-dashboard-ubuntu-theme 1:2014.2.2-0ubuntu1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1
** Tags removed: need-duplicate-check -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to horizon in Ubuntu. https://bugs.launchpad.net/bugs/1434760 Title: package openstack-dashboard-ubuntu-theme 1:2014.2.2-0ubuntu1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/horizon/+bug/1434760/+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 1313231] Re: [systemd] nut-client systemd unit fails when unconfigured
** Changed in: nut (Debian) Status: Confirmed => Fix Released -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to nut in Ubuntu. https://bugs.launchpad.net/bugs/1313231 Title: [systemd] nut-client systemd unit fails when unconfigured To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/nut/+bug/1313231/+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 1434758] [NEW] mysqld: errno: 24 - Too many open files
Public bug reported: After upgrading to 15.04 mysql cannot set the file limit and so it doesn't work well. /var/log/mysql/error.log shows the following: [Warning] Buffered warning: Changed limits: max_open_files: 1024 (requested 5000) [Warning] Buffered warning: Changed limits: table_cache: 431 (requested 2000) [ERROR] /usr/sbin/mysqld: Can't open file: ... (errno: 24 - Too many open files) The issue looks to be related to the recent switch to systemd indeed if I start using upstart everything work fine. I found out similar issues reported on Debian and the general suggestion is to add following line to the `mysqld.service` anyway this file is not present on my installation : LimitNOFILE=infinity LimitMEMLOCK=infinity Other distro stores this file in `/usr/lib/systemd/system/mysqld.service` I'm not sure how Ubuntu is managing this, maybe with file in dir /etc/default/ ? I have also tried adding following lines in /etc/security/limits.conf, but the problem persist: mysql soft nofile 65535 mysql hard nofile 65535 ProblemType: Bug DistroRelease: Ubuntu 15.04 Package: mysql-server (not installed) Uname: Linux 3.19.2-031902-generic x86_64 ApportVersion: 2.16.2-0ubuntu4 Architecture: amd64 CurrentDesktop: Unity Date: Sat Mar 21 10:17:00 2015 InstallationDate: Installed on 2014-03-10 (375 days ago) InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Alpha amd64 (20140309) SourcePackage: mysql-5.5 UpgradeStatus: Upgraded to vivid on 2015-03-20 (0 days ago) ** Affects: mysql-5.5 (Ubuntu) Importance: Undecided Status: New ** Affects: systemd (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug mysqld systemd-boot vivid ** Also affects: systemd (Ubuntu) Importance: Undecided Status: New ** Summary changed: - mysqld & systemd - errno: 24 - Too many open files + mysql: errno: 24 - Too many open files ** Summary changed: - mysql: errno: 24 - Too many open files + mysqld: errno: 24 - Too many open files ** Tags added: systemd-boot ** Description changed: After upgrading to 15.04 mysql cannot set the file limit and so it doesn't work well. /var/log/mysql/error.log shows the following: [Warning] Buffered warning: Changed limits: max_open_files: 1024 (requested 5000) [Warning] Buffered warning: Changed limits: table_cache: 431 (requested 2000) [ERROR] /usr/sbin/mysqld: Can't open file: ... (errno: 24 - Too many open files) The issue looks to be related to the recent switch to systemd indeed if I start using upstart everything work fine. I found out similar issues reported on Debian and the general suggestion is to add following line to the `mysqld.service` anyway this file is not present on my installation : LimitNOFILE=infinity LimitMEMLOCK=infinity + Other distro stores this file in `/usr/lib/systemd/system/mysqld.service` + I'm not sure how Ubuntu is managing this, maybe with file in dir /etc/default/ ? + + I have also tried adding following lines in /etc/security/limits.conf, + but the problem persist: + + mysql soft nofile 65535 + mysql hard nofile 65535 + ProblemType: Bug DistroRelease: Ubuntu 15.04 Package: mysql-server (not installed) Uname: Linux 3.19.2-031902-generic x86_64 ApportVersion: 2.16.2-0ubuntu4 Architecture: amd64 CurrentDesktop: Unity Date: Sat Mar 21 10:17:00 2015 InstallationDate: Installed on 2014-03-10 (375 days ago) InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Alpha amd64 (20140309) SourcePackage: mysql-5.5 UpgradeStatus: Upgraded to vivid on 2015-03-20 (0 days ago) -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to mysql-5.5 in Ubuntu. https://bugs.launchpad.net/bugs/1434758 Title: mysqld: errno: 24 - Too many open files To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mysql-5.5/+bug/1434758/+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 1103353] Re: Invalid GnuTLS cipher suite strings causes libldap to crash
I just now noted the remark above suggesting the remedy to programs which crash abort when having a string parsing error is to not feed it strings it doesn't like. I suppose, mutatis mutandis, were the string one 99 of 100 leave defaulted it could be overlooked. However does anyone really think the string configuring the allowed ciphers isn't tweaked every few months in any serious deployment? -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to openldap in Ubuntu. https://bugs.launchpad.net/bugs/1103353 Title: Invalid GnuTLS cipher suite strings causes libldap to crash To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1103353/+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 1103353] Re: Invalid GnuTLS cipher suite strings causes libldap to crash
If this were a library used in a game or a bug in a screensaver I could see letting a formatting error in a string crash abort any program using the library sit for a year. I'm staggered really to experience this for a package as widely touted as gnutls, contending to be a replacement for openssl, and especially in a business supporting group like ubuntu that aims for site installs. I think this 11-month 'maintainers have higher priorities' event is a strong sign gnutls just is so not ready for mission critical deployment that whatever priority it may have on launchpad--- in the maintainers minds this is a 'might fix, won't deploy'. I've compiled it against openssl, and it's solid. Though I've stuck with ubuntu for many years now I have to agree with the sentiment upstream: this is a confidence buster. -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to openldap in Ubuntu. https://bugs.launchpad.net/bugs/1103353 Title: Invalid GnuTLS cipher suite strings causes libldap to crash To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1103353/+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 1103353] Re: Invalid GnuTLS cipher suite strings causes libldap to crash
Well, considering that Ubuntu openldap maintainers consider e.g. CVE-2013-4449 (denial-of-service, 2.4.31 to 2.4.36 are vulnerable) not important enough to patch or update to a later openldap version, I expect there to be zero chance of this bug to be patched either. It seems that if it does not hurt the maintainers' systems, it's not worth fixing. The current Ubuntu version I am using right now, 14.04 LTS, is certainly the last Ubuntu version I will be using. I am still evaluating the alternatives, but definitely all Debian jessie derivatives are straight out. I won't be monitoring this bug anymore, either. ** CVE added: http://www.cve.mitre.org/cgi- bin/cvename.cgi?name=2013-4449 -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to openldap in Ubuntu. https://bugs.launchpad.net/bugs/1103353 Title: Invalid GnuTLS cipher suite strings causes libldap to crash To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1103353/+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 1434068] Re: Please upgrade to 0.9.5
This bug was fixed in the package migrate - 0.9.5-0ubuntu1 --- migrate (0.9.5-0ubuntu1) vivid; urgency=medium * New upstream point release (LP: #1434068) supporting OpenStack Kilo-3: - d/p/fix-migrate-regressions.patch: Dropped, no longer required. - d/control: Add BD on python-sqlparse and python-tempest-lib. -- James PageFri, 20 Mar 2015 19:49:30 + ** Changed in: migrate (Ubuntu) Status: In Progress => Fix Released -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to migrate in Ubuntu. https://bugs.launchpad.net/bugs/1434068 Title: Please upgrade to 0.9.5 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/migrate/+bug/1434068/+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 1427950] Re: find or install suitable dependencies / maas + curtin with vivid image fails to import yaml
** Description changed: - curtin can run in python3 or python2. its only python dependency is - yaml. + === Begin SRU Template === + [Impact] + In its current state, maas is unable to install vivid/14.10 using curtin. + This is obviously quite serious as users using LTS server can then not + install the Ubuntu development release for testing. + + The failure is fallout of there not being 'python2-yaml' in a maas ephemeral + image (which is used for curtin install environment). The fix is that + curtin is now able to run with either python2 or python3 and finds the + appropriate/available python on the system. + + [Test Case] + Generally, the test case flow is: + * Install MAAS + * import boot resources using the 'daily' stream. + * attempt to install a node with vivid + * see install fail, with message about unable to find 'curtin.commands.main' + + I've documented and walked through installation of maas and use of + libvirt and qemu to test in + maas-1.7 http://bazaar.launchpad.net/~smoser/maas/maas-pkg-test/view/head:/maas-trusty-1.7.txt + maas-1.5 http://bazaar.launchpad.net/~smoser/maas/maas-pkg-test/view/head:/maas-trusty-1.5.txt + + + [Regression Potential] + The potential failure path is in one of 2 paths: + a.) curtin being broken on python3 + b.) curtin's launcher selecting the wrong python + + Curtin basically has 3 dependencies: + python (or python3) + python-yaml (or python3-yaml) + oauth or oauthlib + + These are satisfied in the image by: + precise: python2 (which has no python3 executable) + trusty: python2 (which has python3 executable but no python3-yaml) + vivid: python3 (which has python2 executable but no python-yaml) + + Oauthlib or oauth is satisfied by the same python (riding on dependencies of + cloud-init). curtin does not currently check for that library, but + missing library does not cause failure, just failure to report status + back to maas. That said, in all supported use cases it will be fine. + + === End SRU Template === + + + curtin can run in python3 or python2. its only python dependency is yaml. maas-images of 12.04 do not have python3. maas-images of 15.04 do not have python-yaml (python2) future images might not have any python2. right now maas invokes curtin thorugh cloud-init user-data. curtin packs itself into a self extracting executable, is transferred via user-data and invoked inside the image. Sending it through the user-data means that the maas server being updated is all that is necessary to deliver new curtin (rather than SRU to each release). Right now, in vivid that means that curtin tries to run with python2 and thus fails to import yaml. Basically curtin can't really depend on anything that isn't in ubuntu maas image (cloud-iamge derived). And, it doesn't get installed via apt. A couple solutions here: a.) a mechanism in curtin to run with python3 or python2, and just go on as is. on new cloud-images curtin will get the python3-yaml (a dependency of cloud-init) and in older versions it would run with python2. A '$python -m curtin.checkdeps' would be run as a way to determine which python to run, b.) get python-yaml into maas images and use python2. c.) allow curtin to 'apt-get install' its deps. note, this has the unfortunate dependency on doing that, and then having more io and network traffic and such during an install if the image doesn't contain python-yaml or other things. Note, though, that curtin (or maas) changes that are made in order to support use of vivid would then need to be SRU'd, where as changes to the vivid image itself would not. - Related bugs: - * Bug 1434679: maas 1.5 does not know about vivid + * Bug 1434679: maas 1.5 does not know about vivid -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to curtin in Ubuntu. https://bugs.launchpad.net/bugs/1427950 Title: find or install suitable dependencies / maas + curtin with vivid image fails to import yaml To manage notifications about this bug go to: https://bugs.launchpad.net/curtin/+bug/1427950/+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 1409639] Re: juju needs to support systemd for >= vivid
** Changed in: juju-core Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to juju-core in Ubuntu. https://bugs.launchpad.net/bugs/1409639 Title: juju needs to support systemd for >= vivid To manage notifications about this bug go to: https://bugs.launchpad.net/juju-core/+bug/1409639/+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 1434679] Re: maas does not know about vivid
** Tags added: patch -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to maas in Ubuntu. https://bugs.launchpad.net/bugs/1434679 Title: maas does not know about vivid To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1434679/+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 1434068] Re: Please upgrade to 0.9.5
** Branch linked: lp:ubuntu/vivid-proposed/migrate -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to migrate in Ubuntu. https://bugs.launchpad.net/bugs/1434068 Title: Please upgrade to 0.9.5 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/migrate/+bug/1434068/+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 1434684] Re: Pacemaker is not started and stopped automatically with Corosync
** Description changed:
In Ubuntu 12.04 with:
# dpkg -l |egrep "pacemaker|corosync"
ii corosync 1.4.2-2ubuntu0.2
Standards-based cluster framework (daemon and modules)
ii pacemaker1.1.6-2ubuntu3.3 HA
cluster resource manager
When I start corosync, it'll start the pacemaker resources:
# ps aux |egrep "(heartbeat|corosync)"
root 27043 0.2 0.0 511172 3756 ?Ssl 19:43 0:00
/usr/sbin/corosync
root 27051 0.0 0.0 84716 3124 ?S19:43 0:00
/usr/lib/heartbeat/stonithd
109 27052 0.1 0.1 88768 5856 ?S19:43 0:00
/usr/lib/heartbeat/cib
root 27053 0.1 0.0 97432 3256 ?S19:43 0:00
/usr/lib/heartbeat/lrmd
109 27054 0.0 0.0 84756 3364 ?S19:43 0:00
/usr/lib/heartbeat/attrd
109 27055 0.0 0.0 79040 2872 ?S19:43 0:00
/usr/lib/heartbeat/pengine
109 27056 0.0 0.0 95476 4028 ?S19:43 0:00
/usr/lib/heartbeat/crmd
When I stop corosync, it'll stop them as well.
In Ubuntu 14.04 with:
# dpkg -l |egrep "pacemaker|corosync"
ii corosync2.3.3-1ubuntu1
amd64Standards-based cluster framework (daemon and modules)
ii crmsh 1.2.5+hg1034-1ubuntu4all
CRM shell for the pacemaker cluster manager
ii libcorosync-common4 2.3.3-1ubuntu1
amd64Standards-based cluster framework, common library
ii pacemaker 1.1.10+git20130802-1ubuntu2.3
amd64HA cluster resource manager
ii pacemaker-cli-utils 1.1.10+git20130802-1ubuntu2.3
amd64Command line interface utilities for Pacemaker
When I start corosync, it will NOT start the pacemaker resources. I need
to start pacemaker manually (service pacemaker start or
/etc/init.d/pacemaker start).
This results in nothing working until I figured that out. Yielding errors
such as:
---
# crm status
Could not establish cib_ro connection: Connection refused (111)
ERROR: crm_mon exited with code 107 and said: Connection to cluster failed:
Transport endpoint is not connected
---
# crm_mon
Attempting connection to the cluster...Could not establish cib_ro connection:
Connection refused (111)
---
+ In my testing, both the precise and trusty releases had Pacemaker in the
service.d directory as such:
+ ---
+ service {
+ name: pacemaker
+ ver: 0
+ }
+ ---
+
Is this a bug or is it expected that Pacemaker is no longer started and
stopped by corosync ?
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to corosync in Ubuntu.
https://bugs.launchpad.net/bugs/1434684
Title:
Pacemaker is not started and stopped automatically with Corosync
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/corosync/+bug/1434684/+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 1434068] Re: Please upgrade to 0.9.5
This update resolves dropping constraints with sqlite backed migrations - so much needed. -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to migrate in Ubuntu. https://bugs.launchpad.net/bugs/1434068 Title: Please upgrade to 0.9.5 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/migrate/+bug/1434068/+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 1434684] [NEW] Pacemaker is not started and stopped automatically with Corosync
Public bug reported: In Ubuntu 12.04 with: # dpkg -l |egrep "pacemaker|corosync" ii corosync 1.4.2-2ubuntu0.2 Standards-based cluster framework (daemon and modules) ii pacemaker1.1.6-2ubuntu3.3 HA cluster resource manager When I start corosync, it'll start the pacemaker resources: # ps aux |egrep "(heartbeat|corosync)" root 27043 0.2 0.0 511172 3756 ?Ssl 19:43 0:00 /usr/sbin/corosync root 27051 0.0 0.0 84716 3124 ?S19:43 0:00 /usr/lib/heartbeat/stonithd 109 27052 0.1 0.1 88768 5856 ?S19:43 0:00 /usr/lib/heartbeat/cib root 27053 0.1 0.0 97432 3256 ?S19:43 0:00 /usr/lib/heartbeat/lrmd 109 27054 0.0 0.0 84756 3364 ?S19:43 0:00 /usr/lib/heartbeat/attrd 109 27055 0.0 0.0 79040 2872 ?S19:43 0:00 /usr/lib/heartbeat/pengine 109 27056 0.0 0.0 95476 4028 ?S19:43 0:00 /usr/lib/heartbeat/crmd When I stop corosync, it'll stop them as well. In Ubuntu 14.04 with: # dpkg -l |egrep "pacemaker|corosync" ii corosync2.3.3-1ubuntu1 amd64 Standards-based cluster framework (daemon and modules) ii crmsh 1.2.5+hg1034-1ubuntu4all CRM shell for the pacemaker cluster manager ii libcorosync-common4 2.3.3-1ubuntu1 amd64 Standards-based cluster framework, common library ii pacemaker 1.1.10+git20130802-1ubuntu2.3amd64 HA cluster resource manager ii pacemaker-cli-utils 1.1.10+git20130802-1ubuntu2.3amd64 Command line interface utilities for Pacemaker When I start corosync, it will NOT start the pacemaker resources. I need to start pacemaker manually (service pacemaker start or /etc/init.d/pacemaker start). This results in nothing working until I figured that out. Yielding errors such as: --- # crm status Could not establish cib_ro connection: Connection refused (111) ERROR: crm_mon exited with code 107 and said: Connection to cluster failed: Transport endpoint is not connected --- # crm_mon Attempting connection to the cluster...Could not establish cib_ro connection: Connection refused (111) --- Is this a bug or is it expected that Pacemaker is no longer started and stopped by corosync ? ** Affects: corosync (Ubuntu) Importance: Undecided Status: New ** Summary changed: - Pacemaker is not started automatically with Corosync + Pacemaker is not started and stopped automatically with Corosync -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to corosync in Ubuntu. https://bugs.launchpad.net/bugs/1434684 Title: Pacemaker is not started and stopped automatically with Corosync To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/corosync/+bug/1434684/+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
Re: [Bug 1303903] Re: sgdisk zap/clear doesn't wipe all GPT tables
On Fri, Mar 20, 2015 at 1:02 PM, Roderick Smith
wrote:
> Examining the code, there are several sgdisk calls, but two are relevant
> for this discussion. The first is the one reproduced in this initial bug
> report:
>
> sgdisk --zap-all --clear --mbrtogpt
>
> This call does not seem to have been changed as a result of bug
> #1257491. Upon further review, I think I see why it's written this way:
> When "sgdisk --zap-all --clear" is fed an MBR disk, sgdisk wipes the
> disk but then refuses to create a blank GPT because it still thinks it's
> dealing with an MBR disk. This is a bug and I'll fix it soon. Adding
> --mbrtogpt works around this bug and results in a blank GPT disk.
>
OK. There wasn't much context in the changelog to charm-helpers for that
change, but
I'm assuming one of the ceph tools didn't like getting a non-blank GPT disk
and
appending mbrtogpt resolved that. But that left the case where a GPT disk
was
fed to lvm2 pvcreate which will refuse to work with a disk that has any
partition table (MBR or GPT)
Which led to filing this bug.
>
> The call that bug #1257491 resulted in changing was elsewhere in the
> script, from lines 840 to 856 at
> http://ceph.com/git/?p=ceph.git;a=blob;f=src/ceph-
> disk;h=f771a68c2f9d873710cbe380d702fd0baa725da9;hb=HEAD#l840:
>
> sgdisk --new={part} --change-name={num}:ceph journal --partition-
> guid={num}:{journal_uuid} --typecode={num}:{uuid} journal
>
> It was to THIS call that --mbrtogpt was added, if I've backtracked it
> correctly. Again, I don't understand the context, but my guess is that
> sgdisk was being called on an MBR disk. By default, sgdisk will refuse
> to write data to an MBR disk. This is a safety feature, in case it's
> called carelessly on an MBR disk that should NOT be converted to GPT
> form; but of course if a script doesn't know whether the input will be
> GPT or MBR but the intent of the script is to write out a GPT disk,
> having sgdisk convert the data structures makes sense, so --mbrtogpt
> exists.
>
Indeed. In our use-case the physical disks on the machine get reused for
different purposes from run to run, so
we definitely encountered the case where sgdisk performed as requested, but
ultimately we needed
something to handle clearing the entire disk regardless of initial state
and leaving nothing behind (no MBR, no GPT).
Is there such a call to sgdisk to do so?
>
> So in sum, sgdisk does have a bug, but it's not the one assumed. The
> charm described here was written to work around the bug, and I believe
> you've misinterpreted the expected output of the relevant sgdisk
> command.
>
OK. The end goal was to have a call to sgdisk (or something else) that
would
ensure that the disk looked blank/unused such that the different tools used
to
initialize the disk all worked correctly.
If there is a correct call to sgdisk to handle both MBR and GPT disks and
to
cleaning wipe the drive then we can mark this bug as invalid (I'll leave you
to open the other bug you mentioned)
Ryan
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to gdisk in Ubuntu.
https://bugs.launchpad.net/bugs/1303903
Title:
sgdisk zap/clear doesn't wipe all GPT tables
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gdisk/+bug/1303903/+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 1434679] [NEW] maas does not know about vivid
Public bug reported: maas in trusty right now does not know about vivid. This is fixed in maas 1.7 that it automatically knows about new ubuntu releases, but maas in our LTS does not. The offending file is: /usr/lib/python2.7/dist- packages/maasserver/enum.py this was fixed upstream under bug 1233713. I found this bug when verifying the changes for bug 1427950 work with maas in trusty proper. Scott ProblemType: Bug DistroRelease: Ubuntu 14.04 Package: python-django-maas 1.5.4+bzr2294-0ubuntu1.3 [modified: usr/lib/python2.7/dist-packages/maasserver/enum.py] ProcVersionSignature: Ubuntu 3.13.0-46.79-generic 3.13.11-ckt15 Uname: Linux 3.13.0-46-generic x86_64 NonfreeKernelModules: vhost_net vhost macvtap macvlan veth xt_conntrack ipt_REJECT ip6table_filter ip6_tables ebtable_nat ebtables kvm_intel xt_CHECKSUM iptable_mangle ipt_MASQUERADE iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack xt_tcpudp bridge stp llc iptable_filter ip_tables x_tables ib_iser rdma_cm iw_cm ib_cm ib_sa ib_mad ib_core ib_addr iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi dm_crypt intel_powerclamp coretemp kvm joydev ioatdma serio_raw shpchp gpio_ich i7core_edac edac_core lpc_ich dca mac_hid hid_generic usbhid hid e1000e ptp ahci psmouse pata_acpi libahci pps_core ApportVersion: 2.14.1-0ubuntu3.7 Architecture: amd64 Date: Fri Mar 20 19:17:48 2015 PackageArchitecture: all ProcEnviron: TERM=screen PATH=(custom, no user) LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: maas UpgradeStatus: No upgrade log present (probably fresh install) ** Affects: maas (Ubuntu) Importance: Critical Status: Confirmed ** Tags: amd64 apport-bug third-party-packages trusty -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to maas in Ubuntu. https://bugs.launchpad.net/bugs/1434679 Title: maas does not know about vivid To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1434679/+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 1427950] Re: find or install suitable dependencies / maas + curtin with vivid image fails to import yaml
** Description changed: curtin can run in python3 or python2. its only python dependency is yaml. maas-images of 12.04 do not have python3. maas-images of 15.04 do not have python-yaml (python2) future images might not have any python2. right now maas invokes curtin thorugh cloud-init user-data. curtin packs itself into a self extracting executable, is transferred via user-data and invoked inside the image. Sending it through the user-data means that the maas server being updated is all that is necessary to deliver new curtin (rather than SRU to each release). Right now, in vivid that means that curtin tries to run with python2 and thus fails to import yaml. Basically curtin can't really depend on anything that isn't in ubuntu maas image (cloud-iamge derived). And, it doesn't get installed via apt. A couple solutions here: a.) a mechanism in curtin to run with python3 or python2, and just go on as is. on new cloud-images curtin will get the python3-yaml (a dependency of cloud-init) and in older versions it would run with python2. A '$python -m curtin.checkdeps' would be run as a way to determine which python to run, b.) get python-yaml into maas images and use python2. c.) allow curtin to 'apt-get install' its deps. note, this has the unfortunate dependency on doing that, and then having more io and network traffic and such during an install if the image doesn't contain python-yaml or other things. Note, though, that curtin (or maas) changes that are made in order to support use of vivid would then need to be SRU'd, where as changes to the vivid image itself would not. + + + Related bugs: + * Bug 1434679: maas 1.5 does not know about vivid -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to curtin in Ubuntu. https://bugs.launchpad.net/bugs/1427950 Title: find or install suitable dependencies / maas + curtin with vivid image fails to import yaml To manage notifications about this bug go to: https://bugs.launchpad.net/curtin/+bug/1427950/+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 1434679] Re: maas does not know about vivid
Attaching suggested fix. ** Patch added: "suggested fix" https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1434679/+attachment/4350852/+files/lp-1434679.patch ** Changed in: maas (Ubuntu) Status: New => Confirmed ** Changed in: maas (Ubuntu) Importance: Undecided => Critical ** Description changed: maas in trusty right now does not know about vivid. - This is fixed in maas 1.7 that it automatically knows about new ubuntu releases, but maas in our LTS does not. + This is fixed in maas 1.7 that it automatically knows about new ubuntu releases, but maas in our LTS does not. The offending file is: /usr/lib/python2.7/dist- packages/maasserver/enum.py this was fixed upstream under bug 1233713. + + I found this bug when verifying the changes for bug 1427950 work with + maas in trusty proper. Scott ProblemType: Bug DistroRelease: Ubuntu 14.04 Package: python-django-maas 1.5.4+bzr2294-0ubuntu1.3 [modified: usr/lib/python2.7/dist-packages/maasserver/enum.py] ProcVersionSignature: Ubuntu 3.13.0-46.79-generic 3.13.11-ckt15 Uname: Linux 3.13.0-46-generic x86_64 NonfreeKernelModules: vhost_net vhost macvtap macvlan veth xt_conntrack ipt_REJECT ip6table_filter ip6_tables ebtable_nat ebtables kvm_intel xt_CHECKSUM iptable_mangle ipt_MASQUERADE iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack xt_tcpudp bridge stp llc iptable_filter ip_tables x_tables ib_iser rdma_cm iw_cm ib_cm ib_sa ib_mad ib_core ib_addr iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi dm_crypt intel_powerclamp coretemp kvm joydev ioatdma serio_raw shpchp gpio_ich i7core_edac edac_core lpc_ich dca mac_hid hid_generic usbhid hid e1000e ptp ahci psmouse pata_acpi libahci pps_core ApportVersion: 2.14.1-0ubuntu3.7 Architecture: amd64 Date: Fri Mar 20 19:17:48 2015 PackageArchitecture: all ProcEnviron: - TERM=screen - PATH=(custom, no user) - LANG=en_US.UTF-8 - SHELL=/bin/bash + TERM=screen + PATH=(custom, no user) + LANG=en_US.UTF-8 + SHELL=/bin/bash SourcePackage: maas UpgradeStatus: No upgrade log present (probably fresh install) -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to maas in Ubuntu. https://bugs.launchpad.net/bugs/1434679 Title: maas does not know about vivid To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1434679/+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 1431650] Re: Multipath devices take long to initialize during initramfs
> Well, not necessarily. The swap issue is the same as the rootfs one Ah, yes, you're right. I was thinking with the assumption that the workaround/patch for the timeout was in place. Indeed, if it's not in place, there'll be no swap nor anything multipath'ed at all. In the particular case the workaround/patch is applied, what I've seen is a job waiting/timing out for the swap device (now) incorrectly specified in /etc/fstab. Thanks for pointing that out. > The debdiff looks quite good; I'll add in the removal of scsi_wait_device which is just useless (that module no longer exists). Cool :) thanks! -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to multipath-tools in Ubuntu. https://bugs.launchpad.net/bugs/1431650 Title: Multipath devices take long to initialize during initramfs To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/multipath-tools/+bug/1431650/+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 1431650] Re: Multipath devices take long to initialize during initramfs
Well, not necessarily. The swap issue is the same as the rootfs one-- at some point multipath times out, and other init jobs would also timeout trying to bring up the swap (which can't be identified from the UUID) whereas the rootfs got brought up on a single path using the UUID. The debdiff looks quite good; I'll add in the removal of scsi_wait_device which is just useless (that module no longer exists). -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to multipath-tools in Ubuntu. https://bugs.launchpad.net/bugs/1431650 Title: Multipath devices take long to initialize during initramfs To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/multipath-tools/+bug/1431650/+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 1434261] Re: udev keeps a lock on devices while multipath-tools runs in initramfs
*** This bug is a duplicate of bug 1431650 *** https://bugs.launchpad.net/bugs/1431650 ** This bug has been marked a duplicate of bug 1431650 Multipath devices take long to initialize during initramfs -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to multipath-tools in Ubuntu. https://bugs.launchpad.net/bugs/1434261 Title: udev keeps a lock on devices while multipath-tools runs in initramfs To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/multipath-tools/+bug/1434261/+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 1434247] Re: [FFE] Upstream patches to Libvirt for vivid
@Mark, looking at the patches, the require mm-ctl to be installed on the build machine. When I type 'mm-ctl' on the command line on my viivd laptop, command-not-found does not know of any package which would supply it. So adding these patches to libvirt, right now, would not give you the functionality. Installing whatever package provides mmctl on your target machine would *not* suffice, because the path to it needs to have been detected by AC_PATH_PROG at build time. Where does mm-clt come from? ** No longer affects: linux (Ubuntu Vivid) ** Changed in: libvirt (Ubuntu Vivid) Importance: Undecided => High ** Changed in: libvirt (Ubuntu Vivid) Status: New => Incomplete -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to libvirt in Ubuntu. https://bugs.launchpad.net/bugs/1434247 Title: [FFE] Upstream patches to Libvirt for vivid To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1434247/+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 1303903] Re: sgdisk zap/clear doesn't wipe all GPT tables
Examining the code, there are several sgdisk calls, but two are relevant
for this discussion. The first is the one reproduced in this initial bug
report:
sgdisk --zap-all --clear --mbrtogpt
This call does not seem to have been changed as a result of bug
#1257491. Upon further review, I think I see why it's written this way:
When "sgdisk --zap-all --clear" is fed an MBR disk, sgdisk wipes the
disk but then refuses to create a blank GPT because it still thinks it's
dealing with an MBR disk. This is a bug and I'll fix it soon. Adding
--mbrtogpt works around this bug and results in a blank GPT disk.
The call that bug #1257491 resulted in changing was elsewhere in the
script, from lines 840 to 856 at
http://ceph.com/git/?p=ceph.git;a=blob;f=src/ceph-
disk;h=f771a68c2f9d873710cbe380d702fd0baa725da9;hb=HEAD#l840:
sgdisk --new={part} --change-name={num}:ceph journal --partition-
guid={num}:{journal_uuid} --typecode={num}:{uuid} journal
It was to THIS call that --mbrtogpt was added, if I've backtracked it
correctly. Again, I don't understand the context, but my guess is that
sgdisk was being called on an MBR disk. By default, sgdisk will refuse
to write data to an MBR disk. This is a safety feature, in case it's
called carelessly on an MBR disk that should NOT be converted to GPT
form; but of course if a script doesn't know whether the input will be
GPT or MBR but the intent of the script is to write out a GPT disk,
having sgdisk convert the data structures makes sense, so --mbrtogpt
exists.
So in sum, sgdisk does have a bug, but it's not the one assumed. The
charm described here was written to work around the bug, and I believe
you've misinterpreted the expected output of the relevant sgdisk
command.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to gdisk in Ubuntu.
https://bugs.launchpad.net/bugs/1303903
Title:
sgdisk zap/clear doesn't wipe all GPT tables
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gdisk/+bug/1303903/+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 1422125] Re: ntpdate[634]: no servers can be used, exiting
Latest systemd upgrade has fixed that issue: systemd (219-4ubuntu8) vivid; urgency=medium * force ifup@ to run after systemd-tmpfiles-setup as ifupdown operations require /run/network which is being created by tmpfiles (LP: #1434020). -- Scott Moser Fri, 20 Mar 2015 09:48:23 -0400 ** Changed in: ntp (Ubuntu) Status: New => Fix Released -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to ntp in Ubuntu. https://bugs.launchpad.net/bugs/1422125 Title: ntpdate[634]: no servers can be used, exiting To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/1422125/+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
Re: [Bug 1303903] Re: sgdisk zap/clear doesn't wipe all GPT tables
On Wed, Mar 18, 2015 at 12:59 PM, Roderick Smith wrote: > This is not a bug in sgdisk; it's either a bug in the charm or an > incorrect use of same. Specifically, the sgdisk command shown is: > > sgdisk --zap-all --clear --mbrtogpt /dev/vdb > > This command does four things, in sequence: > > - It zaps all GPT and MBR data structures (--zap-all). > - It creates an empty GPT data structure (--clear). > - It OKs the conversion of any MBR data structure to GPT form (--mbrtogpt). > - It writes the resulting changes to disk. (This is implicit in most uses > of sgdisk.) > > The first and second of those options are both used to wipe data, but in > different ways -- --zap-all zeroes out all the sectors of the disk used > by the GPT data structures, whereas --clear erases the partitions but > leaves the data structures intact. Using --clear after --zap-all should > therefore have the same effect as using --clear alone. (There may be > cases where --zap-all would be necessary if you're dealing with a > damaged disk, but I'd need to study this some more to be sure.) In any > event, the end result of those two commands is a GPT disk with no > partitions defined, not a disk without a partition table. > > The --mbrtogpt option is useless in this context. It should be used when > you want to convert an MBR disk to GPT form, but as the preceding > options set the disk up as GPT, --mbrtogpt does nothing. > > If the goal is to completely erase all partition data, including the > partition table itself, the following command should be used: > > sgdisk --zap-all /dev/vdb > Thanks for the clarification. Looking into the charm-helpers history it appears there was some creep in use of the command. Originally it was as above, --zap-all DEVICE, This bug was encountered: https://bugs.launchpad.net/ubuntu-advantage/+bug/1257491 Which then introduced the use of --mbrtogpt Further errors were encountered and --clear was added, which resulted in re-writing of an empty, but clear partition. Knowing now that it writes out an empty, but present GPT table then issues manifested itself in a separate case; when this disk was re-used to create an LVM, the empty but present GPT table prevented LVM from using the device. Backing up then, the question is why doesn't --zap-all work for bug 1257491? If that can be resolved then we can remove the mbrtogpt and clear altogether and ensure that nothing is present on the disk so it can be used for ceph or lvm block services. Ryan -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to gdisk in Ubuntu. https://bugs.launchpad.net/bugs/1303903 Title: sgdisk zap/clear doesn't wipe all GPT tables To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gdisk/+bug/1303903/+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 1433365] Re: Merge jakarta-taglibs-standard 1.1.2-3 (main) from Debian unstable (main)
This bug was fixed in the package jakarta-taglibs-standard - 1.1.2-3ubuntu1 --- jakarta-taglibs-standard (1.1.2-3ubuntu1) vivid; urgency=low * Merge from Debian unstable. (LP: #1433365) Remaining changes: - debian/ant.properties, debian/control, debian/rules: + Transition from servlet 2.5 -> 3.0. (Closes: #780701) jakarta-taglibs-standard (1.1.2-3) unstable; urgency=high * Team upload. * Fix CVE-2015-0254 XXE and RCE via XSL extension in JSTL XML tags: - Introduce new patch: d/patches/CVE-2015-0254.patch. - Adjust source and target JVM parameters to 1.5. (Closes: #779621). -- Artur RonaWed, 18 Mar 2015 01:11:43 +0100 ** Changed in: jakarta-taglibs-standard (Ubuntu) Status: Confirmed => Fix Released -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to jakarta-taglibs-standard in Ubuntu. https://bugs.launchpad.net/bugs/1433365 Title: Merge jakarta-taglibs-standard 1.1.2-3 (main) from Debian unstable (main) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/jakarta-taglibs-standard/+bug/1433365/+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 1431650] Re: Multipath devices take long to initialize during initramfs
The attachment "multipath-tools_shared-lock.debdiff" seems to be a debdiff. The ubuntu-sponsors team has been subscribed to the bug report so that they can review and hopefully sponsor the debdiff. If the attachment isn't a patch, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are member of the ~ubuntu-sponsors, unsubscribe the team. [This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issue please contact him.] ** Tags added: patch -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to multipath-tools in Ubuntu. https://bugs.launchpad.net/bugs/1431650 Title: Multipath devices take long to initialize during initramfs To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/multipath-tools/+bug/1431650/+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 1433365] Re: Merge jakarta-taglibs-standard 1.1.2-3 (main) from Debian unstable (main)
** Branch linked: lp:~ubuntu-branches/ubuntu/vivid/jakarta-taglibs- standard/vivid-proposed -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to jakarta-taglibs-standard in Ubuntu. https://bugs.launchpad.net/bugs/1433365 Title: Merge jakarta-taglibs-standard 1.1.2-3 (main) from Debian unstable (main) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/jakarta-taglibs-standard/+bug/1433365/+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 1434068] Re: Please upgrade to 0.9.5
** Changed in: migrate (Ubuntu) Milestone: later => ubuntu-15.03 -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to migrate in Ubuntu. https://bugs.launchpad.net/bugs/1434068 Title: Please upgrade to 0.9.5 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/migrate/+bug/1434068/+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 1292234] Re: qcow2 image corruption on non-extent filesystems (ext3)
Sent email to upstream stable to apply this bug to affected kernels. -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to qemu in Ubuntu. https://bugs.launchpad.net/bugs/1292234 Title: qcow2 image corruption on non-extent filesystems (ext3) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1292234/+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 1434300] Re: Merge exim4 4.84-8 (main) from Debian unstable (main)
** Patch added: "debian-ubuntu.debdiff" https://bugs.launchpad.net/ubuntu/+source/exim4/+bug/1434300/+attachment/4350740/+files/debian-ubuntu.debdiff -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to exim4 in Ubuntu. https://bugs.launchpad.net/bugs/1434300 Title: Merge exim4 4.84-8 (main) from Debian unstable (main) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/exim4/+bug/1434300/+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 1434300] Re: Merge exim4 4.84-8 (main) from Debian unstable (main)
** Patch added: "ubuntu-ubuntu.debdiff" https://bugs.launchpad.net/ubuntu/+source/exim4/+bug/1434300/+attachment/4350741/+files/ubuntu-ubuntu.debdiff ** Changed in: exim4 (Ubuntu) Importance: Undecided => Low ** Changed in: exim4 (Ubuntu) Status: New => Confirmed -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to exim4 in Ubuntu. https://bugs.launchpad.net/bugs/1434300 Title: Merge exim4 4.84-8 (main) from Debian unstable (main) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/exim4/+bug/1434300/+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 1434575] Re: [SRU] OpenStack test updates to support PEP 476
** Branch linked: lp:~corey.bryant/keystone/2014.1.4 -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to cinder in Ubuntu. https://bugs.launchpad.net/bugs/1434575 Title: [SRU] OpenStack test updates to support PEP 476 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cinder/+bug/1434575/+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 1434068] Re: Please upgrade to 0.9.5
Required for glance kilo-3. ** Changed in: migrate (Ubuntu) Assignee: Chuck Short (zulcss) => James Page (james-page) ** Changed in: migrate (Ubuntu) Status: Triaged => In Progress -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to migrate in Ubuntu. https://bugs.launchpad.net/bugs/1434068 Title: Please upgrade to 0.9.5 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/migrate/+bug/1434068/+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 1410383] Re: wrong process name match in logrotate script
** Also affects: puppet (Debian) via http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=780847 Importance: Unknown Status: Unknown ** Branch linked: lp:~bartoszcisek/ubuntu/vivid/puppet/bug-1410383 -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to puppet in Ubuntu. https://bugs.launchpad.net/bugs/1410383 Title: wrong process name match in logrotate script To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/puppet/+bug/1410383/+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 1421787] Re: /etc/init.d/spamassassin reload fails unless /var/run/spamd/ exists for pid file
Hi there, I solved my problem with the spamassassin. It was a combination of more that one problem (anything else would be boring ;) ). First one was the missing spamd.pid-file (solution see above). Second: I changed "qmgr" and "pickup" at "/etc/postfix/master.cf". qmgr fifo n - n 1 1 qmgr pickup fifo n - - 60 1 pickup It has to be "fifo" instead of "unix"? Then restart postfix ( service postfix restart or /etc/init.d/postfix restart ). (http://forum.sp.parallels.com/threads/postfix-master-connection-refused.303699/) Third and last I changed the rsyslog" at "/etc/logrotate.d to "solve issues with wrong owner rights after the logrotation" from: postrotate reload rsyslog >/dev/null 2>&1 || true endscript to: postrotate reload rsyslog >/dev/null 2>&1 || true endscript su root root And here is the long Version: http://forum.sp.parallels.com/threads/spamd-sighup-not-working-options-changed.332300/ st. -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to spamassassin in Ubuntu. https://bugs.launchpad.net/bugs/1421787 Title: /etc/init.d/spamassassin reload fails unless /var/run/spamd/ exists for pid file To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/spamassassin/+bug/1421787/+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 1292234] Re: qcow2 image corruption on non-extent filesystems (ext3)
** Description changed: [Impact] Users of non-extent ext4 filesystems (ext4 ^extents, or ext3 w/ CONFIG_EXT4_USE_FOR_EXT23=y) can encounter data corruption when using fallocate with FALLOC_FL_PUNCH_HOLE | FALLOC_FL_KEEP_SIZE flags. [Test Case] 1) Setup ext4 ^extents, or ext3 filesystem with CONFIG_EXT4_USE_FOR_EXT23=y 2) Create and install a VM using a qcow2 image and store the file on the filesystem 3) Snapshot the image with qemu-img 4) Boot the image and do some disk operations (fio,etc) 5) Shutdown image and delete snapshot 6) Repeat 3-5 until VM no longer boots due to image corruption, generally this takes a few iterations depending on disk operations. [Fix] - This is being discussed upstream here: + commit 6f30b7e37a8239f9d27db626a1d3427bc7951908 upstream + + This has been discussed upstream here: http://marc.info/?l=linux-fsdevel&m=142264422605440&w=2 A temporary fix would be to disable punch_hole for non-extent filesystem. This is how the normal ext3 module handles this and it is up to userspace to handle the failure. I've run this with the test case and was able to run for 600 iterations over 3 days where most failures occur within the first 2-20 iterations. diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c index 5653fa4..e14cdfe 100644 --- a/fs/ext4/inode.c +++ b/fs/ext4/inode.c @@ -3367,6 +3367,10 @@ int ext4_punch_hole(struct inode *inode, loff_t offset, loff_t length) unsigned int credits; int ret = 0; + /* EXTENTS required */ + if (!(ext4_test_inode_flag(inode, EXT4_INODE_EXTENTS))) + return -EOPNOTSUPP; + if (!S_ISREG(inode->i_mode)) return -EOPNOTSUPP; -- The security team uses a tool (http://bazaar.launchpad.net/~ubuntu- bugcontrol/ubuntu-qa-tools/master/view/head:/vm-tools/uvt) that uses libvirt snapshots quite a bit. I noticed after upgrading to trusty some time ago that qemu 1.7 (and the qemu 2.0 in the candidate ppa) has had stability problems such that the disk/partition table seems to be corrupted after removing a libvirt snapshot and then creating another with the same name. I don't have a very simple reproducer, but had enough that hallyn suggested I file a bug. First off: qemu-kvm 2.0~git-20140307.4c288ac-0ubuntu2 $ cat /proc/version_signature Ubuntu 3.13.0-16.36-generic 3.13.5 $ qemu-img info ./forhallyn-trusty-amd64.img image: ./forhallyn-trusty-amd64.img file format: qcow2 virtual size: 8.0G (8589934592 bytes) disk size: 4.0G cluster_size: 65536 Format specific information: compat: 0.10 Steps to reproduce: 1. create a virtual machine. For a simplified reproducer, I used virt-manager with: OS type: Linux Version: Ubuntu 14.04 Memory: 768 CPUs: 1 Select managed or existing (Browse, new volume) Create a new storage volume: qcow2 Max capacity: 8192 Allocation: 0 Advanced: NAT kvm x86_64 firmware: default 2. install a VM. I used trusty-desktop-amd64.iso from Jan 23 since it seems like I can hit the bug more reliably if I have lots of updates in a dist-upgrade. I have seen this with lucid-trusty guests that are i386 and amd64. After the install, reboot and then cleanly shutdown 3. Backup the image file somewhere since steps 1 and 2 take a while :) 4. Execute the following commands which are based on what our uvt tool does: $ virsh snapshot-create-as forhallyn-trusty-amd64 pristine "uvt snapshot" $ virsh snapshot-current --name forhallyn-trusty-amd64 pristine $ virsh start forhallyn-trusty-amd64 $ virsh snapshot-list forhallyn-trusty-amd64 # this is showing as shutoff after start, this might be different with qemu 1.5 in guest: sudo apt-get update sudo apt-get dist-upgrade 780 upgraded... shutdown -h now $ virsh snapshot-delete forhallyn-trusty-amd64 pristine --children $ virsh snapshot-create-as forhallyn-trusty-amd64 pristine "uvt snapshot" $ virsh start forhallyn-trusty-amd64 # this command works, but there is often disk corruption The idea behind the above is to create a new VM with a pristine snapshot that we could revert later if we wanted. Instead, we boot the VM, run apt-get dist-upgrade, cleanly shutdown and then remove the old 'pristine' snapshot and create a new 'pristine' snapshot. The intention is to update the VM and the pristine snapshot so that when we boot the next time, we boot from the updated VM and can revert back to the updated VM. After running 'virsh start' after doing snapshot-delete/snapshot-create- as, the disk may be corrupted. This can be seen with grub failing to find .mod files, the kernel not booting, init failing, etc. This does not seem to be related to the machine type used. Ie, pc- i440fx-1.5, pc-i440fx-1.7 and pc-i440fx-2.0 all fail with qemu 2.0, pc- i440fx-1.5 and pc-i440fx-1.7 fail with qemu 1.7
[Bug 1434247] Re: [FFE] Upstream patches to Libvirt for vivid
** No longer affects: linux (Ubuntu) -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to libvirt in Ubuntu. https://bugs.launchpad.net/bugs/1434247 Title: [FFE] Upstream patches to Libvirt for vivid To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1434247/+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 1431650] Re: Multipath devices take long to initialize during initramfs
Updated replies to earlier comments: comment #6 > I think this all goes back to multipath-tools updates that would help a whole > lot; but they may be a little too intrusive past feature freeze -- I'm > looking into just updating the udev rules now. Just to clarify/respond to that (earlier than patch) comment with regards to the patch attached. Given that the patch introduces only 2 changes, which are minimal/small (and one may sometimes be a nop), and is totally contained in multipath stuff, I think it'd be OK to get it in. (Very respectfully,) it should not make multipath less functional than it is now. :) And can't break non-multipath stuff. comment #8 > the installed system will come up using /dev/sdb1 (for example) rather than > the equivalent device mapper device, The patch should help* with that issue (described in bug 1429327 comment #10), because the multipath disks now may* show up before the wait-for- root call.. but a proper fix should probably follow the discussion in there. I'll try to get something addressing this too, according to Steve's suggestion. > [...] and no swap. This one should be fixed w/ 1430074. The /etc/fstab file used to have the incorrect/p separator for the swap device too, so it wasn't found/timed out. -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to multipath-tools in Ubuntu. https://bugs.launchpad.net/bugs/1431650 Title: Multipath devices take long to initialize during initramfs To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/multipath-tools/+bug/1431650/+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 1431650] Re: Multipath devices take long to initialize during initramfs
Hi Mathieu, I did some research for the commit mentioned in comment #10. Its description clarifies (how/why) it solves this problem, and even others we would probably hit later (e.g., after booting, SCSI disks added/removed re-trigerring udev rules, and then involving multipathd). It's been written by a multipath/enterprise hardware guy for the suse distros. I see it in opensuse [1], with a patch named after 'sles12', which also names the branch in his github repo [2]. It looks good to go, combined with another fix applied to the initramfs script (the udev settle thing we talked about, but on a slightly different place). Patch attached. With it applied, the udev timeout/killing disappears as expected, and with the earlier 'udevadm settle' call in place, so disappears the random dm ioctl() failures (race condition w/ multipath in udev rules): device-mapper: create ioctl on mpathX-partY failed: Device or resource busy create/reload failed on mpathX-partY In summary, the attached patch restores event-based multipath discovery.. and we no longer need to remove the 95-multipath.rules from initramfs. Links: [1] https://build.opensuse.org/package/revisions/openSUSE:Factory/multipath-tools [2] https://github.com/hreinecke/multipath-tools/tree/sles12 ** Patch added: "multipath-tools_shared-lock.debdiff" https://bugs.launchpad.net/ubuntu/+source/multipath-tools/+bug/1431650/+attachment/4350707/+files/multipath-tools_shared-lock.debdiff -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to multipath-tools in Ubuntu. https://bugs.launchpad.net/bugs/1431650 Title: Multipath devices take long to initialize during initramfs To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/multipath-tools/+bug/1431650/+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 1407695] Re: [MIR] python-saml2, python-repoze.who, xmlsec1
Here's an idea - I'm not sure keystone is using the repoze.who feature, so we could disable this as a BD (and the assocated test) and push it back to Suggests. -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to python-pysaml2 in Ubuntu. https://bugs.launchpad.net/bugs/1407695 Title: [MIR] python-saml2, python-repoze.who, xmlsec1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/python-pysaml2/+bug/1407695/+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 1434575] Re: [SRU] OpenStack test updates to support PEP 476
** Branch linked: lp:~corey.bryant/cinder/2014.1.4 ** Branch linked: lp:~corey.bryant/neutron/2014.1.4 -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to cinder in Ubuntu. https://bugs.launchpad.net/bugs/1434575 Title: [SRU] OpenStack test updates to support PEP 476 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cinder/+bug/1434575/+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 1433697] Re: maas depends on syslinux-dev, removed upstream
** Branch linked: lp:~andreserl/maas/backport_rev3671 -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to maas in Ubuntu. https://bugs.launchpad.net/bugs/1433697 Title: maas depends on syslinux-dev, removed upstream To manage notifications about this bug go to: https://bugs.launchpad.net/maas/+bug/1433697/+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 1433697] Re: maas depends on syslinux-dev, removed upstream
** Branch linked: lp:~andreserl/maas/packaging_lp1433697 -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to maas in Ubuntu. https://bugs.launchpad.net/bugs/1433697 Title: maas depends on syslinux-dev, removed upstream To manage notifications about this bug go to: https://bugs.launchpad.net/maas/+bug/1433697/+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 1407695] Re: [MIR] python-saml2, python-repoze.who, xmlsec1
Seth Bumping pysaml2 to 2.3.0 is probably not to much of a stretch this late in cycle, but repoze.who 1.0.18 -> 2.2 does feel like a big jump post freeze - esp as it has reverse-depends outside of this chain. Keystone federation (requring pysaml2) landed as part of core in kilo-3 so will focus on this in the next week. -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to python-pysaml2 in Ubuntu. https://bugs.launchpad.net/bugs/1407695 Title: [MIR] python-saml2, python-repoze.who, xmlsec1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/python-pysaml2/+bug/1407695/+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 1434575] [NEW] [SRU] OpenStack test updates to support PEP 476
Public bug reported: [Impact] A new version of Python 2.7 is going to be introduced in Ubuntu 14.04. This version of python includes support for PEP 476 - Enabling certificate verification by default for stdlib http clients (https://www.python.org/dev/peps/pep-0476/). Test updates are therefore required for a few of the OpenStack packages. [Test Case] Running the package's tests via override_dh_auto_test will fail if the tests aren't patched. [Regression Potential] Little to know regression potential as all of the patched code will be test code. ** Affects: cinder (Ubuntu) Importance: Undecided Status: New ** Affects: keystone (Ubuntu) Importance: Undecided Status: New ** Affects: neutron (Ubuntu) Importance: Undecided Status: New ** Package changed: ubuntu => cinder (Ubuntu) ** Also affects: keystone (Ubuntu) Importance: Undecided Status: New ** Also affects: neutron (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to cinder in Ubuntu. https://bugs.launchpad.net/bugs/1434575 Title: [SRU] OpenStack test updates to support PEP 476 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cinder/+bug/1434575/+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 1434575] [NEW] [SRU] OpenStack test updates to support PEP 476
You have been subscribed to a public bug: [Impact] A new version of Python 2.7 is going to be introduced in Ubuntu 14.04. This version of python includes support for PEP 476 - Enabling certificate verification by default for stdlib http clients (https://www.python.org/dev/peps/pep-0476/). Test updates are therefore required for a few of the OpenStack packages. [Test Case] Running the package's tests via override_dh_auto_test will fail if the tests aren't patched. [Regression Potential] Little to know regression potential as all of the patched code will be test code. ** Affects: cinder (Ubuntu) Importance: Undecided Status: New -- [SRU] OpenStack test updates to support PEP 476 https://bugs.launchpad.net/bugs/1434575 You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to cinder 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 1433376] Re: fix a test failure seen with Python 2.7.9
the package builds and passes the tests, and also verified that it passes the tests with python 2.7.9 ** Tags removed: verification-needed ** Tags added: verification-done -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to python-django in Ubuntu. https://bugs.launchpad.net/bugs/1433376 Title: fix a test failure seen with Python 2.7.9 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/python-django/+bug/1433376/+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 1410383] Re: wrong process name match in logrotate script
I reported this to Debian: https://bugs.debian.org/cgi- bin/bugreport.cgi?bug=780847 ** Bug watch added: Debian Bug tracker #780847 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=780847 -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to puppet in Ubuntu. https://bugs.launchpad.net/bugs/1410383 Title: wrong process name match in logrotate script To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/puppet/+bug/1410383/+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 1433782] Re: Sync gdisk 0.8.10-2 (main) from Debian unstable (main)
This bug was fixed in the package gdisk - 0.8.10-2 Sponsored for Jackson Doak (noskcaj) --- gdisk (0.8.10-2) unstable; urgency=medium [ intrigeri ] * Fixed-bug-that-caused-spurious-1-exit-condition-in-g.patch: new patch, cherry-picked from upstream, that fixes spurious non-zero exit code in many cases. (Closes: #779797) [ Guillaume Delacour ] * Test partition table creation return code in upstream testsuite just to be sure the bug is fixed -- Guillaume Delacour Thu, 12 Mar 2015 23:39:16 +0100 ** Changed in: gdisk (Ubuntu) Status: New => Fix Released -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to gdisk in Ubuntu. https://bugs.launchpad.net/bugs/1433782 Title: Sync gdisk 0.8.10-2 (main) from Debian unstable (main) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gdisk/+bug/1433782/+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 1434006] Re: Information leak
I was move files from /etc/update-motd.d/ to safe location and now users can't see this. But it is a security issue. -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/1434006 Title: Information leak To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1434006/+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 1434428] [NEW] add cups/printer.conf* to .gitignore?
Public bug reported: cups/printer.conf and its backup cups/printer.conf.0 are dynamically- created files. They are updated more than once daily on my system. Shouldn't they be added to .gitignore? Am I overlooking any possible problem? ** Affects: etckeeper (Ubuntu) Importance: Undecided Status: New ** Tags: trusty -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to etckeeper in Ubuntu. https://bugs.launchpad.net/bugs/1434428 Title: add cups/printer.conf* to .gitignore? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/etckeeper/+bug/1434428/+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 1424054] Re: Command: sudo nova-rootwrap /etc/nova/rootwrap.conf blkid -o value -s TYPE /dev/nbd12 fails
** Changed in: nova Status: Fix Committed => Fix Released ** Changed in: nova Milestone: None => kilo-3 -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to nova in Ubuntu. https://bugs.launchpad.net/bugs/1424054 Title: Command: sudo nova-rootwrap /etc/nova/rootwrap.conf blkid -o value -s TYPE /dev/nbd12 fails To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1424054/+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
