[blfs-support] /dev/fb0 not being created on boot

Richard Melville richard.melville69 at googlemail.com
Sun Nov 24 04:33:35 PST 2013

> On Fri, Nov 22, 2013 at 07:05:14PM +0000, Richard Melville wrote:
> > Ken, I'm using vesafb on a web server with no Xorg, and I just use the
> > console.  I realise that my kernel was quite old but as I like to check
> > every configuration option (often because of new hardware) it takes a
> long
> > time to configure a new kernel and becomes incredibly boring towards the
> > end :-(  Therefore, I usually limit my upgrades to about one per year, or
> > when I can be bothered.
>  OK, but in that case I suggest that you go for "early stable"
> kernels (.1, .2, etc).  You said you had been using 3.7-rc8 - that
> probably turned out to be totally good for your uses, but sometimes
> even .0 releases still have issues in a few places.
>  Also, the config you use in a late -rc will normally not provide any
> extra questions for released / stable kernels in the same series if
> you use 'make oldconfig'.

Interestingly, as 3.12.1 is now available I downloaded the source, copied
the config across, and ran 'make oldconfig'.  As you predicted there were
no extra questions to answer so I proceeded to compile.  Strangely, it
exited with an error when it reached a *keyboard* configuration.  I know I
should have investigated further, but by this time I was so frustrated that
I returned to 3.12 as I knew it was good.  I can't remember the last time I
had a kernel fail at the compile stage.  I'll investigate further when I
have more time.

> >
> > Bruce, my framebuffer config was much like yours but with one exception:
> I
> > had CONFIG_X86_SYSFB=y.  This was stopping vesafb loading and stopping
> > /dev/fb0 being created.  I've removed that option, reconfigured, and now
> it
> > all works as expected.
>  Interesting.  That option works ok on intel (I'm running with it at
> the moment), I'll try to remember that for the future - my server
> also runs with CONFIG_FB_VESA and vga=792 (it's a radeon RS780, when
> I got it I had no experience with modern ATI hardware and totally
> failed to get the radeon framebuffer to work - 80x25 is too
> restrictive for me!) - for the moment I'm running 3.10 (LTS) there.

Hmm -- I'm using an Intel board.

> >
> > Regarding vga=792, that still works for me.  If I substitute
> video=1024x768
> > the command is ignored an I get a large, ugly font.  I'm currently using
> > grub-2.0, so I can't understand what the problem is likely to be.  Any
> > ideas?
> >
> > Richard
>  Stick with vga=792 since it still works ?  Any idea how large the
> font is, or how many pixels in the screen size when you boot with
> video=1024x768 ?

It's the correct font that I've set but without the resolution setting; It
looks ugly at that size on the screen.

>  When the box boots, you get the font from its bios.  But when the
> LFS bootscripts start to run it ought to switch to your specified
> font (provided the setup supports it, e.g. my own 12x22 is only
> supported on framebuffers and I've not tried it with Vesa, my screen
> there is physically 1024x768 so I use an 8x16 font on that).
>  So, basically work out what sort of console font *size* will suit
> you, then try "setfont" in a spare tty and see if any of the
> available fonts look ok _and_ provide the character coverage you
> require.
>  My own LatGrkCyr are intended for white/pale text on a black
> background and I'm told that at least one of them looks awful with
> dark text on a pale background : there is a balance between getting
> adequate coverage, shapes which do not offend our own particular
> sensibilities, and being able to distinguish the various accents and
> diacritical markings - for some uses, noting that a glyph is e.g.
> "letter a with accent" may be good enough, but others may wish to be
> able to see at a glance what sort of accent is present, particularly
> in unfamiliar languages.
> ?en

I'm using LatGrkCyr and I really like it.  On my console screen at vga=792
it looks good.  So everything is now working but some questions remain
unanswered.  Thanks for your help Ken.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfromscratch.org/pipermail/blfs-support/attachments/20131124/c9a426d7/attachment.html>

More information about the blfs-support mailing list