Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #174853 > unrolled thread

Distinguishing between hardware, software, and operator induced symptoms

Back to article view | Back to linux.debian.user

Contents

  Distinguishing between hardware, software, and operator induced  symptoms Richard Owlett <rowlett@cloud85.net> - 2016-11-18 15:30 +0100
    Re: Distinguishing between hardware, software, and operator induced  symptoms Richard Owlett <rowlett@cloud85.net> - 2016-11-18 15:50 +0100
      Re: Distinguishing between hardware, software, and operator induced symptoms Cindy-Sue Causey <butterflybytes@gmail.com> - 2016-11-18 16:10 +0100
        Re: Distinguishing between hardware, software, and operator induced  symptoms Richard Owlett <rowlett@cloud85.net> - 2016-11-18 17:30 +0100
    Re: Distinguishing between hardware, software, and operator induced symptoms "Thomas Schmitt" <scdbackup@gmx.net> - 2016-11-18 16:30 +0100
      Re: Distinguishing between hardware, software, and operator induced  symptoms Richard Owlett <rowlett@cloud85.net> - 2016-11-18 17:20 +0100
    Re: Distinguishing between hardware, software, and operator induced  symptoms Bob Weber <bobrweber@gmail.com> - 2016-11-18 16:30 +0100
      Re: Distinguishing between hardware, software, and operator induced  symptoms Richard Owlett <rowlett@cloud85.net> - 2016-11-18 17:10 +0100
    Re: Distinguishing between hardware, software, and operator induced  symptoms Pascal Hambourg <pascal@plouf.fr.eu.org> - 2016-11-18 21:00 +0100
      Re: Distinguishing between hardware, software, and operator induced  symptoms Richard Owlett <rowlett@cloud85.net> - 2016-11-19 12:10 +0100
        Re: Distinguishing between hardware, software, and operator induced  symptoms Pascal Hambourg <pascal@plouf.fr.eu.org> - 2016-11-19 13:30 +0100
    Re: Distinguishing between hardware, software, and operator induced  symptoms David Christensen <dpchrist@holgerdanske.com> - 2016-11-19 04:30 +0100
      Re: Distinguishing between hardware, software, and operator induced  symptoms Richard Owlett <rowlett@cloud85.net> - 2016-11-19 12:10 +0100

#174853 — Distinguishing between hardware, software, and operator induced symptoms

As noted in the "Invoking ddrescue" thread 
[https://lists.debian.org/debian-user/2016/11/msg00641.html], my 
laptop [dedicated to educational/experimental projects which 
could fail spectacularly] used to apparently successfully run 
ddrescue, malfunctioned.

<*BACKGROUND*>
The laptop is a used Lenovo R61 running Debian 8.6.0 with MATE 
D.E. installed from purchased set of DVDs. The "damaged" and 
destination drives were connected by separate USB adapters [each 
powered by separate wall warts].

Sequence of events:
A. Run ddrescue
    1. Power on laptop, responding "root" at login prompt.
    2. To force predictable /dev/sdX assignments, sequentially 
connect destination
       and "damaged" drives.
    3. Apparently run ddrescue to a successful conclusion.
    4. Disconnect "damaged" drive.
    5. Power down for the night.
B. Setup to extract data in useful format from the rescued partitions
    [There are missing details as I report from memory, log files 
do *NOT* exist]
    1. Power up sequence fails to run successfully
       a. systemd reports it's checking a partition with mounting 
problems
          [it is the same message as when the UUID of the swap 
partition does
           not have the expected value.]
       b. I notice that wall wart for the destination drive is 
unplugged.
          I power down, plug it in, power up laptop.
       c. systemd again reports mounting problem. I allow 
sequence to continue.
          I never receive login screen and assume fatal error 
related USB drive.
       d. Power down, disconnect USB drive, attempt reboot from 
scratch.
          i. Don't recall if systemd complained that USB was not 
present.
             [It is mentioned in /etc/fstab -- see previous thread.]
         ii. Boot sequence appears to run to point where 
appearance of login
             screen expected. It does not. I'm not able to glean 
useful information
             from log files.
     2. Decide to reinstall as there is no valuable data on the 
hard-drive.
        a. Neither the Install nor Live DVD's will load.
        b. On a second machine dd the Install DVD to a flash drive.
           It installs as expected.
< end *BACKGROUND*>




QUESTIONS:

A. Hardware diagnostics [as CD has already proved unreliable]
    1. Memory - I have memtest86+, will have to put it on flash drive
    2. Hard disk - Somewhere I have a Seagate specific diagnostic 
which has
       proved useful on non-Seagate drives. Is there a 
recommended more
       generic diagnostic?
    3. Are there recommended [for want of a better term] board 
level diagnostics
       that do not depend on an OS already being installed?
B. OS integrity checks
    I would assume that being able to login without noticing any 
thing is a
    fairly good check. However, I have experience symptoms which 
may have multiple
    unrelated causes. Is there a suggested system integrity check?
C. Other
    I have a typical collection of diagnostic CD/DVDs from which 
I can create
    equivalent iso files. I have a vague recollection of a 
procedure to put GRUB
    [or was it LILO?] on a bootable flash drive with multiple iso 
files and being
    able to choose which to boot. Ring any bells? Suggested 
search terms?

TIA

[toc] | [next] | [standalone]

#174854

On 11/18/2016 8:25 AM, Richard Owlett wrote:
> [snip]
>     I have a typical collection of diagnostic CD/DVDs from which
> I can create
>     equivalent iso files. I have a vague recollection of a
> procedure to put GRUB
>     [or was it LILO?] on a bootable flash drive with multiple iso
> files and being
>     able to choose which to boot. Ring any bells? Suggested
> search terms?
>

Upon hitting send recognized obvious search terms ;/
Checking multiple hits.
If anyone has a favorite, I am interested.

[toc] | [prev] | [next] | [standalone]

#174855 — Re: Distinguishing between hardware, software, and operator induced symptoms

On 11/18/16, Richard Owlett <rowlett@cloud85.net> wrote:
> On 11/18/2016 8:25 AM, Richard Owlett wrote:
>> [snip]
>>     I have a typical collection of diagnostic CD/DVDs from which
>> I can create
>>     equivalent iso files. I have a vague recollection of a
>> procedure to put GRUB
>>     [or was it LILO?] on a bootable flash drive with multiple iso
>> files and being
>>     able to choose which to boot. Ring any bells? Suggested
>> search terms?
>>
>
> Upon hitting send recognized obvious search terms ;/
> Checking multiple hits.
> If anyone has a favorite, I am interested.


During your original email, it came to mind that people seem to
interchange "thumb drive" and "pen drive". And depending on the
efficiency of the search engine, sometimes you must match it as one
word if someone wrote it that way, e.g. pendrive and thumbdrive..

And there I go catching a further thought while proofreading before
hitting send... You said flash drive. On this latest cognitive grasp
of that phrase, mental images of SDHC and compact flash.... memory....
drives.... disks... sticks... __CARDS... also came to mind and are
surely used by someone for booting on occasion which would then be
brought up in conversation if there were significant issues and/or
findings.

In fact I just recently purchased a VERY cheap micro-SD card for an
old camera phone I'm using as an in--hand security cam. Having had
that micro.... ooh, card... there's another one to add up above.
Anyway, having had that micro-SD card in hand inspired me to budget in
a second one to experiment with something just like it sounds like
you're attempting to do here and now..

Just thinking out loud. :)

Cindy

-- 
Cindy-Sue Causey
Talking Rock, Pickens County, Georgia, USA

* runs to shut off a very old perking coffee pot *

[toc] | [prev] | [next] | [standalone]

#174862

On 11/18/2016 9:09 AM, Cindy-Sue Causey wrote:
> On 11/18/16, Richard Owlett <rowlett@cloud85.net> wrote:
>> On 11/18/2016 8:25 AM, Richard Owlett wrote:
>>> [snip]
>>>      I have a typical collection of diagnostic CD/DVDs from which
>>> I can create
>>>      equivalent iso files. I have a vague recollection of a
>>> procedure to put GRUB
>>>      [or was it LILO?] on a bootable flash drive with multiple iso
>>> files and being
>>>      able to choose which to boot. Ring any bells? Suggested
>>> search terms?
>>>
>>
>> Upon hitting send recognized obvious search terms ;/
>> Checking multiple hits.
>> If anyone has a favorite, I am interested.
>
>
> During your original email, it came to mind that people seem to
> interchange "thumb drive" and "pen drive". And depending on the
> efficiency of the search engine, sometimes you must match it as one
> word if someone wrote it that way, e.g. pendrive and thumbdrive..
>
> And there I go catching a further thought while proofreading before
> hitting send... You said flash drive. On this latest cognitive grasp
> of that phrase, mental images of SDHC and compact flash.... memory....
> drives.... disks... sticks... __CARDS... also came to mind and are
> surely used by someone for booting on occasion which would then be
> brought up in conversation if there were significant issues and/or
> findings.
>
> In fact I just recently purchased a VERY cheap micro-SD card for an
> old camera phone I'm using as an in--hand security cam. Having had
> that micro.... ooh, card... there's another one to add up above.
> Anyway, having had that micro-SD card in hand inspired me to budget in
> a second one to experiment with something just like it sounds like
> you're attempting to do here and now..
>
> Just thinking out loud. :)
>
> Cindy
>

I JUST knew I had seen something relevant.
Seems I asked the question a few months ago and received >30 
replies ;/
[q.v. https://lists.debian.org/debian-user/2016/04/msg01040.html ]

[toc] | [prev] | [next] | [standalone]

#174856 — Re: Distinguishing between hardware, software, and operator induced symptoms

Hi,

Richard Owlett wrote:
> I have a vague recollection of a procedure to put GRUB
> [or was it LILO?] on a bootable flash drive with multiple iso
> files and being able to choose which to boot.

I guess it depends much on the content of the ISO whether this will work:

  http://www.syslinux.org/wiki/index.php?title=MEMDISK#ISO_images

In any case the booting ISO must fit into RAM and still leave the
system enough RAM to work properly.


Have a nice day :)

Thomas

[toc] | [prev] | [next] | [standalone]

#174861

On 11/18/2016 9:28 AM, Thomas Schmitt wrote:
> Hi,
>
> Richard Owlett wrote:
>> I have a vague recollection of a procedure to put GRUB
>> [or was it LILO?] on a bootable flash drive with multiple iso
>> files and being able to choose which to boot.
>
> I guess it depends much on the content of the ISO whether this will work:
>
>    http://www.syslinux.org/wiki/index.php?title=MEMDISK#ISO_images

Doesn't attack the problem from preconceived direction.
Examining it and links should prove instructive.

>
> In any case the booting ISO must fit into RAM and still leave the
> system enough RAM to work properly.
>
>
> Have a nice day :)
>
> Thomas
>
>

[toc] | [prev] | [next] | [standalone]

#174857

[Multipart message — attachments visible in raw view] — view raw

Try system-rescue-cd at http://www.system-rescue-cd.org.  It has a full set of
Linux commands (boots several versions of Linux kernels) and some hardware
diagnostics including memtest86 you mentioned.  It is a full Linux OS even with
a graphical mode (run startx or select on main menu) to run a browser and other
graphical tools. 

One of the tools is a disk scan and repair utility.  It even has a remap mode to
remap bad sectors.

I have used this disk (burned to CD or put in a flash drive) for years repairing
my Linux or Windows OS's (mostly XP).  It has a grub boot utility to help repair
grub installations.

The ultimate disk repair utility is spinrite (at grc.com).  It is a $89 pay
program but when you need data off a failing drive its worth it.  There are many
testimonials about how a Windows installation can be made bootable again after
running a spinrite scan.

*...Bob*
On 11/18/2016 09:25 AM, Richard Owlett wrote:
> As noted in the "Invoking ddrescue" thread
> [https://lists.debian.org/debian-user/2016/11/msg00641.html], my laptop
> [dedicated to educational/experimental projects which could fail
> spectacularly] used to apparently successfully run ddrescue, malfunctioned.
>
> <*BACKGROUND*>
> The laptop is a used Lenovo R61 running Debian 8.6.0 with MATE D.E. installed
> from purchased set of DVDs. The "damaged" and destination drives were
> connected by separate USB adapters [each powered by separate wall warts].
>
> Sequence of events:
> A. Run ddrescue
>    1. Power on laptop, responding "root" at login prompt.
>    2. To force predictable /dev/sdX assignments, sequentially connect destination
>       and "damaged" drives.
>    3. Apparently run ddrescue to a successful conclusion.
>    4. Disconnect "damaged" drive.
>    5. Power down for the night.
> B. Setup to extract data in useful format from the rescued partitions
>    [There are missing details as I report from memory, log files do *NOT* exist]
>    1. Power up sequence fails to run successfully
>       a. systemd reports it's checking a partition with mounting problems
>          [it is the same message as when the UUID of the swap partition does
>           not have the expected value.] I
>       b. I notice that wall wart for the destination drive is unplugged.
>          I power down, plug it in, power up laptop.
>       c. systemd again reports mounting problem. I allow sequence to continue.
>          I never receive login screen and assume fatal error related USB drive.
>       d. Power down, disconnect USB drive, attempt reboot from scratch.
>          i. Don't recall if systemd complained that USB was not present.
>             [It is mentioned in /etc/fstab -- see previous thread.]
>         ii. Boot sequence appears to run to point where appearance of login
>             screen expected. It does not. I'm not able to glean useful
> information
>             from log files.
>     2. Decide to reinstall as there is no valuable data on the hard-drive.
>        a. Neither the Install nor Live DVD's will load.
>        b. On a second machine dd the Install DVD to a flash drive.
>           It installs as expected.
> < end *BACKGROUND*>
>
>
>
>
> QUESTIONS:
>
> A. Hardware diagnostics [as CD has already proved unreliable]
>    1. Memory - I have memtest86+, will have to put it on flash drive
>    2. Hard disk - Somewhere I have a Seagate specific diagnostic which has
>       proved useful on non-Seagate drives. Is there a recommended more
>       generic diagnostic?
>    3. Are there recommended [for want of a better term] board level diagnostics
>       that do not depend on an OS already being installed?
> B. OS integrity checks
>    I would assume that being able to login without noticing any thing is a
>    fairly good check. However, I have experience symptoms which may have multiple
>    unrelated causes. Is there a suggested system integrity check?
> C. Other
>    I have a typical collection of diagnostic CD/DVDs from which I can create
>    equivalent iso files. I have a vague recollection of a procedure to put GRUB
>    [or was it LILO?] on a bootable flash drive with multiple iso files and being
>    able to choose which to boot. Ring any bells? Suggested search terms?
>
> TIA
>
>
>

[toc] | [prev] | [next] | [standalone]

#174860

On 11/18/2016 9:26 AM, Bob Weber wrote:
> Try system-rescue-cd at http://www.system-rescue-cd.org.
  I have it in my accumulated collection of CDs.
  Need to explore it more.

[toc] | [prev] | [next] | [standalone]

#174866

Le 18/11/2016 à 15:25, Richard Owlett a écrit :
> As noted in the "Invoking ddrescue" thread
> [https://lists.debian.org/debian-user/2016/11/msg00641.html], my laptop
> [dedicated to educational/experimental projects which could fail
> spectacularly] used to apparently successfully run ddrescue, malfunctioned.

The most important tool is a brain with knowledge of the history. Exemple :

Q. Did the operator change anything to the system before it failed ?

A. Yes. He created a permanent automatic mount entry in fstab for a 
removable device which is not always present. BIG mistake. At least when 
you do that, add the "nofail" option and use an identifier which is less 
volatile than the device file.

Solution : revert the change. No need to reinstall.

[toc] | [prev] | [next] | [standalone]

#174876

On 11/18/2016 1:58 PM, Pascal Hambourg wrote:
> Le 18/11/2016 à 15:25, Richard Owlett a écrit :
>> As noted in the "Invoking ddrescue" thread
>> [https://lists.debian.org/debian-user/2016/11/msg00641.html],
>> my laptop
>> [dedicated to educational/experimental projects which could fail
>> spectacularly] used to apparently successfully run ddrescue,
>> malfunctioned.
>
> The most important tool is a brain with knowledge of the history.
> Exemple :
>
> Q. Did the operator change anything to the system before it failed ?
>
> A. Yes. He created a permanent automatic mount entry in fstab for
> a removable device which is not always present. BIG mistake. At
> least when you do that, add the "nofail" option and use an
> identifier which is less volatile than the device file.
>
> Solution : revert the change. No need to reinstall.

If could've, would've <smile>
When I noticed that systemd was having problems with the 
destination disk I discovered the wall wart was unplugged.
If my _only_ problem was the fstab entry, shouldn't my sequence of:
   1. power down laptop
   2. plug in wall wart
   3. power up laptop to reboot
have worked?

[toc] | [prev] | [next] | [standalone]

#174879

Le 19/11/2016 à 12:01, Richard Owlett a écrit :
> On 11/18/2016 1:58 PM, Pascal Hambourg wrote:
>>
>> Q. Did the operator change anything to the system before it failed ?
>>
>> A. Yes. He created a permanent automatic mount entry in fstab for
>> a removable device which is not always present. BIG mistake. At
>> least when you do that, add the "nofail" option and use an
>> identifier which is less volatile than the device file.
>>
>> Solution : revert the change. No need to reinstall.
>
> If could've, would've <smile>
> When I noticed that systemd was having problems with the destination
> disk I discovered the wall wart was unplugged.
> If my _only_ problem was the fstab entry, shouldn't my sequence of:
>   1. power down laptop
>   2. plug in wall wart
>   3. power up laptop to reboot
> have worked?

Maybe. Maybe not. You used the device name /dev/sd* in fstab, but this 
is volatile and may change the next time you plug in the same device.

Bottom line : do not use volatile device names in fstab. Use UUID, label 
or whatever persistent identifier available in /dev/disk instead.

[toc] | [prev] | [next] | [standalone]

#174871

On 11/18/2016 06:25 AM, Richard Owlett wrote:
> As noted in the "Invoking ddrescue" thread
> [https://lists.debian.org/debian-user/2016/11/msg00641.html], my laptop
> [dedicated to educational/experimental projects which could fail
> spectacularly] used to apparently successfully run ddrescue, malfunctioned.
> 
> <*BACKGROUND*>
> The laptop is a used Lenovo R61 running Debian 8.6.0 with MATE D.E.
> installed from purchased set of DVDs. The "damaged" and destination
> drives were connected by separate USB adapters [each powered by separate
> wall warts].

Don't use USB external SSD/ HDD enclosures for low-level work.  You want
to connect your HDD's to a SATA motherboard connector or
known-Linux-good HBA in a desktop or server chassis.


David

[toc] | [prev] | [next] | [standalone]

#174875

On 11/18/2016 9:22 PM, David Christensen wrote:
> On 11/18/2016 06:25 AM, Richard Owlett wrote:
>> As noted in the "Invoking ddrescue" thread
>> [https://lists.debian.org/debian-user/2016/11/msg00641.html], my laptop
>> [dedicated to educational/experimental projects which could fail
>> spectacularly] used to apparently successfully run ddrescue, malfunctioned.
>>
>> <*BACKGROUND*>
>> The laptop is a used Lenovo R61 running Debian 8.6.0 with MATE D.E.
>> installed from purchased set of DVDs. The "damaged" and destination
>> drives were connected by separate USB adapters [each powered by separate
>> wall warts].
>
> Don't use USB external SSD/ HDD enclosures for low-level work.  You want
> to connect your HDD's to a SATA motherboard connector or
> known-Linux-good HBA in a desktop or server chassis.
>
>
> David

It was a case of using what was actually available ;)

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web