# uvesafb fails on boot

## deanpence

uvesafb is failing at boot with this error:

```
[    1.336845] uvesafb: Getting VBE info block failed (eax=0x4f00, err=0)

[    1.336858] uvesafb: vbe_init() failed with -22

[    1.336870] uvesafb: probe of uvesafb.0 failed with error -22
```

I'm running gentoo-sources 3.8.13, generating an initramfs with dracut 029, and running under VMWare Fusion 4.1.4. I've also got v86d 0.1.10 installed.

I've reviewed Documentation/fb/uvesafb.txt and double-checked the Gentoo Wiki as well, and I can't find anything I've missed.

Nothing else is amiss. All my logical volumes are detected, checked, and mounted; initramfs hands off to the real kernel without problems; all init scripts run fine, etc. I just get a very small console. (I am able to scroll back through console output with <FN>+<SHIFT> like I was with vesafb, though; I didn't think that was possible without a framebuffer.)

Here are the relevant kernel options:

```
CONFIG_CONNECTOR=y           # Connector - unified userspace <-> kernelspace linker

CONFIG_PROC_EVENTS=y         #   Report process events to userspace

CONFIG_FB=y                  # Support for frame buffer devices

CONFIG_FIRMWARE_EDID=y       #   Enable firmware EDID (I don't think this is actually needed.)

CONFIG_FB_CFB_FILLRECT=y     #   (an invisible dependency of CONFIG_FB, I think)

CONFIG_FB_CFB_COPYAREA=y     #   (ditto)

CONFIG_FB_CFB_IMAGEBLIT=y    #   (ditto)

CONFIG_FB_MODE_HELPERS=y     #   Enable Video Mode Handling Helpers

CONFIG_FB_UVESA=y            #   Userspace VESA VGA graphics support

CONFIG_VGA_CONSOLE=y         # VGA text console

CONFIG_FRAMEBUFFER_CONSOLE=y # Framebuffer Console support
```

Here's the bulk of my grub (0.97-r12) config:

```
default 0

timeout 30

splashimage=(hd0,0)/boot/grub/splash.xpm.gz

# Gentoo Linux 3.8.13-r0-02 #{{{

title  Gentoo Linux 3.8.13-r0-02

root   (hd0,0)

kernel /boot/kernel-3.8.13-r0-02 root=/dev/mapper/vg.main-slash video=uvesafb:1280x960MR-24m,mtrr:3,ywrap ro

initrd /boot/initramfs-3.8.13-r0-02.img

#}}}
```

(But it doesn't even get to the point of processing the video mode.)

I've also verified that the files uvesafb/v86d needs are in the initramfs. Those files should be the ones listed in /usr/share/v86d/initramfs:

```
dir /dev 0755 0 0

nod /dev/console 0600 0 0 c 5 1

nod /dev/tty1 0600 0 0 c 4 1

nod /dev/zero 0600 0 0 c 1 5

nod /dev/mem 0600 0 0 c 1 1

dir /root 0700 0 0

dir /sbin 0755 0 0

file /sbin/v86d /sbin/v86d 0755 0 0
```

The permissions of /dev/mem, /dev/zero, and /dev/console are more permissive (0640, 0666, and 0644 respectively) than v86d says it wants them, but I don't think that would cause these problems.

A few things that were too long to paste here:

the contents of my initramfs

the dracut module that installs the files uvesafb needs

my full kernel config file

the full output of `dmesg`

----------

## mvaterlaus

hi,

you missed this config in your kernel:

```

General setup  --->

    [*] Initial RAM filesystem and RAM disk (initramfs/initrd) support

    (/usr/share/v86d/initramfs) Initramfs source file(s)

```

put this in your kernel and rebuild it and copy it to your boot folder. then it should work on the next reboot

----------

## deanpence

Unfortunately all /usr/share/v86d/initramfs does is tell the kernel what files to include in an initramfs. Dracut, to my knowledge, doesn't use the kernel source tree's scripts to generate an initramfs, so it doesn't even use this value. But just in case there was something I was missing, I gave it a shot anyhow, but nothing changed. You can see above, though, that I did make sure to include those files in the initramfs with a dracut plugin.

One odd thing I noticed before giving this a shot, though, was that I see these two directories: 

/sys/bus/platform/drivers/uvesafb, which is to be expected, and

/sys/bus/platform/devices/uvesafb.0, which I didn't expect since a framebuffer doesn't seem to exist at all,

... but I do *not* see /sys/bus/platform/drivers/uvesafb/uvesafb.0, which does make sense.

I'd really like to make this work if anyone has any more insight, but I may end up having to move back to the old vesafb.

----------

## mvaterlaus

 *deanpence wrote:*   

> 
> 
> Unfortunately all /usr/share/v86d/initramfs does is tell the kernel what files to include in an initramfs. Dracut, to my knowledge, doesn't use the kernel source tree's scripts to generate an initramfs, so it doesn't even use this value.
> 
> 

 

no, this tells the kernel, that i should load the files located at /usr/share/v86d/initramfs. this does not include the files in your initramfs. for this, as you allready mentioned, you use dracut to generate an initramfs. if this entry is not present, the files in your dracut ramfs are present, but wont be used. your dracut initramfs gets mounted as a pseudo / filesystem, with the files you specified to include. so imho you need this entry.

[edit]quoting fixed[/edit]

----------

## deanpence

 *mvaterlaus wrote:*   

> no, this tells the kernel, that i should load the files located at /usr/share/v86d/initramfs. this does not include the files in your initramfs.

 

Thanks for the info here. The kernel docs on this aren't totally clear on how this happens.

I'm still not having any luck, though. I was able to get a framebuffer to work by enabling AGP and using VMWare's DRM driver (vmwgfx), but that framebuffer doesn't natively support scrolling, and I'm not sure VMWare really cares about offering a lot of configuration options unless you're using VMWare Tools; unfortunately I gave up trying to get either vmware-tools or open-vm-tools/open-vm-tools-kmod to work properly when they stopped supporting the old vmblock driver and moved to FUSE for VMWare Fusion 5. As I don't use X on any of my servers, and as this is a kind of staging image for memory- and CPU-constrained VPSs on Linode, I'd like to keep the kernel small and only use exactly what I need.

Any other ideas will be appreciated. I still get the *exact* same kmsg output, no matter what I try:

```
[    1.119268] uvesafb: Getting VBE info block failed (eax=0x4f00, err=0)

[    1.119281] uvesafb: vbe_init() failed with -22

[    1.119294] uvesafb: probe of uvesafb.0 failed with error -22
```

----------

## deanpence

I discovered that the "0" in "err=0" is -ENOBUFS, which indicates, I think, that either memory couldn't be allocated, or there was no backing store available, so I thought I would compile uvesafb as a module to see if it would load later in the boot sequence. Well, nothing happened, so I tried to modprobe it, per the instructions in Documentation/fb/uvesafb.txt:

```
23:15:15 root@n00:~ # modprobe uvesafb mode_option=1280x1024MR-24m mtrr=3 scroll=ywrap

23:15:47 root@n00:~ # dmesg | tail -n3

[  274.151791] uvesafb: Getting VBE info block failed (eax=0x4f00, err=0)

[  274.151793] uvesafb: vbe_init() failed with -22

[  274.151799] uvesafb: probe of uvesafb.0 failed with error -22
```

So I'm back to square one here.

----------

## mvaterlaus

I'm sorry that I can not help further, because I do not use initrd's. But I can give you some hints. I saw in your kernel config, that you do not have CONFIG_SYSFS enabled. how did you build the kernel. for a minimal config, try pappy's kernel seeds [1]. it also contains a guide on how to configure your kernel. the second one, if you use uvesafb, you must disable all other framebuffer devices in your kernel, because they conflict otherwise. maybe another user who uses an initrd can help you further.

[1]www.kernel-seeds.org

----------

## mvaterlaus

what I also noticed in your kernel command line:

```

video=uvesafb:1280x960MR-24m,mtrr:3,ywrap

```

which should be as follows:

```

video=uvesafb:1280x960-24,mtrr:3,ywrap

```

----------

## SylaSebas

did you ever get it work? I'm actually at the same spot right now and I can't figure out what the problem is ... so I'd appreciate it if you could share your solution (if u have one!  :Wink: 

----------

## worch

I encountered this issue too. While the /dev/* devices were in my initramfs, they weren't in my real root filesystem prior to my init script performing exec to switch from the initramfs to my real root filesystem. To fix the issue, I copied /dev/console, etc to the /dev directory in my real root filesystem.

My init script mounts devtmpfs to /dev, but unmounts it prior to exec switch_root. Because /dev in my real root was empty and the boot process doesn't mount devtmpfs to /dev until later, /dev/console, etc wasn't available when the fb required it.

----------

