[opensuse-factory] Grub2 as default bootloader for installation
Hi all, In factory, yast2-bootloader and perl-Bootloader will be updated with grub2 support and will set as default for installation. However you can go back to your good old grub1 in the loader type selection menu if it doesn't work for you. This will not affect your existing system if you performed update to newest factory, the current loader will remain grub1. But grub2 will be availale in yast2 bootloader and you could switch to use it if you like. It's welcome to report issues to bugzilla and hopefully that issues can get resolved early before 12.2 release. Although we tried to test as much as possible, we can't guarentee the quality without distributing them outside and get more people's feedback and involvement. :) You could refer to the wiki page for current status and information. http://en.opensuse.org/openSUSE:YaST2_And_Perl_Bootloader_Grub2_Modules_Impl... Thanks. Regards, Michael -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tuesday, March 06, 2012 07:44:32 Michael Chang wrote:
Hi all,
In factory, yast2-bootloader and perl-Bootloader will be updated with grub2 support and will set as default for installation. However you can go back to your good old grub1 in the loader type selection menu if it doesn't work for you.
So, if grub2 does not become stable until RC1, we can always just change the default and have grub1 back? Good! Then let's continue.
This will not affect your existing system if you performed update to newest factory, the current loader will remain grub1. But grub2 will be availale in yast2 bootloader and you could switch to use it if you like.
That testing would be very welcome.
It's welcome to report issues to bugzilla and hopefully that issues can get resolved early before 12.2 release. Although we tried to test as much as possible, we can't guarentee the quality without distributing them outside and get more people's feedback and involvement. :)
Should those bugs get directly assigned to you, Michael?
You could refer to the wiki page for current status and information.
http://en.opensuse.org/openSUSE:YaST2_And_Perl_Bootloader_Grub2_Modules_ Implement
Thanks, Andreas -- Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Le 06/03/2012 09:41, Andreas Jaeger a écrit :
You could refer to the wiki page for current status and information.
http://en.opensuse.org/openSUSE:YaST2_And_Perl_Bootloader_Grub2_Modules_Impl...
warning on the eventually broken link in the post (was when I received it) The main feature of the original grub was the ability of using the mini terminal to fix broken boot system. I hope grub2 have similar system, that should be precisely commented in our wiki to ease the work of testers. it's often at this moment then problem arise, and grub2 doc is intimidating (at least it intimidated me :-) thanks jdd -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, Mar 06, 2012 at 10:00:38AM +0100, jdd wrote:
Le 06/03/2012 09:41, Andreas Jaeger a écrit :
You could refer to the wiki page for current status and information.
http://en.opensuse.org/openSUSE:YaST2_And_Perl_Bootloader_Grub2_Modules_Impl...
warning on the eventually broken link in the post (was when I received it)
The link worked for me. Could you please try again? Maybe I was editing it concurrently.
The main feature of the original grub was the ability of using the mini terminal to fix broken boot system.
I hope grub2 have similar system, that should be precisely commented in our wiki to ease the work of testers. it's often at this moment then problem arise, and grub2 doc is intimidating (at least it intimidated me :-)
Grub2 offers same capability. :) It's a good idea to have wiki page that demostrates some of the command line usage of grub2 (for rescue your system from badly installed loader, chainload other systems etc). The grub2 also features new light scripting capability. Also I think we can improve bug reporting page of bootloader. :) http://en.opensuse.org/openSUSE:Submitting_bug_reports#Reporting_a_bug Regards, Michael
thanks jdd -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-- Michael Chang Software Engineer Rm. B, 26F, No.216, Tun Hwa S. Rd., Sec.2 Taipei 106, Taiwan, R.O.C +886223760030 mchang@suse.com SUSE -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Le 06/03/2012 10:41, Michael Chang a écrit :
http://en.opensuse.org/openSUSE:YaST2_And_Perl_Bootloader_Grub2_Modules_Impl...
warning on the eventually broken link in the post (was when I received it)
The link worked for me. Could you please try again? Maybe I was editing it concurrently.
no, the link was cut by a CR just before Implement. I could fix it manually and read the page. I fixed it also in my answer and it get through correctly now jdd -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, Mar 06, 2012 at 09:41:37AM +0100, Andreas Jaeger wrote:
On Tuesday, March 06, 2012 07:44:32 Michael Chang wrote:
Hi all,
In factory, yast2-bootloader and perl-Bootloader will be updated with grub2 support and will set as default for installation. However you can go back to your good old grub1 in the loader type selection menu if it doesn't work for you.
So, if grub2 does not become stable until RC1, we can always just change the default and have grub1 back? Good! Then let's continue.
Yes. the change is trivial and we can do that at anytime we want. Just make sure that we can get enough testing and issues reported thus we could evaluate precisely prior to RC1.
This will not affect your existing system if you performed update to newest factory, the current loader will remain grub1. But grub2 will be availale in yast2 bootloader and you could switch to use it if you like.
That testing would be very welcome.
Yes. testing is always welcome.
It's welcome to report issues to bugzilla and hopefully that issues can get resolved early before 12.2 release. Although we tried to test as much as possible, we can't guarentee the quality without distributing them outside and get more people's feedback and involvement. :)
Should those bugs get directly assigned to you, Michael?
Ok. I'd like to take them .. hope not flooded. :) Regards, Michael
You could refer to the wiki page for current status and information.
http://en.opensuse.org/openSUSE:YaST2_And_Perl_Bootloader_Grub2_Modules_ Implement
Thanks, Andreas -- Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 -- 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
Hi all,
In factory, yast2-bootloader and perl-Bootloader will be updated with grub2 support and will set as default for installation. However you can go back to your good old grub1 in the loader type selection menu
So this means that once I install these updates, that automatically my Grub2 configuration is updated whenever I update/install a newer kernel ? I am glad to finally see support for grub2 coming. Thanks Regards Raymond -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tuesday, March 06, 2012 11:17:20 Raymond Wooninck wrote:
Hi all,
In factory, yast2-bootloader and perl-Bootloader will be updated with grub2 support and will set as default for installation. However you can go back to your good old grub1 in the loader type selection menu
So this means that once I install these updates, that automatically my Grub2 configuration is updated whenever I update/install a newer kernel ?
This should work in 12.1 already - just set LOADER_TYPE="grub2" in /etc/sysconfig/bootloader - and create the initial configuration.
I am glad to finally see support for grub2 coming.
Andreas -- Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
在 2012年3月6日下午6:17，Raymond Wooninck <tittiatcoke@gmail.com> 寫道：
Hi all,
In factory, yast2-bootloader and perl-Bootloader will be updated with grub2 support and will set as default for installation. However you can go back to your good old grub1 in the loader type selection menu
So this means that once I install these updates, that automatically my Grub2 configuration is updated whenever I update/install a newer kernel ?
I am glad to finally see support for grub2 coming.
Same for me to see Plymouth :) Btw .. is there any dependency to loader ? Grub2 seems to be better than Grub1 for Plymouth because it allows to keep mode setting from loader to the kernel. This would have reduced flicking in transition from loader to kernel? To be honest this is just guess, perhaps we should see how fedora treat both (they should use grub2+plymouth) .. Regards, Michael
Thanks
Regards
Raymond -- 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
On Wednesday, March 07, 2012, Michael Chang <mchang@suse.com> wrote:
Btw .. is there any dependency to loader ? Grub2 seems to be better than Grub1 for Plymouth because it allows to keep mode setting from loader to the kernel. This would have reduced flicking in transition from loader to kernel?
Hi Michael, This was one of the reasons why I already started to use grub2 to see the effect on Plymouth. Unfortunately things didn't really changed with regards to reducing the flickering in transition.
To be honest this is just guess, perhaps we should see how fedora treat both (they should use grub2+plymouth) ..
I have looked into this and they have a little different setup than openSUSE. At this moment our plymouth is waiting until udev has created the devices, etc (required for the consoles) and then starts showing the splash on /dev/tty7. This means that there is a little gap between grub2 and the plymouth splash. What I have seen with Fedora is that they do not rely on udev to create the devices, but that their plymouth script is creating the require console device itself. This means that plymouth is most likely either first or the second boot script inside the initrd that is being started. And therefore there is no fall back to a console screen. I didn't had too much time lately to dive into this one more and my first target was to get the package in Factory (which happened now) in order to get some more testing with different video cards, setup's, etc. At this moment there is another strange issue with plymouth that it doesn't show it's splashscreen during shutdown/reboot. Everything is setup correctly (on systemd and plymouth side), but it is not activated. With regards to grub2, I believe that the next item would be to create a proper graphical grub2 menu. This requires some changes to the grub2 package itself and I am not sure if this has happened yet. However I can help you with the setup there as that it is just a matter of defining some additional setting. Regards Raymond -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
在 2012年3月7日下午4:40，Raymond Wooninck <tittiatcoke@gmail.com> 寫道：
On Wednesday, March 07, 2012, Michael Chang <mchang@suse.com> wrote:
Btw .. is there any dependency to loader ? Grub2 seems to be better than Grub1 for Plymouth because it allows to keep mode setting from loader to the kernel. This would have reduced flicking in transition from loader to kernel?
Hi Michael, This was one of the reasons why I already started to use grub2 to see the effect on Plymouth. Unfortunately things didn't really changed with regards to reducing the flickering in transition.
To be honest this is just guess, perhaps we should see how fedora treat both (they should use grub2+plymouth) ..
I have looked into this and they have a little different setup than openSUSE. At this moment our plymouth is waiting until udev has created the devices, etc (required for the consoles) and then starts showing the splash on /dev/tty7. This means that there is a little gap between grub2 and the plymouth splash.
Yes, it would be great to eliminate the gap as much as possible. In theory we can use firmware framebuffer (VESA) in early stage and can display earlier than KMS framebuffer, but it seems Plymouth can only renders on KMS FB ? IMHO big initrd/kernel size is also one significant contributor to the gap, not sure whether grub2 can "hide" the text screen of loading them (with some better graphical foreground).
What I have seen with Fedora is that they do not rely on udev to create the devices, but that their plymouth script is creating the require console device itself. This means that plymouth is most likely either first or the second boot script inside the initrd that is being started. And therefore there is no fall back to a console screen.
Seems like some trick to get the FB console start faster ...
I didn't had too much time lately to dive into this one more and my first target was to get the package in Factory (which happened now) in order to get some more testing with different video cards, setup's, etc.
Good to know. :)
At this moment there is another strange issue with plymouth that it doesn't show it's splashscreen during shutdown/reboot. Everything is setup correctly (on systemd and plymouth side), but it is not activated.
With regards to grub2, I believe that the next item would be to create a proper graphical grub2 menu. This requires some changes to the grub2 package itself and I am not sure if this has happened yet. However I can help you with the setup there as that it is just a matter of defining some additional setting.
Thanks. We need people to work on it. The problem is the missing grub2 font .. we should package them or call grub2-mkfont somewhere (maybe yast2 bootloader) . Not know what's better way to go. Regards, Micahel
Regards
Raymond -- 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
On Wednesday, March 07, 2012, Michael Chang <mchang@suse.com> wrote:
Thanks. We need people to work on it. The problem is the missing grub2 font .. we should package them or call grub2-mkfont somewhere (maybe yast2 bootloader) . Not know what's better way to go.
Hi Michael, I have tried a couple of fonts, but not every font is suitable to be used in Grub2. It has to be able to display certain characters, be unicode, etc. At this moment the best one working is the one that also Fedora is using (unicode.pf2). I will have a look to see if I can find that one and then update the grub2 package to include the graphical menu. We can package this as a sub- package so that people can choose whether or not to implement it. Regards Raymond -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Le mercredi 07 mars 2012 à 17:56 +0800, Michael Chang a écrit :
在 2012年3月7日下午4:40，Raymond Wooninck <tittiatcoke@gmail.com> 寫道：
On Wednesday, March 07, 2012, Michael Chang <mchang@suse.com> wrote:
Btw .. is there any dependency to loader ? Grub2 seems to be better than Grub1 for Plymouth because it allows to keep mode setting from loader to the kernel. This would have reduced flicking in transition from loader to kernel?
Hi Michael, This was one of the reasons why I already started to use grub2 to see the effect on Plymouth. Unfortunately things didn't really changed with regards to reducing the flickering in transition.
To be honest this is just guess, perhaps we should see how fedora treat both (they should use grub2+plymouth) ..
I have looked into this and they have a little different setup than openSUSE. At this moment our plymouth is waiting until udev has created the devices, etc (required for the consoles) and then starts showing the splash on /dev/tty7. This means that there is a little gap between grub2 and the plymouth splash.
Yes, it would be great to eliminate the gap as much as possible. In theory we can use firmware framebuffer (VESA) in early stage and can display earlier than KMS framebuffer, but it seems Plymouth can only renders on KMS FB ?
No, I don't know where this urban legend is coming from, but plymouth is able to render on Vesa FB if there is no KMS FB. -- Frederic Crozat <fcrozat@suse.com> SUSE -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi, some testing info... got the two packages related to grub2 installed [root@abbaton:/home/alin]: zypper se -is grub2 Loading repository data... Reading installed packages... S | Name | Type | Version | Arch | Repository --+-----------+---------+-----------+--------+--------------------- i | grub2 | package | 1.99-16.1 | x86_64 | openSUSE-Factory-Oss i | grub2-efi | package | 1.99-16.1 | x86_64 | openSUSE-Factory-Oss the machine is a macbook pr with these partition table [root@abbaton:/home/alin]: fdisk -l WARNING: GPT (GUID Partition Table) detected on '/dev/sda'! The util fdisk doesn't support GPT. Use GNU Parted. Disk /dev/sda: 250.1 GB, 250059350016 bytes 255 heads, 63 sectors/track, 30401 cylinders, total 488397168 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00000000 Device Boot Start End Blocks Id System /dev/sda1 1 409638 204819 ee GPT /dev/sda2 409640 79011663 39301012 af HFS / HFS+ /dev/sda3 * 79273984 118335487 19530752 83 Linux /dev/sda4 118335488 488396799 185030656 83 Linux at restart I got a new entry in my grub1 menu.... which of course is empty... then I generated the grub.cfg grub2-mkconfig -o /boot/grub2/grub.cfg now at restart I had a proper entry in the grub menu... which correctly showed me a grub2 menu when selected... however I could not boot the system getting all kind of failures mainly udev related... I know my machine is an exotic setup but I am happy and free to test... Alin --- Without Questions there are no Answers! ______________________________________________________________________ Alin Marin ELENA Advanced Molecular Simulation Research Laboratory School of Physics, University College Dublin ---- Ardionsamblú Móilíneach Saotharlann Taighde Scoil na Fisice, An Coláiste Ollscoile, Baile Átha Cliath ----------------------------------------------------------------------------------- http://alin.elenaworld.net ______________________________________________________________________ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tuesday, March 06, 2012 01:44 AM Michael Chang wrote:
Hi all,
In factory, yast2-bootloader and perl-Bootloader will be updated with grub2 support and will set as default for installation. However you can go back to your good old grub1 in the loader type selection menu if it doesn't work for you.
This will not affect your existing system if you performed update to newest factory, the current loader will remain grub1. But grub2 will be availale in yast2 bootloader and you could switch to use it if you like.
Will it be possible to install grub1 to the boot sector of one primary partition and grub2 to the boot sector of another primary partition? This traditional method using the "generic" boot code in the MBR to call whichever primary in the partition is marked active (bootable flag) would permit relatively easy switching between grub1 and grub2 (i.e., just changing the flag) and provide a fall-back from grub2 to grub1. Thanks, --dg -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tuesday, March 06, 2012 13:19:35 Dennis Gallien wrote:
On Tuesday, March 06, 2012 01:44 AM Michael Chang wrote:
Hi all,
In factory, yast2-bootloader and perl-Bootloader will be updated with grub2 support and will set as default for installation. However you can go back to your good old grub1 in the loader type selection menu if it doesn't work for you.
This will not affect your existing system if you performed update to newest factory, the current loader will remain grub1. But grub2 will be availale in yast2 bootloader and you could switch to use it if you like.
Will it be possible to install grub1 to the boot sector of one primary partition and grub2 to the boot sector of another primary partition?
This traditional method using the "generic" boot code in the MBR to call whichever primary in the partition is marked active (bootable flag) would permit relatively easy switching between grub1 and grub2 (i.e., just changing the flag) and provide a fall-back from grub2 to grub1.
You can indeed chainload the bootloaders. But this kind of setup is nothing that we should help setting up, it's getting way to complicated. If grub2 is not working at all right now, grab a rescue system and switch back to grub1. Andreas -- Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2012-03-06 13:34, Andreas Jaeger wrote:
On Tuesday, March 06, 2012 13:19:35 Dennis Gallien wrote:
This traditional method using the "generic" boot code in the MBR to call whichever primary in the partition is marked active (bootable flag) would permit relatively easy switching between grub1 and grub2 (i.e., just changing the flag) and provide a fall-back from grub2 to grub1.
You can indeed chainload the bootloaders.
But this kind of setup is nothing that we should help setting up, it's getting way to complicated.
As far as YaST is concerned, grub is installed on a partition and it is not to write anything in MBR. It doesn't need be concerned that there is another grub on another partition, not his business. - -- Cheers / Saludos, Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk9WBWgACgkQIvFNjefEBxoKNQCgx2AfgAqOZzxBfm+PXL8S8/Rp trMAoJpBQUZtj+3odx7n9BdPSOqiSeJ/ =mCW3 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Tirsdag den 6. marts 2012 14:44:32 Michael Chang skrev:
In factory, yast2-bootloader and perl-Bootloader will be updated with grub2 support and will set as default for installation.
It's welcome to report issues to bugzilla and hopefully that issues can get resolved early before 12.2 release. Although we tried to test as much as possible
I wonder if the testing included testing of a dual boot of 12.1 with legacy grub + 12.2/factory with grub2. That's how I do my factory testing. And it would be good to know in advance if installing some 12.2 milestone in dualboot with 12.1 will "break" the 12.1 boot, or if some fiddling will be required, or if it should "just work". -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, Mar 06, 2012 at 02:38:56PM +0100, Martin Schlander wrote:
Tirsdag den 6. marts 2012 14:44:32 Michael Chang skrev:
In factory, yast2-bootloader and perl-Bootloader will be updated with grub2 support and will set as default for installation.
It's welcome to report issues to bugzilla and hopefully that issues can get resolved early before 12.2 release. Although we tried to test as much as possible
I wonder if the testing included testing of a dual boot of 12.1 with legacy grub + 12.2/factory with grub2.
It should "just work". Depend mostly on your setup of partition. If a simple setup like below it would work .. primary 1 "/swap" primary 2 "/ for 12.1" primary 3 "/ for 12.2 milestone" But more complex setup I can't gurarentee .. especially the case below. Now that we rely on grub2 scripts for install (and also for detecting foreign OS), there might be some issues related with that. For example, it did not work if extended partition is the target install partition on my test. It seems to make wrong assumption on partition has to be with filesystems in probing.. However still keep proposing extended partition because this seems to be grub2's issue and we should fix in it instead in yast2. Also make changes to proposed location would have to discuss as well (for example: mbr). So please file a bug if you have .. let's discuss and come to a fix together. :)
That's how I do my factory testing. And it would be good to know in advance if installing some 12.2 milestone in dualboot with 12.1 will "break" the 12.1 boot, or if some fiddling will be required, or if it should "just work".
It would not break your 12.1 boot path as master and volume boot record of your 12.1 installation are not touched, if 12.2 milestone intallation not work you could activate your 12.1 partiton and you won't lost them. Regards, Michael
-- 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
On Wed, Mar 07, 2012 at 12:18:25PM +0800, Michael Chang wrote:
On Tue, Mar 06, 2012 at 02:38:56PM +0100, Martin Schlander wrote:
Tirsdag den 6. marts 2012 14:44:32 Michael Chang skrev:
In factory, yast2-bootloader and perl-Bootloader will be updated with grub2 support and will set as default for installation.
It's welcome to report issues to bugzilla and hopefully that issues can get resolved early before 12.2 release. Although we tried to test as much as possible
I wonder if the testing included testing of a dual boot of 12.1 with legacy grub + 12.2/factory with grub2.
It should "just work". Depend mostly on your setup of partition. If a simple setup like below it would work ..
primary 1 "/swap" primary 2 "/ for 12.1" primary 3 "/ for 12.2 milestone"
But more complex setup I can't gurarentee .. especially the case below.
Now that we rely on grub2 scripts for install (and also for detecting foreign OS), there might be some issues related with that. For example, it did not work if extended partition is the target install partition on my test. It seems to make wrong assumption on partition has to be with filesystems in probing..
However still keep proposing extended partition because this seems to be grub2's issue and we should fix in it instead in yast2. Also
Meanwhile, I filed a bug this grub2 issue. https://bugzilla.novell.com/show_bug.cgi?id=750897
make changes to proposed location would have to discuss as well (for example: mbr).
So please file a bug if you have .. let's discuss and come to a fix together. :)
That's how I do my factory testing. And it would be good to know in advance if installing some 12.2 milestone in dualboot with 12.1 will "break" the 12.1 boot, or if some fiddling will be required, or if it should "just work".
It would not break your 12.1 boot path as master and volume boot record of your 12.1 installation are not touched, if 12.2 milestone intallation not work you could activate your 12.1 partiton and you won't lost them.
Regards, Michael
-- 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
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Onsdag den 7. marts 2012 12:18:25 Michael Chang skrev:
On Tue, Mar 06, 2012 at 02:38:56PM +0100, Martin Schlander wrote:
I wonder if the testing included testing of a dual boot of 12.1 with legacy grub + 12.2/factory with grub2.
It should "just work". Depend mostly on your setup of partition. If a simple setup like below it would work ..
primary 1 "/swap" primary 2 "/ for 12.1" primary 3 "/ for 12.2 milestone"
But more complex setup I can't gurarentee .. especially the case below.
Now that we rely on grub2 scripts for install (and also for detecting foreign OS), there might be some issues related with that. For example, it did not work if extended partition is the target install partition on my test. It seems to make wrong assumption on partition has to be with filesystems in probing..
Thanks. I would be installing 12.2 on an extended partition, with 12.1 on a primary, so I guess I need to be careful. I probably won't install 12.2 until milestone 4 though, so I'll monitor the bugreport, and hope the issue can be resolved by then. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tuesday, March 06, 2012 11:18 PM Michael Chang wrote:
On Tue, Mar 06, 2012 at 02:38:56PM +0100, Martin Schlander wrote:
Tirsdag den 6. marts 2012 14:44:32 Michael Chang skrev:
In factory, yast2-bootloader and perl-Bootloader will be updated with grub2 support and will set as default for installation.
It's welcome to report issues to bugzilla and hopefully that issues can get resolved early before 12.2 release. Although we tried to test as much as possible
I wonder if the testing included testing of a dual boot of 12.1 with legacy grub + 12.2/factory with grub2.
It should "just work". Depend mostly on your setup of partition. If a simple setup like below it would work ..
primary 1 "/swap" primary 2 "/ for 12.1" primary 3 "/ for 12.2 milestone"
But more complex setup I can't gurarentee .. especially the case below.
Now that we rely on grub2 scripts for install (and also for detecting foreign OS), there might be some issues related with that. For example, it did not work if extended partition is the target install partition on my test. It seems to make wrong assumption on partition has to be with filesystems in probing..
However still keep proposing extended partition because this seems to be grub2's issue and we should fix in it instead in yast2. Also make changes to proposed location would have to discuss as well (for example: mbr).
Where are we locating core.img, the disk's extended area just past the MBR or in a filesystem? IIRC the manual recommends the former over the latter. Both locations have vulnerabilities. I seem to recall that the master's extended area is sometimes used by MS e.g. for BitLocker, and perhaps other vendors use this space too for proprietary purposes, although these are quite unusual. But a filesystem is vulnerable to moving blocks which can render the address hard-coded into boot.img invalid. Besides this issue, there is another vulnerability with using a filesystem - getting the address to embed into boot.img wrong in the first place. Here again grub2 has an advantage over grub1 when using the MBR extended area for core.img. The grub installer program checks several data to determine the disk address of core.img, including making a bios query. Sometime the address is just plain wrong. In my tests with grub1 and for a reason I cannot explain, this happened more often when stage1 was looking for grub on a logical partition. If core.img is placed in the MBR extended area, it is always in exactly the same location on disk and so the address hard-coded into boot.img will always be correct. Given the above, it seems that it would always be best to install boot.img to the MBR and core.img to the area immediately following, unless that space is already used (I would think the installation program could check that). For users who already have Windows installed, this means writing over the DOS code in the MBR (as already is frequently done in installation now). It would be good to have a simple recovery mechanism whereby /usr/lib/master-boot-code could be written back to the MBR, or at least instructions somewhere on how to do this with live-media, in the event the grub installation fails; the machine would then at least be bootable again. The alternative to this is to not use the MBR at all for grub, which means using the generic code in the MBR with the active flag set + a primary PBR for boot.img + a filesystem for core.img, and with that back to the problems above. My $.02. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi Dennis, I agree with your suggestions. To be host I love the idea to put boot.img to mbr and core.img to sectors following it (mbr hole), especially it was also suggested in manual. But things are not just vulnerability considerations. We had some discussions internally about this, we should have to consider different scenarios and setups .. overwriting mbr would mostly likely to cause some setup to fail (as we can't figure out what's current setup users have, then better not touch them). Also writing to mbr means that SUSE loaders takes control over the master boot code, well we can chain load to other systems, but what if the chain load fail or even loader is broken? We don't support booting into others systems .. so let mbr do his job still .. :) I think mbr is a feasible propose to new or single OS environment, that is we don't need to consider multi-os booting and solid is the only concern. Also change to use gpt is a good idea for such booting scenario. PS. What we taking is about "proposed location", or default location would install. We can override it if we prefer others. :) 在 2012年3月8日上午12:22，Dennis Gallien <dwgallien@gmail.com> 寫道：
On Tuesday, March 06, 2012 11:18 PM Michael Chang wrote:
Where are we locating core.img, the disk's extended area just past the MBR or in a filesystem? IIRC the manual recommends the former over the latter. Both locations have vulnerabilities. I seem to recall that the master's extended area is sometimes used by MS e.g. for BitLocker, and perhaps other vendors use this space too for proprietary purposes, although these are quite unusual. But a filesystem is vulnerable to moving blocks which can render the address hard-coded into boot.img invalid.
Besides this issue, there is another vulnerability with using a filesystem - getting the address to embed into boot.img wrong in the first place. Here again grub2 has an advantage over grub1 when using the MBR extended area for core.img. The grub installer program checks several data to determine the disk address of core.img, including making a bios query. Sometime the address is just plain wrong. In my tests with grub1 and for a reason I cannot explain, this happened more often when stage1 was looking for grub on a logical partition. If core.img is placed in the MBR extended area, it is always in exactly the same location on disk and so the address hard-coded into boot.img will always be correct.
Given the above, it seems that it would always be best to install boot.img to the MBR and core.img to the area immediately following, unless that space is already used (I would think the installation program could check that).
For users who already have Windows installed, this means writing over the DOS code in the MBR (as already is frequently done in installation now). It would be good to have a simple recovery mechanism whereby /usr/lib/master-boot-code could be written back to the MBR, or at least instructions somewhere on how to do this with live-media, in the event the grub installation fails; the machine would then at least be bootable again. The alternative to this is to not use the MBR at all for grub, which means using the generic code in the MBR with the active flag set + a primary PBR for boot.img + a filesystem for core.img, and with that back to the problems above.
yast2 bootloader have some facility to backup and restore mbr in grub1's setting page. Maybe we have to copy them to grub2. (noted)
My $.02.
Thanks a lot. :) Michael
-- 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
On Thursday, March 08, 2012 12:02 AM Michael Chang wrote:
Hi Dennis,
I agree with your suggestions. To be host I love the idea to put boot.img to mbr and core.img to sectors following it (mbr hole), especially it was also suggested in manual.
But things are not just vulnerability considerations. We had some discussions internally about this, we should have to consider different scenarios and setups .. overwriting mbr would mostly likely to cause some setup to fail (as we can't figure out what's current setup users have, then better not touch them). Also writing to mbr means that SUSE loaders takes control over the master boot code, well we can chain load to other systems, but what if the chain load fail or even loader is broken? We don't support booting into others systems .. so let mbr do his job still .. :)
I think mbr is a feasible propose to new or single OS environment, that is we don't need to consider multi-os booting and solid is the only concern. Also change to use gpt is a good idea for such booting scenario.
PS. What we taking is about "proposed location", or default location would install. We can override it if we prefer others. :)
I agree that using the mbr is best if a new, single-OS install. I understand the risk if there is already another setup on the machine, which is why I suggested that the installation first check those disk sectors. I don't know if the grub2 install program does that (I doubt it) or if YaST is making that check before calling the grub install program (I doubt it) or if YaST *could* make that check to decide whether to use the mbr - and here I suggest that grub2 *should* provide at least that option (but probably will not) and that therefore it would be great if YaST could because *even if there is no OS installed* it is still possible those disk sectors were used for another proprietary purpose. I strongly suspect that some hardware manufacturers are using that space for bios extensions and/or recovery image subsystems which are called from the bios, which we should not disturb without user permission. <snip>
yast2 bootloader have some facility to backup and restore mbr in grub1's setting page. Maybe we have to copy them to grub2. (noted)
I am aware of that capability, which is good. The problem however is that there is a catch-22: If the machine is unbootable to openSUSE because the grub install failed, then YaST is not available to restore the mbr. To be honest, I don't recall whether YaST on Live-CD/DVD can do that. IIRC it could do that on the install DVD when we had the recovery system, which is good now. Perhaps we should consider including just the boot loader recovery to the install DVD, because for new users this is our single largest vulnerability - having the openSUSE installation render the machine unbootable, we should IMO for Windows users have a way back to Windows if we bork their machine. Thanks for your consideration. --dg -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2012/03/07 11:22 (GMT-0500) Dennis Gallien composed:
Where are we locating core.img, the disk's extended area just past the MBR or in a filesystem? IIRC the manual recommends the former over the latter. Both locations have vulnerabilities. I seem to recall that the master's extended area is sometimes used by MS e.g. for BitLocker, and perhaps other vendors use this space too for proprietary purposes, although these are quite unusual.
Depends on your definition of "unusual". OS/2 & eCS have long used the last sector on the first track for IBM Boot Manager data. Now eCS is shipping with a replacement boot manager called AiR-Boot, which has been using sectors following the MBR sector for its whole existence. http://air-boot.sourceforge.net/ What AiR-Boot is that Grub2 is not is user-friendly.
But a filesystem is vulnerable to moving blocks which can render the address hard-coded into boot.img invalid.
Besides this issue, there is another vulnerability with using a filesystem - getting the address to embed into boot.img wrong in the first place. Here again grub2 has an advantage over grub1 when using the MBR extended area for core.img. The grub installer program checks several data to determine the disk address of core.img, including making a bios query. Sometime the address is just plain wrong. In my tests with grub1 and for a reason I cannot explain, this happened more often when stage1 was looking for grub on a logical partition. If core.img is placed in the MBR extended area, it is always in exactly the same location on disk and so the address hard-coded into boot.img will always be correct.
But MBR is not "compatible" with multibooting Windows, which seemingly at every opportunity will replace the MBR code with generic boot code, putting Grub in need of repair.
Given the above, it seems that it would always be best to install boot.img to the MBR and core.img to the area immediately following, unless that space is already used
Only thrice has Grub been installed on any MBR of mine. The first was Corel Linux, which shipped with WordPerfect, which I eventually learned how to install without overwriting the MBR. The second was Xandros, which apparently at the time could not be installed without overwriting the MBR. The third was 12.2M1, where at one point during boot loader configuration I wasn't paying close enough attention after doing a goback from entering an unwanted step, which resulted in changing what I had changed to get the bootloader off the extended and MBR and onto /. IOW, they've all amounted to accidents. Grub is unlikely ever to be installed to any MBR of mine on purpose, because there's _always_ some way to make a system bootable via generic MBR code, and thus no need to replace standard code with non-standard code that depends on configuration on some partition and/or boot track sectors to work at all.
For users who already have Windows installed, this means writing over the DOS code in the MBR (as already is frequently done in installation now).
This amounts to a huge percentage of installs, almost a general rule, and most difficult as to first time would-be converts from Window to Linux.
It would be good to have a simple recovery mechanism whereby /usr/lib/master-boot-code could be written back to the MBR, or at least instructions somewhere on how to do this with live-media, in the event the grub installation fails; the machine would then at least be bootable again.
But of course the problem is easily avoided by Air-Boot, .... or by
The alternative to this is to not use the MBR at all for grub, which means using the generic code in the MBR with the active flag set + a primary PBR for boot.img + a filesystem for core.img, and with that back to the problems above.
Such problems I don't have. But then, I generally try RTFM first instead of waiting to see what damage needs repair. And I know how to avoid these issues: http://fm.no-ip.com/PC/install-doz-after.html -- "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
On Thursday, March 08, 2012 12:12 AM Felix Miata wrote:
On 2012/03/07 11:22 (GMT-0500) Dennis Gallien composed:
Where are we locating core.img, the disk's extended area just past the MBR or in a filesystem? IIRC the manual recommends the former over the latter. Both locations have vulnerabilities. I seem to recall that the master's extended area is sometimes used by MS e.g. for BitLocker, and perhaps other vendors use this space too for proprietary purposes, although these are quite unusual.
Depends on your definition of "unusual". OS/2 & eCS have long used the last sector on the first track for IBM Boot Manager data. Now eCS is shipping with a replacement boot manager called AiR-Boot, which has been using sectors following the MBR sector for its whole existence.
http://air-boot.sourceforge.net/
What AiR-Boot is that Grub2 is not is user-friendly.
Yes, I'm aware that there are cases where those disk sectors are being used for proprietary reasons. While I think that in the grand scheme of things that is still a small minority, I agree that it is certainly a valid concern that cannot be ignored. I'm aware that there are hardware oem's that have used that space for bios extensions and/or OS image recovery mechanisms, so I'm not surprised that ECS is doing so. This is why I suggested that there be a check of those sectors before using that space; perhaps I didn't emphasize that enough in my previous message. I see that as a dependency. That would be important to do even on a single OS blank disk install because it is conceivable that even though the user is providing the whole disk it is possible that the user is unaware that the manufacturer has a function built into that space, and we should not take that away from the user without permission. <snip> I know it is claimed that openSUSE does not typically install grub to the mbr, but in fact it frequently does so. I worked the Forums rather heavily for several years exclusively focused on boot and hardware issues (and before that did the same for Ubuntu it's first year, before I knew better). After every release there is a wave of new users, typically Windows, that try to install openSUSE. One of the most common problems encountered was with the bootloader - and *most* of the time, the problem was that grub was installed to the mbr with the hard-coded disk address pointer to find stage2 being wrong, and there was no way back to Windows. I really wish that grub was in the pbr and that the fix was simply re-setting the active flag, but it rarely was that way. Furthermore, the default advice on the Forums was always to install grub to the mbr (I didn't agree with that, although I understood why). This almost always resulted in a very difficult and time-consuming - and unpleasant - experience for both the user and us on the Forums, as we struggled trial-an- error to get grub working or, failing that, to get the user back to a bootable Windows machines. For Vista/W7 users I often recommended installing grub to the openSUSE primary pbr (the extended primary if a logical was used to install root) and using the Windows boot loader system to chainload openSUSE; that system works well although the command-line interface utility to manage it that MS provides really sucks, but there is a very easy-to-use free 3rd- party utility alternative. Of course, once the boot loader was borked by grub, the first task was just to get back a bootable machine, and oem Windows users don't have media to do that, so the user had to download that tool from another machine, burn it to media, do the recovery, just to get back to square one. I'll just add that the frequency of this problem increased noticeably with the popularity of laptops and external boot device options, the former because of manufacturers doing undocumented proprietary things with the disk and the latter because of bios wierdness. So to reiterate where I'm coming from . . . keeping mind that there are two considerations, i.e., where to put boot.img and where to put core.img. First, I advocate using the mbr for boot.img and core.img, but *only* if we can validate that the mbr hole disk sectors are not already used. That is not difficult to do programmatically, and would result in the cleanest and safest setup. Personally I think that the grub2 team should do this, especially since they advocate using this method. But if they will not, it would be an excellent and relatively easy addition to YaST. If we do this, since it is conceivable that some condition could be missed, it would be great if there were a simple mechanism included with the install media to restore the generic master-boot-code as YaST can now do when openSUSE is running. Second, if Windows is installed I suggest we leave the DOS code in the mbr and boot.img in the pbr of the root partition; if root is on a logical the pbr of the extended primary must be used. Then set the active flag on that primary. Then check the mbr hole; if it is empty, use it for core.img, otherwise use the root filesystem and install boot.img accordingly. With this method, recovery to the Windows boot loader only requires switching the active flag back to the Windows boot partition, which we should provide some simple mechanism to do, or at least instructions how to do, in the event the grub install fails and makes the machine unbootable. In this approach, if boot.img fails to execute from the pbr it will be because we were required to use the filesystem for core.img and the pointer to it is wrong or core.img itself is damaged/moved, and so it must be understood that even if the user were to use Windows to boot openSUSE that will fail also because Windows simply chainloads to the pbr. A re-installation may resolve this, but that is not guaranteed. --dg -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2012/03/08 10:26 (GMT-0500) Dennis Gallien composed:
if Windows is installed I suggest we leave the DOS code in the mbr and boot.img in the pbr of the root partition; if root is on a logical the pbr of the extended primary must be used. Then set the active flag on that primary. Then check the mbr hole; if it is empty, use it for core.img, otherwise use the root filesystem and install boot.img accordingly.
http://tech.groups.yahoo.com/group/dfsee-support/message/13859 explains that *buntu installations usually make eCS unbootable by making a change in the 64 byte MBR partition table itself even when *buntu installation is to existing partition(s). I have no idea whether Grub2 installation is responsible for this, but it is something to watch for in 12.2's support and installation systems for Grub2. I don't recall ever having this happen from an openSUSE installation. It may well be *buntu's partitioning routine does this even when there's no reason to touch the tables, and has nothing to do with Grub2. -- "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
On Thursday, March 08, 2012 11:03 AM Felix Miata wrote:
On 2012/03/08 10:26 (GMT-0500) Dennis Gallien composed:
if Windows is installed I suggest we leave the DOS code in the mbr and boot.img in the pbr of the root partition; if root is on a logical the pbr of the extended primary must be used. Then set the active flag on that primary. Then check the mbr hole; if it is empty, use it for core.img, otherwise use the root filesystem and install boot.img accordingly.
http://tech.groups.yahoo.com/group/dfsee-support/message/13859 explains that *buntu installations usually make eCS unbootable by making a change in the 64 byte MBR partition table itself even when *buntu installation is to existing partition(s). I have no idea whether Grub2 installation is responsible for this, but it is something to watch for in 12.2's support and installation systems for Grub2. I don't recall ever having this happen from an openSUSE installation. It may well be *buntu's partitioning routine does this even when there's no reason to touch the tables, and has nothing to do with Grub2.
That's scary. I've seen programs which re-write table records rather than updating them, e.g., when the partition type is simply being changed. And IMO it's particularly risky if the table has already been created by another OS on the machine, a risk warned about in the partitioning utilities. (Years ago there were occasions where the only way I could get linux installed with grub was to first create a partition table from within Windows with PartitionMagic; wasn't there even once a time when SuSE was distributed with PM?) Anyway, if Ubuntu or grub2 is manipulating the table, be a good idea to know how and why. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (10)
-
Alin M Elena -
Andreas Jaeger -
Carlos E. R. -
Dennis Gallien -
Felix Miata -
Frederic Crozat -
jdd -
Martin Schlander -
Michael Chang -
Raymond Wooninck