[opensuse-factory] Drop grub1 support from yast2-bootloader

older
[opensuse-factory] 13.2 networking...

Josef Reidinger

11 Aug 2014 11 Aug '14

13:13

Hi geekos, I plan to implement https://features.opensuse.org/317700. What it is and why we need it? In general grub1 and grub2 configuration is almost completely different, which makes yast2-bootloader life hard as it contain two almost separated parts, which we need to maintain and we have a lot of bug reports which we cannot handle about various misconfiguration. We focused on fixing stuff for grub2 to work for everyone, but grub1 stuff still make quite a lot of mess in code. So I plan to do some cleaning in yast2-bootloader and also simplify how it works to make maintenance and new features easier to born ( like quite nice direct boot from encrypted LVM ). Such simplify should contain also complete drop of grub1 support. Of course we allow usage of such bootloader, just you cannot use yast2-bootloader to configure it. In installation you can simply choose "none" bootloader and configure it manually as you want, same way as you can use old lilo or anything else. Our goal for yast2-bootloader is to have tool that create working boot configuration for everyone ( everyone from technical side of view, for different storage configuration and different hardware, not to support all personal requirements ). So I would like to ask if anyone have troubles with grub2, that grub2 cannot be used for his hardware or storage setup, so we can handle it before I did it. If anyone is interested in maintaining yast2-bootloader for grub1, I can create splitted package, that handle only grub1 configuration ( but I do not do it unless there is serious maintainer as it is additional work for me ). Josef -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Show replies by date

Richard Brown

11 Aug 11 Aug

13:31

On 11 August 2014 15:13, Josef Reidinger wrote:

...

Hi geekos, I plan to implement https://features.opensuse.org/317700. What it is and why we need it? In general grub1 and grub2 configuration is almost completely different, which makes yast2-bootloader life hard as it contain two almost separated parts, which we need to maintain and we have a lot of bug reports which we cannot handle about various misconfiguration. We focused on fixing stuff for grub2 to work for everyone, but grub1 stuff still make quite a lot of mess in code. So I plan to do some cleaning in yast2-bootloader and also simplify how it works to make maintenance and new features easier to born ( like quite nice direct boot from encrypted LVM ). Such simplify should contain also complete drop of grub1 support. Of course we allow usage of such bootloader, just you cannot use yast2-bootloader to configure it. In installation you can simply choose "none" bootloader and configure it manually as you want, same way as you can use old lilo or anything else.

Our goal for yast2-bootloader is to have tool that create working boot configuration for everyone ( everyone from technical side of view, for different storage configuration and different hardware, not to support all personal requirements ). So I would like to ask if anyone have troubles with grub2, that grub2 cannot be used for his hardware or storage setup, so we can handle it before I did it.

If anyone is interested in maintaining yast2-bootloader for grub1, I can create splitted package, that handle only grub1 configuration ( but I do not do it unless there is serious maintainer as it is additional work for me ).

Josef --

FWIW - I have only used Grub2 since it's become an option in openSUSE. It's worked without issue on all my hardware, including some pretty exotic stuff. So, from my perspective, +1 to the idea of dropping Grub1 support from yast-bootloader -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Guido Berhoerster

13:47

* Josef Reidinger [2014-08-11 15:13]:

...

Hi geekos, I plan to implement https://features.opensuse.org/317700. What it is and why we need it? In general grub1 and grub2 configuration is almost completely different, which makes yast2-bootloader life hard as it contain two almost separated parts, which we need to maintain and we have a lot of bug reports which we cannot handle about various misconfiguration. We focused on fixing stuff for grub2 to work for everyone, but grub1 stuff still make quite a lot of mess in code. So I plan to do some cleaning in yast2-bootloader and also simplify how it works to make maintenance and new features easier to born ( like quite nice direct boot from encrypted LVM ). Such simplify should contain also complete drop of grub1 support. Of course we allow usage of such bootloader, just you cannot use yast2-bootloader to configure it. In installation you can simply choose "none" bootloader and configure it manually as you want, same way as you can use old lilo or anything else.

Our goal for yast2-bootloader is to have tool that create working boot configuration for everyone ( everyone from technical side of view, for different storage configuration and different hardware, not to support all personal requirements ). So I would like to ask if anyone have troubles with grub2, that grub2 cannot be used for his hardware or storage setup, so we can handle it before I did it.

If anyone is interested in maintaining yast2-bootloader for grub1, I can create splitted package, that handle only grub1 configuration ( but I do not do it unless there is serious maintainer as it is additional work for me ).

What about TrustedGRUB support? AFAIK it is a fork of GRUB1 (as the GRUB2 developers have some crazy attitudes towards TC) and it is the only bootloader which can take advantage of a TPM to grant the integrity of the boot process from BIOS into the OS. -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Josef Reidinger

14:11

On Mon, 11 Aug 2014 15:47:53 +0200 Guido Berhoerster wrote:

...

* Josef Reidinger [2014-08-11 15:13]:

...
Hi geekos, I plan to implement https://features.opensuse.org/317700. What it is and why we need it? In general grub1 and grub2 configuration is almost completely different, which makes yast2-bootloader life hard as it contain two almost separated parts, which we need to maintain and we have a lot of bug reports which we cannot handle about various misconfiguration. We focused on fixing stuff for grub2 to work for everyone, but grub1 stuff still make quite a lot of mess in code. So I plan to do some cleaning in yast2-bootloader and also simplify how it works to make maintenance and new features easier to born ( like quite nice direct boot from encrypted LVM ). Such simplify should contain also complete drop of grub1 support. Of course we allow usage of such bootloader, just you cannot use yast2-bootloader to configure it. In installation you can simply choose "none" bootloader and configure it manually as you want, same way as you can use old lilo or anything else.

Our goal for yast2-bootloader is to have tool that create working boot configuration for everyone ( everyone from technical side of view, for different storage configuration and different hardware, not to support all personal requirements ). So I would like to ask if anyone have troubles with grub2, that grub2 cannot be used for his hardware or storage setup, so we can handle it before I did it.

If anyone is interested in maintaining yast2-bootloader for grub1, I can create splitted package, that handle only grub1 configuration ( but I do not do it unless there is serious maintainer as it is additional work for me ).

What about TrustedGRUB support? AFAIK it is a fork of GRUB1 (as the GRUB2 developers have some crazy attitudes towards TC) and it is the only bootloader which can take advantage of a TPM to grant the integrity of the boot process from BIOS into the OS.

Well, I worry, that also trusted grub need to be done manually as grub2 do not support it ( so same as grub1 or lilo ). Better side is that users who need trustedgrub are paranoic enough to not use GUI tool to configure something and do it on their own ;) Josef -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Felix Miata

17:32

On 2014-08-11 15:13 (GMT+0200) Josef Reidinger composed:

...

Our goal for yast2-bootloader is to have tool that create working boot configuration for everyone ( everyone from technical side of view, for different storage configuration and different hardware, not to support all personal requirements ).

I don't see "working ... for everyone" as realistic as long as upstream policy remains in conflict with neutral MBR policy. Choosing to install to a partition with Grub2 as neutral MBR necessarily requires carries unavoidable frightening warnings that non-astute users should not have to ever be confronted by. Yast may be able to shield users from such warnings, but only when Yast is actually available at those all too frequent repair times that show up in support forums.

...

So I would like to ask if anyone have troubles with grub2, that grub2 cannot be used for his hardware or storage setup, so we can handle it before I did it.

I can't comprehensively answer that, because I refuse to use Grub2 on openSUSE installations. What I can say is those messages produced by Grub2 when vga= is included on cmdline and when installing Grub2 to a partition are themselves troubling just to have to see. As long as vga= does what it needs to do, no one should have to be warned about its deprecation on every boot. The only installations here that have Grub2 installed are my few *buntus, all of which either get chainloaded to (producing ugly ttys and boot messages), or get booted via a(n openSUSE) Grub Legacy on a non-root/non-boot partition (with sometimes better tty results, depending on the actual installation configuration). All other distros that have no Grub Legacy installation option get installed sans bootloader. That's not a problem on my own systems, just a nuisance that already means fewer test installations of Factory will get done here. What it does mean is I have to seriously consider looking elsewhere for installations I do on others' computers. For the foreseeable post-13.1 support future that appears would be Mageia, which has already been my second choice distro for some time, and still last I checked by installing Cauldron defaults to Grub Legacy instead of Grub2. The radical differences between the two Grubs make it easy to understand the desire to divorce maintenance of them both under the same package umbrella. I can only wish there will be found a maintainer for a separated Grub Legacy Yast bootloader package. Long term, UEFI will replace BIOS booting. In that world, I don't see the complicated and less friendly relative monster that is the Grub2 some of us now know making better sense to keep in distro and sync'd to Yast for the few remaining functional BIOS systems than Grub Legacy. Let it not remain unsaid that a substantial change like this ought to be made early as possible in a development cycle, not on the cusp of base system freeze. Now is a wrong time to do it, if it must be done at all. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Josef Reidinger

12 Aug 12 Aug

06:54

On Mon, 11 Aug 2014 13:32:08 -0400 Felix Miata wrote:

...

On 2014-08-11 15:13 (GMT+0200) Josef Reidinger composed:

...
Our goal for yast2-bootloader is to have tool that create working boot configuration for everyone ( everyone from technical side of view, for different storage configuration and different hardware, not to support all personal requirements ).

I don't see "working ... for everyone" as realistic as long as upstream policy remains in conflict with neutral MBR policy. Choosing to install to a partition with Grub2 as neutral MBR necessarily requires carries unavoidable frightening warnings that non-astute users should not have to ever be confronted by. Yast may be able to shield users from such warnings, but only when Yast is actually available at those all too frequent repair times that show up in support forums.

I think that we support almost all cases to not install to MBR if it is not needed. We use generic boot code and install to partition. Only exception is md raid, where even for raid1 we need to install to MBR. In other cases and even for xfs we allow install to PBR.

...

...
So I would like to ask if anyone have troubles with grub2, that grub2 cannot be used for his hardware or storage setup, so we can handle it before I did it.

I can't comprehensively answer that, because I refuse to use Grub2 on openSUSE installations. What I can say is those messages produced by Grub2 when vga= is included on cmdline and when installing Grub2 to a partition are themselves troubling just to have to see. As long as vga= does what it needs to do, no one should have to be warned about its deprecation on every boot.

It is deprecation warning, yast2-bootloader sets new option there instead of vga one.

...

The only installations here that have Grub2 installed are my few *buntus, all of which either get chainloaded to (producing ugly ttys and boot messages), or get booted via a(n openSUSE) Grub Legacy on a non-root/non-boot partition (with sometimes better tty results, depending on the actual installation configuration). All other distros that have no Grub Legacy installation option get installed sans bootloader. That's not a problem on my own systems, just a nuisance that already means fewer test installations of Factory will get done here.

Well, old grub have problems that it is no longer developed, so e.g. some new features like btrfs and booting its snapshots missing, so there is no option to focus only on grub1.

...

What it does mean is I have to seriously consider looking elsewhere for installations I do on others' computers. For the foreseeable post-13.1 support future that appears would be Mageia, which has already been my second choice distro for some time, and still last I checked by installing Cauldron defaults to Grub Legacy instead of Grub2.

It is your choice. Linux is about freedom to choose what fits your needs.

...

The radical differences between the two Grubs make it easy to understand the desire to divorce maintenance of them both under the same package umbrella. I can only wish there will be found a maintainer for a separated Grub Legacy Yast bootloader package.

Anyone can step up. He(she) just need to really work on it.

...

Long term, UEFI will replace BIOS booting. In that world, I don't see the complicated and less friendly relative monster that is the Grub2 some of us now know making better sense to keep in distro and sync'd to Yast for the few remaining functional BIOS systems than Grub Legacy.

I still see even for big disks, that some users use BIOS boot even with GPT for big disks. So we will see what is future of booting. I think BIOS booting is still not minor one.

...

Let it not remain unsaid that a substantial change like this ought to be made early as possible in a development cycle, not on the cusp of base system freeze. Now is a wrong time to do it, if it must be done at all.

Well, opensuse release cycle and milestones is not much clear for me, so it is hard to say when it is right time. I now see that some milestone was decided, so I would like to do it before this milestone. Josef -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Felix Miata

07:10

On 2014-08-12 08:54 (GMT+0200) Josef Reidinger composed:

...

...
those messages produced by Grub2 when vga= is included on cmdline and when installing Grub2 to a partition are themselves troubling just to have to see. As long as vga= does what it needs to do, no one should have to be warned about its deprecation on every boot.

...

It is deprecation warning, yast2-bootloader sets new option there instead of vga one.

SiS and mga chips and other legacy chips are not affected by including video= on cmdline because there is no KMS support for them. Only KMS responds to video=. Only vga= can specify video mode on ttys for KMS-unsupported gfxchips. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Josef Reidinger

07:19

On Tue, 12 Aug 2014 03:10:28 -0400 Felix Miata wrote:

...

On 2014-08-12 08:54 (GMT+0200) Josef Reidinger composed:

...
...
those messages produced by Grub2 when vga= is included on cmdline and when installing Grub2 to a partition are themselves troubling just to have to see. As long as vga= does what it needs to do, no one should have to be warned about its deprecation on every boot.

...
It is deprecation warning, yast2-bootloader sets new option there instead of vga one.

SiS and mga chips and other legacy chips are not affected by including video= on cmdline because there is no KMS support for them. Only KMS responds to video=. Only vga= can specify video mode on ttys for KMS-unsupported gfxchips.

gfxpayload for not help in such case? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Felix Miata

08:02

On 2014-08-12 09:19 (GMT+0200) Josef Reidinger composed:

...

...
...
It is deprecation warning, yast2-bootloader sets new option there instead of vga one.

...

...
SiS and mga chips and other legacy chips are not affected by including video= on cmdline because there is no KMS support for them. Only KMS responds to video=. Only vga= can specify video mode on ttys for KMS-unsupported gfxchips.

...

gfxpayload for not help in such case?

What I do know is vga= not only still works, but also it's nice and short, a pleasure to use on cmdlines already swollen by multiple instances of UUIDs and/or device IDs plus the long-winded other options not in existence or needed before Grub2. I've never been able to grok and retain man page explanation how to use /etc/default/grub's non-intuitive similar video options GRUB_GFXMODE, GRUB_GFXPAYLOAD_LINUX, GRUB_TERMINAL, GRUB_CMDLINE_LINUX, GRUB_CMDLINE_LINUX_DEFAULT et al for configuring Grub2 cmdline for video. It's nice if yast2 understands how it all plays together, but that's little comfort for a user familiar with Grub Legacy's shell prompt interactive editing of a stanza, looking instead at a Grub2 edit menu trying to interactively tweak the much more complex Grub2 stanza. If Grub Legacy must go, it should at the same time be replaced by something that also embraces KISS principle favored by many. Grub2's complexity is unlikely to ever to fill such a role, unlike Syslinux/Extlinux, or Grub Legacy. A Yast installation menu choice only between Grub2 and install no bootloader at all is very sad, very much narrowing the gap between what has historically been the best Linux installer around, and the also-rans from other distros. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Josef Reidinger

09:41

On Tue, 12 Aug 2014 04:02:53 -0400 Felix Miata wrote:

...

On 2014-08-12 09:19 (GMT+0200) Josef Reidinger composed:

...
...
...
It is deprecation warning, yast2-bootloader sets new option there instead of vga one.

...
...
SiS and mga chips and other legacy chips are not affected by including video= on cmdline because there is no KMS support for them. Only KMS responds to video=. Only vga= can specify video mode on ttys for KMS-unsupported gfxchips.

...
gfxpayload for not help in such case?

What I do know is vga= not only still works, but also it's nice and short, a pleasure to use on cmdlines already swollen by multiple instances of UUIDs and/or device IDs plus the long-winded other options not in existence or needed before Grub2.

Reason is simple majority of people found gfxmode=1280x800 better then having vga=791 which is easier to read and understand. So it is pleasure for people who is already familiar with it, but for newcomers it is easier to use new syntax.

...

I've never been able to grok and retain man page explanation how to use /etc/default/grub's non-intuitive similar video options GRUB_GFXMODE, GRUB_GFXPAYLOAD_LINUX, GRUB_TERMINAL, GRUB_CMDLINE_LINUX, GRUB_CMDLINE_LINUX_DEFAULT et al for configuring Grub2 cmdline for video. It's nice if yast2 understands how it all plays together, but that's little comfort for a user familiar with Grub Legacy's shell prompt interactive editing of a stanza, looking instead at a Grub2 edit menu trying to interactively tweak the much more complex Grub2 stanza.

Well, vga is deprecated, but still works, so you can use until it is removed. I think there is enough tutorials and documents if you google around "grub2 gfxmode"

...

If Grub Legacy must go, it should at the same time be replaced by something that also embraces KISS principle favored by many. Grub2's complexity is unlikely to ever to fill such a role, unlike Syslinux/Extlinux, or Grub Legacy. A Yast installation menu choice only between Grub2 and install no bootloader at all is very sad, very much narrowing the gap between what has historically been the best Linux installer around, and the also-rans from other distros.

Problem is that current hardware no longer followed KISS and for your side GRUB looks like KISS, but from yast side grub is really complex stuff to be configured correctly. And we are alone for such task, now some low level stuff is moved to grub2, so such low level stuff is handled by grub maintainer which share work with other distributions. YaST then can focus on more important tasks like proposing working configuration in corner cases so everyone can boot his machine. JFYI I create list of supported boot scenarios (still in review) which can give you idea how hard task it is to propose correct bootloader configuration: https://github.com/yast/yast-bootloader/blob/supported_scenarios/SUPPORTED_S... -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

David Haller

17 Aug 17 Aug

18:48

Hello, On Tue, 12 Aug 2014, Felix Miata wrote:

...

SiS and mga chips and other legacy chips are not affected by including video= on cmdline because there is no KMS support for them. Only KMS responds to video=. Only vga= can specify video mode on ttys for KMS-unsupported gfxchips.

Nope. Matrox Mystique and others respond to "video". From one of the later lilo.conf's I used: image = /boot/bzImage-2.4.25-1 append="video=matrox:vesa:789 ..." I did use XFree 3.3.6 there though, I think, but the above is the kernel matroxfb driver I compiled in those kernels. # zgrep MATROX /proc/config.gz CONFIG_W1_MASTER_MATROX=m CONFIG_FB_MATROX=m CONFIG_FB_MATROX_MILLENIUM=y CONFIG_FB_MATROX_MYSTIQUE=y CONFIG_FB_MATROX_G=y # uname -r 3.1.10-1.29-default See /usr/src/linux/Documentation/fb/matroxfb.txt and most of the others: grep -l video= /usr/src/linux/Documentation/fb/* e.g. /usr/src/linux/Documentation/fb/intelfb.txt video=intelfb:option1,option2=value2 FWIW, -dnh -- I'm going to a meeting...? I'd bore myself to death -- if I weren't already dead. -- Georgia 'George' L. Lass, Dead Like Me -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Felix Miata

21:47

New subject: [opensuse-factory] non-KMS gfxchip framebuffer config (was: Drop grub1 support...)

On 2014-08-17 20:48 (GMT+0200) David Haller composed:

...

On Tue, 12 Aug 2014, Felix Miata wrote:

...

...
SiS and mga chips and other legacy chips are not affected by including video= on cmdline because there is no KMS support for them. Only KMS responds to video=. Only vga= can specify video mode on ttys for KMS-unsupported gfxchips.

...

Nope. Matrox Mystique and others respond to "video". From one of the later lilo.conf's I used:

...

image = /boot/bzImage-2.4.25-1 append="video=matrox:vesa:789 ..."

...

I did use XFree 3.3.6 there though, I think, but the above is the kernel matroxfb driver I compiled in those kernels.

...

# zgrep MATROX /proc/config.gz CONFIG_W1_MASTER_MATROX=m CONFIG_FB_MATROX=m CONFIG_FB_MATROX_MILLENIUM=y CONFIG_FB_MATROX_MYSTIQUE=y CONFIG_FB_MATROX_G=y # uname -r 3.1.10-1.29-default

...

See /usr/src/linux/Documentation/fb/matroxfb.txt and most of the others: grep -l video= /usr/src/linux/Documentation/fb/* e.g. /usr/src/linux/Documentation/fb/intelfb.txt video=intelfb:option1,option2=value2

I've never been able to get matroxfb to work on any distro with any kernel. What I wrote is WRT people who do not build the software they use themselves, installing from DVD or HTTP, those who have no practical use for source code, those who find from the higher profile docs that the standard meaning of video= with KMS kernels does not work. This is the scenrio with "current" software (13.1): # lspci | grep VGA 01:00.0 VGA compatible controller: Matrox Electronics Systems Ltd. MGA G400/G450 (rev 04) # hwinfo --gfxcard 18: PCI(AGP) 100.0: 0300 VGA compatible controller (VGA) [Created at pci.319] Unique ID: VCu0.iS5svn0wnIC Parent ID: vSkL.Wu+t1nTm_x2 SysFS ID: /devices/pci0000:00/0000:00:01.0/0000:01:00.0 SysFS BusID: 0000:01:00.0 Hardware Class: graphics card Model: "Matrox Millennium G400 16Mb SGRAM" Vendor: pci 0x102b "Matrox Graphics, Inc." Device: pci 0x0525 "MGA G400 AGP" SubVendor: pci 0x102b "Matrox Graphics, Inc." SubDevice: pci 0x19d8 "Millennium G400 16Mb SGRAM" Revision: 0x04 Memory Range: 0xf4000000-0xf5ffffff (ro,non-prefetchable) Memory Range: 0xfcffc000-0xfcffffff (rw,non-prefetchable) Memory Range: 0xfc000000-0xfc7fffff (rw,non-prefetchable) Memory Range: 0xfc800000-0xfc80ffff (ro,non-prefetchable,disabled) IRQ: 7 (no events) I/O Ports: 0x3c0-0x3df (rw) Module Alias: "pci:v0000102Bd00000525sv0000102Bsd000019D8bc03sc00i00" Driver Info #0: XFree86 v4 Server Module: mga Driver Info #1: XFree86 v4 Server Module: mga 3D Support: yes Extensions: dri Config Status: cfg=no, avail=yes, need=no, active=unknown Attached to: #10 (PCI bridge) Primary display adapter: #18 # egrep 'ware Rev | Matrox' /var/log/Xorg.0.log [ 167.435] (II) MGA: driver for Matrox chipsets: mga2064w, mga1064sg, mga2164w, [ 168.710] (II) MGA(0): VESA VBE OEM: Matrox Graphics Inc. [ 168.710] (II) MGA(0): VESA VBE OEM Software Rev: 2.1 [ 168.710] (II) MGA(0): VESA VBE OEM Vendor: Matrox [ 168.710] (II) MGA(0): VESA VBE OEM Product: Matrox G400 # grep PRETTY /etc/*lease /etc/os-release:PRETTY_NAME="openSUSE 13.1 (Bottle) (i586)" # uname -a Linux gx150 3.12.22-1.g3f06f02-desktop #1 SMP PREEMPT Fri Jun 20 16:06:47 UTC 2014 (3f06f02) i686 i686 i386 GNU/Linux # dmesg | grep matrox [ 0.000000] Kernel command line: root=LABEL=S12Asuse131 ipv6.disable=1 noresume splash=verbose video=matrox:vesa:789 3 # zgrep /proc/config.gz CONFIG_W1_MASTER_MATROX=m CONFIG_FB_MATROX=m CONFIG_FB_MATROX_MILLENIUM=y CONFIG_FB_MATROX_MYSTIQUE=y CONFIG_FB_MATROX_G=y CONFIG_FB_MATROX_I2C=m CONFIG_FB_MATROX_MAVEN=m # fbset open /dev/fb0: No such file or directory Booting with vga=791 instead of any video= does product expected VESA compatible output: # fbset mode "1024x768-76" # D: 78.653 MHz, H: 59.949 kHz, V: 75.694 Hz geometry 1024 768 1024 768 16 timings 12714 128 32 16 4 128 4 rgba 5/11,6/5,5/0,0/0 endmode It's the same with G550, and I assume with G200, which as PCI only here I haven't checked on in quite some time. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

David Haller

18 Aug 18 Aug

00:34

New subject: [opensuse-factory] non-KMS gfxchip framebuffer config (was: Drop grub1 support...)

Hello, On Sun, 17 Aug 2014, Felix Miata wrote:

...

On 2014-08-17 20:48 (GMT+0200) David Haller composed:

...
On Tue, 12 Aug 2014, Felix Miata wrote:

...
SiS and mga chips and other legacy chips are not affected by including video= on cmdline because there is no KMS support for them. Only KMS responds to video=. Only vga= can specify video mode on ttys for KMS-unsupported gfxchips.

...
Nope. Matrox Mystique and others respond to "video". From one of the later lilo.conf's I used:

...
image = /boot/bzImage-2.4.25-1 append="video=matrox:vesa:789 ..." [..] I've never been able to get matroxfb to work on any distro with any kernel.

Weird.

...

# lspci | grep VGA 01:00.0 VGA compatible controller: Matrox Electronics Systems Ltd. MGA G400/G450 (rev 04) [..] # dmesg | grep matrox [ 0.000000] Kernel command line: root=LABEL=S12Asuse131 ipv6.disable=1 noresume splash=verbose video=matrox:vesa:789 3

0x115 = 789 (-512). That should result in 800x600x32bpp according to /usr/src/linux/Documentation/fb/matroxfb.txt Which should look rather similar to what you're used to without "video=", you might not notice the difference (depending on other options for grub/kernel). [..]

...

Booting with vga=791 instead of any video= does product expected VESA compatible output:

# fbset mode "1024x768-76" # D: 78.653 MHz, H: 59.949 kHz, V: 75.694 Hz geometry 1024 768 1024 768 16 timings 12714 128 32 16 4 128 4 rgba 5/11,6/5,5/0,0/0 endmode

That fits. 791-512 = 0x117 which is: 1024x768x16bpp according to (s.a). Depending on your monitor, try e.g. video:matrox:vesa:795 which should give you 1280x1024x32bpp. See matroxfb.txt for further modes. I prefer to use the "+512 (dec)" modes, so I don't confuse them with the "plain" Vesa modes[1]. You can use those too. But remember, that lilo (dunno about grub) cannot translate hex-parms into decimals or whatever the kernel wants. Be safe and use the decimal parms. Sadly, matroxfb does not seem to have a debug option. BTW: I loved my Mystique (the big original one with 4 MB and 170MHz RAMDAC). Just a naked chip on the board :)) Not even a cooler. Specced to ~4.5W max IIRC according to the V/A in the specs. Well, now I have a GT610, that's noticeably faster with e.g. Descent2 and other games ;) (actually: D2x was "unplayable" until I upgraded from the Mystique to a Nvidia 7600GS). But the main reason actually was that the Mystique did not support resolutions above 1024x768 at a decent refresh rate / bit depth. Even if I'm still at just a "mere" 1280x1024 on an 17" screen (I could add a second screen with those specs, I'm too lazy to unpack that other screen though (I switched with my mom, my good second screen to her crap one as her primary, and thus far, I had no need to connect the latter as my secondary ;)). HTH, -dnh [1] if you can boot cleanly with e.g. 791, you're sure to use matroxfb and not vesafb, as the latter does not support those +512 mode specs, in the case of 791 just 279 i.e. 0x117. -- I am the "ILOVEGNU" signature virus. Just copy me to your signature. This message was infected under the terms of the GNU General Public License. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Stefan Seyfried

12 Aug 12 Aug

13:14

Am 11.08.2014 um 15:13 schrieb Josef Reidinger:

...

Such simplify should contain also complete drop of grub1 support.

I'm fine with that, even though I'll certainly try to avoid grub2 like the plague (my favorite being syslinux for now :-))

...

Of course we allow usage of such bootloader, just you cannot use yast2-bootloader to configure it. In installation you can simply choose "none" bootloader and configure it manually as you want, same way as you can use old lilo or anything else.

It would be cool if during installation there was a hint that using "none" presents you later with a shell or something allowing you to configure the boot loader on your own. I was doing a factory install yesterday and only had the option "grub2" or "none" and I was under the impression that choosing "none" was not a good idea, so I installed grub2 even though I really did not want to :-) -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Mike Galbraith

13:39

On Tue, 2014-08-12 at 15:14 +0200, Stefan Seyfried wrote:

...

Am 11.08.2014 um 15:13 schrieb Josef Reidinger:

...
Such simplify should contain also complete drop of grub1 support.

I'm fine with that, even though I'll certainly try to avoid grub2 like the plague (my favorite being syslinux for now :-))

Ew. I'd rather not contemplate grub2 with my (counts) 48 kernels :) -Mike -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Roman Bysh

19:10

On 08/12/2014 09:14 AM, Stefan Seyfried wrote:

...

Am 11.08.2014 um 15:13 schrieb Josef Reidinger:

...
Such simplify should contain also complete drop of grub1 support.

I'm fine with that, even though I'll certainly try to avoid grub2 like the plague (my favorite being syslinux for now :-))

...
Of course we allow usage of such bootloader, just you cannot use yast2-bootloader to configure it. In installation you can simply choose "none" bootloader and configure it manually as you want, same way as you can use old lilo or anything else.

It would be cool if during installation there was a hint that using "none" presents you later with a shell or something allowing you to configure the boot loader on your own. I was doing a factory install yesterday and only had the option "grub2" or "none" and I was under the impression that choosing "none" was not a good idea, so I installed grub2 even though I really did not want to :-)

Having a Grub1 shell is very helpful. Rather using none, please also add alternate. None means no bootloader. It would be helpful if a Grub1 template was provided. Can it be added to the help button. - Cheers! Roman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Josef Reidinger

13 Aug 13 Aug

05:39

On Tue, 12 Aug 2014 15:10:13 -0400 Roman Bysh wrote:

...

On 08/12/2014 09:14 AM, Stefan Seyfried wrote:

...
Am 11.08.2014 um 15:13 schrieb Josef Reidinger:

...
Such simplify should contain also complete drop of grub1 support.

I'm fine with that, even though I'll certainly try to avoid grub2 like the plague (my favorite being syslinux for now :-))

...
Of course we allow usage of such bootloader, just you cannot use yast2-bootloader to configure it. In installation you can simply choose "none" bootloader and configure it manually as you want, same way as you can use old lilo or anything else.

It would be cool if during installation there was a hint that using "none" presents you later with a shell or something allowing you to configure the boot loader on your own. I was doing a factory install yesterday and only had the option "grub2" or "none" and I was under the impression that choosing "none" was not a good idea, so I installed grub2 even though I really did not want to :-)

Having a Grub1 shell is very helpful.

Rather using none, please also add alternate. None means no bootloader. It would be helpful if a Grub1 template was provided. Can it be added to the help button.

Alternate do not help much with cleaning our yast2-bootloader code. For grub1 you need to have own section management, own os prober and also own smart translation between kernel devices and grub devices. I do not understand what you mean with grub1 template, maybe add how to install other bootloaders to help? Josef

...

- Cheers!

Roman

-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Michal Kubecek

12 Aug 12 Aug

20:26

On Mon, Aug 11, 2014 at 03:13:09PM +0200, Josef Reidinger wrote:

...

Our goal for yast2-bootloader is to have tool that create working boot configuration for everyone ( everyone from technical side of view, for different storage configuration and different hardware, not to support all personal requirements ). So I would like to ask if anyone have troubles with grub2, that grub2 cannot be used for his hardware or storage setup, so we can handle it before I did it.

I checked now and on my machine, yast2-bootloader is still unable to setup bootloader with GRUB2 ("warning: this GPT partition label contains no BIOS Boot Partition; embedding won't be possible." / "error: embedding is not possible, but this is required for RAID and LVM install.") With GRUB, everything is configured without complaint and works perfectly. The only progress I have seen so far is the complaint about GPT without BIOS boot partition. Before, it just said that ebmedding is not possible and it cannot setup the bootloader without it. Michal Kubeček -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Andrey Borzenkov

13 Aug 13 Aug

02:42

В Tue, 12 Aug 2014 22:26:40 +0200 Michal Kubecek пишет:

...

On Mon, Aug 11, 2014 at 03:13:09PM +0200, Josef Reidinger wrote:

...
Our goal for yast2-bootloader is to have tool that create working boot configuration for everyone ( everyone from technical side of view, for different storage configuration and different hardware, not to support all personal requirements ). So I would like to ask if anyone have troubles with grub2, that grub2 cannot be used for his hardware or storage setup, so we can handle it before I did it.

I checked now and on my machine, yast2-bootloader is still unable to setup bootloader with GRUB2 ("warning: this GPT partition label contains no BIOS Boot Partition; embedding won't be possible." / "error: embedding is not possible, but this is required for RAID and LVM install.") With GRUB, everything is configured without complaint and works perfectly.

Do you know details how grub legacy handled this configuration? I.e. where it installed stage1 and stage1.5 (or stage2)?

...

The only progress I have seen so far is the complaint about GPT without BIOS boot partition. Before, it just said that ebmedding is not possible and it cannot setup the bootloader without it.

Michal Kubeček

-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Michael Chang

03:19

On Wed, Aug 13, 2014 at 06:42:02AM +0400, Andrey Borzenkov wrote:

...

В Tue, 12 Aug 2014 22:26:40 +0200 Michal Kubecek пишет:

...
On Mon, Aug 11, 2014 at 03:13:09PM +0200, Josef Reidinger wrote:

...
Our goal for yast2-bootloader is to have tool that create working boot configuration for everyone ( everyone from technical side of view, for different storage configuration and different hardware, not to support all personal requirements ). So I would like to ask if anyone have troubles with grub2, that grub2 cannot be used for his hardware or storage setup, so we can handle it before I did it.

I checked now and on my machine, yast2-bootloader is still unable to setup bootloader with GRUB2 ("warning: this GPT partition label contains no BIOS Boot Partition; embedding won't be possible." / "error: embedding is not possible, but this is required for RAID and LVM install.") With GRUB, everything is configured without complaint and works perfectly.

Do you know details how grub legacy handled this configuration? I.e. where it installed stage1 and stage1.5 (or stage2)?

My understanding is YaST would create separate /boot partition and wrote stage1 on boot partition. Then it would wrote gptmbr from syslinux to mbr to chainload boot. The diret LVM booting scenario (ie without boot partition) never worked for legacy grub regardless msdos or gpt table. regards, Michael

...

...
The only progress I have seen so far is the complaint about GPT without BIOS boot partition. Before, it just said that ebmedding is not possible and it cannot setup the bootloader without it.

Michal Kubeček

-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Michal Kubecek

05:12

On Wednesday 13 of August 2014 11:19:54 Michael Chang wrote:

...

On Wed, Aug 13, 2014 at 06:42:02AM +0400, Andrey Borzenkov wrote:

...
В Tue, 12 Aug 2014 22:26:40 +0200 Michal Kubecek пишет:

...
I checked now and on my machine, yast2-bootloader is still unable to setup bootloader with GRUB2 ("warning: this GPT partition label contains no BIOS Boot Partition; embedding won't be possible." / "error: embedding is not possible, but this is required for RAID and LVM install.") With GRUB, everything is configured without complaint and works perfectly.

Do you know details how grub legacy handled this configuration? I.e. where it installed stage1 and stage1.5 (or stage2)?

No. Is there an easy way to find out?

...

My understanding is YaST would create separate /boot partition and wrote stage1 on boot partition. Then it would wrote gptmbr from syslinux to mbr to chainload boot.

I don't have a separate /boot

...

The diret LVM booting scenario (ie without boot partition) never worked for legacy grub regardless msdos or gpt table.

LVM is used only for data, root filesystem is on a SW RAID 1. Details of the layout are attached. Michal Kubeček