[arch-general] Video Resolution, Grub2 and Kernel 2.6.32
When I installed grub2 a short while back, I was using the kernel 2.6.31.6 and I enjoyed a full screen of 1024.768 32K color depth. I followed the steps outlined here <http://wiki.archlinux.org/index.php/GRUB2#Setting_the_framebuffer_resolution> to the letter and all was great. But when the kernel26 package upgraded to 2.6.32.2, This functionality broke. I ended up having to remove the video related stuff from my grub line to get my system to boot. When I say this didn't work anymore, basically my system wouldn't boot and I end up with a blank screen showing. When I experimented by removing the insmod statement and using vga=790 by itself, the best I get is a 30 line display with 80 columns width. Anyone know what changed? It would appear that we may need to update the wiki page with new info for grub2 and video resolution.
On Sat, Jan 02, 2010 at 11:38:33AM -0700, Steve Holmes wrote:
When I installed grub2 a short while back, I was using the kernel 2.6.31.6 and I enjoyed a full screen of 1024.768 32K color depth. I followed the steps outlined here <http://wiki.archlinux.org/index.php/GRUB2#Setting_the_framebuffer_resolution> to the letter and all was great.
But when the kernel26 package upgraded to 2.6.32.2, This functionality broke. I ended up having to remove the video related stuff from my grub line to get my system to boot. When I say this didn't work anymore, basically my system wouldn't boot and I end up with a blank screen showing.
When I experimented by removing the insmod statement and using vga=790 by itself, the best I get is a 30 line display with 80 columns width.
Anyone know what changed? It would appear that we may need to update the wiki page with new info for grub2 and video resolution.
Steve, Just to complicate the issue, I upgraded to 2.6.32 on two systems without incident, and vga=790 in the grub2 configuration file gives me 128 columns and 48 rows with the new kernel, just as it did with the older one. One of the systems is an AMD Athlon, the other is an Intel Pentium IV dual core processor.Both are i686 systems. Is your system perchance an X86-64? Chuck -- The Moon is Waning Gibbous (94% of Full) General web site: www.hallenbeck.ftml.net Audio editor weblog: edway.wordpress.com Or jabber 1on1 with me, chuckh1@jabber.org -------- Violence is a sword that has no handle -- you have to hold the blade.
Am Sat, 02 Jan 2010 11:38:33 -0700 schrieb Steve Holmes <steve.holmes88@gmail.com>:
When I experimented by removing the insmod statement and using vga=790 by itself, the best I get is a 30 line display with 80 columns width.
Try vga=0x316 instead. I can set the framebuffer resolution for my graphics card only with the hexadecimal but not with the decimal value. Greetings, Heiko
Am Sat, 02 Jan 2010 11:38:33 -0700 schrieb Steve Holmes <steve.holmes88@gmail.com>:
When I experimented by removing the insmod statement and using vga=790 by itself, the best I get is a 30 line display with 80 columns width.
Or try video=1024x768 instead of vga=790 if you have a graphics card for which the kernel has KMS support. Greetings, Heiko
Hello archers, I just want to let you know that the french hosting service OVH now provide Arch among many others distro. Reference : http://www.ovh.com/fr/items/distributions/archlinux.xml?sort=gnu Here is a (attempt at) translation : « Arch Linux distribution, lightweight and fast, which purpose is to keep it simple. No service (except SSH) is provided in order to allow everyone to customize his server to taste. Request confirmed administration skills. » They provide ArchLinux 2009.08 in both 32 and 64 bit with their own kernel with grsecurity (2.6.31.5-grs) It runs on dedicated server, I don't know if it's planned to be supported on a virtualized one. -- radio ianux - http://ianux.fr/
On Wed, Jan 13, 2010 at 07:51, ianux <ianux@free.fr> wrote:
They provide ArchLinux 2009.08 in both 32 and 64 bit with their own kernel with grsecurity (2.6.31.5-grs) How well does this integrate? Arch doesn't have any officially-endorsed grsecurity kernel. Does it require userspace modifications? Have they submitted their package to Arch so the devs can look at it and check for flaws?
On Wed, 13 Jan 2010 08:00 -0500, "Daenyth Blank" <daenyth+arch@gmail.com> wrote:
On Wed, Jan 13, 2010 at 07:51, ianux <ianux@free.fr> wrote:
They provide ArchLinux 2009.08 in both 32 and 64 bit with their own kernel with grsecurity (2.6.31.5-grs) How well does this integrate? Arch doesn't have any officially-endorsed grsecurity kernel. Does it require userspace modifications? Have they submitted their package to Arch so the devs can look at it and check for flaws?
In general, kernel's don't need to integrate with anything, and no changes whatsoever should be necessary in userspace. The exception is when the kernel is too old to be compatible with our udev version. I build my own kernels, not via PKGBUILDs/pacman. They work fine and it's tidy too. Kernels keep to their own directories with the kernel itself a single file in /boot and modules in /lib/modules. James
Am 13.01.2010 14:31, schrieb James Rayner:
They provide ArchLinux 2009.08 in both 32 and 64 bit with their own kernel with grsecurity (2.6.31.5-grs) How well does this integrate? Arch doesn't have any officially-endorsed grsecurity kernel. Does it require userspace modifications? Have they submitted their package to Arch so the devs can look at it and check for flaws?
In general, kernel's don't need to integrate with anything, and no changes whatsoever should be necessary in userspace. The exception is when the kernel is too old to be compatible with our udev version.
I build my own kernels, not via PKGBUILDs/pacman. They work fine and it's tidy too. Kernels keep to their own directories with the kernel itself a single file in /boot and modules in /lib/modules.
That isn't entirely the point. IIRC SELinux requires lots of support in userspace, this might be the same for grsecurity. I don't know for sure what needs modification though.
On Wed, 13 Jan 2010 14:38:45 +0100 Thomas Bächler <thomas@archlinux.org> wrote:
Am 13.01.2010 14:31, schrieb James Rayner:
They provide ArchLinux 2009.08 in both 32 and 64 bit with their own kernel with grsecurity (2.6.31.5-grs) How well does this integrate? Arch doesn't have any officially-endorsed grsecurity kernel. Does it require userspace modifications? Have they submitted their package to Arch so the devs can look at it and check for flaws?
In general, kernel's don't need to integrate with anything, and no changes whatsoever should be necessary in userspace. The exception is when the kernel is too old to be compatible with our udev version.
[...]
That isn't entirely the point. IIRC SELinux requires lots of support in userspace, this might be the same for grsecurity. I don't know for sure what needs modification though.
As far as skimming their (rather old) quick install guide can tell me, grsec doesn't do much out of the box. If sysctl is enabled, *all* options have to be enabled manually. In normal unconfigured operation you probably only get some memory address randomization and the same for network ports. Some programs may not work with the memory protections and get killed instantly. the 'chpax' utility (available in aur) can circumvent this. For everything else you need the 'gradm' tool (also available in aur) which manages policies, etc. This seems to be the whole extent of required userspace support. Greetings, jinks --
Hi archers, I'm maintening stellarium-svn in AUR and I saw Stellarium 0.10.3 in [testing]. It shows qt>=4.5.1 in dependencies but this version (which doesn't seem to be very stable - several bugs with QT and GLSL - according to the mailing list) depends on qt 4.6. Here is the error output when launching : stellarium: Symbol `_ZTI15QGraphicsWidget' has different size in shared object, consider re-linking Use compilation-provided default graphics system: raster stellarium: symbol lookup error: stellarium: undefined symbol: _ZN9QListData7detach3Ev In fact I'm not using my own package for the moment (it doesn't compile anymore) since I don't have installed qt 4.6 from testing... -- radio ianux - http://ianux.fr/
2010/2/4, ianux <ianux@free.fr>:
Hi archers,
I'm maintening stellarium-svn in AUR and I saw Stellarium 0.10.3 in [testing]. It shows qt>=4.5.1 in dependencies but this version (which doesn't seem to be very stable - several bugs with QT and GLSL - according to the mailing list) depends on qt 4.6.
Hi ianux, Stellarium 0.10.3 in [testing] has been built against qt 4.6 -- Arch Linux Developer http://www.archlinux.org http://www.archlinux.it
Le 04/02/10, Giovanni Scafora <giovanni@archlinux.org> a écrit :
2010/2/4, ianux <ianux@free.fr>:
Hi archers,
I'm maintening stellarium-svn in AUR and I saw Stellarium 0.10.3 in [testing]. It shows qt>=4.5.1 in dependencies but this version (which doesn't seem to be very stable - several bugs with QT and GLSL - according to the mailing list) depends on qt 4.6.
Hi ianux,
Stellarium 0.10.3 in [testing] has been built against qt 4.6
yes indeed, it's mandatory to use - and compile - stellarium 0.10.3 with qt 4.6 but packages from testing requires qt>=4.5.1, so enabling [testing] in pacman.conf and doing pacman -S stellarium doesn't upgrade qt since qt 4.5.3 (>=4.5.1) is already in extra, which leads to broken binary. I'm just saying that stellarium PKGBUILD from [testing] MUST mention qt>=4.6 -- radio ianux - http://ianux.fr/
On 02/05/2010 12:41 AM, ianux wrote:
Le 04/02/10, Giovanni Scafora<giovanni@archlinux.org> a écrit :
2010/2/4, ianux<ianux@free.fr>:
Hi archers,
I'm maintening stellarium-svn in AUR and I saw Stellarium 0.10.3 in [testing]. It shows qt>=4.5.1 in dependencies but this version (which doesn't seem to be very stable - several bugs with QT and GLSL - according to the mailing list) depends on qt 4.6.
Hi ianux,
Stellarium 0.10.3 in [testing] has been built against qt 4.6
yes indeed, it's mandatory to use - and compile - stellarium 0.10.3 with qt 4.6 but packages from testing requires qt>=4.5.1, so enabling [testing] in pacman.conf and doing pacman -S stellarium doesn't upgrade qt since qt 4.5.3 (>=4.5.1) is already in extra, which leads to broken binary. I'm just saying that stellarium PKGBUILD from [testing] MUST mention qt>=4.6
but still the only supported way is to fully update from testing and not cherry picking. -- Ionut
On Sat, Jan 02, 2010 at 11:38:33AM -0700, Steve Holmes wrote:
When I installed grub2 a short while back, I was using the kernel 2.6.31.6 and I enjoyed a full screen of 1024.768 32K color depth. I followed the steps outlined here <http://wiki.archlinux.org/index.php/GRUB2#Setting_the_framebuffer_resolution> to the letter and all was great.
But when the kernel26 package upgraded to 2.6.32.2, This functionality broke. I ended up having to remove the video related stuff from my grub line to get my system to boot. When I say this didn't work anymore, basically my system wouldn't boot and I end up with a blank screen showing.
When I experimented by removing the insmod statement and using vga=790 by itself, the best I get is a 30 line display with 80 columns width.
Anyone know what changed? It would appear that we may need to update the wiki page with new info for grub2 and video resolution.
KMS conflicts with vga,video. What GPU do you have ?
On Sat, Jan 02, 2010 at 09:25:33PM +0200, arch@nezmer.info wrote:
On Sat, Jan 02, 2010 at 11:38:33AM -0700, Steve Holmes wrote:
When I installed grub2 a short while back, I was using the kernel 2.6.31.6 and I enjoyed a full screen of 1024.768 32K color depth. I followed the steps outlined here <http://wiki.archlinux.org/index.php/GRUB2#Setting_the_framebuffer_resolution> to the letter and all was great.
But when the kernel26 package upgraded to 2.6.32.2, This functionality broke. I ended up having to remove the video related stuff from my grub line to get my system to boot. When I say this didn't work anymore, basically my system wouldn't boot and I end up with a blank screen showing.
When I experimented by removing the insmod statement and using vga=790 by itself, the best I get is a 30 line display with 80 columns width.
Anyone know what changed? It would appear that we may need to update the wiki page with new info for grub2 and video resolution.
KMS conflicts with vga,video. What GPU do you have ? I meant vga,vesa.
On 01/02/2010 12:29 PM, arch@nezmer.info wrote:
KMS conflicts with vga,video. What GPU do you have ?
I have a generic mother boasrd with an AMD Athlon64 K8 1.6 Ghz processor and a Via Technologies VGA compatible controler. This info came to me courtesy of the lsmod command.:) But I did some more digging and I got my full screen back. I had previously commented out the via line in /etc/modprobe.d/frame-buffer-blacklist.conf. So I re-enabled that entry by removing the # mark, put the 'insmod vbe' back in my grub.cfg and retained the vga=790 entry in the linux entry. After doing all that, my higher resolution is working again. I don't seem to have much if any background information to support what I'm doing with FB support but I like having the higher resolution. It would be nice to have a fuller understanding of which modules are needed and which kernel parameters should still be used. Anyway, thanks for indulging in my experimentation and messing about.
participants (11)
-
Alexander Duscheleit
-
arch＠nezmer.info
-
Chuck Hallenbeck
-
Daenyth Blank
-
Giovanni Scafora
-
Heiko Baums
-
ianux
-
Ionut Biru
-
James Rayner
-
Steve Holmes
-
Thomas Bächler