AF:
NF:0
PS:10
SRH:1
SFN:
DSR:
MID:<20070216181310.634e5aaa@ripper.onstor.net>
CFG:
PT:0
S:andy.sharp@onstor.com
RQ:
SSV:onstor-exch02.onstor.net
NSV:
SSH:
R:<chris.vandever@onstor.com>,<tim.gardner@onstor.com>,<caeli.collins@onstor.com>,<eric.barrett@onstor.com>,<ed.kwan@onstor.com>,<jay.michlin@onstor.com>,<larry.scheer@onstor.com>,<paul.hammer@onstor.com>,<dl-software@onstor.com>
MAID:1
X-Sylpheed-Privacy-System:
X-Sylpheed-Sign:0
SCF:#mh/Mailbox/sent
RMID:#imap/andys@onstor.net@onstor-exch02.onstor.net/INBOX	0	BB375AF679D4A34E9CA8DFA650E2B04E0138C465@onstor-exch02.onstor.net
X-Sylpheed-End-Special-Headers: 1
Date: Fri, 16 Feb 2007 18:13:46 -0800
From: Andrew Sharp <andy.sharp@onstor.com>
To: "Chris Vandever" <chris.vandever@onstor.com>
Cc: "Tim Gardner" <tim.gardner@onstor.com>, "Caeli Collins"
 <caeli.collins@onstor.com>, "Eric Barrett" <eric.barrett@onstor.com>, "Ed
 Kwan" <ed.kwan@onstor.com>, "Jay Michlin" <jay.michlin@onstor.com>, "Larry
 Scheer" <larry.scheer@onstor.com>, "Paul Hammer" <paul.hammer@onstor.com>,
 "dl-Software" <dl-software@onstor.com>
Subject: Re: corruption and upgrade workflow for Lambo [and 1.3.3.?]
Message-ID: <20070216181346.14f6cbe5@ripper.onstor.net>
In-Reply-To: <BB375AF679D4A34E9CA8DFA650E2B04E0138C465@onstor-exch02.onstor.net>
References: <20070216142730.10a7902b@ripper.onstor.net>
	<BB375AF679D4A34E9CA8DFA650E2B04E0138C465@onstor-exch02.onstor.net>
Organization: Onstor
X-Mailer: Sylpheed-Claws 2.6.0 (GTK+ 2.8.20; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit


On Fri, 16 Feb 2007 18:01:35 -0800 "Chris Vandever"
<chris.vandever@onstor.com> wrote:

> My understanding was that the number of files that fail the compare is
> small in comparison with the total number of files that need to be
> upgraded, thus the second upgrade should get everything remaining
> without any problem.

Based on what I've been seeing, I would characterize it as "the number
of files corrupted is small" but doesn't have any relation to the
number being upgraded.  The max number of upgrade iterations using the
method I describe below is 2.  The max number using the corruption
prone method is ... ?

I'm just talkin' 'bout what I bin seen.

> ChrisV
> 
> -----Original Message-----
> From: Andy Sharp 
> Sent: Friday, February 16, 2007 2:28 PM
> To: Tim Gardner
> Cc: Caeli Collins; Eric Barrett; Ed Kwan; Jay Michlin; Larry Scheer;
> Paul Hammer; dl-Software
> Subject: Re: corruption and upgrade workflow for Lambo [and 1.3.3.?]
> 
> 
> On Fri, 16 Feb 2007 14:19:32 -0800 "Tim Gardner"
> <tim.gardner@onstor.com> wrote:
> 
> > The documented procedure is to upgrade the secondary flash, run a
> > system compare, and if 
> > corrupted files are found, upgrade again. Once you have a successful
> > compare, reboot from the secondary flash. 
> 
> What I'm concerned about is that the 'upgrade again' is still the
> corruption prone upgrade process.  It is quite possible, I might even
> hazard a 'likely', that a user will have to execute that loop many
> times before chancing on a lucky upgrade that doesn't corrupt
> anything.
> 
> > -----Original Message-----
> > From: Andy Sharp 
> > Sent: Friday, February 16, 2007 1:19 PM
> > To: Caeli Collins; Eric Barrett; Ed Kwan; Jay Michlin; Tim Gardner;
> > Larry Scheer; Paul Hammer; dl-Software
> > Subject: corruption and upgrade workflow for Lambo [and 1.3.3.?]
> > 
> > Howdy,
> > 
> > Since I've been messing about with the upgrade code a bunch for
> > Delorean, I've been doing a lot of upgrades in the past several days
> > in the process of doing unit testing, and one thing I've noticed is
> > that upgrades from 1.3.3 to 2.2 or later always find several files
> > that are corrupted after the upgrade.
> > 
> > This is because the upgrade process has a corruption problem, as we
> > all know, which was fixed in 2.2 (and possibly some version of
> > 1.3.3?). However, when you upgrade to 2.2 you use the old,
> > corruption prone, upgrade process.
> > 
> > Therefore, I believe the workflow for upgrading from a
> > non-upgrade-fixed release to a fixed release requires that you
> > actually upgrade twice.  You must be running the new version when
> > you upgrade the second time.  So, for the sake of brevity, I will
> > just mention 1.3.3 -> 2.2+ in the following:
> > 
> > 1.  Upgrade from 1.3.3 or 2.1 to 2.2
> > 2.  Boot 2.2
> > 	Note: you may have problems at this point, since any file
> > could conceivably be corrupted, including one of the .bin boot
> > images for the TXRX or FP processors.  If necessary, log in quickly
> > 	after rebooting and kill pm in order to keep the system from
> > 	rebooting itself before you can execute the next step.
> > 3.  Upgrade to 2.2 again.  You may use the same tar ball you did in
> >     step 1.
> > 
> > Please set aside a decent amount of time for this: upgrades in 2.2
> > are not fast.  It downloads the tarball twice and verifies the
> > entire system twice for each upgrade.  I am fixing these issues in
> > Delorean so we won't have to live with this for too terribly long.
> > 
> > Cheers,
> > 
> > a
