v86d missing from initramfs

Bug #273833 reported by Slogger on 2008-09-24
22
Affects Status Importance Assigned to Milestone
v86d (Ubuntu)
High
Unassigned
Intrepid
High
Unassigned

Bug Description

Binary package hint: v86d

Sep 23 19:47:21 ****** kernel: [ 3.768056] uvesafb: failed to execute /sbin/v86d
Sep 23 19:47:21 ****** kernel: [ 3.768067] uvesafb: make sure that the v86d helper is installed and executable
Sep 23 19:47:21 ****** kernel: [ 3.768074] uvesafb: Getting VBE info block failed (eax=0x4f00, err=-2)
Sep 23 19:47:21 ****** kernel: [ 3.768081] uvesafb: vbe_init() failed with -22
Sep 23 19:47:21 ****** kernel: [ 3.768094] uvesafb: probe of uvesafb.0 failed with error -22

These lines (with comp name for ******) show up in my syslog every boot.

Should v86d be installed, or is this an extraneous error?
If v86d should be installed, it seems that it's not installed by default.

-Zeus- (matthew-momjian) wrote :

I get that too, it's no problem. Just ignore it.

Changed in v86d:
importance: Undecided → High
milestone: none → ubuntu-8.10-beta
status: New → Triaged
Matt Zimmerman (mdz) wrote :

In Ubuntu 8.04 and earlier, things worked as follows:

- vesafb.ko is included in the initramfs and conf/modules by virtue of being in /lib/modules/x/initrd/
- If vga= or similar is passed on the kernel command line, vesafb is loaded with the appropriate parameters
  (/usr/share/initramfs-tools/scripts/init-top/framebuffer)
- the initramfs init script will try to load it again via conf/modules, but it's already loaded (harmless)
- thus, all that is needed to enable vesafb is passing a kernel parameter

In Intrepid, it now works as follows:
- vesafb is gone, and we have uvesafb.ko
- uvesafb.ko is included in the initramfs and conf/modules by virtue of being in /lib/modules/x/initrd/
- initramfs-tools has no smarts for uvesafb, so it gets loaded via conf/modules
- I see no way to pass parameters to the module as was done with vesafb
- it's impossible to do anything with the module without manually installing v86d

This should be made to work similarly to how it did with vesafb. If an additional package is required by a kernel module, it should have a dependency relationship (recommends?) with the kernel package.

HugoHirsch (ubuntubugs-aiki-it) wrote :

BTW: I experienced the same with a fresh install from intrepid daily -
after installing the proprietary nvidia graophics driver the error message does not show up and the machine boots with a splash screen.

Colin Watson (cjwatson) on 2008-10-06
Changed in v86d:
milestone: ubuntu-8.10-beta → ubuntu-8.10

I have the same problem at Intrepid x86_64.

Ben Collins (ben-collins) wrote :

Looking into getting this into the default install.

Changed in v86d:
assignee: nobody → ben-collins
status: Triaged → In Progress

On Wed, Oct 08, 2008 at 02:17:00PM -0000, Ben Collins wrote:
> Looking into getting this into the default install.

The important thing is that this doesn't change behavior from 8.04. Users
who are setting vga= should get a vesa framebuffer console, users who are
not should get a text console.

I also have a concern that this bug will have masked regressions in uvesafb
relative to vesafb. How much is changed between the two drivers?

--
 - mdz

Fahim Abdun-Nur (fahim-a) wrote :

...or related at the very least.

itsmegawtf (itsmegawtf) wrote :

Has same problem on Linux bentley 2.6.27-7-server #1 SMP Fri Oct 10 04:50:54 UTC 2008 i686 GNU/Linux

[ 2.630760] uvesafb: failed to execute /sbin/v86d
[ 2.631057] uvesafb: make sure that the v86d helper is installed and executable
[ 2.631307] uvesafb: Getting VBE info block failed (eax=0x4f00, err=-2)
[ 2.631471] uvesafb: vbe_init() failed with -22
[ 2.631735] uvesafb: probe of uvesafb.0 failed with error -22

Gabriel Bauman (gabrielbauman) wrote :

I dist-upgraded to Intrepid from Hardy. Boot would hang immediately after the usplash progress bar stopped 'bouncing' and started counting up. Removing 'splash' from kernel options allowed boot to complete; installing v86d fixed the problem altogether.

This is with the nvidia driver, if that means anything.

itsmegawtf (itsmegawtf) wrote :

I didn't install any graphical card driver, I am using server distro as you can understand from my 'uname -a'.
Everything were working correct, but for the moment I made a decision to do 'do-release-upgrade -d', after this this sh*t happened :)

I don't need any serious graphical stuff on server, as I don't need a splashscreen :)

Tim Wright (timw) wrote :

OK, this broke for me too going to Intrepid. My system hung unless I removed "splash" from the boot options. Initially, I had the same error "failed to execute /sbin/v86d". However, installing it, did NOT fix the problem, instead, booting without splash, I now get the following:

uvesafb: Getting VBE info block failed (eax=0x4f00, err=-3)
uvesafb: vbe_init() failed with -22
uvesafb: probe of uvesafb.0 failed wioth error -22

In Googling around, it seems that v86d is broken when builtt with gcc 4.3 unless you use a newer version (compiling it with 4.1.2 apparently works). See the debugging performed in http://bugs.gentoo.org/196848 for details. Unfortunately, it looks like Intrepid is currently using 0.1.5 of v86d. Please give serious thought switching to 0.1.8. I am going to try to download it and build it myself to see if it fixes the problem.

Ben Collins (ben-collins) wrote :

v86d is available as a separate package. uvesafb is no longer going to be the default. If you want to use it, you will need to install v86d manually.

Changed in v86d:
assignee: ben-collins → nobody
status: In Progress → Invalid
Matt Zimmerman (mdz) wrote :

On Tue, Oct 14, 2008 at 03:33:36PM -0000, Ben Collins wrote:
> v86d is available as a separate package. uvesafb is no longer going to
> be the default. If you want to use it, you will need to install v86d
> manually.

If that's the intent, then uvesafb should not be loaded by default, and it
should be automatically loaded when v86d is installed.

--
 - mdz

Tim Wright (timw) wrote :

Thanks Ben,
Matt covered it for me. I *don't* want to use it, but it's getting installed anyway, and it doesn't work. So making it not be the default is fine for me, but for those who do want to use it, it still needs to be dependent on v86d, and at least with my hardware, it seems v86d needs updating (0.1.9 is now current) for it to work reliably.

pietjepuk (pietjepuk72) wrote :

1. This bug is marked as invalid, but I observe the same when booting Kubuntu i386 Live CD RC (from kubuntu-8.10-rc-desktop-i386.iso).
2. This bug looks like bug 274346 and bug 246269, but I am not sure

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Bug attachments