Okay, I can try the cli installer.  I am getting okay at typing nvme0n1p9 anyway.

The /var/log/messages file had 2 booting sessions in it.  I think the first is the booting of the VM, and the second is the (attempted) booting of the NVMe.  The end of the messages file is a bunch of nulls.  I don't see any obvious errors in it.

The NIC is getting the igp driver, but for whatever reason it never comes up.  There seems to be problems with bad non volatile memory in the I211 NIC, but I am not seeing that in the log file.

Rebooting the VM, I see nothing in the log file or .xsession-errors about the NIC.  WICD tries to do something, but I don't know why it is failing.

I downloaded lubuntu-17.10, and booted it to live-cd.  It too uses igp for a driver, and this gets an IP.  So I now know that the cable works.  I've got some stuff to do outside, and then I'll come back and try to figure out what lubuntu is doing differently.

And try the cli installer.

I was hoping that some btrfs experts might come by, oh well ....

I used gdisk (from SysRescue) to partition the disk.  Partition #1 of each device is a 200 (201?) MB EFI System Partition (I believe starting at sector 2048).

A NVMe "disk" is the root device, which has a bunch of partitions to be used eventually, and a scratch partition to install Devuan into initially.  If the previous partition is less than 1G, no extra space was inserted.  For partitions bigger than 1G, a space of 129 (or 128) MB was used.  There will be a bunch of partitions, and about half of the NVMe was partitioned.

The 4 (spinning rust) disks got a 16G partition (2 for swap, 2 for /tmp as a RAID-0), and then almost everything else to be part of a RAID-10 /home.

With gdisk, if you want an "empty space" before a partition begins, instead of using a sector number, you can give it an offset.  For a beginning value, the offset probably is positive.  So I typically used +129M as an offset (gdisk seems to round things, and if you want a 128MB space, it seems like you need to enter +129M).  For the end of disks, I wanted to assign all the space except for about 40GB or so, so I used -40G (or -48G ?) for the end value of a partition.

The thinking is that if you go to unfragment a partition at some point, and you are using a smart program for unfragmenting, it will notice this unallocated space adjoining the partition and use it when unfragmenting.

Back again.

I tried running the install again.  The refract error log has an error with grub-install of
/usr/lib/grub/i386-pc/modinfo.sh
doesn't exist.  specify target or directory.

There is a /usr/lib/grub/x86_64-efi directory, and it has a modinfo.sh file.

The install doesn't use the uefi installer, as /sys/firmware/efi doesn't exist.

I tried looking in the refracta shell scripts and the config file for this /usr/lib/grub subdirectory name, and if it is there, I missed it.

But, from the BIOS, if I choose the NVMe to boot, it is just a silent failure.  No grub menu or grub shell is ever displayed.

The refracta environment is also loading the igb driver for the network.  I'm beginning to think the cable might be bad, so maybe I should check that.

This machine (and most of my machines) connect to the OpenWRT router via an unmanaged switch.  But, when I looked at the switch before plugging in this new machine, all the ports are full.

Some of the disks I have booted, have attempted to configure networking, and been unsuccessful.  I am beginning to think that unmanaged switches don't like to have old hardware removed and new hardware installed.

The GUI does have a menu item to use the refracta (I hope I spelled that correct) installer.  I ran that, and it allowed me to pick the scratch partition, and it seemed to install stuff.  But, a reboot would not get there, but maybe I need to mess with the BIOS on that.  I then booted the system rescue CD, and attempted to have it boot into an OS on the machine.  No joy there.  But maybe it doesn't look in /dev/nvme* for OS's?

The router should only have WAN and a single LAN connection (to the switch).  So I should be able to plug the network cable into the router, and maybe then dhclient (or whatever) will be able to get an IP, and be able to connect to the internet.

That should allow me using the system rescue CD, to boot into what refracta installed.

I do have another unmanaged switch here (never used) with 8 ports (more than the 5 the current switch has), because my network is growing.  So I could invoke that.

But the ISO that fsmithred produced still looks like a good start.  He doesn't want complaints, can I send teases?  Emacs is not present.  So I will guess that fsmithred is a vi person.  :-)  I seen a virc file from (I believe) Tom Christensen (one of the gods of Perl), and it was huge.  So I have no doubt that vi works well for some people.  One explanation I've seen on vi/emacs, is how long your fingers are.  Sure.  I don't think mine are that much longer than everyone elses.  And I've never written any extension in LISP.  So I guess I am not a _real_ emacs user.

Everyone can have problems.  I think I am a long ways along the process of getting Devuan working on this "razor edge" machine.  :-)

I am just missing a few details.

I think I like penguinista more than ryzenista.  But, I had never run across the Ryzen version before.

Live long and prosper.
Gord

Thanks a lot.  I think I should be able to figure it out.  I started with Linux with the 1.2.13 kernel (Yggdrasil, or something like that).  Me and command lines go way back.

Some place in my old hardware pile, I have a pair of AMD CPUs that double as heaters.  I think they are still on a motherboard, I don't remember if it was working when I replaced them, but it is likely they still work.

Razor edge?  Some of these parts have been sitting on the shelf for 6 months, waiting for winter to allow time to put things together.  :-)

But, if you want me to try a bunch of things, I can try to do that.  I shouldn't run out of disk space with 4TB of completely empty RAID-10 disk (rust) space.

I tried to get to an text terminal with the NET ISO, and nothing happened, so I am guessing that nothing keyboard or mouse was working.

Just now, I burned the refracta to a DVD and booted it.  It got through the boot fine, but once everything settled there was no response to keyboard or mouse.  Just like the NET ISO and DVD install images.

It's getting late, time to go to sleep.

The 8 core computer with RX-460 continues to crunch.  The only GPU work it gets is from Einstein@Home, which are jobs which are about equally split between CPU and GPU.  SETI@Home jobs I believe all assume you are running Catalyst (or Crimson) or AMDGPU-Pro (in other words, proprietary).

I moved a mini-ITX motherboard from a fullsize ATX case into a mini-ITX case.  This has a A10-7860k APU.  It was  planned to run with a R7-250, but that seemed to require Crimson, which was a nightmare.  The R7-250 was replaced with a HD-6450, which ran under Catalyst (but was proprietary).  On the move, I put a RX-550 into the machine.  The HDMI output is plugged into the motherboard, and so makes use of the GPU part of the A10.  The RX-550 is left all alone to do crunching.  Perhaps in the future it will be possible to get the GPU side of the A10 to number crunch as well.

Initial E@H estimated time was 1:11, first job ran in 34 minutes.

I am only allowing 2 (of 4) CPU cores to run BOINC, leaving 2 free for other stuff.  Perhaps a person can throw another CPU at things?

Maybe I am reading too much.  :-)

I am not too overjoyed at having purchased hardware to find it deprecated, or about to be deprecated.  Some of this I may be mis-interpreting.

Advances in the Xorg server have made fglrx (Catalyst or Crimson) a non-starter for anyone with an up to date OS.  Mesa/Clover/libclc/Clang is providing a OpenCL-1.1 environment, and work continues.  It appears that the choke point in this is libclc.  Apparently nobody has tried (published?) an attempt to run OpenCL-1.2 tests against this combination.  What is there now, is 1.1 with extensions, and most of what is needed for 1.2 seems to be done.  But there doesn't seem to be any urgency in getting to this 1.2 state.  I'm not writing code, so it is easy for me to write.

AMD helped with the open source amdgpu module, and produces a proprietary amdgpu-pro driver.  Does this driver following the same philosophy as fglrx?  Is it just as enjoyable to work with?  In any event,  I gather AMDs answer to Clover is ROCm.  While amdgpu is supposed to support all GCN cards/GPUs, ROCm doesn't seem to support all of GCN.  So, if you follow the AMD hardware side and go to ROCm for OpenCL support, you may find that your older hardware will not play any more.  For instance, my A10-7860k APU and R7-250 GPU would be too old.

---

In any event, Einstein CPU and GPU jobs are working on the RX-460 using MESA (no fglrx).  SETI sent some GPU jobs, but as near as I can tell it is only compiling them for Oland (and fglrx).  So I get a build failure, and it pauses for a while, and then another build failure.  Oland is what was in this computer before (the R7-250).  I have looked to see if there is some old data file doing this, but I am drawing a blank.  The CPU jobs are coming through fine.

I have stopped downloading new tasks on this machine to empty the queue (except for these build failures, which will never run I guess), as I am ready to copy my old /home to a new disk, and BOINC data actually sits in /home.

Which may give me time to see what this HD5450 can do again.

Happy Thanksgiving!

Looking in the "slots", I have found a log file of interest.

It is looking for a OpenCL kernel file, which is not present.  Is this file supposed to be part of the download from Seti@Home, or is it supposed to be calculated locally?

This is being manually typed (not cut and paste), so there could be errors

AstroPulse_Kernels_ r2751.cl_ bin_V7_TWIN_FFA_1721

The only OpenCL things I am seeing for GPU, are Oland files.

Woo Hoo!  Partial success.  I have CPU jobs working.

It seems that at about the 4.8 kernel, the vsyscall was set to "none".  If you look in your logs, you should see a bunch of lines where BOINC jobs are getting squashed because of this.  These are the system logs, not the files in the BOINC directories.

On booting in grub, you can edit a command line and add
vsyscall=emulate
to the linux (kernel boot) line.

If this works, you can change the grub default linux boot line in /etc/default/grub and add
vsyscall=emulate
to that parameter, and then update-grub.

Maybe with something working, I will see why amdgpu (not amdgpu-pro) and mesa are not getting together to run GPU jobs.  Or maybe they will start by magic as well.  :-)