Trying to troubleshoot crash on new installation (SOLVED)

Featherfoot · Last edited by Featherfoot on Sat Feb 03, 2018 2:27 am; edited 1 time in total

I am rebuilding my amd_64 system after a catastrophe and I am having some problems.

I used a .config file from a system pre-crash to rebuild my system. It appears to mostly complete and then crash. The screen goes blank and after a few seconds there is a lot of whirring on the disk.
I tried to turn off X with the nox option on my boot and it seemed to work as Xorg.0.log stopped appearing in the logs. This implies to me that X is not the problem.

I am chrooting into the gentoo environment from Mint 18.3. I found that dmesg produces the Mint output even when I have chrooted in per the manual. Can I trust the listing in /var/log/dmesg? If not, is there a way to make it happen?

/var/log/sddm.log appeared to be reasonable for a long time then showed junk.
/var/log/messages is a hex dump. If I am looking for fatal messages, should I be looking at the tail?

Is there a way to log the messages so that I know which module could be the problem? Is increasing the dmesg level in the kernel worthwhile?

Featherfoot · Posted: Fri Feb 02, 2018 3:15 am Post subject:

I should have said my kernel is being built by genkernel-3.4.52.4-r2. The kernel is gentoo-sources-4.9.76-r1.

The system is an amd64 system with 16 Gb of memory. It uses an AMD Phenom II X4970 processor. The disk system is a 240 Gb Crucial SSD and a 1 Tb RAID 1 array.

NeddySeagoon · Posted: Fri Feb 02, 2018 9:18 am Post subject:

Featherfoot,

Edit your original post to provide further information until you have a reply. When you respond to yourself your topic falls out of the unanswered post search and helpers may miss it.

When you boot mint, you will always get the mint dmesg. dmesg is the booting kernels log.
Saving logs depends on having somewhere to save them. That only happens if the boot gets as far as remounting root read /write.
In the chroot, /var/log/dmesg will be the leftovers of your last normal boot. Do check the timestamp. If its pre apocalypse, it won't be useful.

For the purposes of the investigation, lets assume that the system boots normally but you can't see it.
Can you boot normally and ssh in to get logs?

In parallel, but on the same theme, please post your

Featherfoot · Posted: Fri Feb 02, 2018 7:57 pm Post subject:

Thanks for responding. As I mentioned, I booted with and without X and it crashed each time. There wasnt time to ssh in. I looked at the dmesg file in /var/log and it had a bunch of complaints from the open source Nvidia driver which shouldn't have been involved. Apparently you can set dmesg levels in the kernel. Do you know if they do anything useful for a non-kernel xeveloper?

NeddySeagoon · Posted: Fri Feb 02, 2018 8:05 pm Post subject:

Featherfoot,

Lets try some analysis.

Featherfoot · Posted: Fri Feb 02, 2018 9:21 pm Post subject:

lspci follows:\

jburns · Posted: Sat Feb 03, 2018 1:29 am Post subject:

From your dmesg output both the nouveau and the nvidia driver are being loaded.

Featherfoot · Posted: Sat Feb 03, 2018 1:45 am Post subject:

I see that too. I probably should remove nouveau from my .config file, but it worked before.

I rebooted and tried to ssh into the gentoo system from another computer. It failed. I was able to get information in /var/log/messages: https://pastebin.com/fyW522zN

There are lot of evbug messages that I need to figure out how to get rid of, but it basically shows the same thing

Featherfoot · Posted: Sat Feb 03, 2018 2:26 am Post subject:

I removed nouveau from the kernel and it started to work!

Of course, I have a few things to set up but I can probably solve these problems.

Thank all of you for your help.