I compiled sys-kernel/gentoo-sources-6.6.13 on two different machines with same hardware. Upgraded from 6.1.67 with make syncconfig. On one machine I accepted all default options. On the other I always chose N(o) when newer options were suggested. Both kernels are stuck without any errors at populating with uevents. I stumbled across the Arch thread which is exactly the same error. Only difference is the need for VIDEO_CARDS="radeon r600" because of Tahiti-GPU that never worked with AMDGPU. It is also not a blank screen boot. This would happen if for example firmware of GPU would not be loaded. Had this occasionally when initramfs was improperly built. Which is not the case now, double checked that everything necessary is available. It also does not matter whether firmware is built into the kernel or loaded upon boot. (Checked this, too with 6.1.x, works fine.) Reproducible: Always Steps to Reproduce: 1. make syncconfig 2. compile kernel 3. build initramfs (with genkernel) 4. grub-mkconfig 5. reboot 6. Grub appears, loads kernel and initramfs correctly, some messages appear about clock, crypto disks and last one is uevents Actual Results: Boot hangs indefinitely, Num-key still operating, no beeps, no Ctrl+Alt+Del, not TTY-switching. Expected Results: Correct boot
Created attachment 886355 [details] .config
Some typical steps here at to try the latest 6.6.X, the latest 6.7.X to see if anything changes because it could potentially have been fixed in a later release. If that proves to not solve the issue, a git bisect could help identify the offending commit. That would be done from the last working kernel to the first non-working kernel. Please all attach the full dmesg of the broken kernel
As described in the ArchLinux-thread nomodeset makes boot possible but keeps X from loading because radeon driver cannot modeset. (In reply to Mike Pagano from comment #2) > Some typical steps here at to try the latest 6.6.X, the latest 6.7.X to see > if anything changes because it could potentially have been fixed in a later > release. Already at it, but thx for reminder. > > Please all attach the full dmesg of the broken kernel Which is either impossible or useless. Impossible because the stuck boot process never finishes and also never reaches sshd to dial in. With nomodeset everything is fine until display-manager starts up. Then Xorg.0.log complains about impossible modeset. I already compared dmesg of the 6.6 with the one from 6.1 when the first booted successfully. There is nothing obvious like extra warnings, incompatibilities or such.
Something seems odd. Give me a full working dmesg Take a picture of where the broken one stops What is this? CONFIG_LOCALVERSION="-sec2"
https://gitlab.freedesktop.org/drm/amd/-/issues/3235 – opened a bug ticket there, from MAINTAINERS file of kernel. There seem to be more issues going from 6.1.x to 6.6. Will try 6.5, too.
Ok, we'll follow the upstream bug
(In reply to Mike Pagano from comment #4) > […] > > > What is this? > > CONFIG_LOCALVERSION="-sec2" https://wiki.gentoo.org/wiki/Genkernel#How_do_I_create_a_separate_kernel.2Finitramfs_to_test_something.3F (I use a build machine that automatically spits out various kernel images, initramfs and such and this is the local version/ version appendix for a hardened/ security improved kernel targeting Lenovo machines produced around 2012. I own/ maintain some of them.)
Created attachment 886719 [details] dmesg gentoo-sources-6.1.74
Created attachment 886720 [details] dmesg gentoo-sources-6.4.16
6.4.16 seems to be the last working kernel. I attached two dmesg dumps. How can I obtain the log of OpenRC/ systemd-udevd during sysvinit? I switched on all earlyprink-logging in the kernel but this is too early. It takes places before init takes over. syslog-ng chimes in quite late in run level default. I doubt it will work in sysvinit before udev. Comments in /etc/rc.conf suggest that all logging of OpenRC itself happens after sysvinit. All I need is the output of dmesg/ activity of systemd-udevd when populating /dev based on uevents.
CONFIG_UBSAN_TRAP=y is a precondition in combination with array index out of bounds accesses. I have no idea what flex arrays are but they were introduced and cause the issue. Has to be fixed upstream. Without CONFIG_UBSAN_TRAP kernel boots fine, video is working and system is stable – from my point of view. (Didn't test any 3D-gimmicks with Blender or games.)
Solved with gentoo-sources-6.9.6 incl. UBSAN in hardened configuration.
