On Wednesday, June 21, 2017 at 10:07:31 AM UTC-7, Nikolaus Rath wrote:
>
> On Jun 21 2017, joseph via s3ql <[email protected] <javascript:>> 
> wrote: 
> > On Tuesday, June 20, 2017 at 7:55:58 PM UTC-7, Nikolaus Rath wrote: 
> >> 
> >> On Jun 20 2017, joseph via s3ql <[email protected] <javascript:>> 
> >> wrote: 
> >> > jessie has s3ql 2.11.1, stretch has 2.21. 
> >> > 
> >> > NEWS.Debian.gz seems to indicate I need to upgrade via the 
> intermediate 
> >> > version 2.14, is this correct? 
> >> 
> >> No, this should work out of the box. Debian ships a special patch to 
> >> enable backwards compatibility with jessie. 
> >> 
> >> > root@ns3022725:~# s3qladm upgrade 
> >> > s3://echo-maher-org-uk-backup/                                       
>     
> >>                                             
> >> > Getting file system parameters.. 
> >> > ERROR: Uncaught top-level exception: 
> >> > Traceback (most recent call last): 
> >> >   File "/usr/lib/s3ql/s3ql/common.py", line 564, in 
> thaw_basic_mapping 
> >> >     d = literal_eval(buf.decode('utf-8')) 
> >> > UnicodeDecodeError: 'utf-8' codec can't decode byte 0x80 in position 
> 0: 
> >> > invalid start byte 
> >> 
> >> Hmm. That looks like a bug. 
> >> 
> >> Are you confident that the filesystem was unmounted cleanly the last 
> >> time it was mounted? In that case you can try a workaround: temporarily 
> >> move the "s3:=2F=2Fecho-maher-org-uk-backup*" files from ~/.s3ql/ 
> >> somewhere else and re-try the upgrade. Does that help? 
> >> 
> >> 
> > mount.log seems to think so. 
>
> Yes, that looks good. If you still have a jessie box, you can also run 
> fsck.s3ql from there to be 100% sure. Then try the workaround. 
>
> > Before I received your response I upgraded a jessie install to 2.14 and 
> ran: 
> > 
> > s3qladm upgrade s3://echo-maher-org-uk-backup/ 
> > 
> > but this failed with (I think) a timeout: 
> > 
> > Encountered ConnectionClosed (server closed connection), retrying 
> > Backend.lookup (attempt 4)... 
> > ..processed 901724/2215676 objects (40.7%, 0 bytes 
> rewritten)..Encountered 
> > HTTPError (500 Internal Server Error), retrying Backend.lookup (attempt 
> > 5)... 
> [...] 
> > 
> > Is there any way to recover from this? 
>
> You should be able to just restart the upgrade. 
>
>

Thanks! I've restarted the upgrade, which started without errors, but it 
will take some time to finish. 
 

>> Do you still have access to a jessie system? If so, can you reproduce 
> >> the problem with a freshly created file system? 
> >> 
> >> 
> > I can't reproduce - I just made a new filesystem on a jessie box and it 
> > upgraded just fine on the stretch box. 
>
> Hmm.. So the ~/.s3ql folder wasn't shared between jessie and stretch, 
> right? That gives hope for the workaround. 
>
>
Yes - they had different .s3ql folders.

I have one remaining jessie box with an s3ql filesystem to upgrade to 
stretch, which I will do in the next few days. I will let you know if I 
have a similar issue with that one.

Thanks!

Joseph 

-- 
You received this message because you are subscribed to the Google Groups 
"s3ql" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to