Likely curl needs to be recompiled against this version of libressl first?

Well, thanks I guess. I know this is stupid, but what would happen if I were to use the outdated stable ISO to install, and then do a sorcery update & recompile my system from there?

There have been a lot of API/ABI breakages in the last 10 years (even from current stable to test), so I doubt this upgrade path would work smoothly.

The easiest to guarantee was from one stable to another (like what OpenBSD does), but we never tested it besides basic 120-140 spells due to lack of human resources, and now we have been lagging in preparing stable releases (for a few years by now), so we're in half-rolling release state now.

This has become a common problem with modern host systems.

Make sure PATH variable is exported as described in Install/Chroot#head-1-2-7-2.

Not easily I'd say, but it depends on the case.

Spells are very easy to hack, and as long as drivers are compatible with this specific xorg version, there shouldn't be any issues.

You'll have to use a custom spell though: checkout the commit from grimoire.git when the driver was at specific version and copy it to a local grimoire. If there were not a lot of spell customizations between two versions (like dependencies that will be needed to be tweaked), it should be fine.

I personally have a lot of new/old spells in the mix.

Welcome! I'll mark it as resolved then.

I would still refer to one of my previous comments and say it's important to understand what's the difference with 2 kernel configs: working and non-working.

I'm a fan of stripping off the kernel myself, but I also know it's easy to miss a setting or two in completely unrelated sections (like in experimental drivers or specific chip support) that make the system less functional.

What somewhat related here might be: ACPI, backlight kernel parameters.

Experiment with other stock kernel configs and see if they address quirks like this with specific kernel parameters.

Regarding xf86-video-intel: it's mandatory anyway for X to run with good performance, so it won't be a problem if you enable KMS past kernel boot.

How about trying vga=ask, vga=normal and vga=771 in /etc/lilo.conf?

As well as append="video=640x480" OR append="nomodeset i915.modeset=0" under the kernel image section.

flux_control on #sourcemage also suggested this:

<flux_control> Stealth: My guess would be display issues.
<flux_control> I haven't checked the chroot kernel config in a while, but if it includes a whole bunch of different display drivers (likely, in order to support different hardware combinations), it's possible that the kernel is wrongly autodetecting and (via userland) autoloading kernel modules that are blanking the display.
<flux_control> There should be a kernel bootparam to force the display to old but gold standard vga 80x25.
<flux_control> The other things I can think of immediately are that possibly (depending on hw and how the user is booting) the kernel is switching to a serial console as the default console output which they wouldn't see unless they connected to it, or that there's possibly even a hw issue.
<flux_control> Stealth: I took one last glance at the forum post. They mentioned initramfs. I would also recommend trying to boot the kernel config without the initramfs (it should crash if the initramfs is needed for something), and even if they get the same result that way, they should check the initramfs if *that* is loading kernel modules or whatever too.
<flux_control> An initramfs is like a whole other OS loaded before the real OS, so the problem could either be there or the real root OS loaded after. It's not clear at what point the display dropped, as in how far the kernel loaded.
<flux_control> If it was the initial "uncompressing kernel image BLAH ..." and then the display immediately dropped that's very different from going blank after loading wlan drivers, for example

I would double check the modules in use when you loaded the system that was used to install SMGL and compare configuration to compiled-in modules / initramfs. Could be some specific controller driver (like vmd) or FB driver.

I would also check another kernel compiled with the config of Arch or Void if they boot successfully.

cast -r