On Saturday 07 September 2019 12:05:45 Nathan Stratton Treadway wrote:

> On Sat, Sep 07, 2019 at 04:31:04 -0400, Gene Heskett wrote:
> > i interchanged the order, so /boot was first and removed those dle's
> > that weren't mounted. Same story, dead the second amanda touched it.
>
> (Note that the order the DLEs are listed in the disklist doesn't
> control the order they are dumped.  But I guess in fact you would be
> able to tell which DLE was the one that triggered the crash because
> that one DLE will have a "data timeout" error in the Amanda Mail
> Report.)
>
That would be /, the last in last nights emailed list. All report loss of 
path.

> > too, then I will re-install, using the armhf version. Maybe theres
> > something in amanda that demands armhf.
>
> That doesn't seem very likely to me... but this is definitely a
> question to take up with an rpi-knowledgeable crowd.

Who are rather unsupprisingly, ill informed if its not a core app for 
them. My running amanda, or LinuxCNC isn't an approved and blessed 
activity on one of their beloved pi's and is not going to be blessed by 
the koolade drinkers answers.  The answers are more often than not 
delivered with a liberal dose of condecension.

> > There is also another possibility, building amanda on the arm64, as
> > opposed to using the common and clients debs from the repo. I have
> > NDI which the repo versions are built for.
>
> (Again, I would say it shouldn't be possible for any sort of Amanda
> build to cause a full system crash... but rpi folks will hopefully
> have some actual ideas as to what's going on.)
>
> > AHA!!!!!
> >
> > Maybe this is a clue, I had three ssh -Y sessions running into that
> > machine before amanda ran. Two of then lost route to host, as
> > expected for a crash, but the third was running a sudo -i (root)
> > shell, and it logged this:
> > ------------------
> > root@picnc:/usr/local/etc# ls
> > (I expected that to be empty, it was, and I left it there for the
> > night) root@picnc:/usr/local/etc#
> > Broadcast message from systemd-journald@picnc (Sat 2019-09-07
> > 02:04:29 EDT):
> >
> > systemd[1]: Caught <BUS>, dumped core as pid 3974.
> >
> >
> > Broadcast message from systemd-journald@picnc (Sat 2019-09-07
> > 02:04:29 EDT):
> >
> > systemd[1]: Freezing execution.
> > ---------------
>
> Yes, this is definitely what you are looking for.
>
> > This should be a clue, when I go out and power cycle it to reboot,
> > I'll see if I can find that core dump and preserve it. The question
> > then is what do I do with it? Can gdb look at it?
>
> I don't know much about debugging rpi/ARM systems.  The only
> Amanda-related advice I can think of is to check your Amanda logs to
> see if pid 3974 was an Amanda process.  It certainly seems like
> your next step is to track down exactly what process is trigging that
> SIGBUS....
>
> (Googling for "systemd[1]: Freezing execution." may lead you to some
> journalctl commands that could provide more info on the crash... but I
> don't know if the debian-arm's installation sets up all the logging,
> etc. needed for that to work.)
>
Neither do I.

That journalctl would take a reboot, which might do some housekeeping, so 
I'll stick card in reader and get the core dump before I reboot.

>                                       Nathan
>
> ----------------------------------------------------------------------
>------ Nathan Stratton Treadway  -  [email protected]  -  Mid-Atlantic
> region Ray Ontko & Co.  -  Software consulting services  -  
> http://www.ontko.com/ GPG Key:
> http://www.ontko.com/~nathanst/gpg_key.txt   ID: 1023D/ECFB6239 Key
> fingerprint = 6AD8 485E 20B9 5C71 231C  0C32 15F3 ADCD ECFB 6239



Copyright 2019 by Maurice E. Heskett
Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>

Reply via email to