You are not logged in.
Not seeing anything that looks like KVM in the BIOS. Time to go googleing.
Offline
There is a virtualization option. In the CPU configuration, it is called SVM mode. It was disabled, so I enabled it. Tried to reboot, picked the first option in the grub menu, and again the boot hangs about 8 seconds (or is it 8 milliseconds?) in. Last line printed has something like
sp5100_tco: I/O address 0x0cd6 already in use
Offline
When you get to the part in the installer where it wants to install grub, everything should already be mounted. The efi partition should be mounted at /boot/efi, and /sys /proc /dev and /dev/pts should all be mounted to the corresponding point on /target. It sounds like grub found it anyway.
When you get to the grub boot menu, press "e" and add to the linux line: nomodeset
Then ctrl-x to boot.
Offline
I am not sure what the installer did, it the EFI partition was mounted at /boot/efi. Because looking there (I think it was there), there was /boot/efi/EFI/* There were 4 subdirectories in EFI, and from an earlier session they all contained a single file of the same name and size.
But when I tried to mount the EFI partition manually (/dev/nvme0n1p1) mount complained that there was no filesystem on that partition. So I put a FAT filesystem on there.
But adding nomodeset to the grub linux line allows it to boot.
Now to figure out why networking still isn't working.
Oh. In the install process it asked me for a root password. Which I gave it. When I finally got a login, and entered root, I had to use the password that the CD has. The one I gave it was not used. I've since changed the passwd manually.
Offline
So happy to hear that you're making progress! Your persistence is impressive. Guess we're just a stubborn bunch in this camp.
Offline
I added nomodeset to /etc/default/grub and update-grub
The name of the wired interface in /etc/wicd/manager-settings.conf was wrong. DHCP now runs and gets an IP,and ping works.
Thanks for the help!
Offline
The persistence would have been wasted, had fsmithred not been willing to help with that CD.
I still have lots of work to do before this machine will be set to number crunching. And I need to get emacs on it soon. :-)
But, if devuan wants stuff tested on a Ryzen 1600X, I think I can soon do some of that. I suppose I might extend that to Refracta as well.
Offline
I hope I didn't offend fsmithred. I said I was teasing about emacs. I also reported a couple of things I noticed about the refracta CD (well for me it was a DVD, but ...).
It looks like nomodeset is not exactly the answer I am looking for, but I have an idea where to look. With nomodeset, it appears that amdgpu is not loaded as a module, and what I end up with are VESA graphics. Which is probably okay. The problem is that without amdgpu loaded, the GPU won't work. So finding an alternative to nomodeset to allow booting is needed.
I installed a bunch of mesa stuff (and llvm-5) to use the GPU at some point. I also loaded a bunch of BOINC packages. But, I forgot to add vsyscall=emulate to the bootline before, so the first job downloaded from SETI@Home died. Eventually they are supposed to move away from needing vsyscall, and then a person can drop this from the boot line (it is supposed to be a security problem). The kernel does report the 1600X as having 12 cores (it is 6 cores, but they are dual threaded). So allowing BOINC to use 90% of the CPUs, means 10 jobs are running at the same time.
Hmm, I should load some sensors packages, to see what the temperature is doing.
Anyway, I am making headway with getting this machine going. Thanks to fsmithred.
Offline
I hope I didn't offend fsmithred.
He is pretty unoffendable . . .
Offline
Thank you. I don't mean to hurt anyone's feelings, but I have little ability to read people, so it makes it quite likely that I will say or write something that has effects I hadn't planned on.
Offline
libsensors4/lmsensors reads almost nothing. Looking at development information on these packages, there have been no updates for months.
There is a fork by groeck at github, which among other things has tackled the new sensor (ITE8665E) which is in many AM4 motherboards. Supposedly it is working for many people.
I can try this fork here. What is the best way to handle this? Download the source tree for libsensor4/lmsensors as well as this fork, and if it works make a diff of the 2 trees? (Probably someone knows magic to get git to do that directly?)
I do see that I forgot to hook up one connector in this build. The power supply is a Corsair RM750i, and so I need to connect the power supply to a USB2 header. There is at least one open source package now that can read data from these Corsair digital power supplies.
I'm still looking into the nomodeset "problem". I now have a 4.13 kernel also installed, which works well with RX460 and RX550 using amdgpu, so I'll try editing the grub boot line to remove it and see what happens. Some people thought that Linux Mint might be a good test for screen resolution abilities, so I have that LiveCD here too.
Offline
The 4.13 kernel from Devuan boots and seems to work fine without nomodeset. So I get the amdgpu driver. Boinc has noticed the GPU that is present, and is currently doing an Einstein@Home GPU/CPU job involving it.
SETI@Home is currently down for maintenance, so I can't check anything from that end.
LinuxMint/Mate-18.3 boots fine, for those so inclined. It takes a long time to boot in my opinion (UEFI DVD).
Offline
I cloned the git tree, and then downloaded (apt-get source) the Debian source tree (or more properly, the devuan source tree). There are probably differences in some include files, but I did a diif -u of the Debian lib/ subtree and the git lib/ subtree. Ignoring things only found in the git subtree (because I had compiled the package, and hence had all those files present), the diff -u file is 158 lines long.
A lot of differences are of the form
-ifdef BLAH
+ifdef BLAH_H
which are philosophical/cosmetic in nature.
There is a different kind of sensor which this git fork has in it, which is not present in the Debian code. I don't (yet) know if this new sensor on AM4 motherboards is of this type or not.
I'm guessing what I do, is that I make the changes to the Debian source tree, and build a package with is incrementally greater in version number than what I have installed. I install the new package to test it, and afterwards I revert things to what was there before.
How can this work be made available to others?
Offline
Sorry, I was busy doing other things. No, I'm not offended easily, as golinux mentioned, and certainly not about which editor to use. .I knew you were kidding. However, if I ever announce that I'm going to run notepad in wine, you are welcome to come down on me hard.
If you can make a package that works, you could put it up anywhere and tell people about it. If you want to try to get it into the devuan repo, you should set it up on git.devuan.org and follow the d1h directions in the Documentation section of this forum. Other than that, you seem to know what to do. Mess with the package, test it, and then I'm not sure why you would revert your system if you just created a solution. For versioning, you should check the debian documentation on that. You could use the same version as the source you're using and add a +something like we do for the devuan packages. But really, check the docs. It can be a bit confusing. (is for me, anyway).
Mint/ubuntu seem to be slow at everything. Not just booting. Trying to run them in a VM can give me an anxiety attack from waiting for something to respond.
Offline
Well, I downloaded I believe the most current lm-sensors from Debian, and I have the git source tree of this fork which has support for a few other things, not just the chip on the motherboard I have. The git source compiles, but I didn't test it.
I have now replaced all the original source with the stuff from git, and I am going to try and make a Debian package. I'm following the Debian wiki on this, it looks like there are lots of finicky steps involved.
I will go along this route, is it will probably be easier to keep my system going this way. As far as making packages for other people, I suppose the place I would start is the person who forked lm-sensors. I didn't look to see if he wanted people to package his archive (sorry, assuming "his" there).
I suspect this will be a good exercise, because I probably wouldn't mind being involved with Perl packages on Devuan. And I am going to be doing some OpenCL stuff in the future.
Last weekend there was an interview on the CBC Radio with an American who was a buddhist. And the interviewer asked him if there was anything that got him uptight. And he said that it would probably be driving behind someone who was really slow on a narrow country road. You seem to be cut from the same cloth as him.
Offline
It is not recommended to use Debian packages except those that have been monitored by amprolla for Devuan. Even if it seems to work, you will not get security or other updates via Devuan and there may be incompatible changes as Devuan moves forward. Was lm-sensors not in the Devuan repos? Maybe in backports or ascii? (Apologies if I missed something above)
Offline
I did use apt-get to get the lm-sensors source package, so it would have been a Devuan source package.
You didn't miss anything, I normally talk to people who are not pedantic enough, and stuff slipped.
What differences can be realised between a Debian package, and a Devuan package?
I can put this in context. As I mentioned above, I am interested in helping with Perl. One thing that has always bothered me about perl modules in Debian, is that the package pages seldom tell you what the CPAN name of the package is. Another is that tests and examples (from CPAN) often go missing. So if you are trying to figure out how to use a Perl package, none of this is there to help you.
I am not an expert at XS (or SWIG?). I suppose I will have to develop that. At heart, I am a FORTRAN person. But, I have written something that was like RATFOR for FORTRAN-77, and I once ported most of Perl-4 to QNX-2.x (nothing related to networking). Nothing ever published on the Internet, but the Perl port to QNX-2.x was used for production where I was working (at a research nuclear reactor).
Offline
I did use apt-get to get the lm-sensors source package, so it would have been a Devuan source package.
Oh . . . that's a good thing then.
You didn't miss anything, I normally talk to people who are not pedantic enough, and stuff slipped.
There are pedants here and especially on the dng list. I am not one of them. I am a gui-girl who couldn't package my way out of a paper bag. I do a pretty good job of playing with crayons though . . .
What differences can be realised between a Debian package, and a Devuan package?
The thing we're most concerned with is removing systemd dependencies. But there are also versioning differences that make packages compatible with the Devuan repos for continuity of upgrading.
I am unqualified to comment on the rest of what you posted.
Offline
Split the personal chatter to Off Topic and forgot to leave a link. Sorry . . .
Offline
No problem.
Have a great day!
Offline