[opensuse-factory] Installation of ImageMagick-6.8.6.9-4.3 failed
I'm doing zypper dup in a VM with btrfs, the dup fails like shown below. exception_8h.html is currently a file. Is this just an intermediate state between 12.3 and 13.1, or will a dist upgrade now likely fail? Olaf (1654/2159) Installing: ImageMagick-6.8.6.9-4.3 ...........................................................................[error] Installation of ImageMagick-6.8.6.9-4.3 failed: (with --nodeps --force) Error: Subprocess failed. Error: RPM failed: error: unpacking of archive failed on file /usr/share/doc/packages/ImageMagick/www/api/MagickCore/exception_8h.html;524c4c73: cpio: link error: ImageMagick-6.8.6.9-4.3.x86_64: install failed error: ImageMagick-6.8.5.7-3.5.x86_64: erase skipped Abort, retry, ignore? [a/r/i] (a): r (1654/2159) Installing: ImageMagick-6.8.6.9-4.3 ...........................................................................[error] Installation of ImageMagick-6.8.6.9-4.3 failed: (with --nodeps --force) Error: Subprocess failed. Error: RPM failed: error: unpacking of archive failed on file /usr/share/doc/packages/ImageMagick/www/api/MagickCore/exception_8h.html;524c4d21: cpio: link error: ImageMagick-6.8.6.9-4.3.x86_64: install failed error: ImageMagick-6.8.5.7-3.5.x86_64: erase skipped Abort, retry, ignore? [a/r/i] (a): -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 10/2/13 1:29 PM, Olaf Hering wrote:
I'm doing zypper dup in a VM with btrfs, the dup fails like shown below. exception_8h.html is currently a file. Is this just an intermediate state between 12.3 and 13.1, or will a dist upgrade now likely fail?
Olaf
(1654/2159) Installing: ImageMagick-6.8.6.9-4.3 ...........................................................................[error] Installation of ImageMagick-6.8.6.9-4.3 failed: (with --nodeps --force) Error: Subprocess failed. Error: RPM failed: error: unpacking of archive failed on file /usr/share/doc/packages/ImageMagick/www/api/MagickCore/exception_8h.html;524c4c73: cpio: link error: ImageMagick-6.8.6.9-4.3.x86_64: install failed error: ImageMagick-6.8.5.7-3.5.x86_64: erase skipped
Abort, retry, ignore? [a/r/i] (a): r (1654/2159) Installing: ImageMagick-6.8.6.9-4.3 ...........................................................................[error] Installation of ImageMagick-6.8.6.9-4.3 failed: (with --nodeps --force) Error: Subprocess failed. Error: RPM failed: error: unpacking of archive failed on file /usr/share/doc/packages/ImageMagick/www/api/MagickCore/exception_8h.html;524c4d21: cpio: link error: ImageMagick-6.8.6.9-4.3.x86_64: install failed error: ImageMagick-6.8.5.7-3.5.x86_64: erase skipped
Abort, retry, ignore? [a/r/i] (a):
btrfstune -r <device> will fix this. The kernel in the next release will have the ability to do this while the fs is mounted via echo 1 > /sys/fs/btrfs/<fsid>/features/extended_iref -Jeff -- Jeff Mahoney SUSE Labs
On Wed, Oct 02, Jeff Mahoney wrote:
btrfstune -r <device> will fix this.
The kernel in the next release will have the ability to do this while the fs is mounted via echo 1 > /sys/fs/btrfs/<fsid>/features/extended_iref
Its this kernel: Linux hammer121 3.11.0-rc4-7.g327e5fc-default #1 SMP Sun Aug 11 19:28:11 UTC 2013 (327e5fc) x86_64 x86_64 x86_64 GNU/Linux Olaf -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Dne St 2. října 2013 13:51:40, Jeff Mahoney napsal(a):
On 10/2/13 1:29 PM, Olaf Hering wrote:
I'm doing zypper dup in a VM with btrfs, the dup fails like shown below. exception_8h.html is currently a file. Is this just an intermediate state between 12.3 and 13.1, or will a dist upgrade now likely fail?
Olaf
btrfstune -r <device> will fix this.
As he is doing zypper dup he has older btrfs-progs so he can't exec that command, awesome huh. Nor he can use 12.3 dvd in that manner.
The kernel in the next release will have the ability to do this while the fs is mounted via echo 1 > /sys/fs/btrfs/<fsid>/features/extended_iref
And that solves the problem how, as if you do zypper dup which is our update mechanism for openSUSE you still have old kernel booted in. Basically from 12.3 to 13.1 you need to run installer to get over it, zypper dup will never be sufficient as you have no tools available at hand to migrate the btrfs layout before the update. Also possibility is to revert the %fdupes call on the imagemagick to ensure the dup works and just put it in effect later on which should not deem trouble. Tom
El 02/10/13 15:04, Tomáš Chvátal escribió:
Also possibility is to revert the %fdupes call on the imagemagick to ensure the dup works and just put it in effect later on which should not deem trouble.
I just tried to correct this with btrfstune but can't be issued to a mounted root filesystem.. -_- I suggest to omit the %fdupes call in the package instead. -- "If debugging is the process of removing bugs, then programming must be the process of putting them in." - Edsger Dijkstra -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, Oct 02, 2013 at 03:11:58PM -0300, Cristian Rodríguez wrote:
El 02/10/13 15:04, Tomáš Chvátal escribió:
Also possibility is to revert the %fdupes call on the imagemagick to ensure the dup works and just put it in effect later on which should not deem trouble.
I just tried to correct this with btrfstune but can't be issued to a mounted root filesystem.. -_- I suggest to omit the %fdupes call in the package instead.
bnc#841472 %fdupes -s seems to work? Petr
On Thu, Oct 3, 2013 at 3:03 AM, Petr Gajdos <pgajdos@suse.cz> wrote:
On Wed, Oct 02, 2013 at 03:11:58PM -0300, Cristian Rodríguez wrote:
El 02/10/13 15:04, Tomáš Chvátal escribió:
Also possibility is to revert the %fdupes call on the imagemagick to ensure the dup works and just put it in effect later on which should not deem trouble.
I just tried to correct this with btrfstune but can't be issued to a mounted root filesystem.. -_- I suggest to omit the %fdupes call in the package instead.
bnc#841472
%fdupes -s seems to work?
Petr
I assume you don't want to make that change for all packages. How could it be assured that every package with too many hardlinks is converted to use symbolic links? Considering users will sometimes use zypper dup to update from M to M+2 or M+3, how long would you have to leave that workaround in place? Obviously I don't like the approach. I'd rather see "zypper dup" patched to error out if: btrfs is in use for / or /usr, the current kernel is < 3.11 and the repositories it will pull from are >= 13.1. It could just tell the user that "zypper dup" upgrade is not supported for that and they need to download the DVD and upgrade that way. That has the advantage of being a permanent "fix" that won't need to be undone in the future. Then if the kernel is >= 3.11 zypper could check the filesystem and ensure it supports large numbers of hardlinks prior to starting the upgrade. After all, having these users download a DVD is not the end of the world and I would hope anyone running btrfs for / or /usr knew they were taking a risk of not having it go perfectly smoothly. Greg -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 03.10.2013 16:42, schrieb Greg Freemyer:
I'd rather see "zypper dup" patched to error out if: btrfs is in use This just replaces one egg-chicken problem with another, because the dup you need to patch is in 12.3's zypper.
Greetings, Stephan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Stephan Kulow <coolo@suse.de> wrote:
Am 03.10.2013 16:42, schrieb Greg Freemyer:
I'd rather see "zypper dup" patched to error out if: btrfs is in use This just replaces one egg-chicken problem with another, because the dup you need to patch is in 12.3's zypper.
Greetings, Stephan
I thought zypper in general pulled all updates to its own stack and installed them, then exited with a message that zypperneeds was updated and needs to be re-run. Is that not true also of zypper dup? Greg -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, Oct 04, 2013 at 08:11:29AM -0400, Greg Freemyer wrote:
Stephan Kulow <coolo@suse.de> wrote:
Am 03.10.2013 16:42, schrieb Greg Freemyer:
I'd rather see "zypper dup" patched to error out if: btrfs is in use This just replaces one egg-chicken problem with another, because the dup you need to patch is in 12.3's zypper.
Greetings, Stephan
I thought zypper in general pulled all updates to its own stack and installed them, then exited with a message that zypperneeds was updated and needs to be re-run.
Is that not true also of zypper dup?
This is a flag in the patch metadata, this just works for "zypper patch". Ciao, Marcus -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, Oct 4, 2013 at 8:21 AM, Marcus Meissner <meissner@suse.de> wrote:
On Fri, Oct 04, 2013 at 08:11:29AM -0400, Greg Freemyer wrote:
Stephan Kulow <coolo@suse.de> wrote:
Am 03.10.2013 16:42, schrieb Greg Freemyer:
I'd rather see "zypper dup" patched to error out if: btrfs is in use This just replaces one egg-chicken problem with another, because the dup you need to patch is in 12.3's zypper.
Greetings, Stephan
I thought zypper in general pulled all updates to its own stack and installed them, then exited with a message that zypperneeds was updated and needs to be re-run.
Is that not true also of zypper dup?
This is a flag in the patch metadata, this just works for "zypper patch".
Ciao, Marcus
Is there anything happening on this? Or is it just going to have to be addressed in the release notes? Greg -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, 11 Oct 2013 23:34, Greg Freemyer <greg.freemyer@...> wrote:
On Fri, Oct 4, 2013 at 8:21 AM, Marcus Meissner <meissner@suse.de> wrote:
On Fri, Oct 04, 2013 at 08:11:29AM -0400, Greg Freemyer wrote:
Stephan Kulow <coolo@suse.de> wrote:
Am 03.10.2013 16:42, schrieb Greg Freemyer:
I'd rather see "zypper dup" patched to error out if: btrfs is in use This just replaces one egg-chicken problem with another, because the dup you need to patch is in 12.3's zypper.
Greetings, Stephan
I thought zypper in general pulled all updates to its own stack and installed them, then exited with a message that zypperneeds was updated and needs to be re-run.
Is that not true also of zypper dup?
This is a flag in the patch metadata, this just works for "zypper patch".
Ciao, Marcus
Is there anything happening on this? Or is it just going to have to be addressed in the release notes?
Greg
well, I did some testing, and got some working solution (at least for me): 1. change repos to 13.1 2. udgrade zypper, do "zypper up -r OSS_13.1 zypper" 3. full distro up "zypper dup --from OSS_13.1" works, or at least tells me why it fails. Now, I'm playing stupid here: How much work would it be to get a working patch / update / upgrade for zypper (and sw stack) as patch for OSS 12.3 ?? That way the zypper dup would work out of the box, or at least tell the user why it can't work. Thanks for the work, - Yamaban. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 02.10.2013 20:11, schrieb Cristian Rodríguez:
El 02/10/13 15:04, Tomáš Chvátal escribió:
Also possibility is to revert the %fdupes call on the imagemagick to ensure the dup works and just put it in effect later on which should not deem trouble.
I just tried to correct this with btrfstune but can't be issued to a mounted root filesystem.. -_- I suggest to omit the %fdupes call in the package instead.
break packages instead of fixing the broken file system? Seems like a plan! :-) -- Stefan Seyfried "If your lighter runs out of fluid or flint and stops making fire, and you can't be bothered to figure out about lighter fluid or flint, that is not Zippo's fault." -- bkw -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 10/3/13 11:17 AM, Stefan Seyfried wrote:
Am 02.10.2013 20:11, schrieb Cristian Rodríguez:
El 02/10/13 15:04, Tomáš Chvátal escribió:
Also possibility is to revert the %fdupes call on the imagemagick to ensure the dup works and just put it in effect later on which should not deem trouble.
I just tried to correct this with btrfstune but can't be issued to a mounted root filesystem.. -_- I suggest to omit the %fdupes call in the package instead.
break packages instead of fixing the broken file system? Seems like a plan! :-)
This problem doesn't occur if you boot from install media and do an update. The file system *is* fixed. It's the upgrade path that doesn't have the updated tools to enable the feature on an umounted file system or the kernel that can do it online that's the problem. -Jeff -- Jeff Mahoney SUSE Labs
On Thu, Oct 3, 2013 at 11:48 AM, Jeff Mahoney <jeffm@suse.com> wrote:
On 10/3/13 11:17 AM, Stefan Seyfried wrote:
Am 02.10.2013 20:11, schrieb Cristian Rodríguez:
El 02/10/13 15:04, Tomáš Chvátal escribió:
Also possibility is to revert the %fdupes call on the imagemagick to ensure the dup works and just put it in effect later on which should not deem trouble.
I just tried to correct this with btrfstune but can't be issued to a mounted root filesystem.. -_- I suggest to omit the %fdupes call in the package instead.
break packages instead of fixing the broken file system? Seems like a plan! :-)
This problem doesn't occur if you boot from install media and do an update. The file system *is* fixed. It's the upgrade path that doesn't have the updated tools to enable the feature on an umounted file system or the kernel that can do it online that's the problem.
-Jeff
I only see 3 options: 1) Mangle the affected packages 2) Update the kernel and userland tools in 12.3 such that zypper patch; zypper dup works 3) Designate zypper dup for configs with btrfs on / or /usr unsupported for this release cycle. I vote for 3) Greg -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 10/3/13 12:14 PM, Greg Freemyer wrote:
On Thu, Oct 3, 2013 at 11:48 AM, Jeff Mahoney <jeffm@suse.com> wrote:
On 10/3/13 11:17 AM, Stefan Seyfried wrote:
Am 02.10.2013 20:11, schrieb Cristian Rodríguez:
El 02/10/13 15:04, Tomáš Chvátal escribió:
Also possibility is to revert the %fdupes call on the imagemagick to ensure the dup works and just put it in effect later on which should not deem trouble.
I just tried to correct this with btrfstune but can't be issued to a mounted root filesystem.. -_- I suggest to omit the %fdupes call in the package instead.
break packages instead of fixing the broken file system? Seems like a plan! :-)
This problem doesn't occur if you boot from install media and do an update. The file system *is* fixed. It's the upgrade path that doesn't have the updated tools to enable the feature on an umounted file system or the kernel that can do it online that's the problem.
-Jeff
I only see 3 options:
1) Mangle the affected packages
2) Update the kernel and userland tools in 12.3 such that zypper patch; zypper dup works
This is easily doable. I'll get patches worked up. -Jeff
3) Designate zypper dup for configs with btrfs on / or /usr unsupported for this release cycle.
I vote for 3)
Greg
-- Jeff Mahoney SUSE Labs
Jeff Mahoney <jeffm@suse.com> wrote:
2) Update the kernel and userland tools in 12.3 such that zypper patch; zypper dup works
This is easily doable. I'll get patches worked up.
Will it be: zypper patch; reboot; echo 1 > /sys/fs/btrfs/<fsid>/features/extended_iref; zypper dup Does fstab need to be updated to have a new mount option? That's not the normal upgrade path, so it begs the question of how it should be documented. Greg -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Le mardi 15 octobre 2013 à 09:19 -0400, Greg Freemyer a écrit :
Jeff Mahoney <jeffm@suse.com> wrote:
2) Update the kernel and userland tools in 12.3 such that zypper patch; zypper dup works
This is easily doable. I'll get patches worked up.
Will it be:
zypper patch; reboot; echo 1 > /sys/fs/btrfs/<fsid>/features/extended_iref; zypper dup
Does fstab need to be updated to have a new mount option?
If both kernel and userland tools are updated for 12.3, zypper dup will be run with the correct support for enabling the needed btrfs feature, so everything can be done in one of the packages %post during zypper dup. (Jeff, feel free to correct me if I'm wrong ;) And nothing needs to be changed on /etc/fstab .. -- Frederic Crozat <fcrozat@suse.com> SUSE -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 10/15/13 9:19 AM, Greg Freemyer wrote:
Jeff Mahoney <jeffm@suse.com> wrote:
2) Update the kernel and userland tools in 12.3 such that zypper patch; zypper dup works
This is easily doable. I'll get patches worked up.
Will it be:
zypper patch; reboot; echo 1 > /sys/fs/btrfs/<fsid>/features/extended_iref; zypper dup
Basically, yeah.
Does fstab need to be updated to have a new mount option?
Nope. It's in the file system superblock. It's a permanent change.
That's not the normal upgrade path, so it begs the question of how it should be documented.
Yep. It'd be interesting to make this automatic and as-needed. i.e. fdupes fails with EMLINK and runs the echo command. -Jeff -- Jeff Mahoney SUSE Labs
On Wed, Oct 02, Tomáš Chvátal wrote:
Basically from 12.3 to 13.1 you need to run installer to get over it, zypper dup will never be sufficient as you have no tools available at hand to migrate the btrfs layout before the update.
Also possibility is to revert the %fdupes call on the imagemagick to ensure the dup works and just put it in effect later on which should not deem trouble.
That would mean to remove every hardlink from every package, it just papers over the issue. The VM has some Factory state from August. So in the end I think its ok to require an upgrade to 13.1+ via the installer. Now that my VM is in the middle of the dup, maybe I will just skip that package and see what happens. Olaf -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
El 02/10/13 15:17, Olaf Hering escribió:
On Wed, Oct 02, Tomáš Chvátal wrote:
Basically from 12.3 to 13.1 you need to run installer to get over it, zypper dup will never be sufficient as you have no tools available at hand to migrate the btrfs layout before the update.
Also possibility is to revert the %fdupes call on the imagemagick to ensure the dup works and just put it in effect later on which should not deem trouble.
That would mean to remove every hardlink from every package, it just papers over the issue. The VM has some Factory state from August. So in the end I think its ok to require an upgrade to 13.1+ via the installer.
What about adding the required step to the initrd before mounting the root filesystem ? -- "If debugging is the process of removing bugs, then programming must be the process of putting them in." - Edsger Dijkstra -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 10/2/13 2:17 PM, Olaf Hering wrote:
On Wed, Oct 02, Tomáš Chvátal wrote:
Basically from 12.3 to 13.1 you need to run installer to get over it, zypper dup will never be sufficient as you have no tools available at hand to migrate the btrfs layout before the update.
Also possibility is to revert the %fdupes call on the imagemagick to ensure the dup works and just put it in effect later on which should not deem trouble.
That would mean to remove every hardlink from every package, it just papers over the issue. The VM has some Factory state from August. So in the end I think its ok to require an upgrade to 13.1+ via the installer.
Now that my VM is in the middle of the dup, maybe I will just skip that package and see what happens.
Or the fdupes macro could handle ENLINK gracefully. -Jeff -- Jeff Mahoney SUSE Labs
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 02.10.2013 20:36, schrieb Jeff Mahoney:
On 10/2/13 2:17 PM, Olaf Hering wrote:
On Wed, Oct 02, Tomáš Chvátal wrote:
Basically from 12.3 to 13.1 you need to run installer to get over it, zypper dup will never be sufficient as you have no tools available at hand to migrate the btrfs layout before the update.
Also possibility is to revert the %fdupes call on the imagemagick to ensure the dup works and just put it in effect later on which should not deem trouble.
That would mean to remove every hardlink from every package, it just papers over the issue. The VM has some Factory state from August. So in the end I think its ok to require an upgrade to 13.1+ via the installer.
Now that my VM is in the middle of the dup, maybe I will just skip that package and see what happens.
Or the fdupes macro could handle ENLINK gracefully.
The %fdupes happen during building, cpio is creating the hardlinks Greetings, Stephan -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.21 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlJNH9oACgkQwFSBhlBjoJb6lQCfWlcOpcneeZnRe3+eaKTlDNAU e34AoJzXGRLx71mc9Hy2CRNn2OJRG0p5 =5bIt -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (11)
-
Cristian Rodríguez -
Frederic Crozat -
Greg Freemyer -
Jeff Mahoney -
Marcus Meissner -
Olaf Hering -
Petr Gajdos -
Stefan Seyfried -
Stephan Kulow -
Tomáš Chvátal -
Yamaban