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