I upgraded my machine to ‘openSUSE 13.2 “Harlequin” - Kernel 3.16.7-21-default i586’, using grub2 as boot loader.
The kernel command line is containing “video=vesafb:ywrap” as it did for years.
Grub2 is configured to use 1280x1024 as resolution and the gfxpayload is set to “keep”.
The “vesafb” driver is compiled into the kernel, not as a module.
The kernel messages after boot
0.000000] Kernel command line: BOOT_IMAGE=/vmlinuz-3.16.7-21-default root=UUID=c12c3e67-e7b5-4ff8-83d1-9db32c7bed3c resume=/dev/disk/by-id/ata-IBM-DTLA-305030_YGEYG0L5220-part1 splash=verbose showopts video=vesafb:ywrap
...
23.084521] vesafb: mode is 1280x1024x16, linelength=2560, pages=0
23.084637] vesafb: scrolling: redraw
23.084736] vesafb: Truecolor: size=0:5:6:5, shift=0:11:5:0
23.084996] vesafb: framebuffer at 0xe6000000, mapped to 0xd0800000, using 2560k, total 2560k
23.198347] Console: switching to colour frame buffer device 160x64
23.307049] fb0: VESA VGA frame buffer device
show that “ywrap” was ignored, apparently.
I already tried to set the parameter in the file “/etc/modprobe.d/99-local.conf” by “options vesafb scroll=ywrap” and then rebuilding the initrd to no avail.
How do I tell the builtin vesafb to use the scrolling mode “ywrap” as it did before?
I tried (on my Tumbleweed install) and could not get it either. I did a quick check and it looks like vesafb hasn’t had a commit in over two years. Perhaps something else has changed in the FBDEV realm that has affected this.
Suggestions:
Try another distro (liveCD) to see if you can reproduce this.
Try disabling plymouth and see if that affects anything.
I think it may have something to do with vesafb being compiled into the kernel and not being a module.
The framebuffer detection takes place before even “thinking” about plymouth.
Uninstalling plymouth didn’t make a difference.
Trying a live CD isn’t so easy as the machine doesn’t have any CD drive.
I’ll try that on another machine.
The framebuffer detection takes place before even “thinking” about plymouth.
true
Uninstalling plymouth didn’t make a difference.
no need to have uninstalled – just disable it at boot (rd.plymouth=0, plymouth.enable=0)
Trying a live CD isn’t so easy as the machine doesn’t have any CD drive.
I’ll try that on another machine.
as gogalthorp points out, that new fangled usb technology has its uses
***** its complied statically here too. I also noted (from the .config) that efi.ko is too. However, I can’t find either of those fbdev drivers listed
I made some checks with the rescue-system on the opensuse 13.2 32-bit DVD.
The alternative machine has a nvidia card and a ready 13.2 32-bit system installed on hardisk with grub2 as boot loader.
Booting from DVD and starting the rescue system with screen resolution 1280x1024 and the additional parameters “modprobe.blacklist=nouveau video=vesafb:ywrap” results in a rescue system with “vesafb: scrolling: ywrap…” in the kernel messages => ywrap active.
Booting the same rescue system from a folder on harddisk with grub2 (configured to 1280x1024, gfxpayload=keep) and the additional parameters “modprobe.blacklist=nouveau video=vesafb:ywrap” results in a rescue system with “vesafb: scrolling: redraw” in the kernel messages => ywrap inactive.
Thus it seems to have something to do with grub2.
Next thing I’ll try will be to reactivate grub legacy on the target machine with “vga=0x31a video=vesafb:ywrap”.
As opensuse isn’t using grub legacy as supported boot loader anymore (see “yast2 bootloader”) this wouldn’t be a very good solution.
Well you can still use it BUT yast does not support it so you must do all by hand.
Grub 1 will not work in an EFI boot though should be ok if using legacy mode in newer machines. BUT you should not mix boot modes if muti-booting. All EFI or all legacy otherwise you will have problems.
So far: The alternative machine booting with grub legacy succeeds to activate ywrap, which it didn’t with grub2.
The test on the target machine will have to wait until tomorrow as it is working on some jobs right now.
Wait, what are you upgrading from and did you use Grub2 before?
What bootloader is the rescue cd using? one of the ones from isolinux?
Booting the same rescue system from a folder on harddisk with grub2 (configured to 1280x1024, gfxpayload=keep) and the additional parameters “modprobe.blacklist=nouveau video=vesafb:ywrap” results in a rescue system with “vesafb: scrolling: redraw” in the kernel messages => ywrap inactive.
Thus it seems to have something to do with grub2.
If you haven’t been using Grub2 previously (which is what I initially assumed was the case), then I think that the combination of a static vesafb and the peculiarities of Grub2 will prevent this.
Well, I upgraded step by step (= version by version) from SuSE 9.2 to opensuse 13.2 and switched from grub legacy to grub2 after the successful upgrade to 13.2.
The standard 13.2 Installation-DVD, also featuring a rescue part, is using isolinux, which probably is using the 16-bit mode.
So there seems to be no way to configure the special parameters of vesafb (not uvesafb) when booting in 32-bit mode?
of vesafb (not uvesafb)[/QUOTE]of course, but that was not the point … the point was a simple logic extension that vesafb will likely (not gauranteed, but likely to) work too, given that particular page indicates that a non static uvesafb is able to achieve the desired result with grub2
In any regard, you could also attempt to do this with the DRM/KMS drivers … though, I get a sneaky suspicion that you’re using a nvidia adapter and the prop drivers in the machine in question.
