I just upgraded my Dell Latitude from Slackware-13.37/X86_64 to -14.0/X86_64, changed the links in /boot, modified /etc/lilo.conf, and ran /sbin/lilo. When booting now the system hangs at this line:

fb: conflicting fb hw usage inteldrmfb vs VESA VGA - removing generic driver

I should mention that I searched the Web for this error and found references to it happening with Red Hat, Ubuntu, and Slackware. Looking at the linuxquestions.org thread for the latter (from 2010) I tried the solution recommended there (uncommenting 'chipset VGA' in /etc/vga/libvga.config) to no avail. Still hangs.

In /etc/lilo.conf I still have an append line with nomodeset on it.

I'd like to get this running today or tomorrow as I have a business trip next week on which I'll need to use the laptop. Suggestions on what to check are certainly appreciated.

BTW, since the system will not complete booting I need an alternative way of viewing and checking files. I boot the Slackware-14.0/x86_64 dvd and accept defaults until I can log in as root. I then 'mount /dev/sda1 /mnt' and this allows me to navigate to where changes need to be made, for example, /mnt/etc/vga/.

Not having encounted this issue before when upgrading a system I'm at a loss of how to fix the problem. Pointers to a solution greatly appreciated!

Rich

/etc/vga/ is used only for svgalib and is not likely to be related to your problem, or even anything that you're running. It's hardly used these days.

I'd make sure that vga=normal and get rid of nomodeset in lilo.conf, and reinstall lilo.

I changed from vga=773 to vga=normal and removed nomodeset from the append line. Then ran /sbin/lilo. Rebooting still hangs at the same error.

For context, I think it was -12.0 that I first installed on this laptop and has no problems upgrading distributions through 13.37. I did not see anything in the CHANGES_AND_HINTS file relating to this issue. Also, I'm trying to boot the generic-smp kernel, not the huge kernel; I used the script in the UPGRADE file to make a new initrd.

Booting with the 3.2.29 huge kernel makes it one line past the fb error before it, too, hangs. The huge kernel hangs here:

input: PS/2 Generic Mouse as /devices/platform/i8042/serio1/input/input7

Rich

I'd try blacklisting the Intel driver and see what happens.

Till this problem be solved you could use the vesa driver for X as a fall back.

Didier,

Please point me to where I blacklist the Intel driver (it's not in lilo.conf that I can see) and how I tell the system to use the VESA driver. If it matters, I boot into runlevel 3, not 4.

It was suggested that this might be a kernel issue but that seems to be with the 3.5.x kernel series and when I upgraded the Sony Vaio laptop here to -14.0 there was no issue.

Thanks,

Rich

Do you still have xf86-video-fbdev installed? That was removed way back before Slackware 13.0 was released, and causes known conflicts with newer versions of X. Among other things, it prevents X from starting up without an xorg.conf, which is the preferred way of doing things now. If you have an old xorg.conf, you should at least rename it to try running without it since it probably has references to obsolete drivers.

Also, you didn't say, but if you're trying to boot into runlevel 4, I'd recommend changing /etc/inittab to use runlevel 3 until the machine is booting properly.

Pat,

xf86-video-fbdev is in /var/cache/packages/extra/, but apparently not installed. There no longer is an xorg.conf file; that was removed in, I believe, 13.0. As I wrote in my response to Didier I boot into runlevel 3.

Thanks,

Rich

How long have you waited after the machine halts? Some of the messages I read about this (there are a couple thousand out there referencing this error, for every distribution!) said that the boot may continue after a few minutes.

If this has anything to do with that firmware loading delay the udev maintainers inserted to punish us all (or for some other reason that's not clear), then perhaps putting the i915 module into your initrd could help. It'll probably pull in a lot of other related modules as well.

Just a guess... I'm not finding a lot of solutions in the threads that talk about this.

Wait time: about 45 minutes now (lunch break).

Given that I've booted from the distribution DVD, how do I add the i915 module into the initrd?

Is there a way to turn off the framebuffer on the boot line? Or, any other option on the boot line that might provide more insight into what broke here?

Thanks,

Rich

Considering you said your lilo.conf was using vga=normal, there shouldn't be a framebuffer. But just in case -- when you boot, do you see penguins? If so, you're running a framebuffer. In that case I'd double check the lilo.conf to make sure there isn't maybe a duplicate vga= line lurking somewhere.

Oh, and the question about how to recreate the initrd. I'd mount the root partition on /mnt and chroot into it with "chroot /mnt", then run /usr/share/mkinitrd/mkinitrd_command_generator.sh to see the recommended command line to make the initrd. Use that line, but add to the list of modules :i915

First make sure you're not somehow starting up with a framebuffer active, because if you are that should be disabled first to see if that's the cause of the problem.

Pat,

I rebooted from the distribution DVD with the command line suggested above the boot: prompt, but I added 'fd=off' to the end. A lot of display flashing followed, then the system booted to a point where it told me that the boot disk was already loaded rw (I specified ro per the example) and showed that the Intel i915 driver was loaded. When I pressed the [Enter] key, it finished booting!

So, do I need to turn off all frame buffers with 'fb=off' on the append line? This might work as a temporary kludge, but I would really like to know why frame buffers are causing this laptop to not boot with this new distribution. I will gladly make all tests you want to isolate the reason for this issue and to allow for a fix.

Rich

vga=normal in the lilo.conf is all that should be needed to not use a VESA framebuffer... which is why I was curious about whether you see penguins when you boot the machine without the installation DVD. Penguins == framebuffer.

Pat,

I had changed lilo.conf from vga=773 to vga=normal but the system still did not boot to completion. I'll try again ... OK! Now it works. The initial font resolution looks like 640x400, then the screen blanks and continues at 1024x768.

Yes, I would see 4 penguins when the system booted up to this upgrade. Now, with vga = normal working there are no Tux visible. I certainly do not need to see the number of cores when the system boots so I'll just keep it like this.

Is this issue something that the dev team would want to address in a patch some time?

Many thanks for your help,

Rich

Glad to hear it's working!

Other than taking the choice of using a VESA framebuffer away, I'm not sure what we could do. Some time ago when issues relating to using the framebuffer with KMS modules/drivers first began to occur, I did make some changes to liloconfig. It defaults to vga=normal, says that is "the safe choice", and warns that some drivers are not compatible with a framebuffer.

I guess I could try to word it more strongly, but it would probably still be README-encrypted.