Slqckware 13.37 & lilo & vga
Johannes D.H. Beekhuizen
I'm trying to install SlackWare 13.37.
I was used to have vga=normal in my lilo.conf, which gave me a screen which
I could read, I believe it was 80x32 characters, more or less like the old
Dos.
Now when I use normal, it gives a font that I can hardly read, not even with
my spectables on.
How do I get the old screen back?
Thanks for usefull help,
--
Regards,
Hans.
Eef Hartman
> I was used to have vga=normal in my lilo.conf, which gave me a screen which
> I could read, I believe it was 80x32 characters, more or less like the old
80x25, the "normal" screeen EVERY video card still will support.
> Now when I use normal, it gives a font that I can hardly read, not even with
> my spectables on.
> How do I get the old screen back?
Use "vga=ask" in your lilo config and see what modes it DOES support.
Don't forget to rerun "lilo" after every change to /etc/lilo.conf !
Normal should normally be mode 0, I believe, but the card should
tell you.
--
******************************************************************
** Eef Hartman, Delft University of Technology, dept. SSC/ICT **
** e-mail: E.J.M....@tudelft.nl - phone: +31-15-27 82525 **
******************************************************************
Edwin Johnson
> Hello,
>
> I'm trying to install SlackWare 13.37.
> I was used to have vga=normal in my lilo.conf, which gave me a screen which
> I could read, I believe it was 80x32 characters, more or less like the old
> Dos.
> Now when I use normal, it gives a font that I can hardly read, not even with
> my spectables on.
> How do I get the old screen back?
Try adding at the beginning of lilo.conf in the append line, video=640x480,
...Edwin
____________________________________________________________
"Once you have flown, you will walk the earth with your eyes
turned skyward, for there you have been, there you long to
return."-da Vinci http://bellsouthpwp2.net/e/d/edwinljohnson
Grant
Similar issue here on a machine that slack could do better with,
defaulted to the DOS 750x350 or some such crazily unreadable
screen, so I set the thing to framebuffer 1024x768, which got me
as far as a kernel panic 'cos it cannot see root disk :( Usual
teething troubles... I'm not terribly fussed yet.
This is my second 13.37 install, the first was sort of okay except
it cannot talk graphics, but that box needed only text mode to
backup windoze, so I don't care, box gone to client so it's good
enough. I was hoping to introduce them to Linux, another day.
My second install is on my RAID box, and if it doesn't behave I'll
soon set it back to 13.1, leave the update to when I can focus on
the task more.
Grant.
Dario Niedermann
> I was used to have vga=normal in my lilo.conf, which gave me a screen
> which I could read, I believe it was 80x32 characters, more or less
> like the old Dos. Now when I use normal, it gives a font that I can
> hardly read, not even with my spectables on.
I've had the same issue, thanks to the new kernel modesetting which
happily ignores the 'vga=' option.
In '/etc/lilo.conf', add the following to the 'append=' line (or,
better yet, enter an image-specific 'addappend' line):
video=640x480MR-8
Then run `lilo`.
See: <http://www.kernel.org/doc/Documentation/fb/modedb.txt>
--
> head -n1 /etc/*-{version,release} && uname -moprs
Slackware 13.37.0
Linux 2.6.37.6 x86_64 AMD Turion(tm) 64 Mobile Technology MK-36 GNU/Linux
Aragorn
identifying as Dario Niedermann wrote...
> Johannes D.H. Beekhuizen <jbee...@duinheks.nl> wrote:
>
>> I was used to have vga=normal in my lilo.conf, which gave me a screen
>> which I could read, I believe it was 80x32 characters, more or less
>> like the old Dos. Now when I use normal, it gives a font that I can
>> hardly read, not even with my spectables on.
>
> I've had the same issue, thanks to the new kernel modesetting which
> happily ignores the 'vga=' option.
>
> In '/etc/lilo.conf', add the following to the 'append=' line (or,
> better yet, enter an image-specific 'addappend' line):
>
> video=640x480MR-8
>
> Then run `lilo`.
>
> See: <http://www.kernel.org/doc/Documentation/fb/modedb.txt>
Or, if he simply wants pure VGA mode, try adding "nomodeset" to the
kernel's append line. ;-)
--
*Aragorn*
(registered GNU/Linux user #223157)
Dario Niedermann
> Or, if he simply wants pure VGA mode, try adding "nomodeset" to the
> kernel's append line. ;-)
That'll work for the console, but you might end up not being able to run
X11, depending on your graphics card and driver. Also, rumor has it that
the ability to disable kernel modesetting is going to be phased out.
Aragorn
identifying as Dario Niedermann wrote...
> Aragorn <ara...@chatfactory.invalid> wrote:
>
>> Or, if he simply wants pure VGA mode, try adding "nomodeset" to the
>> kernel's append line. ;-)
>
> That'll work for the console, but you might end up not being able to
> run X11, depending on your graphics card and driver.
No, that is not true. That's not what kernel modesetting is for.
Framebuffer graphics and X11 have always worked without kernel
modesetting - the kernel I'm currently using on this system here
doesn't even have kernel modesetting yet.
Kernel modesetting simply ads an improvement to certain scenarios, but
disabling it does not suddenly wreak havoc, although it /might/ do that
in the future as userland evolves to making use of the kernel
modesetting feature. For now, that is still not the case, as the
feature is still too new. In a way, you can compare the kernel
modesetting feature to udev - not technically, but from the development
point of view.
During the first couple of years after udev was introduced, you could
still easily set up a system without it. Today, this is no longer true
for most distributions, because many things in userspace now depend on
udev. Many(/most?) distributions even already start udev from within
the initrd, so the on-disk "/dev" directory is actually empty before
udev gets started, and this decision also makes it more difficult - not
impossible, but more difficult - to boot a kernel without an initrd.
You will then have to take the extra steps for creating a few essential
device special files in the "/dev" directory on the root filesystem
itself - most notably "/dev/null" and "/dev/console" - and then make
sure that udev gets started by the init scripts from very early on.
But I digress. Either way, I quote from Kernel Trap...:
<quote>
"Jesse Barnes posted a summary of recent efforts to improve
the Linux kernel's support for graphics, "in collaboration
with the [framebuffer] guys, we've been working on enhancing
the kernel's graphics subsystem in an attempt to bring some
sanity to the Linux graphics world and avoid the situation
we have now where several kernel and userspace drivers
compete for control of graphics devices." He then explained,
"there are several reasons to pull modesetting and proper
multihead support into the kernel: suspend/resume, debugging
(e.g. panic), non-X uses, and more reliable VT switch," going
on to offer detail on each of these listed reasons."
</quote>
Full text...:
http://kerneltrap.org/node/8242
> Also, rumor has it that the ability to disable kernel modesetting is
> going to be phased out.
That seems unlikely at this point. As of 2.6.30, upstream Linux now has
support for deployment as dom0 on top of the Xen hypervisor. However,
kernel modesetting breaks /something/ with regard to the Xen consoles
in kernels that have Xen dom0 support via the pvops framework. This,
as opposed to dom0 support via the XenLinux patches from xen.org
itself, but as of Xen 4.0, pvops is now preferred for the dom0 kernel,
and the XenLinux patches are simply forward-ported from 2.6.18 to newer
kernels by distribution-related kernel hackers from Debian, SuSE and a
few other distributions.
So it would be very unwise that Linus & friends would be phasing out the
ability to disable kernel modesetting at this point. This does of
course not mean that they wouldn't be planning for that at /some/ point
in the future, but the Xen dom0 support via the upstream pvops
framework still needs a lot of work before it works as efficiently as
the XenLinux patches, and things cannot simply be copied back and forth
between the two projects because they're very different.
XenLinux patches offer support to vanilla Linux for use as a Xen dom0
and domU, while the pvops framework is designed to also work with other
hypervisors and virtual machine monitors, among which kvm/qemu and
lguest.
My educated guess therefore is that the ability to disable kernel
modesetting won't be phased out anytime soon yet.
Johannes D.H. Beekhuizen
n Mon, 30 May 2011 15:23:24 +0200, Eef Hartman wrote:
> 80x25, the "normal" screeen EVERY video card still will support.
> Use "vga=ask" in your lilo config and see what modes it DOES support.
> Don't forget to rerun "lilo" after every change to /etc/lilo.conf !
> Normal should normally be mode 0, I believe, but the card should tell
Alas, choosing mode 0 did not help. But I saw other suggestions, which I
will try this weekend.
TYhanks for your suggetion anyway.
Hans.
Johannes D.H. Beekhuizen
On Tue, 31 May 2011 02:44:05 +0000, ljb wrote:
> I have not figured out how to stop it (short of building a kernel
> without framebuffer_console), but since they use XDM for graphical login
> it isn't a real problem in my case.
I hope it won't be necessary to buid a new kernel.This weekend I'll have
some time to play around, and will try what the append video= does im my
case.
Hans.
Edwin Johnson
Hello Hans,
In a previous post I suggested, as I had done, adding video=640x480 to the
append line at the begining of the lilo.conf file. But I forgot to also say
that the video mode later in the file was set vga = normal. What this did,
apparently, is keep the video from jumping to the framebuffer mode halfway
throught the boot process. (I may not be exactly correct in this assumption,
but it did fix the problem on my 13.1.)
Good luck on yours.
Aragorn
identifying as Edwin Johnson wrote...
> On 2011-06-03, Johannes D.H. Beekhuizen <news...@duinheks.nl> wrote:
>
> Hello Hans,
>
> In a previous post I suggested, as I had done, adding video=640x480 to
> the append line at the begining of the lilo.conf file. But I forgot to
> also say that the video mode later in the file was set vga = normal.
> What this did, apparently, is keep the video from jumping to the
> framebuffer mode halfway throught the boot process. (I may not be
> exactly correct in this assumption, but it did fix the problem on my
> 13.1.)
Try adding "nomodeset" to the kernel's boot options. It /may/ make a
difference.
Ron Gibson
<jbee...@duinheks.nl> wrote:
>I'm trying to install SlackWare 13.37.
>I was used to have vga=normal in my lilo.conf, which gave me a screen which
>I could read, I believe it was 80x32 characters, more or less like the old
>Dos.
>Now when I use normal, it gives a font that I can hardly read, not even with
>my spectables on.
>How do I get the old screen back?
It's probably the tty font you selected. I'm not in Linux now but the
trend is for splash screens and other nonsense and to use the frame
buffer device in a tty, both of which I abhor. Strip out everything in
lilo.conf referring to screens, menus, whatever and set vga=normal as a
global option in lilo.
Then select a nice 8x16 font (you'll have to change this by hand most
likely and I'm not in Slack right now so someone else will have to point
out which file).
Rerun lilo if you made any changes.
Reboot and all should come up nice now.
I have to do this on about every distro I try now. With stupid Suse I
have to install grub and then once I get it to boot create a lilo.conf
and change over to lilo AND fix the microscopic font they insist on
using.
Geez, is eye candy really worth all of this hassle?
--
"The power of the Executive to cast a man into prison without
formulating any charge known to the law, and particularly to
deny him the judgement of his peers, is in the highest degree
odious and is the foundation of all totalitarian government
whether Nazi or Communist." -- W. Churchill, Nov 21, 1943
Johannes D.H. Beekhuizen
Edwin Johnson wrote:
EJ In a previous post I suggested, as I had done, adding video=640x480 to the
EJ append line at the begining of the lilo.conf file.
And this finally did the trick!
I really should leran how to type :( When you make a mistake there,
lilo does not complain. But what you type in wrongly is silently ignored.
Now I can at last continue with the installation of 13.37.
To everybody who gave advice: thank you very much!
--
Regards,
Hans.