sysdig.com has an article on troubleshooting containers.  I believe this story has something to do with vsyscall later on in the document.

https://sysdig.com/blog/troubleshooting-containers/

But, an early troubleshooting step shown here, is to generate a core dump.

ulimit -c unlimited
bad_command_to_execute

For me, this is some kind of BOINC process.  It might be that executing the shell script in init.d might show something interesting, but I suppose the core produced would be of bash, dash or something like that.  So, I think I need to manually start a BOINC job, in the hopes that it makes this vsyscall?

Too many posts under my name at the top of the list.

As it appears that the original ASRock motherboard was at least partially at fault for why the Ryzen 1600 would not work, it seems possible that that CPU is not a dud.

---

I picked up a A320 motherboard on sale.  If this Ryzen 1600 works, that's wonderful.  But I doubt the application requires a 12 core CPU.

Long ago, I heard of the stealth logserver.

I suppose the original stealth logserver was a printer attached to the console, and it just printed everything that happened.  If someone broke in, they could do nothing about the log entries already printed.  Regardless of kernel messages about printer on fire, which was always a "joke".

But the stealth logserver I remember from way back when; was a computer on a LAN, where all non-stealth computers were configured to send their logs to a public logserver.  And it logged everything.  But on the LAN was a computer with a NIC that had no assigned IP address, and the NIC was in promiscuous mode.  And so, it could also log everything.  As it had no IP address, there is no (easy) way to get to it, to erase logs.

More recently, writeups about stealth logservers, don't talk about a stealth (promiscuous) machine paralleling logs.  All the machines on the LAN are configured to send log messages to a machine which doesn't exist.

Is it better that the stealth logserver is paralleling a real logserver, or that the config of all the other machines makes it obvious that the logs are on a "stealth" machine?

Recent articles on this concept talk about running a network intrusion detector on a stealth machine.  Like snort.  The idea of a stealth machine, is that there is no way to get to it; it has no IP.  So, if the intrusion detection machine detects that an intrusion has happened, how does this message get to the LAN server and/or the router, to stop the intrusion?

I see that the DEB_BUILD_OPTIONS from the earliest comment is slightly different from what I have tonight.  I think the important part is nostrip (don't strip the DEBUG symbols out).

A day or so ago, I ran across some new threads of interest about APUs and GPUs in a computer.

If want to compare
%command%

with
DRI_PRIME=1 %command%

If command is glxinfo and I go looking for the provider, the first version reports the APU, and the second version reports the RX-550.  So, I am guessing that the motherboard graphics and APU are the default.  If command is glxgears, I get about 20% higher frame rate with the RX-550.  The monitor is connected to the motherboard VGA connector.

I am guessing that this means that amdgpu is able to work with both the APU and the GPU.  I have never read anything about having to put DRI_PRIME=1 in anything having to do with BOINC jobs, so I don't know if that is a solution or not.  There is still the problem that clinfo hangs, and never tells you anything.

Some time ago, I had time to pull the old motherboard (old, it is almost new).  One of the support posts came undone, so that  required a little fiddling.  The odd header in different places between the old ASRock and the new MSI motherboard.  Manufacturers really don't include everything they should in the instructions.

Anyway, I cleaned the old heat transfer fluid off stock wraith cooler and CPU with the Arctic kit (the cooler never did look like a mirror).  I put some Arctic MX-4 on the new (Ryzen 2600) CPU, and re-installed the wraith cooler.  I had problems with the cooler no being coplanar with the CPU, which is aggravated by the screws on the cooler being (IMHO) too short.

As this new motherboard had never been booted before, I had some adjustments to make.  Like different net hardware.  And possibly that SATA1 is not available if you have a nvme SSD (I did); that is poorly documented.  Anyway, Devuan booted.  BOINC ran fine with 3 cores (of 12).  Run more than 3 cores, and eventually it dies.  I thought at first; I've got another dog of a CPU.  Nothing in the logs.  But, run xsensors and the CPU is running too warm.  I think the mounting problem caused much of the thermal compound to get squeezed out.

Why spend time using a stock cooler which suffers from screws being 2mm too short?  So, I bought the AM4 specific Noctua U12 tower cooler.  Wait a while for it to arrive in the mail, and it pops on just fine.  Used the Noctua compound with the Noctua cooler.  I've run it with 3 cores, 4 cores, 5 cores, 6 cores and now 8 cores under BOINC, and the temperatures are sitting in the high 50 to low 60C.  There is a lot of overlap, you couldn't predict number of cores active from the temperatures.

I picked up a _big_ disk (Seagate 8TB NAS) and put it in this machine as well, the idea to try and set it up as documentation server (involving squid) should the Internet go down.  It's on btrfs.  I'm still trying to figure out how to get it to cache things for HTTP and HTTPS.  Essentially I am the only person in the house that uses the computers, so I don't think there are any breaking encryption problems with this.

---

This machine was originally a Ryzen 1600, I also have a Ryzen 1600X.  That machine has a not too big RAID-10, and is running BackupPC, mostly to backup my LAN server, which is due for hardware upgrades yet this (almost finished) winter.

If I write back in this post, will it get noticed?

I am still working with problems related to graphics.

I never did get a local version of that amd graphics firmware built.  Debian cascading to Devuan did produce updates.  On the machine I was having problems with, some newer kernels would boot and some wouldn't.  That problem eventually resolved through upgrades to the kernel.

But the problem of the CPU locking up, whether it was lightly loaded, heavily loaded or something else never went away.  The firmware package that is in Devuan, should load the right stuff.  I've upgraded the BIOS to the newest available.  I have tried playing with the various settings on the kernel command line, and while it may change lockups in an hour or 2 to lock ups in several hours, the machine just wouldn't run.

To me, the symptoms looked like the idle lockup, where a CPU core goes to sleep, and never wakes up, and this brings the entire system down at some point.  I don't have sleep or hibernation or anything like that set up (it's a desktop, and if running does BOINC or other stuff).

Oh, about the time I tried the Ryzen 5 2600, I also had purchased a pure sine wave UPS, so it was on better power than before.  I believe the power supply is a Seasonic Focus 80+ Platinum.  Should be good enough components.

That was with a Ryzen 5 1600.  I bought a Ryzen 5 2600 and tried that, and it does the same thing.  This being winter, I had time to work on things, and so I am almost finished replacing the motherboard.

What is left is to remove the CPU/cooler from the old motherboard, clean the two surfaces off (I have the Arctic kit for this) and apply new compound to the CPU/cooler interface before installing the new cooler (factory Wraith) on the CPU.

If the new motherboard works, then I will be happy.  I will report on that.

----

If the new system works, I am going to think that my old CPU is fine.  I have another application where I have a AM4 socket motherboard with the low end A320 chipset.

AMD not too long ago announced some new CPUs.  One of them was a Ryzen 5 2600E - a 45W CPU.  It appears that at least in the near term, this is an OEM chip only.  But some people are thinking that if you devolt the CPU, you probably should be able to get it down to 45W.  The A320 chipset is supposed to not let overclocking (and yet, you can find manufacturers saying how wonderfully their A320 motherboard overclock), but perhaps it will let a person devolt the CPU?  I will report on that at some point.  But, I have another post to make.

I restarted 7 BOINC jobs with the kernel command line trying to help, and after about 3 days it found a long enough idle to freeze.

I restarted (not getting the kernel command line mods in), so I used that zen program to disable cstate6.  The power went out before it crashed.  I guess I forgot to tell the power company that I was going to do this test.  :-)

I think I will wait for 4.19 before I start this again.

I guess there was no "real" problem with filesystems.  The only thing that seems to have happened, is the "dirty bit" was set on the VFAT mounted at /boot/efi.

Fixing that "dirty bit", it boots now.

However, that new BIOS doesn't fix the problem.  At least not without kernel command line arguments.  I again added

rcu_nocbs=0-11 processor.max_cstate=5 idle=nomwait

to the kernel command line.  We'll see if that helps with the freezing in idle.

Okay, booted into the graphical install Devuan-Ascii DVD, blew away the gpt partitioning of the NVMe SSD, and partitioned a singl;e 20GB MBR partition, and installed Devuan into it.  I am almost finished, just grub to install.

It asks me, I've noticed that you have 2 other OS installed on this computer (on the SATA SSD which is /dev/sda).  Do you want me to write to the MBR of the _FIRST_ disk?

What pray tell, is the first disk?  /dev/nvme0n1p1 sorts before /dev/sda*.  The SATA SSD is partitioned with a gpt partition scheme, which includes a protective MBR (I believe).

It would be nicer, if the query we define what it thinks the first disk is.

I booted the ASCII DVD in a UEFI manner to graphical/rescue.  Console F1 has a message about fixing fbdev (xf86gamma).

The system asks me for the root partition, so I point at nvme0n1p3.  It asks about a boot partition, is I point at nvme0n1p2.  It asks about EFI partition, so I point at nvme0n1p1 (for /boot/efi).

It then asks about starting a shell in the root partition.  But so far no questions about /usr and /var partitions, so I am going to mount those manually from console F2 before answering the question.

No, I haven't booted any Linux from the NVMe drive.  I can change the order drives are searched through, I had tried moving the NVMe up to first.  There is lots of storage on the LAN, so I could back up that device to a disk somewhere, and install a MBR based Linux.  I would hope that an image based backup of /dev/nvme0n1 would be sufficient.

Oh well, it's not raining and my coffeebreak is over.  Time to get back to work.