Curiosity on syslinux' vesamenu.c32

[CentralWare]

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?

[curaga]

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.

[CentralWare]

@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!

[curaga]

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.

[CentralWare]

@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.