diagnose/fix boot/software issue: (e.g.) linuxmafia.com host

[Michael Paoli]

[BCC some SF-LUG folk(s)][0]

Rick,

Well, in my earlier email[1], I was primarily addressing remote
assistance, but I also had in mind to email you regarding in-person
on-site visit (I'll cover some of that below, and some of it in separate
email).

Regarding in-person on-site visit, points well taken (and which I
more-or-less mostly already had in mind, even well before seeing that
email from you).  Sort of the "too many cooks spoil the soup" and/or
some problems just don't well parallelize.[2]

And (extended) vacation is generally good.  :-)  Only so much
time/resource, so good to get in some vacation and rest/relaxation when
and as feasible and reasonably appropriate relative to
time/resources/priorities.

On the (potential) remote bits, I was thinking folk(s) (including
myself), could potentially poke away at software/data bits of the issue,
and at their leisure (e.g. comfort of one's home, and at any convenient
time ... like 2:36 A.M. on a Sunday ... when on-site wouldn't be so
convenient/feasible and would likely be a lot colder).  But that may or
may not be all that useful/helpful - as it not only would require making
the relevant data available (which itself takes time/energy/resources),
but also it's mostly only useful if hardware issues are already mostly
or entirely out of the way - and thus may not be feasible and/or the
most time/resource efficient way to get the issue(s) resolved.  But I
was also pointing it out more generally, how such an approach *could* be
used - even if might not be "best", or even fitting/usable approach
in this particular case.  E.g. If not that to be used like that for this
case, I'd still probably use bit of similar approach before any
potential on-site visit, to (re)familiarize myself with some
lower-level GRUB commands and (a)typical GRUB boot/repair scenarios ...
not that I've not done them before, but more so that it's so rare that
I have to deal with more complex GRUB repair scenarios, it would be
good to refresh myself on that a bit before going into that
comparatively cold (and cold garage).  So, would be good
exercise/refresher for me to do that prep work/exercise, and would
thus better optimize use of on-site time (particularly also since the
latter involves at least two people's time, rather than just my time).

Footnotes/references/excerpts:
0. per request - good luck to them on seeing further replies
1. Message-ID: <20150104001726.189661sugotbt3oc at webmail.rawbw.com>
    excerpts also referenced further below (notably much of body)
2. I was thinking, among potential volunteer(s) for such - including
    myself, regardless of how skillful/talented any or all may be, you
    might want to quite severely limit how many you'd want to do for at
    least any single visit to (or attempt to) assist/help you, and you
    may want to - even very severely - limit person(s) and number of
    person(s) to what would be an optimal number for you to be able to
    get done what needs to be done.  And realizing the optimal number of
    additional persons beyond yourself could be a very small number -
    perhaps even as small as zero, if, e.g., you already quite know what
    needed to be done, and just needed the time to do it, and couldn't
    (more) feasibly hand it off to someone else to do or complete.  And
    yes, sometimes more folks, regardless of how skilled, doesn't make
    things go faster.  E.g. reminds me of a situation at work some years
    ago.  "Of course" there was something that was desired to be done
    faster, but such just wasn't feasible given the nature and
    complexity of the needed to be done, and the (comparatively) little
    that remained to be completed on the project vs. its complexity and
    relatively unique nature and environment specific loads of details -
    essentially the overhead of just hand-off itself would've exceeded
    the time/resources needed to complete it with those already involved
    and working on the project.  So, sometimes you just can't throw
    resources at something to make it go faster.  Sometimes there's also
    critical bottleneck(s) that can't be accelerated - e.g. access to
    critical resource/person - such as one highly familiar with relevant
    details, where that data isn't elsewhere, or isn't nearly as
    accessible elsewhere, or there may be limited resource on hardware
    that can't be simultaneously shared, or CPU/memory resources (how
    much time to compile/compress how much code/data), needed time for
    testing and regression testing, testing with additional
    systems/interconnects, bandwidth limits, etc.


> From: "Rick Moen" <rick at deirdre.net>
> Subject: Re: diagnose/fix boot/software issue: (e.g.) linuxmafia.com host
> Date: Sun, 4 Jan 2015 01:11:41 -0800

> Hi, Michael.  Are you saying you-personally or you-plural wish to come
> over and work through debugging?  Your mail left that unclear.
>
> To be quite frank, I've been on extended vacation, i.e., slacking off,
> and also a bit deterred by the very cold weather.  Thus the lack of
> any hurry doing investigation.  If I'd been determined to deal with
> the problem, it would have been gone long before now, either by
> working through the annoying apparent combination of hardware and
> software problems on the current machine, or by saying the hell with
> antiquated 2001-era PIII hardware, building a from-scratch Debian
> installation, restoring data files from my backup, and grinding
> through the really time-consuming task of rebuilding all the services
> needed.  No question about my ability to do that; I've been able to do
> it several times on an emergency basis since the '80s when I started
> having my own Unix hosts.  I've just been a slacker about dealing with
> this problem.  Sorry to have to admit that, but it's the truth.
>
> If you are offering in-person resources that you seriously hope to
> bring net resources to the table (and I do absolutely respect you, to
> be clear), then thank you, and give me at call at 650-283-7902
> (cellular) to say when you hope to visit.  There was a friend who
> visited to help during my initial round of investigations, where I
> diagnosed the initial problem as an apparent motherboard failure,
> moved the hard drives to a spare VA Linux 2230 box, to my great relief
> verified that all my filesystems were intact, updated my backups, and
> tried and failed to fix the boot configuration before running out of
> patience.  (This was just before I left the country, then came back
> and found that now the _newer_ model 2230 now also produced no video
> and gave the appearance of having suffered motherboard failure.)
>
> My point about the friend (whom I won't name because i don't want to
> embarrass him):  He really did want to help, and I bless him for
> generously donating a Saturday, but in the end all he did was chew up
> my time asking me questions and making incredibly bad suggestions.  On
> the plus side, he was good company, _but_ the work would in all
> honesty have gone more quickly if he hadn't visited at all.  I'm glad
> he came, because I like the guy and do not begrudge the couple of
> hours of my time that he wasted, but -- man! -- wanting to help and
> actually providing help are sometimes _so_ totally different things.
> For example, I'd be concentrating on working through the suspect list
> and my friend would suddenly break my concentration with an
> unbelievably clueless question that relied on a bunch of wrong
> assumptions - and I'd have to then spend half an hour working through
> his misunderstandings to get to the point where he could understand
> why his question hadn't even been relevant or useful, and then
> painfully attempt to return to the original problem I'd been
> considering when he broke my concentration.  The whole day was like
> that.
>
> If your idea is to not visit but rather offer remote assistance, then,
> no thank you.
>
> A couple of you visiting who have relevant experience diagnosing and
> fixing boot configs would be most welcome.  I make really good coffee.