[conspire] upgrade and grub

[Michael Paoli]

So ... a lot on this (more-or-less) "thread" :-)

Thought I'd try and add some useful bits, while trying to avoid
being redundant - Rick Moen has already made many excellent points,
so I'll try to mostly skip what's already been (well) covered.

Anyway, my contributions/comments, mostly in-line (to aid with context)
below:

(Egad, once upon a time I had a manager that was crud, insist I include
complete full context on anything and everything I replied to in email,
not merely excerpts, but the entirety of any and all emails and thread
to that point of any email I responded to.  Edad, that was an
ill-informed "request", and after due consideration, I refused to
comply.  :-) So, I'll save you from (re)reading such entirety, and just
provide fairly minimal relevant context.  Pardon's if you might think I
missed including some bits you think ought be included, but of course
those can be easily obtained - and full context - from the list
archive.)

> Date: Fri, 22 Jun 2018 06:12:25 +0000 (UTC)
> From: Paul Zander <paulz at ieee.org>
> To: Conspire List <conspire at linuxmafia.com>
> Message-ID: <2030398000.673784.1529647945384 at mail.yahoo.com>

> So I decided to try my laptop instead. This would be the machine
> that was at CABAL a couple years back.
>
> sources.list as previously discussed. All went reasonably well
> until I get to an issue about grub.
> First dialog box:The GRUB boot loader was previously installed to a
> disk that is no longer present or
>

> Date: Thu, 21 Jun 2018 23:16:23 -0700
> From: Rick Moen <rick at linuxmafia.com>
> To: "conspire at linuxmafia.com" <conspire at linuxmafia.com>
> Subject: Re: [conspire] How to update packages when Deb is behind?

> And, one thing you mentioned just sunk in.
>
> Quoting Paul Zander (paulz at ieee.org):
>
> > My present guess is that my sources.list file really was doing
> > "testing", but something is amiss with Firefox. I know I have
> > downloaded and added SeaMonkey without using apt-get.

Uhm, yeah, as oft pointed out by Rick Moen, and many others,
in general, mixing stuff in from other than one's distribution - and
specifically and only from the repository(/ies) provided by one's
distribution, is a quick way to a broken system ... even if it may not
at all be immediately obvious the ways in which the system is broken.
In the case of Debian, such a broken system would typically be referred
to as a FrankenDebian - such would also typically result from mixing of
different Debian releases (e.g. sid ("unstable") and stable).
https://wiki.debian.org/DontBreakDebian

And, if one must have/install other/additional software, there are
generally much more appropriate ways to do that.  (But I'll not repeat
what's already been better and more fully stated).

> As it happens, the Debian Wiki happens to
Debian wiki tends to be very good to excellent, ... but ... it's a wiki.
It can certainly have less that ideal, correct, and most current
information ... heck, it can even be *wrong*!  But ... one can rather
easily also fix/improve it ... it is a wiki after all!  And yes, I have
occasionally done so (not to mention large numbers of other
contributors that have made lots of great contributions to build up the
whole wiki).  Also, with wiki, can be quite useful to look at the history,
and if applicable, comments or "talk" page or the like - for information
on what was/wasn't done earlier, changed, etc., and most notably *why*.

> 'ubuntuzilla'
Sounds like Ubuntu version of a monster ;-) ... or maybe intended to
sound more like Ubuntu+Mozilla, rather than other more commonly known
*zilla (e.g. featured in well known movie(s)).

> Date: Thu, 21 Jun 2018 23:30:20 -0700
> From: Rick Moen <rick at linuxmafia.com>
> To: conspire at linuxmafia.com
> Message-ID: <20180622063020.GT32401 at linuxmafia.com>
>
> I hope someone with more relevant experience will speak up and help.
> As a necessary disclaimer:
>
> 1.  I really don't like GRUB at all.

Well, GRUB is quite nice ... for certain definitions of "nice". ;-) 8-O

Yeah, it's quite big 'n bloated and all that, but it *is* loaded with
many features and capabilities ... which is both a quite significant
advantage ... *and* disadvantage.  E.g. there's a whole helluva a lot
of bells and whistles and options and things that can be done with GRUB
... so there's lots of details to potentially get lost among, and a
whole lot of screwey ways one could configure GRUB that one ought not to.
But GRUB can be comparatively easy to save one's bacon, when things go
a bit sideways - e.g. GRUB has lots of capabilities, to often pretty
darn easily and interactively, go from a semi-broken configuration/state,
to doing some modest bit of interactive boot stuff, to be booted and
up and running, and then typically fairly easily fix whatever was
messed up so that next time all boots nice and smoothly again - so
that's often highly doable without having to resort to some "recovery"
media or the like.

And ... Debian and GRUB?  As far as I'm aware, with (non-ancient) Debian
at least booting i386/amd64 from installed drive, the default bootloader
is GRUB, and has for a fair while now been GRUB "2.x".  Also, beware,
the version numbering on GRUB has been a bit loosey-goosey.  As often
happens with many open source projects, they'll do a relatively
high-numbered minor number portion of the version, e.g. x.9[89]...
before going to the x+1.0 release.  Okay, that's semi-fine to not do
major version number bump/release, until one's quite confident it's
well stable, most or all significant bugs have been chased out, and it's
very much production ready/quality.  However, the problem and confusion
tends to come in when this is done as part of stable/production release
version series - rather than a separate version series - and it tends to
start getting widely adopted because x.9[98]... version is so much
better (or more popular) than the earlier x.[0-8]... versions, that,
well, everyone starts using x.9[98]... in production, even though x+1.0
isn't yet out.  So, confusion over x.whatever versions vs. each other
and x+1.whatever versions ensue.  Such is the case with GRUB "2.0"
and the latter - and earlier - 1.9[whatever] and 1.[<=8]whatever
versions.  And GRUB is certainly not unique in this type version number
confusion.  Anyway, back to GRUB and *Debian* ... on (non-ancient) Debian,
default bootloader is GRUB, and more recently "2.x" version series
(starting, "of course", somewhere in the 1.9x range).  And, for Debian,
it mostly "just works", and pretty dang well so.  There's one GRUB
(mis?-)feature that Debian generally has enabled by default which I
generally disable - here's a big hint:
$ fgrep -i probe /etc/default/grub
GRUB_DISABLE_OS_PROBER=true
$
And ... why do I disable that (mis?-)feature?  I don't want GRUB poking
around and automagically building GRUB boot entries for anything and
everything it sees which it thinks might be a bootable operating system.
E.g. I have virtual machines ... GRUB having the audacity to think it
knows how to boot such - if/where it spots them - as if they could be or
ought be booted directly to run straight on the hardware - and not at
all virtual ... yeah, ... I certainly don't want that.  Anyway, that
prober thingy can end up creating GRUB boot entries for things that
ought not be attempted to be booted at all ... so ... I typically
disable it.  Other than that, I don't have any *major* complaints
about GRUB ... but the ones I do tend to occasionally grumble about
a bit is it is quite big (bloated) and complex ... but hey, it does
mostly just work, and quite dang well, and sure, it has (way too?) many
features/capabilities ... but at least *sometimes* those things come in
dang handy.  Debian being Debian, there are of course *many* choices,
including among them many other bootloaders one may choose to use
instead of GRUB.  Also, Debian - if one goes the upgrade route, I think
Debian fairly smoothly does take one from the earlier GRUB to the "2.x"
- at least if one has configuration that's default or not too absurdly
far from default.

And ... one other plus for GRUB (and may not be unique to GRUB) - very
well handles md RAID-1 and properly setting up so one can boot from either
drive if the other fails - all pretty dang seamlessly ... though there's
about a step or two one needs to manually do like about once to have that
properly set up.

Also, GRUB ... default on Debian, so, typically the easier path/approach.

And no, not a GRUB tutorial or how to fix one's broken GRUB/boot, but
thought I'd mention some key points, advantages/disadvantages, and
Debian specific GRUB bits.

>     (IMO, it's a lot smarter to meet any multi-OS needs using
>     virtual machine technology, though there are edge cases where
>     this isn't attractive.)

Yes, virtual machines - lovely solution in many (but not all) cases.

> It would have been really handy, about now, if you knew _where_ you
> installed GRUB when you last did so.
Most of the time it's fairly easy to figure out how bootloader(s) are
installed/configured ... GRUB is even pretty dang good about assisting
with that (many capabilities to probe stuff, list relevant information
about what it finds, etc.).  The only bit that can be slightly more
tricky is vestigial bits.  Something that was once installed, but never
fully overwritten, might be falsely detected as what it *was*, rather
than what it *is* ... rather similar to a former filesystem, where some
of the earlier data towards the start of the device/partition hasn't
yet been wiped or overwritten.

> Date: Fri, 22 Jun 2018 07:13:48 +0000 (UTC)
> From: Paul Zander <paulz at ieee.org>
> To: Rick Moen <rick at linuxmafia.com>,
>  "conspire at linuxmafia.com" <conspire at linuxmafia.com>
> Message-ID: <838105133.709284.1529651628840 at mail.yahoo.com>
> Subject: Re: [conspire] upgrade and grub

> BUT AFTER ALL OF THAT, firefox is still 45.8.0.=20

So ... Debian ... and similar also applies to at least *some* other
distributions (or sometimes at least in part).

Let's say, for sake of argument, one has an older Debian installation ...
maybe something that's been sitting unused in a closet for years, ... and
then one wants to use it again and get it current ... via upgrades.  Is
that doable?  What if it's from a point in time / version that's no
longer supported?  Well, if it's not too ancient - and pure Debian - not
some FrankenDebian or such, in general one can still upgrade it!  But yes,
it will take some extra steps.  I've in fact done this on occasion with
some very old Debian (or similar - notably some *buntu) installations,
that were no longer in a supported (due to age of installation)
configuration.  Anyway, repositories ... most notably for Debian, and in
not exactly any particular order:
o LTS - Debian has LTS ... it's a different support model than, e.g.
   Ubuntu's LTS.  But, one can read up on Debian's LTS and what's under
   LTS support, and if it may be the case that one has an installation
   that's no longer under Debian's main support, but is supported under
   LTS - and if that covers one's architecture, and the packages one has
   installed (or at least cares about), one may be able to relatively
   simply switch to LTS ... then get caught up on that, and if/when
   desired, upgrade from LTS to something that's still under Debian's
   main (non-LTS) support.
http://cdimage.debian.org/mirror/cdimage/archive/
   That's got binaries going back to just about Debian 3.0 (last I
   checked they were missing some packages to make it all they way fully
   back to 3.0 - and I'd in fact also followed up and made that data
   available to Debian).  And it's not just the CDs, etc., but all the
   packages (actually, older CDs, they don't have the ISOs there, but
   have the .jigdo files, etc., to build and validate the ISOs if one
   needs to have/recreate those).
https://snapshot.debian.org/
   Y'all can read about that on its web page, but in very brief, if one
   wants to find package by specific version or date, or use entire
   archive in a point-in-time manner ... yeah, one can do it that way.

So, with above facilities available, for some older Debian installation,
at least if it's pure Debian, and not too horribly ancient, one can
generally upgrade to a supported version.  Upgrades, ... also, don't
forget Debian's fine documentation up upgrades - notably release notes,
etc.  Many manage to upgrade quite fine without ever even reading such,
but one would be well advised to read (or at least skim) the materials,
to avoid most any "gottcha"s or other unpleasant surprises.

And, even if one may have some FrankenDebian or such, at least with such
archives, etc. available, it's often still quite feasible to fix and get
to a working system, get it consistent (consistently Debian), and upgrade
to something supported from there.

Oh, there are also various Debian lists and user groups,
e.g. bad.debian.net ... debian also has support via IRC.
Might not be as friendly for unwinding one's FrankenDebian or such,
but for pure Debian, tend to get *excellent* Debian support from such
resources.

Some other distributions may have some similar capabilities.  E.g.
Ubuntu:
   http://old-releases.ubuntu.com/releases/
   #archive of specific Ubuntu .deb binaries, e.g.:
    
https://launchpad.net/ubuntu/+archive/primary/+files/apport_2.14.1-0ubuntu3.2_a
ll.deb
Fedora:
   http://archives.fedoraproject.org/pub/archive/fedora/linux/releases/
CentOS:
   http://vault.centos.org/

> Date: Fri, 22 Jun 2018 00:15:55 -0700
> From: Rick Moen <rick at linuxmafia.com>
> To: conspire at linuxmafia.com
> Subject: Re: [conspire] upgrade and grub

> Apparently, the Official Debian installer disks now include a 'rescue
> mode' option offering suboption 'Reinstall GRUB boot loader', which is
> detailed on that page (in case you run into trouble).

Yes, over the years, the Official Debian installer images have added
some pretty dang nice and convenient repair/recovery capabilities.

> Date: Fri, 22 Jun 2018 00:24:24 -0700
> From: Rick Moen <rick at linuxmafia.com>
> To: conspire at linuxmafia.com
> Subject: Re: [conspire] upgrade and grub
>
> Quoting Paul Zander (paulz at ieee.org):
>
> confusing replacements for better bootloaders, but GRUB2 throws in the
> problem of being gratuitously different in important ways from GRUB
> Lecacy aka GRUB v1.)

Oh yes, for better and/or worse, GRUB "2.0" is very different than
"1.0".  On the plus side, "2.0" significantly easier to *use* (but not
necessarily configure) than "1.0", and "2.0" is quite nicely (over?
featured.  And Debian makes the "1.0" to "2.0" upgrade relatively
painless ... at least if one is at or not too horribly far from a
default Debian GRUB configuration.

> > BUT AFTER ALL OF THAT, firefox is still 45.8.0.
>
> So, figure out what package that is, remove it (preferably with the
> --purge) flag for apt-get so that you ritual-exercise _everything_ it

Another thing that might be quite useful/informative, is more
information/hints about where the installed version came from.  Use of
dpkg can quite help that.  For sake of argument/example, let's say our
Firefox installed binary is:
/usr/bin/firefox
Well, then we can do:
$ dpkg -S /usr/bin/firefox
diversion by firefox-esr from: /usr/bin/firefox
diversion by firefox-esr to: /usr/bin/firefox.real
firefox-esr: /usr/bin/firefox
$ dpkg -l firefox-esr
ii firefox-esr 52.8.1esr-1~deb9u1 amd64 Mozilla Firefox web browser -  
Extended Support Release (ESR)
$ dpkg -L firefox-esr | fgrep -x /usr/bin/firefox
/usr/bin/firefox
So, we can see in my installation above that /usr/bin/firefox is from
the firefox-esr package.  One might also want to notice are the version
numbers consistent.  E.g. if what the browser itself shows, and the
version shown by dpkg aren't consistent, one may be looking at a
FrankenDebian or such, whereas if they look to match / be consistent, then
it may at least be matched and managed by some installed .deb based package.
And, too, with the information I provided about Debian archives and such,
one may be able to check if one's installed version matches a version
that was released by Debian.  One can not only look at the version number
information, but the package itself - examine the binary in it - does
the binary of that browser in the package from Debian match the binary
of the installed browser? ... as opposed to happening to match the
version number, but possibly having come from somewhere other than Debian.
And ... .deb package files ... format?  They're ar(1) archive files with
a particular set of contents and format thereof.  So one can
(recursively) work to pull out the binary(/ies) from a .deb file, to
inspect or whatever.  Let's see ... (bit from my local cache I use, to
avoid multiple downloads of same binary to install on multiple on-site
Debian hosts):
$ find /var/tmp/cache -name '*52.8.1esr-1~deb9u1*' -type f -print
/var/tmp/cache/firefox-esr_52.8.1esr-1~deb9u1_amd64.deb
$ ar p /var/tmp/cache/firefox-esr_52.8.1esr-1~deb9u1_amd64.deb data.tar.xz |
xz -d |
tar -O -xf - ./usr/lib/firefox-esr/firefox-esr |
cmp - /usr/lib/firefox-esr/firefox-esr &&
echo MATCHED
MATCHED
... turns out /usr/lib/firefox-esr/firefox-esr is where the actual
browser binary is for this package.  And I can see from the above that
what I have installed at /usr/lib/firefox-esr/firefox-esr exactly
matches that contained in the Debian package
firefox-esr_52.8.1esr-1~deb9u1_amd64.deb

Also, if one's trying to hunt down when/where one's installed binary
came from, mtime can be handy.  Browsers (especially large complex ones)
tend to have frequent updates due to security issues (big, complex ...
bugs ... security bugs).  So, the modification time on the file may
quite narrow down around when it was released.  And then with Debian,
e.g. via snapshots, one may more quickly focus on Debian packages it may
possibly have come from.

> Should have said 'GPT/EFI thingie' or the like.
Yeah, ... that'd be another boot (& partition) thingy ... one I've not
yet had much experience with (but, among other things ... larger and
larger drive capacities ... will get there).

> Date: Fri, 22 Jun 2018 10:03:12 -0700
> From: Rick Moen <rick at linuxmafia.com>
> To: conspire at linuxmafia.com
> Message-ID: <20180622170312.GZ32401 at linuxmafia.com>
> Subject: Re: [conspire] upgrade and grub
>
> consequence of your having been tracking Testing.  As I've said, Debian
> doesn't really support downgrading very well.  Such situations can be

Testing ... or somewhat similarly sid/"unstable".  If one was using or
had installed that, then powered down and shoved system in a closet for
years ... yeah, that'd be at best a more difficult place to pick up from.
Most notably sid/"unstable", and testing, change quite frequently, so
the longer one goes without updating either of those, the less probable
it will become that one can subsequently update/upgrade and have that
all work reasonably smoothly (if feasibly at all).  Nevertheless ...
the aforementioned snapshot and such may still be quite useful
(particularly if it well covers testing/unstable).  Also, if one had
last updated using testing shortly before or after a major Debian stable
release, the testing, at/around that point may be "close enough", that
subsequently doing update/upgrade/dist-upgrade from that point may still
work well, or relatively reasonably.

> BTW, p.d.o. is very handy, and I keep lazily using it myself, but
> probably we'd both be better off training our fingers to instead use
> 'apt-cache search' in most cases.
Yup, "me too" - guilty as charged.  I do (also) use apt-cache search
quite a bit, but https://packages.debian.org/ is often more efficient on
my human time.  Also, if one has aptitude installed, it has very dang
capable search functionality - even well beyond that of p.d.o. - whereas
apt-cache search is "just" REs on a couple fields of data.  Also, aptitude,
I wouldn't mix use of aptitude to install/configure, with apt/apt-get
and for reasonably current Debian I'd strongly recommend apt / apt-get
for package management.  But aptitude may be worth having around just
for its search capabilities.  But I tend to purge aptitude before major
version upgrades - mostly because it kind'a gets in the way and
complicates things a bit (aptitude tracks desired package status, etc., in
a way that's just a wee bit different than and independent of
apt/apt-get; it also does dependency and conflict resolution and such a
wee bit different too).  But aptitude is mighty fine for searching stuff
about packages.

> Date: Mon, 25 Jun 2018 18:04:57 -0700
> From: Rick Moen <rick at linuxmafia.com>
> To: conspire at linuxmafia.com
> Subject: Re: [conspire] upgrade and grub
>
> As I mentioned before, _exactly_ that way of doing it is recommended on
> the Debian wiki:  https://wiki.debian.org/Seamonkey
As I mentioned before ... wiki.
Ooooh, we can fix that!  ;-)

> In fact, the standard expectation with desktop packages from or for
> Debian is that the software will register itself with the Debian
> facility for that purpose called 'menu', whose purpose in life is to

In more/most current Debian stable, that's changed somewhat ... I don't
recall the details, but I do recall it being mentioned in ... the
Release Notes?  Well, I thought I'd read it there - not finding it there
now ... it may be somewhere else that I read that.

http://linuxmafia.com/pipermail/conspire/2018-June/date.html