About News Download Docs Forum Bugs Contact

Forum

Information

Tools

Resources

[solved] Source Mage not booting after installation

Submitted by Xenanthropy 29 Sep, 2021 09:01 #

I'm currently trying to install Source Mage onto my Thinkpad X230 and I am having some issues. I've followed the installation instructions under the "chroot" method 10 or so times and sadly I can't seem to figure out what my issue is. All of the steps go fine, yet when I try to load the kernel, it prints the normal text you'd see when a kernel first starts loading and then... nothing, just a black screen. No blinking cursor or input of any kind (can't ctrl+atl+f2 or etc. to get to a tty)

I'm not sure if i've done something wrong when compiling the kernel or something went wrong when it built the initramfs (I tried both customizing it to my device as well as just leaving everything on the defaults) (Note: The kernel in question is 5.14.7)

To rule out any issues to it pointing to the wrong drive (I have 2 SSDs (A and B) A has windows, B is what i'm installing both Source Mage and the bootloader onto) i've used UUIDs in my fstab, as well as in my lilo config (via liloconfig) I also tried with grub as well, but no change. (For relevance, i'm using MBR as I didn't want to mess with GPT)

I've tried checking for log files but I can't seem to find any. Any advice would be greatly appreciated! (Can also provide more info if needed)

Edited 29 Sep, 2021 09:04
Submitted by stealth 29 Sep, 2021 14:16 #

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.

Edited 29 Sep, 2021 14:25
Submitted by stealth 29 Sep, 2021 14:56 #

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
Submitted by Xenanthropy 29 Sep, 2021 18:18 #

Thanks for the suggestions, guys. So one bit of info I forgot to include is the host OS i'm using to install SMGL is Bunsenlabs. I don't know what modules are loaded into Bunsenlabs but I can certainly check! I'll grab the output of lsmod here in an hour or so.

So what you're saying is I should try rebuilding the kernel without initramfs support? Initially i'd turned that on, because when I booted without compiling the initramfs (in a virtual machine) I had gotten kernel panics due to not being able to find a specific directory (I googled the issue and it looks like the issue was "you are missing the initramfs") although i'm definitely not an expert so I don't really know how it works all that well.

Also i'll try recompiling the kernel again this time and i'll really dig through the options! When I customized it, I went through every single menu and made sure to turn off anything that wasn't relevant to my system, but who knows maybe I missed something! I'll try doing that again, as well as not making an initramfs this time. I'll keep you guys posted (Will still post the lsmod from bunsenlabs)

OH as far as for how much it got into the loading process though, I took a video of the text that flies past before the black screen, and I think the last line it showed on screen was "[ 0.519659] Key Type asymmetric registered" No clue if that means anything though, I tried googling it and didn't find much.

Submitted by Xenanthropy 29 Sep, 2021 21:14 #

The LSMOD output

I should also note that i've successfully compiled a kernel and ran it before (Just a week or two ago i'd built and was running Lunar Linux on this very laptop, so I know that kernel was functioning fine)

Edited 29 Sep, 2021 21:15
Submitted by Xenanthropy 29 Sep, 2021 22:58 #

Ok so I rebuilt the kernel (I checked under "driver support > graphics" and the only thing that was checked was intel graphics, not nvidia or amd (the x230 has only intel integrated graphics) I made sure I unchecked everything that wasn't relevant to my system. I also said "No" to building an initramfs file as well (I also checked inside of /boot to make sure the initrd files were gone, which they were) I reconfigured Lilo (basically just commented out the "initrd=blahblah" line) ran lilo; Rebooted, and.. no change, sadly. I guess I can officially rule out the initramfs being the issue at this point.

Submitted by stealth 30 Sep, 2021 00:49 #

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.

Edited 30 Sep, 2021 02:22
Submitted by Xenanthropy 30 Sep, 2021 10:38 #

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.

Ok so I fixed it (for the most part...) There was 2 problems. 1, the graphics mode was indeed giving me the black screen (nomodeset fixed that there, I should've thought to have tried that since i've used that before)

After I fixed the black screen though, behind it was a kernel panic :D I can't remember what the exact kernel panic was (I think it was having some troubles with mounting my partitions) I fixed it by changing my fstab and my lilo.conf to use /dev/sdx instead of UUIDs. See initially that's why I had initramfs support enabled because I was reading online that in order for lilo to support "UUID=xxx" as root, you had to have an initrd (which seemed to be correct, it didn't recognize "UUID" as a valid mount point unless I had the initrd as well. I was having some issues with my flash drive (which had bunsenlabs on it) occasionally putting itself as priority and becoming "/dev/sda" (which would make my "sdb" turn into an "sdc") hence why I went the route of using UUIDs. I'm still not sure why it wouldn't boot without it, but that's alright (I just make sure to remove the flash drive while booting just in case that happens).

So I guess the question I have now is, how do I prevent the black screen without having to turn off modesetting? When I had issues with modesetting years ago with my radeon card, I had to use "nomodeset" until I could install the proper drivers, then I was able to remove the command to let it use it. If I install "xf86-video-intel", would that fix my issues or is there something else going on here?

Submitted by stealth 02 Oct, 2021 19:27 #

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.

Submitted by Xenanthropy 03 Oct, 2021 02:48 #

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.

Ok, thank you so much for the help! Since it's "working" right now with nomodeset, I think i'll leave it for now and focus on rebuilding my system (Very tedious work on a dual-core Ivy Bridge i5... phew) i'll look at different distros' default kernel configs and see what I could possibly be missing that's giving me the black screen issue!

 
Register or login to post a reply.