[Bug 1209085] Re: update-smart-drivedb uses old download link
** Description changed: [Impact] Updating the smart driver db fails because the tool selected by the script (curl) is not called with a parameter that allows it to follow redirects. Since upstream changed the URL for that driver file, the script now fails. The fix is to just add -L to the curl command line. [Test Case] - sudo apt-get install smartmontools --no-install-recommends - sudo update-smart-drivedb + $ sudo apt-get install smartmontools --no-install-recommends + $ sudo update-smart-drivedb /var/lib/smartmontools/drivedb/drivedb.h.error: rejected by /usr/sbin/smartctl, probably no longer compatible The file /var/lib/smartmontools/drivedb/drivedb.h.error contains the redirect notice: 302 Found - The resource was found at https://sourceforge.net/p/smartmontools/code/HEAD/tree/branches/RELEASE_6_2_DRIVEDB/smartmontools/drivedb.h?format=raw;>https://sourceforge.net/p/smartmontools/code/HEAD/tree/branches/RELEASE_6_2_DRIVEDB/smartmontools/drivedb.h?format=raw; + The resource was found at https://sourceforge.net/p/smartmontools/code/HEAD/tree/branches/RELEASE_6_2_DRIVEDB/smartmontools/drivedb.h?format=raw;>https://sourceforge.net/p/smartmontools/code/HEAD/tree/branches/RELEASE_6_2_DRIVEDB/smartmontools/drivedb.h?format=raw; you should be redirected automatically. - Update the packages and run the command again, this time it will - succeed: - + Update the packages and run the command again, this time it will succeed: + $ sudo update-smart-drivedb + /var/lib/smartmontools/drivedb/drivedb.h updated from branches/RELEASE_6_2_DRIVEDB [Regression Potential] If there is a redirect loop, before it wouldn't be followed, and now it will. There is a default limit of 50, though (--max-redirs' default), so eventually it will stop and fail (correctly). [Other Info] Later supported releases of Ubuntu and Debian have dropped this script from the package, so no fix is necessary there. Following the spirit of the smallest change possible, I chose to not change the URL from where the file is downloaded. - [Original Description] Package: smartmontools-6.1+svn3812-1 and older. Due to sourceforge platform upgrades (http://sourceforge.net/blog /upgrades-april22/), the smartmontools SVN repository was moved to a new location. The update-smart-drivedb script from a smartmontools build before r3814 downloads drivedb.h from the old respository which is still present but set to R/O. Possible fix: - Update to smartmontools 6.2 (final, r3841), or - Replace update-smart-drivedb with a new one generated from 6.2 tarball. Adjust the branch version number in line 'BRANCH="RELEASE_6_2_DRIVEDB"'. This should work for smartmontools 5.40 to 6.1. These drivedb.h branches are still maintained. -- You received this bug notification because you are a member of Ubuntu Server, which is subscribed to smartmontools in Ubuntu. https://bugs.launchpad.net/bugs/1209085 Title: update-smart-drivedb uses old download link To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/smartmontools/+bug/1209085/+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 1209085] Re: update-smart-drivedb uses old download link
** Description changed: [Impact] - * An explanation of the effects of the bug on users and + Updating the smart driver db fails because the tool selected by the + script (curl) is not called with a parameter that allows it to follow + redirects. Since upstream changed the URL for that driver file, the + script now fails. - * justification for backporting the fix to the stable release. - - * In addition, it is helpful, but not required, to include an -explanation of how the upload fixes this bug. + The fix is to just add -L to the curl command line. [Test Case] + sudo apt-get install smartmontools --no-install-recommends + sudo update-smart-drivedb + /var/lib/smartmontools/drivedb/drivedb.h.error: rejected by /usr/sbin/smartctl, probably no longer compatible - * detailed instructions how to reproduce the bug + The file /var/lib/smartmontools/drivedb/drivedb.h.error contains the redirect notice: + 302 Found + The resource was found at https://sourceforge.net/p/smartmontools/code/HEAD/tree/branches/RELEASE_6_2_DRIVEDB/smartmontools/drivedb.h?format=raw;>https://sourceforge.net/p/smartmontools/code/HEAD/tree/branches/RELEASE_6_2_DRIVEDB/smartmontools/drivedb.h?format=raw; + you should be redirected automatically. - * these should allow someone who is not familiar with the affected -package to reproduce the bug and verify that the updated package fixes -the problem. + Update the packages and run the command again, this time it will + succeed: + [Regression Potential] - - * discussion of how regressions are most likely to manifest as a result - of this change. - - * It is assumed that any SRU candidate patch is well-tested before -upload and has a low overall risk of regression, but it's important -to make the effort to think about what ''could'' happen in the -event of a regression. - - * This both shows the SRU team that the risks have been considered, -and provides guidance to testers in regression-testing the SRU. + If there is a redirect loop, before it wouldn't be followed, and now it will. There is a default limit of 50, though (--max-redirs' default), so eventually it will stop and fail (correctly). [Other Info] - - * Anything else you think is useful to include - * Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board - * and address these questions in advance + Later supported releases of Ubuntu and Debian have dropped this script from the package, so no fix is necessary there. + + Following the spirit of the smallest change possible, I chose to not + change the URL from where the file is downloaded. [Original Description] Package: smartmontools-6.1+svn3812-1 and older. Due to sourceforge platform upgrades (http://sourceforge.net/blog /upgrades-april22/), the smartmontools SVN repository was moved to a new location. The update-smart-drivedb script from a smartmontools build before r3814 downloads drivedb.h from the old respository which is still present but set to R/O. Possible fix: - Update to smartmontools 6.2 (final, r3841), or - Replace update-smart-drivedb with a new one generated from 6.2 tarball. Adjust the branch version number in line 'BRANCH="RELEASE_6_2_DRIVEDB"'. This should work for smartmontools 5.40 to 6.1. These drivedb.h branches are still maintained. -- You received this bug notification because you are a member of Ubuntu Server, which is subscribed to smartmontools in Ubuntu. https://bugs.launchpad.net/bugs/1209085 Title: update-smart-drivedb uses old download link To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/smartmontools/+bug/1209085/+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 1209085] Re: update-smart-drivedb uses old download link
** Changed in: smartmontools (Ubuntu Trusty) Status: Triaged => In Progress ** Changed in: smartmontools (Ubuntu Trusty) Assignee: (unassigned) => Andreas Hasenack (ahasenack) ** Description changed: + [Impact] + + * An explanation of the effects of the bug on users and + + * justification for backporting the fix to the stable release. + + * In addition, it is helpful, but not required, to include an +explanation of how the upload fixes this bug. + + [Test Case] + + * detailed instructions how to reproduce the bug + + * these should allow someone who is not familiar with the affected +package to reproduce the bug and verify that the updated package fixes +the problem. + + [Regression Potential] + + * discussion of how regressions are most likely to manifest as a result + of this change. + + * It is assumed that any SRU candidate patch is well-tested before +upload and has a low overall risk of regression, but it's important +to make the effort to think about what ''could'' happen in the +event of a regression. + + * This both shows the SRU team that the risks have been considered, +and provides guidance to testers in regression-testing the SRU. + + [Other Info] + + * Anything else you think is useful to include + * Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board + * and address these questions in advance + + + [Original Description] + Package: smartmontools-6.1+svn3812-1 and older. Due to sourceforge platform upgrades (http://sourceforge.net/blog /upgrades-april22/), the smartmontools SVN repository was moved to a new location. The update-smart-drivedb script from a smartmontools build before r3814 downloads drivedb.h from the old respository which is still present but set to R/O. Possible fix: - Update to smartmontools 6.2 (final, r3841), or - Replace update-smart-drivedb with a new one generated from 6.2 tarball. Adjust the branch version number in line 'BRANCH="RELEASE_6_2_DRIVEDB"'. This should work for smartmontools 5.40 to 6.1. These drivedb.h branches are still maintained. -- You received this bug notification because you are a member of Ubuntu Server, which is subscribed to smartmontools in Ubuntu. https://bugs.launchpad.net/bugs/1209085 Title: update-smart-drivedb uses old download link To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/smartmontools/+bug/1209085/+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 1209085] Re: update-smart-drivedb uses old download link
update-smart-drivedb was dropped in 6.4+svn4214-1:
smartmontools (6.4+svn4214-1) unstable; urgency=medium
...
[ Jonathan Dowland ]
...
* Get rid of update-smart-drivedb. Closes: #783317, #804299, #706909.
...
-- Jonathan Dowland Thu, 04 Feb 2016 23:21:58 +
So the last ubuntu release that is still supported and has this bug is trusty.
As others have pointed out, adding -L to curl's command line fixes that case:
--- a/update-smart-drivedb.in
+++ b/update-smart-drivedb.in
@@ -155,7 +155,7 @@ download()
case $tool in
curl)
- vrun curl ${q:+-s} -f --max-redirs 0 \
+ vrun curl ${q:+-s} -f -L --max-redirs 0 \
** Also affects: smartmontools (Ubuntu Trusty)
Importance: Undecided
Status: New
** Changed in: smartmontools (Ubuntu)
Status: Triaged => Fix Released
** Changed in: smartmontools (Ubuntu Trusty)
Status: New => Triaged
** Changed in: smartmontools (Ubuntu Trusty)
Importance: Undecided => Medium
** Tags removed: precise
** Tags added: bitesize trusty
--
You received this bug notification because you are a member of Ubuntu
Server, which is subscribed to smartmontools in Ubuntu.
https://bugs.launchpad.net/bugs/1209085
Title:
update-smart-drivedb uses old download link
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/smartmontools/+bug/1209085/+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 1587065] Re: btrfs qemu-ga - multiple mounts block fsfreeze
** Description changed:
[Impact]
- * backport upstream fix to avoid double unmounts (e.g. bind mounts)
-hanging the freeze action.
+ * backport upstream fix to avoid double unmounts (e.g. bind mounts)
+ hanging the freeze action.
[Test Case]
* Prepare a guest
$ uvt-simplestreams-libvirt --verbose sync --source
http://cloud-images.ubuntu.com/daily arch=amd64 release=xenial label=daily
uvt-kvm create --password ubuntu x-freeze arch=amd64 release=xenial
label=daily
* Shut it down and use virsh edit to add a channel for the agent. Add this
somewhere under :
* Start the guest again, in it install qemu-guest-agent
*
* On the Host then freeze and thaw the guest
$ virsh domfsfreeze x-freeze
$ virsh domfsthaw x-freeze
# The above works, then trigger the issue, in the guest do
$ sudo mkdir /mnt/test
$ sudo mount -o bind / /mnt/test/
- * Now the freeze/thaw will fail unless the fix is applied.
+ * Now the freeze/thaw will fail unless the fix is applied to the
+ guest.
[Regression Potential]
* From looking at the code alone I could think of a different cause that
makes it return EBUSY.
The biggest risk I could see due to that is the agent reporting a
successful freeze due to accepting EBUSY which is not actually true.
But we have that in Ubuntu since Artful and
upstream since January 2017 and there are no such reports.
[Other Info]
* n/a
---
Having two mounts of the same device makes fsfreeze through qemu-ga
impossible.
root@CmsrvMTA:/# mount -l | grep /dev/vda2
/dev/vda2 on / type btrfs (rw,relatime,space_cache,subvolid=257,subvol=/@)
/dev/vda2 on /home type btrfs
(rw,relatime,space_cache,subvolid=258,subvol=/@home)
Having two mounts is rather common with btrfs, so the feature fsfreeze
is unusable on these systems.
Below more information about how we encountered this issue...
Message send to qemu-disc...@nongnu.org:
Message 1:
--
I use external snapshots to backup my guests. I use the 'quiesce' option to
flush and frees the guest file system with the qemu guest agent.
With the exeption of one guest, this procedure works fine. On the 'unwilling'
guest, I get this error message:
"ERROR 2016-05-25 00:51:19 | T25-bakVMSCmsrvVH2 | fout: internal error:
unable to execute QEMU agent command 'guest-fsfreeze-freeze': failed to freeze
/: Device or resource busy"
I don't think this is not some sort of time-out error, because
activation of the fsfreeze and the error message happen immediately
after each other:
$ grep qemu-ga syslog.1
May 25 00:51:19 CmsrvMTA qemu-ga: info: guest-fsfreeze called
This is the only entry of the qemu guest agent in syslog.
$ sudo virsh version
Compiled against library: libvirt 1.3.1
Using library: libvirt 1.3.1
Gebruikte API: QEMU 1.3.1
Draaiende hypervisor: QEMU 2.5.0
$ virsh qemu-agent-command CmsrvMTA '{"execute": "guest-info"}'
{"return":{"version":"2.5.0", ...
,{"enabled":true,"name":"guest-fstrim","success-response":true},{"enabled":true,"name":"guest-fsfreeze-thaw","success-response":true},{"enabled":true,"name":"guest-fsfreeze-status","success-response":true},{"enabled":true,"name":"guest-fsfreeze-freeze-list","success-response":true},{"enabled":true,"name":"guest-fsfreeze-freeze","success-response":true},
... }
For making an external snapshot, I use this command:
$ virsh snapshot-create-as --domain CmsrvMTA sn1 --disk-only --atomic
--quiesce --no-metadata --diskspec vda,file=/srv/poolVMS/CmsrvMTA.sn1
Piece of reply 1:
-
I have encountered this before. Some operating systems
may have bind-mounts that let a device appear multiple times in the mount
list. Unfortunately the guest agent is not smart enough to consider a device
that has been frozen as succesfull and keep going. This causes this specific
error.
Piece of reply 2:
-
Ok, that seems to be it.
I’ve got the ‘/’ and ‘/home’ on the same device formatted as btrfs on
two separate sub volumes.
--
You received this bug notification because you are a member of Ubuntu
Server, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1587065
Title:
btrfs qemu-ga - multiple mounts block fsfreeze
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1587065/+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 1779621] Re: chrony exits unexpectedly
Do you have any kind of override file for timesyncd and/or chrony (it could be named anything with a .conf extension) in the directories under /etc/systemd/system? If yes, could you please show its contents? -- You received this bug notification because you are a member of Ubuntu Server, which is subscribed to chrony in Ubuntu. https://bugs.launchpad.net/bugs/1779621 Title: chrony exits unexpectedly To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/chrony/+bug/1779621/+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 1744062] Please test proposed package
Hello Corey, or anyone else affected, Accepted keepalived into queens-proposed. The package will build now and be available in the Ubuntu Cloud Archive in a few hours, and then in the -proposed repository. Please help us by testing this new package. To enable the -proposed repository: sudo add-apt-repository cloud-archive:queens-proposed sudo apt-get update Your feedback will aid us getting this update out to other Ubuntu users. If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-queens-needed to verification-queens-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-queens-failed. In either case, details of your testing will help us make a better decision. Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance! ** Changed in: cloud-archive/queens Status: Triaged => Fix Committed ** Tags added: verification-queens-needed -- You received this bug notification because you are a member of Ubuntu Server, which is subscribed to keepalived in Ubuntu. https://bugs.launchpad.net/bugs/1744062 Title: [SRU] L3 HA: multiple agents are active at the same time To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/1744062/+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
