Using 800x600 or higher resolution for pfSense console



  • When I boot up my pfSense box while it's connected to one of my LCD monitors, the BIOS step shows up fine, but immediately afterwards, it seems to drop into 720x400 @ 70Hz, which is incompatible with my monitor, so I can't see anything.

    Is there any way to have pfSense change over to 800x600 or higher - to ANY resolution that is usable by my LCD, so I can see the console?


  • Rebel Alliance Developer Netgate

    the vidcontrol command can adjust the screen parameters but for some reason I'm thinking we didn't include all of the kernel options someone might need to do that.

    This might help…

    fetch -o /boot/modules http://files.chi.pfsense.org/jimp/ko-8.1/i386/vesa.ko
    kldload vesa
    vidcontrol MODE_292
    

    (assuming you're on i386)

    You can find all the modes with

    vidcontrol -i mode
    

    If that works, add the shellcmd package and have it run that in an earlyshellcmd (might need the full path, /usr/sbin/vidcontrol).



  • @jimp:

    the vidcontrol command can adjust the screen parameters but for some reason I'm thinking we didn't include all of the kernel options someone might need to do that.

    Yes, I think there is not enough in the pfsense kernel to do proper raster display in terminal - loading vesa.ko is not enough, you need SC_PIXEL_MODE in the kernel, and I do not think there is a .ko file for that …

    Pretty unbelievable, actually - people that use pfsense are going to want to be in the console and using curses monitoring tools, etc. - how did any of you last even a day without a proper console ?

    Can this be (quickly) fixed ?


  • Banned

    @apfusertoo:

    Pretty unbelievable, actually - people that use pfsense are going to want to be in the console and using curses monitoring tools, etc. - how did any of you last even a day without a proper console ?

    Loads of HW used with pfSense have serial console at best… or no console at all. I fail to see how's VGA console resolution of any priority with firewalls.


  • Rebel Alliance Developer Netgate

    The vast majority of installs I've worked with customers on were either:

    1. Server grade gear in a rack running headless or on a KVM only checked/used on rare occasions
    2. Embedded units with only serial console.

    Very few run with monitors attached. Fewer still run with a monitor attached in a place where someone might think to use it for monitoring anything.

    People are more likely to use that monitor as a second display on their PC and then monitor over ssh or via a monitoring system such as zabbix, cacti, or the GUI itself.



  • Can this (quickly) be fixed ?


  • Rebel Alliance Developer Netgate

    Making changes to the kernel options this close to a release is not likely to happen, especially when it would have unknown potential consequences.

    Perhaps it can be revisited for 2.2, but for 2.0.x and 2.1, no.



  • @jimp:

    Making changes to the kernel options this close to a release is not likely to happen, especially when it would have unknown potential consequences.

    Perhaps it can be revisited for 2.2, but for 2.0.x and 2.1, no.

    Uhmmm…  not sure if kidding ??

    You're not sure if options VESA and SC_PIXEL_MODE (which have been kernel options for ... 15 years now ?) will have unknown consequences for your networking utility ?

    Ok, let's assume you're serious.

    Can the culture of pfsense, which completely discourages any attempt at building custom pfsense kernels, offers no HOWTOs for that, and no proper build recipe, be changed so that I can just add this by myself ?

    Or do people like that culture ?


  • Rebel Alliance Developer Netgate

    Just because the options have existed for that long does not mean they are things we want/need. Especially this close to a release. Every change must be vetted properly. If you had asked 6 months or a year ago, we probably would do it. And we can certainly look at it for 2.2 (on FreeBSD 10.x). It's mostly bad timing.

    It may seem safe, but those are the most dangerous things. We can't just add them without proper testing. It may be harmless, but the fact is, we don't know. As unlikely as it seems, there is hardware out there that barfs on the most seemingly innocuous of options in certain cases. Not typical off-the-shelf stuff, but specialized/embedded hardware.

    We don't discourage people from making their own builds, the process is documented, it's just not simple/easy.

    If there were a large number of pfSense users demanding the feature, we'd be more likely to investigate it sooner, but you resurrected a year-old thread in which nobody even bothered to respond to my suggestion. I'd say demand is fairly low for doing this.

    I will say that we have done a build with VESA and splash for a customer, and that did work (though they eventually opted out of keeping it), but I don't think anyone has ever tried running with SC_PIXEL_MODE.

    I certainly would not expect it to cause any problems, but that still doesn't mean we can add it right this moment.


  • Banned

    @jimp:

    It may seem safe, but those are the most dangerous things. We can't just add them without proper testing. It may be harmless, but the fact is, we don't know. As unlikely as it seems, there is hardware out there that barfs on the most seemingly innocuous of options in certain cases. Not typical off-the-shelf stuff, but specialized/embedded hardware.

    I have seen so many machines with boot broken by VESA/kernel modesetting on Linux that I'd be amazed if this did not break anything. And, those are normal desktop machines, not even embedded HW that gets easily upset by a whole lot less than this. On a FreeBSD note, read e.g. this:

    http://lists.freebsd.org/pipermail/freebsd-bugs/2012-November/050688.html

    This stuff is definitely not safe to mess with without proper testing, not to mention that most people just don't use this at all on a firewall.