Mailinglist Archive: opensuse-factory (715 mails)
| < Previous | Next > |
Re: [opensuse-factory] Grub2 as default bootloader for installation
- From: Dennis Gallien <dwgallien@xxxxxxxxx>
- Date: Thu, 8 Mar 2012 10:26:17 -0500
- Message-id: <201203081026.17235.dwgallien@gmail.com>
On Thursday, March 08, 2012 12:12 AM Felix Miata wrote:
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@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-factory+owner@xxxxxxxxxxxx
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@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-factory+owner@xxxxxxxxxxxx
| < Previous | Next > |