Tiny Core Linux
General TC => General TC Talk => Topic started by: CentralWare on February 17, 2015, 04:30:58 AM
-
I was just curious... if I can get vesamenu to load up a graphical menu on boot, and because the size is tremendously small, does anyone have an idea as to whether or not this could be used as a boot splash screen (ie: during tc-config) ?
Concept:
UI vesamenu.c32 (with graphic) as a boot menu.
Once a menu item is selected, have a second image shown while we're running tc-config.
I know it's a little "out there" I just figured since we already have something in place utilizing the frame-buffer, why not re-use it during boot?
-
I've done something like that in the past. First direct the console out with console=/dev/null, then in the start of tc-config start a framebuffer image viewer, and in the end kill it. I think you can find the viewer I used, fbv hacked, in the 2.x or 1.x archives.
The kernel does clear the screen, so even if you used the same image, there will be a flicker.
-
@curaga: Thank you! Interesting idea. I'm assuming console= is pertaining to a kernel boot code, but what about after boot? I have to assume we have to redirect output back to tty in some fashion?
Theoretically speaking, would doing so as a file output instead of a device (null) work that early in the game? (ie: console=/tmp/console.log) Logging from init and afterward is straight-forward enough, but what I'd really like to do is capture all kernel-only messages (such as usb devices being detected, etc.)
Thanks again and take care!
-
console= only affects the boot messages before login, tty* work fine. Redirecting to a file probably won't work, kernel messages are all in dmesg.
-
@curaga: Thanks for the info! I have a machine I want to test this on to see if I can get hardware issues (missing firmware mods) to be saved (even if in dmesg) while muting the errors on-screen (I'm assuming I can just echo "0" > printk but I don't think that took care of the issue last time around, so I'll have to keep digging.) Since I can install the firmeware extension and the problem goes away, I have to assume the problem (and notices) are coming from udevadm and not the kernel itself, or somewhere in the middle of both.