| View previous topic :: View next topic |
| Author |
Message |
GDH-gentoo
Veteran
Joined: 20 Jul 2019
Posts: 1687
Location: South America
|
 Posted: Sun Aug 22, 2021 1:46 am Post subject: |
 |
|
| "EFI-based Framebuffer Support" and "Simple framebuffer support" are not under "AMD GPU", they are under "Frame buffer Devices", which I forgot to add. I edited my earlier post. Sorry. |
|
| Back to top |
|
 |
ONEEYEMAN
Advocate
Joined: 01 Mar 2005
Posts: 3650
|
| Posted: Sun Aug 22, 2021 3:32 am Post subject: |
|
|
Hi,
Turned them on, recompiled the kernel, and it didn't boot up.
Same results - all I see is:
| Code: |
Loading kernel 5.x.xx......
|
and that's it.
Here is the new configuration.
Thank you. |
|
| Back to top |
|
|
ONEEYEMAN
Advocate
Joined: 01 Mar 2005
Posts: 3650
|
| Posted: Tue Aug 24, 2021 12:57 am Post subject: |
|
|
GDH-gentoo et al,
Any idea what to try next?
Thank you. |
|
| Back to top |
|
|
apiaio
Guru
Joined: 04 Dec 2008
Posts: 426
|
| Posted: Tue Aug 24, 2021 6:42 pm Post subject: |
|
|
Hi ONEEYEMAN.
I assume that your kernel config is correct. Could you please send output of ?
Which filesystems did you create for your partitions layout? |
|
| Back to top |
|
|
ONEEYEMAN
Advocate
Joined: 01 Mar 2005
Posts: 3650
|
| Posted: Tue Aug 24, 2021 7:03 pm Post subject: |
|
|
Hi,
You mean the partition scheme?
OK, I will do that tonight.
Thank you. |
|
| Back to top |
|
|
figueroa
Advocate
Joined: 14 Aug 2005
Posts: 3005
Location: Edge of marsh USA
|
| Posted: Tue Aug 24, 2021 7:34 pm Post subject: |
|
|
Yeah, -l for "list" like:
| Code: | | $ sudo fdisk -l /dev/sda |
_________________
Andy Figueroa
hp pavilion hpe h8-1260t/2AB5; spinning rust x3
i7-2600 @ 3.40GHz; 16 gb; Radeon HD 7570
amd64/23.0/split-usr/desktop (stable), OpenRC, -systemd -pulseaudio -uefi |
|
| Back to top |
|
|
ONEEYEMAN
Advocate
Joined: 01 Mar 2005
Posts: 3650
|
| Posted: Tue Aug 24, 2021 10:45 pm Post subject: |
|
|
Hi,
| Code: |
[root@sysrescue ~]# fdisk -l /dev/sda
Disk /dev/sda: 931.51 GiB, 1000204886016 bytes, 1953525168 sectors
Disk model: HGST HTS721010A9
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 8234EA55-7D56-8D49-828F-0032D3704579
Device Start End Sectors Size Type
/dev/sda1 2048 526335 524288 256M EFI System
/dev/sda2 526336 34080767 33554432 16G Linux swap
/dev/sda3 34080768 1953525134 1919444367 915.3G Linux filesystem
[root@sysrescue ~]#
|
Thank you. |
|
| Back to top |
|
|
figueroa
Advocate
Joined: 14 Aug 2005
Posts: 3005
Location: Edge of marsh USA
|
| Posted: Wed Aug 25, 2021 1:22 am Post subject: |
|
|
Sadly, looks perfectly normal.
_________________
Andy Figueroa
hp pavilion hpe h8-1260t/2AB5; spinning rust x3
i7-2600 @ 3.40GHz; 16 gb; Radeon HD 7570
amd64/23.0/split-usr/desktop (stable), OpenRC, -systemd -pulseaudio -uefi |
|
| Back to top |
|
|
ONEEYEMAN
Advocate
Joined: 01 Mar 2005
Posts: 3650
|
| Posted: Wed Aug 25, 2021 1:32 am Post subject: |
|
|
Hi,
Is there a way to see where does it stop?
What I mean is this:
When the kernel starts booting up it frop everything into dmesg.
Unfortunately when I start booting SystemRescueCD, the dmeg from Gentoo becomes overwritten and lost.
Is there a way to boot Gentoo and then when rebooted on SR CD somehow preserve the dmesg?
Thank you. |
|
| Back to top |
|
|
jburns
Veteran
Joined: 18 Jan 2007
Posts: 1217
Location: Massachusetts USA
|
| Posted: Wed Aug 25, 2021 2:30 am Post subject: |
|
|
In your kernel .conf you have | Code: | | # CONFIG_HSA_AMD is not set |
the AMDGPU wiki has | Code: | <*/M> HSA kernel driver for AMD GPU devices (HSA_AMD)
|
|
|
| Back to top |
|
|
ONEEYEMAN
Advocate
Joined: 01 Mar 2005
Posts: 3650
|
| Posted: Wed Aug 25, 2021 4:07 am Post subject: |
|
|
Hi
| jburns wrote: |
In your kernel .conf you have
| Code: |
# CONFIG_HSA_AMD is not set
|
the AMDGPU wiki has
| Code: |
<*/M> HSA kernel driver for AMD GPU devices (HSA_AMD)
|
|
Turned this on, recompiled, installed, rebooted - same results.
Thank you. |
|
| Back to top |
|
|
ONEEYEMAN
Advocate
Joined: 01 Mar 2005
Posts: 3650
|
| Posted: Wed Aug 25, 2021 5:07 pm Post subject: |
|
|
Hi,
As I said - how to check the dmesg from the build log that failed?
Right now completely booting SystemRescueCD overwrites the dmesg output with the boot from it.
I just feel that it is trial and error instead of going to the source and fixing it. 
Thank you. |
|
| Back to top |
|
|
apiaio
Guru
Joined: 04 Dec 2008
Posts: 426
|
| Posted: Wed Aug 25, 2021 5:23 pm Post subject: |
|
|
It seems so, that your kernel or GRUB installation is botched.
I think, that the way how to eliminate one of this two possibilities is to use BIOS boot.
Please, create MBR
| Code: | | grub2-install /dev/sda |
and new GRUB
| Code: | | grub-mkconfig -o /boot/grub/grub.cfg |
If you boot new installation, problem is in your EFI setup.
If not, in your kernel |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 22626
|
| Posted: Thu Aug 26, 2021 2:18 am Post subject: |
|
|
| ONEEYEMAN wrote: | As I said - how to check the dmesg from the build log that failed?
Right now completely booting SystemRescueCD overwrites the dmesg output with the boot from it. |
That doesn't sound right. SystemRescueCD shouldn't be overwriting any files from the Gentoo filesystem unless you specifically tell it to do so. Overwriting /var/log/dmesg is particularly bad. |
|
| Back to top |
|
|
ONEEYEMAN
Advocate
Joined: 01 Mar 2005
Posts: 3650
|
| Posted: Thu Aug 26, 2021 3:20 am Post subject: |
|
|
Hu,
This is what I'm getting:
| Code: |
root@sysrescue ~]# mkdir -p /mnt/gentoo
[root@sysrescue ~]# mount /dev/sda3 /mnt/gentoo
[root@sysrescue ~]# mount --types proc /proc /mnt/gentoo/proc
[root@sysrescue ~]# mount --make-rslave /mnt/gentoo/sys
mount: /mnt/gentoo/sys: not mount point or bad option.
[root@sysrescue ~]# mount --rbind /sys /mnt/gentoo/sys
[root@sysrescue ~]# mount --rbind /dev /mnt/gentoo/dev
[root@sysrescue ~]# chroot /mnt/gentoo/ /bin/bash
sysrescue / # source /etc/profiloe
bash: /etc/profiloe: No such file or directory
sysrescue / # source /etc/profile
sysrescue / # export PS1="(chroot) ${PS1}"
(chroot) sysrescue / # which dmesg
/bin/dmesg
(chroot) sysrescue / # /bin/dmesg
[ 0.000000] Linux version 5.10.52-1-lts (linux-lts@archlinux) (gcc (GCC) 11.1.0, GNU ld (GNU Binutils) 2.36.1) #1 SMP Tue, 20 Jul 2021 16:46:09 +0000
[ 0.000000] Command line: BOOT_IMAGE=/sysresccd/boot/x86_64/vmlinuz archisobasedir=sysresccd archisolabel=RESCUE804
[ 0.000000] [Firmware Info]: CPU: Re-enabling disabled Topology Extensions Support.
[ 0.000000] random: get_random_u32 called from bsp_init_amd+0x284/0x2c0 with crng_init=0
[ 0.000000] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'
[ 0.000000] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
[ 0.000000] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
[ 0.000000] x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256
[ 0.000000] x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 'standard' format.
[ 0.000000] BIOS-provided physical RAM map:
|
According to this output the dmesg on my hard drive refer to the SystemRescueCD.
Unless dmesg binary only suppose to look at the booted drive.
Thank you. |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 22626
|
| Posted: Thu Aug 26, 2021 3:00 pm Post subject: |
|
|
That output seems right. | ONEEYEMAN wrote: | | Code: | (chroot) sysrescue / # /bin/dmesg
[ 0.000000] Linux version 5.10.52-1-lts (linux-lts@archlinux) (gcc (GCC) 11.1.0, GNU ld (GNU Binutils) 2.36.1) #1 SMP Tue, 20 Jul 2021 16:46:09 +0000
[ 0.000000] Command line: BOOT_IMAGE=/sysresccd/boot/x86_64/vmlinuz archisobasedir=sysresccd archisolabel=RESCUE804 |
According to this output the dmesg on my hard drive refer to the SystemRescueCD. |
Effectively, yes. | ONEEYEMAN wrote: | | Unless dmesg binary only suppose to look at the booted drive. |
No. dmesg does not look at any drive. Per the manual page: | Code: | dmesg is used to examine or control the kernel ring buffer.
The default action is to display all messages from the kernel ring buf‐
fer. |
Therefore, you can only use it to manage the contents of the ring buffer from the running kernel. There is a file, named /var/log/dmesg, that some init systems will write during early boot by running dmesg > /var/log/dmesg or similar. That file can persist across reboots and show you a snapshot of the ring buffer of the kernel that last had an init system run on that drive. |
|
| Back to top |
|
|
ONEEYEMAN
Advocate
Joined: 01 Mar 2005
Posts: 3650
|
| Posted: Thu Aug 26, 2021 3:47 pm Post subject: |
|
|
Hu,
So then I was right - dmesg on my HDD is from the last booted kernel, which is SystemRescueCD booted off of USB stick.
But then I'm not sure how it is possible.
The USB stick should have its own /var/log/dmesg file or similar where SR CD should drop the boot kernel messages. And it shouldn't touch
the one on the HDD.
Am I being paranoid?
Thank you. |
|
| Back to top |
|
|
ONEEYEMAN
Advocate
Joined: 01 Mar 2005
Posts: 3650
|
| Posted: Thu Aug 26, 2021 3:50 pm Post subject: |
|
|
Hi,
I made some progress.
I inspected the kernel configuration last night and fouind that one of the Drivers option had both "Intel" and "AMD" turned on.
I turned off the "Intel" one, recompiled and installed the kernel and then the boot started proceeding.
Unfortunately it stopped somewhere in the middle.
Today I will see if I can find more multiple kernel options that has to be turned off/on...
The last line on the screen reads:
| Code: |
fb0: switching to amdgpudrmfb from EFI VGA
|
So maybe activating EFI in the video driver was a mistake?
Thank you. |
|
| Back to top |
|
|
poe_1957
Apprentice
Joined: 26 Sep 2018
Posts: 192
Location: Mortsel
|
| Posted: Thu Aug 26, 2021 3:57 pm Post subject: |
|
|
| Code: | | CONFIG_SYSCTL_EXCEPTION_TRACE=y |
You activated this while you are running OPENRC....
_________________
Linuxpioneer
ALUG |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 22626
|
| Posted: Thu Aug 26, 2021 4:21 pm Post subject: |
|
|
| ONEEYEMAN wrote: | | So then I was right - dmesg on my HDD is from the last booted kernel, which is SystemRescueCD booted off of USB stick. |
As I said above, the dmesg program always shows the running kernel's ring buffer, regardless of where you got the program. | ONEEYEMAN wrote: | | But then I'm not sure how it is possible. |
The kernel keeps its messages in memory. dmesg uses the system call that accesses that memory. | ONEEYEMAN wrote: | The USB stick should have its own /var/log/dmesg file or similar where SR CD should drop the boot kernel messages. And it shouldn't touch
the one on the HDD. |
Correct. Do you see evidence to the contrary? You haven't shown any indication of a problem. |
|
| Back to top |
|
|
ONEEYEMAN
Advocate
Joined: 01 Mar 2005
Posts: 3650
|
| Posted: Thu Aug 26, 2021 5:06 pm Post subject: |
|
|
Hu,
Consider the following scenario:
1. I have a USB stick with SystemRescueCD.
2. I'm booting it up in order to install Gentoo.
3. So I boot it up on the Windows machine, (at this point, IIUC, the dmesg will be dropped on the USB, right? ), follow the HB and then rebooted.
4. The Gentoo boot failed. At this point the HDD should contain the dmesg from the failed attempt, right?
5. So in order to fix the install I need to boot from the SR CD. After that, the dmesg on the HDD shouldn't be overwritten and the USB should
contain dmesg from this SR CD boot. Am I right?
Please point me where I am wrong.
Thank you. |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 22626
|
| Posted: Thu Aug 26, 2021 5:19 pm Post subject: |
|
|
| I don't know if SystemRescueCD writes /var/log/dmesg. It might not, since it is meant to run in a live environment, and many of those are read-only, or at least not useful to rewrite. Depending on how the Gentoo boot fails, it may or may not reach the stage where the init system will save the output of dmesg to the hard disk's file /var/log/dmesg. Other than those points, that seems right. What are you seeing that disagrees with it? |
|
| Back to top |
|
|
ONEEYEMAN
Advocate
Joined: 01 Mar 2005
Posts: 3650
|
| Posted: Thu Aug 26, 2021 5:33 pm Post subject: |
|
|
Hu,
As explained in the beginning:
On the step 4 all I see on the screen was "Loading kernel 5.x.xx".
So my "natural reaction" was to boot SR CD back up and inspect dmesg on the HDD to see what failed.
To my surprise dmesg on the HDD contained the log from the SR CD.
Now, if the Gentoo boot up failed and I need to reboot in SR CD from USB - shouldn't the dmesg file be empty?
I mean its possible that kernel/bootloader didn't have time to write anything...
Thank you. |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 22626
|
| Posted: Thu Aug 26, 2021 6:05 pm Post subject: |
|
|
| ONEEYEMAN wrote: | So my "natural reaction" was to boot SR CD back up and inspect dmesg on the HDD to see what failed.
To my surprise dmesg on the HDD contained the log from the SR CD. |
That doesn't seem right at all. SystemRescueCD shouldn't even be mounting /var, much less overwriting log files on it. | ONEEYEMAN wrote: | | Now, if the Gentoo boot up failed and I need to reboot in SR CD from USB - shouldn't the dmesg file be empty? |
No. Even before init begins executing, the kernel will have written dozens of lines to its ring buffer. If the init scripts successfully run dmesg >/var/log/dmesg, you would at least get those lines. If the init scripts don't reach that point, /var/log/dmesg won't be touched, and will have the results of your previous successful boot. I suppose it's possible you could have a logrotate rule that truncated dmesg, but I don't see the point of such a rule. Since /var/log/dmesg isn't maintained once the system is up and running, it can't grow particularly large, which is the usual reason for a logrotate rule. |
|
| Back to top |
|
|
jburns
Veteran
Joined: 18 Jan 2007
Posts: 1217
Location: Massachusetts USA
|
| Posted: Thu Aug 26, 2021 6:15 pm Post subject: |
|
|
The SystemRescueCD writes to an overlay file system which does not survive a reboot.
To look at the dmesg file on the HDD boot the SystemRescueCD, mount the HDD and use the less command to look at the file on the HDD. You should check if the file exists and time the file was written. |
|
| Back to top |
|
|
|
Installing Gentoo
