Hi,
Alright, I figured this one out.
First, the reason you're having an s3ql_metadata_bak_0 object right
after the upgrade is that the upgrade itself backups up the metadata
*after* having added the _pre21 suffix to the existing backups.
Secondly (and contrary to what I said before), this
control: tags -1 +pending
I've just uploaded a new package to mentors that should fix the issue
with the unsafe metadata backup.
If this works for you too, I think this is suitable for
stable-updates. I'm not sure what the procedure is to get a package in
there, so please let me know if I can do
On Jul 30 2015, Sam Hartman hartm...@debian.org wrote:
I'll try and reproduce this in the next day or so and give you access to
a failing example.
No need, I just managed to reproduce it locally with a filesystem
freshly created in wheezy. I'll look into it.
Best,
-Nikolaus
--
GPG encrypted
Hi.
I attempted the following:
* Built with the patch applied on a jessie chroot
* installed s3ql
* On a wheezy system mkfs.s3ql, mount and add some data. unmount.
* On my patched jessie system run s3qladm upgrade
So far so good.
Then run fsck.s3ql.
It looks like it has trouble with the old
On Jul 29 2015, Sam Hartman hartm...@debian.org wrote:
Hi.
I attempted the following:
* Built with the patch applied on a jessie chroot
* installed s3ql
* On a wheezy system mkfs.s3ql, mount and add some data. unmount.
* On my patched jessie system run s3qladm upgrade
So far so good.
Note to self:
S3QL versions prior to 2.10 (and all of the 1.x versions) did not read
the object metadata on object copy and object rename. Therefore, the
unsafe pickle could have been there for quite some time. However, this
still does not explain why the object survived the upgrade without
being
On Jul 29 2015, Sam Hartman hartm...@debian.org wrote:
Then run fsck.s3ql.
It looks like it has trouble with the old metadata:
Backing up old metadata...
Uncaught top-level exception:
Traceback (most recent call last):
[...]
Could you please post the complete traceback? The one you included
Just as an FYI, I'm in Prague at an IETF meeting and that's taking up
most of my time, so it may be this weekend before I get a chance to try
your patch.
--Sam
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
Nikolaus == Nikolaus Rath nikol...@rath.org writes:
Nikolaus I agree. There shouldn't have been an s3ql package in
Nikolaus Wheezy. This was when I was young and inexperienced with
Nikolaus Debian packaging. However, the situation is different for
Nikolaus Jessie. Now that it is
On Jul 19 2015, Sam Hartman hartm...@debian.org wrote:
Nikolaus I agree. There shouldn't have been an s3ql package in
Nikolaus Wheezy. This was when I was young and inexperienced with
Nikolaus Debian packaging. However, the situation is different for
Nikolaus Jessie. Now that
On Jul 19 2015, Nikolaus Rath nikol...@rath.org wrote:
Looking at the debian news file, the only announced upgrade is at
version 2.5 between 1.11 and 2.11.1.
Oh. Obviously my memory has failed me completely here. You are right. I
just checked, all that is needed is one interim version. The
Hi,
Could you give the attached patch for Jessie's S3QL a try? It should
allow to upgrade from wheezy file systems.
(Try it with a test file system first)
Best,
-Nikolaus
--
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E
package: s3ql
severity: grave
version: 2.11.1+dfsg-1
Justification: Renders filesystem unusable and data accessible
Hi.
I'm upgrading a system from wheezy to jessie.
Wheezy ships s3ql 1.11, jessie ships version 2.11.
I have a filesystem that I can easily mount and fsck in wheezy, but when
I try
On Jul 17 2015, Sam Hartman hartm...@debian.org wrote:
I have a filesystem that I can easily mount and fsck in wheezy, but when
I try to run the jessie s3qladm upgrade command I get:
Getting file system parameters..
File system revision too old to upgrade!
[...]
It's critical that there be
Nikolaus == Nikolaus Rath nikol...@rath.org writes:
Nikolaus I agree that this is unfortunate, but preserving backwards
Nikolaus compatibility over so many upstream versions just for
Nikolaus Debian wheezy users did not seem worth the time.
I totally understand that it's a lot of
On Jul 17 2015, Sam Hartman hartm...@debian.org wrote:
If a package is not going to provide an upgrade from one debian
release to the next, it should not generally be in the Debian release.
It would be fine for it to continue to be in unstable.
We need to figure out if someone is willing to
16 matches
Mail list logo
