On 2/10/15, David Wright <deb...@lionunicorn.co.uk> wrote: > Quoting Brian (a...@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. * -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/cao1p-kcxhdd+hlekyybc4umpkj3yj1+g7ao4sj-66botl3y...@mail.gmail.com
