grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 3/5] msdos-part: allow embedding in extended partition


From: Michael Chang
Subject: Re: [PATCH 3/5] msdos-part: allow embedding in extended partition
Date: Thu, 13 Sep 2012 13:26:27 +0800

2012/9/13 Lennart Sorensen <address@hidden>:
> On Wed, Sep 12, 2012 at 03:25:43PM +0800, Michael Chang wrote:
>> Installing on extended partition is one of scenarios for SUSE and
>> openSUSE installation. If the /boot resides in a logical partition,
>> the installer would propose installing bootloader to extended
>> partition.  For historic reasons, we prefer partition bootsector than
>> mbr, and use a generic mbr boot code to control the booting to active
>> partition. This is good or bad depends on what's the your view point,
>> but the point here is that for users who upgrade to grub2, we don't
>> want to break his current setup and still offer him the same options
>> he used to install grub. This is the major reason why we have to
>> install grub2 to extended partition.
>>
>> I could understand the patch is not good to be accepted , although it
>> works to solve our problem for now. However we'd like to feedback our
>> situation here and hope that grub2 could consider to support
>> installing to extended partition (I believe there must be more people
>> needs it) or point us a direction how to fix this problem cleanly.
>
> How much room is there in the filesystem for embedding the boot loader?
> It must depend on the filesystem in use too.

Yes. And thanks to the great grub2 would do the check for us. :)

For openSUSE supported filesystem, they're all allowing embedding and
grub|grub2 works pretty well.

I understand the drawbacks and pitfalls that having bootloaders
installed on a partition in use, it's fragile, file system dependent
and not work on lvm partiton.  The question here is that these maybe
not enough to convince people to use mbr as default proposed location,
especially to deal with multiboot setup. I illustrate some of the
problems below:

1. Booting after bios is thus fully controlled by a distro loader and
you couldn't boot into other distro once that *main* disto failed. The
active partition no longer worked.

2. You can't use chainload if you're not installed to a partition.
Grub2 has been done well to probe the foreign os config and knows how
to load the kernel and initrd directly, thus the chainload seems not
required. It's true but only if the foreign OS never changes his
config. There's a problem reported that foregin os not booting after
receiving kernel update. If using chainload then it would not have
problem because it's no depend to config change.

So we are keeping the "boot from partition .." scenario although we
know grub2 not encourage to do this. The question here is that we hope
installing to extended partition could be supported, as unfortunately
that's one of the scenario.

>
> What do you do when the disk is over 2TB in SUSE?  You must be using
> GPT instead for that.  Do you still try to embed the bootloader into
> the filesystem rather than use a GPT boot partition?

I agree with you that for gpt on legacy bios scheme, we should embed
bootloader to the boot partition. Given that generic(or standard) mbr
boot code is no longer to work on gpt (it always shows error, no
active partition ;), there's no good reason to embed bootloader on
partitions in use, assuming that the gpt introduces concept of boot
partition, and the old-day booting from msdos active partition no
longer worked or favored.

However syslinux which prefers living in a partition has provided
gptmbr, it maybe used to boot off a gpt partition. But IMHO for grub,
we should go for the bios boot partition (as it's name says GRAND
UNIFIED ..) and gptmbr might be optional for those still insist in
legacy way.

>
> After all getting rid of the block mapping in grub2 has made it a lot
> less fragile, although you can still do it if you force it.

Yes. Using block-list install is much more improved on 2.00. Thanks
for working on that. :)

Regards,
Michael

>
> --
> Len Sorensen
>
> _______________________________________________
> Grub-devel mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/grub-devel
>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]