11-09-2024, 10:41 AM (This post was last modified: 11-09-2024, 01:00 PM by Cactus2580.)
Thank you so much for the info!
I managed to get the AntiX 23.2 runit image downloaded, tried to DD it to flash drive, actually bricked one. Other one I was barely able to revive? Honestly unsure. It'll boot into the bootloader for DSL2024 but picking the first boot option no longer heads into rainbow snow, just flashing cursor in top left. Other boot modes return snow as expected thus far.
Something I can say with certainty is that the netbook will run on a 6.x kernel, as I tested with tinycore 14. It also runs 5.1x kernels on 12 and 13. Obviously they're a bit different but if such tiny packages have the drivers/wiring required to operate the screen . It also runs on Debian 12.7, albeit unusably slow. I believe that is the newest kernel.
Tiny core 14 uses xvesa, has zero issues. So maybe the issue is with Xorg? Will update more later tonight, still trying to wrangle the different flash drives into working. In older Linux distributions, choice between xorg and xvesa at boot menu was a simple flag, haven't been able to find one for DSL so far. Honestly stumped, especially as to how I managed to brick a flash drive entirely with the AntiX ISO and temporarily brick another as well. Hardware, am I right?
Thanks again!
EDIT:
After much messing around, managed to get TinyCorePlus15 to boot up and run, using a 6.1.x ish kernel, the plus image having wireless support so that I could install inxi to compare outputs. Oddly enough, the inxi program there recognizes the graphics as the HD6290 yet names the driver as N/A. As for display options, it states TinyX Xvesa, driver: vesa. I believe you are right, and xorg may simply not support the 6000 series. So it's looking like I either need to tear into the DSL iso and reroll, or force use of Xvesa. Resolution will take a bit of a hit at 1024x600 but at least it would run?
Something to do with installing AntiX on the second flash drive definitely did something very strange to it, was able to halfway restore it, can install other images and boot from them successfully, yet the text displayed looks like something straight out of "The Matrix" and is unusable I have no idea what the cause, brand new flash drive.
I am unsure if swapping the version of X.org and it's dependencies to an earlier version such as the 1.12.4 which was used by Slitaz would be an effective way of fixing the issue, or if that'll just end in dependency clobbering and breaking the whole system. Will attempt and see, possibly try an AntiX kernel from an earlier release, hopefully not lose any more flash drives in the process. I'm running out!
Will update. Thanks again for your time.
11-09-2024, 02:49 PM (This post was last modified: 11-09-2024, 03:48 PM by Cactus2580.
Edit Reason: Failure
)
Currently rolling a new "linuxfs" image with updated x.org.conf.in and amdgpu blob installed, will see if I can manage to pack it back up into something usable or if I broke it hopefully I'll have some new results to share soon. Probably should have tested changes one at a time for the sake of troubleshooting but... I didn't. Oh well.
Update:
Rerolled .iso, was able to get the iso itself bootable on flash drive after using iso hybrid, still will not boot into usable graphics no matter what boot parameters I set. AMD blob is within firmware files, can't invoke xvesa, can't invoke Radeon drivers. I am at a bit of a loss here. Perhaps someone with more in depth kernel experience than I have could figure this out, but I simply don't understand where or how to point the system to use either xvesa or the correct drivers for Xorg.
11-09-2024, 05:53 PM (This post was last modified: 11-09-2024, 05:56 PM by grindstone.)
OK you beat me--wrote a big response that should be fixed/revised but I'll just tack it on the end of this right now.
First, are you referring to DSL or to AntiX that you re-did the image in?
Also, can you append a 3 and boot in text mode?
----------------------------------
Yeah, tinycore isn't going to help us debug the Debian/AntiX tree because it indeed uses tinyX and they alone (tinycore devs) are (heroically!) keeping it alive at all. And, in general, one can't just mix and match entire subsystems as things are built together.
Ideally, we need to figure out if proper "normal" Xorg has the support in the
xserver-xorg-video-radeon
(Note: xserver-xorg-video-ati seems to be for older chips but it says to leave it in there for autodetection unless you're sure you don't need it )
and if we need the
firmware-amd-graphics
blob to be able to recognize the device. Getting AntiX full or Bookworm to boot would likely give us this answer. Onward.
If we root-around for your chip, the GPU seems to be Cedar so that looks good for what we can tell, anyway:
apt-cache show xserver-xorg-video-radeon
Package: xserver-xorg-video-radeon
Source: xserver-xorg-video-ati
Version: 1:19.1.0-3
Installed-Size: 869
Maintainer: Debian X Strike Force <debian-x@lists.debian.org>
Architecture: i386
Provides: xorg-driver-video
Depends: libc6 (>= 2.17), libdrm-radeon1 (>= 2.4.39), libgbm1 (>= 8.1~0), libudev1 (>= 183), xorg-video-abi-25, xserver-xorg-core (>= 2:21.1.1)
Suggests: firmware-amd-graphics
Description-en: X.Org X server -- AMD/ATI Radeon display driver
This package provides the 'radeon' driver for the AMD/ATI cards. The
following chips should be supported: R100, RV100, RS100, RV200, RS200,
RS250, R200, RV250, RV280, RS300, RS350, RS400/RS480, R300, R350, R360,
RV350, RV360, RV370, RV380, RV410, R420, R423/R430, R480/R481,
RV505/RV515/RV516/RV550, R520, RV530/RV560, RV570/R580,
RS600/RS690/RS740, R600, RV610/RV630, RV620/RV635, RV670, RS780/RS880,
RV710/RV730, RV740/RV770/RV790, CEDAR, REDWOOD, JUNIPER, CYPRESS,
HEMLOCK, PALM, SUMO/SUMO2, BARTS, TURKS, CAICOS, CAYMAN, ARUBA, TAHITI,
PITCAIRN, VERDE, OLAND, HAINAN, BONAIRE, KABINI, MULLINS, KAVERI, HAWAII.
Check (CEDAR), and firmware is a suggest but not dependency.
Soooo...this should work(?) (given the higher-labor customizing to get the firmware in). Thinking it'll find the module if we just give it firmware. Wikipedia shows a lot of support /drm/radeon (but of course yours isn't listed) and there's the 2011 gap right where yours belongs.
Diving in the radeon modinfo, it looks like the minimal Cedar firmware files are:
but I'm far out of my depth here so those might not be all you need--call it a start if you're trying to keep it minimal when you make a new image.
As a suitable "also-ran" solution, some sort of vesa support would be acceptable, but it'll need to be in the current Xorg as that's what AntiX releases (or in bookworm), ie, not xvesa (xvesa is long-gone, too).
There is also
xserver-xorg-video-amdgpu
but that seems to be for "3rd generation" chips released after 2015. You can see that it depends on the
xserver-xorg-video-radeon
Yeah, so if Xorg works at all for your 6290 chip, it's the current -radeon that should be the right package.
If I have this straight, you are unable to boot the full 23.2 AntiX but it just sits there flashing cursor or do you get a grub menu? I've not used that 23.2 image (any of them) so I don't know if you need to run isohybrid on them before you do the dd (?). If the machine can't even find the image to boot, I'd do the isohybrid & re- mkfs.vfat & re-dd. If you're doing all this stuff in ventoy or something else, I'd have no idea how to fix that.
So we still have the same questions. If you got it going in AntiX or Debian something, maybe we start there (?) Otherwise--yeah--you'd be off on a different distro path.
11-12-2024, 12:21 PM (This post was last modified: 11-12-2024, 01:29 PM by Cactus2580.
Edit Reason: Successfully ran XFCE4 on AntiX23.2-runit-core-i386!
)
Okay, after some more testing, I have managed to get Antix23.2 Runit Core to boot with no errors, correctly changed resolution from 800x600 or whatever the grub menu runs in, to 1366x768 about halfway through booting up. Ran Inxi -Fv7 and got the following for output:
(Hand typing this on another computer, sorry for formatting)
Graphics:
Device-1: AMD Wrestler [Radeon HD 6290] vendor: Acer Incorporated ALI driver: radeon v: kernel
arch: TeraScale-2 ports: active: LVDS-1 empty: HDMI-A-1,VGA1 bus-id: 00:01.0 chip-ID: 1002:9807
class-ID: 0300
Device-2: Chicony WebCam driver: uvcvideo type: USB rev: 2.0 speed: 480 Mb/s lanes: 1
bus-ID: 2-1:2 chip-ID: 04f2:b209 class-ID: 0e02
Display: server: No display server data found. Headless machine? tty: 124x34
Monitor-1: LVDS-1 model: Chi Mei Opto 0x1113 res: 1366x768 dpi: 136
size: 256x144mm (10.08x5.67") diag: 294mm (11.6") modes: max: 1366x768 min:640x480
API: N/A Message: No API data available in console. Headless machine?
So, while this isn't the base or full edition of AntiX23.2 with desktop environment, it does boot into text mode just fine and appears to be able to properly display on this graphics card. Doesn't appear to be using Xorg, does appear to be using the Radeon driver... its a start? Radeon driver is present within the DSL2024.R7 firmware directory, just need to force it to use it.
Can't determine why DSL won't allow text only mode yet at this time. Will attempt to build up a functioning desktop using the package manager and Xorg within Antix23.2-runit-core, see if I can get it to run X, and will update afterwards. I figure if I have to install and configure the DE myself, maybe I'll learn something needed to tell DSL how to do what I want in the process?
Noted on xvesa, I had no idea it had been discontinued! Apparently a lot has changed since the last time I was mucking around inside of a distribution besides TinyCore or some older variant of BSD.
Thanks again for your time!
Will keep updated.
UPDATE:
Have some success! Sort of. AntiX23.2-runit-core will properly display graphics via Xorg.
Was able to use the package manager within AntiX-cli-cc preinstalled application to install Xorg, and XFCE4. Installation unremarkable, instant startup into remarkably snappy DE upon using startx as root, no configuration required. Post being written from within AntiX23.2-runit-core.
So, there's that. I will attempt to pull my Xorg configuration file to see what it says, hopefully it's shorter than the one which comes pre-installed with DSL2024.R7, as that file is large and complex. At this point, I've determined that AntiX23.2 has zero issue displaying graphics on this netbook (AO722) as I'm posting this from said netbook via Palemoon while running AntiX23.2. Issue with DSL seems to be in configuration, not sure yet. Maybe it's missing a driver that the standard Xorg package includes, but I didn't see anything special besides drm-radeon, pertaining to radeon graphics cards, while installing. Seeing as this firmware is also included in the DSL2024.R7 ISO, it should just be a matter of invoking it properly? Unsure. Will update with more info as I figure it out.
Unsure if also necessary, but here is my Xsession.options as well:
# $Id: Xsession.options 189 2005-06-11 00:04:27Z branden $
#
# configuration options for /etc/X11/Xsession
# See Xsession.options(5) for an explanation of the available options.
allow-failsafe
allow-user-resources
allow-user-xsession
use-ssh-agent
use-session-dbus
So, with these bits of information, can we figure this out? After using XFCE4 on the hardware within AntiX23.2 with success, I am optimistic.
Thanks again for your time!
EDIT:
Did some basic visual comparison of the xorg.conf.in files between DSL2024.R7 and the AntiX23.2-runit-core which is successfully running XFCE4, do not see much difference at all. Confused as to why this would be, did the Xorg package that I installed have drivers included which are not included within the DSL2024 Radeon package? Why won't DSL auto-configure into running the same way that the installed Xorg package from AntiX base repo will?
Woo-hoo--nice work Perfect. No, I'm not sure we can assume that its the same firmware in 23.2-core and in RC7 as John is doing a size-based balancing act to support as much as he can in a CD. They _might_ be the same for ATI/AMD but we don't know that yet until we look. I'm still new to this entire tree, myself, so I'm thinking how to get us a diff w/o having to do a frugal install of both a clean RC7 *and* clean 23.2-core. At the moment, I think we need to diff the package lists and find a way to do the same for relevant /usr/lib/firmware for the ATI/AMD GPU stuff.
Elsewhere, and maybe unrelated, I did see someone report a boot freeze before display owing to a network driver support problem, too. Maybe nothing, maybe something. I'd save yourself some text files with the lspci and lsmod info as well as that inxi and the conf, just for reference.
11-12-2024, 02:54 PM (This post was last modified: 11-12-2024, 03:13 PM by Cactus2580.)
(11-12-2024, 02:20 PM)grindstone Wrote: Woo-hoo--nice work Perfect. No, I'm not sure we can assume that its the same firmware in 23.2-core and in RC7 as John is doing a size-based balancing act to support as much as he can in a CD. They _might_ be the same for ATI/AMD but we don't know that yet until we look. I'm still new to this entire tree, myself, so I'm thinking how to get us a diff w/o having to do a frugal install of both a clean RC7 *and* clean 23.2-core. At the moment, I think we need to diff the package lists and find a way to do the same for relevant /usr/lib/firmware for the ATI/AMD GPU stuff.
Elsewhere, and maybe unrelated, I did see someone report a boot freeze before display owing to a network driver support problem, too. Maybe nothing, maybe something. I'd save yourself some text files with the lspci and lsmod info as well as that inxi and the conf, just for reference.
I will do so shortly, and post them here. I apologize for the post "spam" but I am currently unable to find any other way to save the files due to hardware detection issues within the AntiX core wrt SD cards, my last USB is in use for the AntiX live system.
Aside from performing a frugal install, could I not simply mount the ISO images of both on loopback and extract their respective "linuxfs" files? Not familiar with any sort of Diff program so I'll need to look that up but it appears that the AntiX23.2 package manager has a Diff tool easily available, so should be able to figure that out. If not, can always use eyes.
Boot freeze before display would make sense, I've used waitusb=5 a lot on the older Aspire ZG5 to get distributions to properly boot up with the 8gb flash drive from ~2010 soldered to the inside of the USB port and tucked into the space where the HDD used to be, quick fix when it failed a long time ago... I've been meaning to update it to a modern flash drive as it was already quite worn out when pushed into service in this manner nearly 15 years ago but have been using primarily TORAM distributions as if they're ROM files and SD cards as the storage device for the files I wish to save, in an attempt to make the flash drive last as long as possible, or else I'd simply install DSL on that and not look back!
Very excited, thanks again for all of your help!
Will update soon.
Okay, heres the output of LSMOD:
00:00.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 14h Processor Root Complex
00:01.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Wrestler [Radeon HD 6290]
00:01.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Wrestler HDMI Audio
00:11.0 SATA controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 SATA Controller [AHCI mode]
00:12.0 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB OHCI0 Controller
00:12.2 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB EHCI Controller
00:13.0 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB OHCI0 Controller
00:13.2 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB EHCI Controller
00:14.0 SMBus: Advanced Micro Devices, Inc. [AMD/ATI] SBx00 SMBus Controller (rev 42)
00:14.2 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] SBx00 Azalia (Intel HDA) (rev 40)
00:14.3 ISA bridge: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 LPC host controller (rev 40)
00:14.4 PCI bridge: Advanced Micro Devices, Inc. [AMD/ATI] SBx00 PCI to PCI Bridge (rev 40)
00:15.0 PCI bridge: Advanced Micro Devices, Inc. [AMD/ATI] SB700/SB800/SB900 PCI to PCI bridge (PCIE port 0)
00:15.2 PCI bridge: Advanced Micro Devices, Inc. [AMD/ATI] SB900 PCI to PCI bridge (PCIE port 2)
00:15.3 PCI bridge: Advanced Micro Devices, Inc. [AMD/ATI] SB900 PCI to PCI bridge (PCIE port 3)
00:18.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 12h/14h Processor Function 0 (rev 43)
00:18.1 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 12h/14h Processor Function 1
00:18.2 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 12h/14h Processor Function 2
00:18.3 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 12h/14h Processor Function 3
00:18.4 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 12h/14h Processor Function 4
00:18.5 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 12h/14h Processor Function 6
00:18.6 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 12h/14h Processor Function 5
00:18.7 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 12h/14h Processor Function 7
06:00.0 Ethernet controller: Qualcomm Atheros AR8152 v2.0 Fast Ethernet (rev c1)
07:00.0 Network controller: Qualcomm Atheros AR9485 Wireless Network Adapter (rev 01)
I will work on extracting and comparing the two ISO "linuxfs" images in a little while, have to go run some errands. Will post the update here. I'm thinking it may be a matter of swapping the Xorg files from one to the other, to make it function properly. In -MY SPECIFIC USE CASE- I have no issues with an .ISO file that results being larger than what fits on a standard CD, as these netbooks never came with CD drives and the flash drives I have are of about 16gb. So long as it works, it will fit. It may not align perfectly with the ideas of the project, but oh well. Resizing can be done later.
11-13-2024, 04:11 AM (This post was last modified: 11-14-2024, 11:27 PM by grindstone.)
Sitting on a month-end data-limit right now, personally, so 23.1 core (to be apples-to-apples for RC7) can't happen here today.
Took a (manual) look at package lists for 23.0 core (what I had here already) vs. RC7
- RADEON bits of kernel configs identical
- relevant X libs in core are all in RC7
- core contains 5 more firmware packages than RC7
firmware-amd-graphics
firmware-ast
firmware-linux
firmware-linux-nonfree
firmware-samsung
firmware-linux is the top-level meta package dep on both -free (present already) and firmware-linux-nonfree (not included in RC7). Top-level descriptions are no help and I haven't dug online for details.
At the individual file level (/usr/lib/firmware):
- Something like 3200+ lines in firmware under core, ~2600 RC7 (forgot/bleery)
If memory serves, John has "hand-adjusted" certain firmware for other users but perhaps not installed the entire packages, so conclusions at the package level, on one hand, are an "easy" install+snapshot/remaster away. OTOH, if that works, we still wouldn't know why.
Arguably more sane way to look at packages is to swipe bitjam's "spin" investigation method; for each version, run (redirect to different filenames):
dpkg-query -l | sed -n 's/^ii\s\+//p' > installed-packages.txt
then use the following commands to get lists of added and removed packages:
comm -23 <(sort f.old) <(sort f.new)
comm -13 <(sort f.old) <(sort f.new)
man comm
-> The beauty of you using -core is that it can only be a kernel module and firmware (and radeon.ko and radeonfb.ko are present in core).
-> You already custom-made an image with the firmware-amd-graphics contents, right, and that didn't work. apt-cache show on that package might be the answer:
replaces: firmware-linux-nonfree
which is what was in core but not in RC7. Certainly it's large and that's likely among the reasons why it has been pruned.
Here's some raw (unsorted) stuff for now.
--------------
Edit: I missed the obvious again. What happens if you just swipe all of /usr/lib/firmware from -core runit 23.2 and chuck it in your DSL re-brew?
11-15-2024, 11:18 PM (This post was last modified: Yesterday, 12:22 AM by Cactus2580.
Edit Reason: dissected DMESG, very confused.
)
Another update:
Moved /usr/lib/firmware over to the DSL2024 reroll, no effect on rainbow snow. Unsure why this is the case.
Moved /antiX/vmlinuz from AntiX23.2 runit core to DSL2024 reroll, no effect on rainbow snow, wouldnt boot either. (Duh)
Whatever the issue is, it "strikes" right as ISOLINUX gives control over to the bootup process. I can't seem to figure out what the issue here is. AntiX itself works just fine, moving over the /usr/lib/firmware directory should have brought all of the firmware from AntiX into DSL, yet no change. I do notice a difference in size between the kernel for Antix23.2 core and DSL2024, with DSL being a little bit smaller in size. I wonder, is there some driver compiled directly into the kernel of AntiX23.2 which allows for the display to work on AO722 which is not present within DSL? I have been looking into the initrd file from DSL2024, and it appears I may be able to move modules from the linuxfs file into the initrd file and repack, maybe this is what is required?
It seems that the more I mess with this, the less it makes sense. Firmware would be loaded from the /usr/lib/firmware area only after the system managed to Unsquashfs the entire linuxfs image. This does not occur as the first step of the bootup process. Initrd should be loaded first? So I put the firmware and module files into the initrd. Still does not work. Whatever the issue is, it seems to affect the initial console of the computer. Antix23 core goes directly into a normal looking console window upon bootup, shows init process, etc. No issues. DSL2024 goes directly into rainbow snow, and never comes out. So whatever it is appears to be an issue literally right at the moment of first booting. Even without Xorg installed on AntiX, lsmod does show Radeon as the driver active.
Checking DMESG soon, will update once I reinstall Xorg on Antix23
It appears that early on in the boot process, when the kernel is "paravirtualized on bare hardware" it states it's got a [ 0.219929] Console: colour VGA+ 80x25\
Next thing pertaining to graphics at all is [ 0.334940] smpboot: CPU0: AMD C-60 APU with Radeon™ HD Graphics (family: 0x14, model: 0x2, stepping: 0x0)
[ 0.335500] Performance Events: AMD PMU driver.
[ 0.335515] ... version: 0
[ 0.335519] ... bit width: 48
[ 0.335522] ... generic registers: 4
[ 0.335526] ... value mask: 0000ffffffffffff
[ 0.335529] ... max period: 00007fffffffffff
[ 0.335532] ... fixed-purpose events: 0
[ 0.335536] ... event mask: 000000000000000f
[ 0.335576] rcu: Hierarchical SRCU implementation.
[ 0.336374] smp: Bringing up secondary CPUs ...
[ 0.336870] x86: Booting SMP configuration:
[ 0.540675] amd_nb: x86/cpu/AMD: CPU erratum 688 worked around
and
[ 0.712503] pci 0000:00:01.0: Video device with shadowed ROM at [mem 0x000c0000-0x000dffff]
[ 0.712625] pci 0000:00:01.1: D0 power state depends on 0000:00:01.0
[ 0.725978] pci 0000:00:12.0: quirk_usb_early_handoff+0x0/0x680 took 12978 usecs
[ 0.739987] pci 0000:00:12.2: quirk_usb_early_handoff+0x0/0x680 took 13591 usecs
[ 0.752989] pci 0000:00:13.0: quirk_usb_early_handoff+0x0/0x680 took 12622 usecs
[ 0.766985] pci 0000:00:13.2: quirk_usb_early_handoff+0x0/0x680 took 13545 usecs
[ 0.767169] pci 0000:06:00.0: [Firmware Bug]: disabling VPD access (can't determine size of non-standard VPD format)
[ 0.767258] PCI: CLS 64 bytes, default 64
Next thing it does after this is unpack the Initramfs
Nothing related to graphics appears to happen in between loading the initrd and actually starting the Init process.
Then:
[ 35.846638] ACPI: Video Device [VGA] (multi-head: yes rom: no post: no)
and
[ 35.938165] input: Video Bus as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input6
and
[ 38.266199] [drm] radeon kernel modesetting enabled.
[ 38.269252] platform regulatory.0: Direct firmware load for regulatory.db failed with error -2
[ 38.269268] cfg80211: failed to load regulatory.db
[ 38.275064] radeon 0000:00:01.0: vgaarb: deactivate vga console
[ 38.276390] Console: switching to colour dummy device 80x25
[ 38.293067] [drm] initializing kernel modesetting (PALM 0x1002:0x9807 0x1025:0x0598 0x00).
[ 38.293608] resource sanity check: requesting [mem 0x000c0000-0x000dffff], which spans more than PCI Bus 0000:00 [mem 0x000c0000-0x000c3fff window]
[ 38.293624] caller pci_map_rom+0x65/0x200 mapping multiple BARs
[ 38.302763] ATOM BIOS: Acer
[ 38.302894] radeon 0000:00:01.0: VRAM: 256M 0x0000000000000000 - 0x000000000FFFFFFF (256M used)
[ 38.302904] radeon 0000:00:01.0: GTT: 1024M 0x0000000010000000 - 0x000000004FFFFFFF
[ 38.302928] [drm] Detected VRAM RAM=256M, BAR=256M
[ 38.302933] [drm] RAM width 32bits DDR
[ 38.304909] [TTM] Zone kernel: Available graphics memory: 433188 KiB
[ 38.304917] [TTM] Zone highmem: Available graphics memory: 889530 KiB
[ 38.304921] [TTM] Initializing pool allocator
[ 38.304942] [TTM] Initializing DMA pool allocator
[ 38.305007] [drm] radeon: 256M of VRAM memory ready
[ 38.305014] [drm] radeon: 1024M of GTT memory ready.
[ 38.305063] [drm] Loading PALM Microcode
and
[ 38.489071] [drm] radeon: dpm initialized
and
[ 38.716959] [drm] PCIE GART of 1024M enabled (table at 0x0000000000162000).
[ 38.717253] radeon 0000:00:01.0: WB enabled
[ 38.717265] radeon 0000:00:01.0: fence driver on ring 0 use gpu addr 0x0000000010000c00
[ 38.717272] radeon 0000:00:01.0: fence driver on ring 3 use gpu addr 0x0000000010000c0c
[ 38.718722] radeon 0000:00:01.0: fence driver on ring 5 use gpu addr 0x0000000000072118
[ 38.771551] radeon 0000:00:01.0: radeon: MSI limited to 32-bit
[ 38.771701] radeon 0000:00:01.0: radeon: using MSI.
[ 38.771763] [drm] radeon: irq initialized.
Now if only I could manage to get a DMESG from DSL2024, although at that point I wouldn't need one as it would be booted into usable graphics.
I have no idea if anything from the dmesg above is at -all- helpful, but my intuition suggests that the issue I'm having here is related to something compiled(or not) into the kernel itself, as it won't even proceed to the point of loading the initrd or what not without going all rainbow. Is it picking the wrong framebuffer device? I have literally no idea at this point, especially considering that the AntiX23 core image is much smaller than the DSL2024 image. The AntiX23 kernel is slightly larger than the DSL2024 kernel. I have no idea why this is, but it seems to be an important difference considering moving all of the firmware from AntiX to DSL does... nothing. Is there a way for me to attempt to recompile the kernel with the Radeon drivers inside? (I don't think this is how drivers such as that work, but maybe it's possible to statically compile it in instead of attempting to load a module?)
I am fairly well out of my zone of understanding on why there's a major failure to output anything but rainbow snow in DSL. Whatever the issue is, it happens basically the very moment that any selection chosen proceeds past the "loading kernel....100%" message. Straight to rainbow. Never comes out of it.
On AntiX, it goes directly to a very readable console display, then about halfway through booting (as shown in Dmesg above) video drivers kick in and it redisplays in a higher res format. Even without Xorg, it displays text just fine, can run AntiX-cli-cc Curses type menu, even browse the internet with Elinks. Upon installing Xorg, using startx causes it to again change resolution to the proper 1366x768, which honestly makes terminal windows pretty hard to read, tiny text.
. It also runs on Debian 12.7, albeit unusably slow. I believe that is the newest kernel. 
Perfect. No, I'm not sure we can assume that its the same firmware in 23.2-core and in RC7 as John is doing a size-based balancing act to support as much as he can in a CD. They _might_ be the same for ATI/AMD but we don't know that yet until we look. I'm still new to this entire tree, myself, so I'm thinking how to get us a diff w/o having to do a frugal install of both a clean RC7 *and* clean 23.2-core. At the moment, I think we need to diff the package lists and find a way to do the same for relevant /usr/lib/firmware for the ATI/AMD GPU stuff.