On Nov 7, 2012, at 2:40 AM, Felix Miata <mrmazda@xxxxxxxxxxxxx> wrote: > > It only "squelches" when its installer finds MBR code that is incompatible with the legacy PC BIOS standard, which is to say code that results from installing any portion of Lilo or Grub in the MBR code space. Isn't it true that grub2-install always replaces this 440 bytes of code in the MBR code region? > Windows' bootloaders are well enough understood that, for single HD BIOS systems at least, it should require no more than a relatively simple algorithm to create an additional entry in the Windows boot menu, forcing its menu to appear at each boot, and allowing the user to choose between Windows and Linux at boot time. It would be nice to leverage this instead of clobbering it with GRUB, however it can't directly bootload linux. So while it could be the boot manager, it would have to redirect the process to a linux capable bootloader. And that's a bit problematic… > Once this is done, it should make no significant difference whether Windows "squelches" the MBR by flipping two partition table bits. After it does so, it's a very simple and quick process to unflip them if it is desired to restore master boot loader status to the Linux bootloader installed on a Linux native primary partition. Unfortunately ext[234] lack a sufficiently large enough offset (or a modifiable offset) into which an up to 64KB GRUB bootloader (stage 1.5 or core.img) can reside. To put the bootloader on a linux primary partition using ext[234] means using blocklists from the outset and that means to expect fragility in bootloading. On Nov 7, 2012, at 3:08 AM, Adam Williamson <awilliam@xxxxxxxxxx> wrote: > he criteria. It's a bit of a fudge, > but anaconda team considers resizing fundamentally too fragile to > guarantee, it's too easy for it to go wrong. I think it's a good idea to avoid it. On Nov 7, 2012, at 9:31 AM, Jóhann B. Guðmundsson <johannbg@xxxxxxxxx> wrote: > > > Do you at least test all the GA supported releases of Microsoft Windows which might reside on the users machine when doing that test in a VM since HD partitioning differs between release as got mentioned earlier in this thread? Btu what are you testing for, or against? Again regardless of the version of Windows, the volume being ignored is NTFS in any case (except XP where it could maybe be FAT32). But this is supposed to be ignored no matter what. So all you really need is a check to make sure non-targeted volumes weren't written to. You don't actually need every possibly version of Windows tested against. Chris Murphy -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
