Re: Upgrading, was Re: jessie upgrade sources.list entries?
On 2/10/15, David Wright <deblis@lionunicorn.co.uk> wrote:
> Quoting Brian (ad44@cityscape.co.uk):
>>
>> Some people also recommend checking progress and the state of the system
>> by doing a reboot between an upgrade and a dist-upgrade.
>
> Lots of good advice here. I can't remember where I got my checklist
> from but it's grow like topsy over the years. Please hack it back
> (in the gardening sense) as it's OTT (preparing for senility)...
>
> -----
>
> A fairly full list of steps in upgrading a Debian distribution.
> Running script might help, with care when it is upgraded itself.
> It's safer not to be in X.
>
> 0. check backups are valid, rebackup, and repeat before big steps.
That's the most important one for me. These days I just debootstrap
looking for the latest updates. I keep .debs archived to save wear and
tear on both my ISP (Internet provider) and Debian volunteer
repository servers..
On checking backups, I don't just peer in, I boot my last one up. I
rsync my copies. I saw someone call that not a backup, but so far it's
worked for me.
Only issue I ran into was I use UUIDs within /etc/fstab and
what-have-you. Those are 100% specific and MUST MATCH the new
partition a backup may be operating from......
Think I mentioned this before. I ran into adding that to my personal
checklist recently. While verifying my backup copy, things felt like
they were booting all OVER the place. Just looked funky. Turned out
to be right about that.
As a cognitively friendly aid, I plant partition specific dummy
directories at the top of each partition. When what I thought was the
backup booting up as itself was viewed in the file manager, the wrong
"dummy directory" was showing at the top. Was instant verification
SOMETHING SOMEWHERE needed fixed before the process could progress any
further.
What happened was the UUIDs were working fabulously. The backup copy
was finishing up the boot by loading the original that was about to be
replaced. It did so because that's what was being read in the backup
copy's /etc/fstab.. At the end of the boot, all it proved was that the
long standing functional original worked. We already KNEW that. *oops*
This past week I... skipped a step. Everyone has their *_CHOICE_* for
getting the same info, but I use lshw to gather UUID info for
verification purposes. I did NOT do that this last time.... and
simultaneously SOMEHOW multiples of my UUIDs CHANGED without me
consciously doing it.
Not sure how it happened. It's on a to-do list to see if I can't
backtrack to determine accidental cause. Moral of the story was I got
locked out of EVERY SINGLE PARTITION. 100% across the board received
couldn't find file errors at boot, including on my now old fallback
and very stable Wheezy. Had to turn to Knoppix LiveDVD to fix that
mess before things functioned properly again.
That leads me to ask... I deleted the list and just left that first
one because it's my absolute most important one these days. Did you
mention... having a LiveDVD handy? Having one here SAVED MY BACKSIDE
three or four days ago.
Good luck to whatever or whomever has inspired this latest chatter..
Cindy :)
PS It was purely by accident that UUIDs being changed became
apparent. Recognizing the first couple and last couple characters of
longstanding UUIDs and therefore realizing those suddenly didn't exist
was the time saving hero there..
--
Cindy-Sue Causey
Talking Rock, Pickens County, Georgia, USA
* falls on face occasionally. 3 times last week. literally. ouch. *
Reply to: