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