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: Lennart Sorensen
Subject: Re: [PATCH 3/5] msdos-part: allow embedding in extended partition
Date: Thu, 13 Sep 2012 11:52:19 -0400
User-agent: Mutt/1.5.20 (2009-06-14)

On Thu, Sep 13, 2012 at 01:26:27PM +0800, Michael Chang wrote:
> 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.

Makes sense.

> 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.

I personally have never understood the desire for multiple linux installs
on a machine, and hence have never had a reason to have more than one
grub on the system.  Any other OS for me has always been one windows
install (and I don't have those very often either).

I used to install grub to the partition because whenever you reinstalled
windows it would overwrite the MBR and being able to change the active
partition to get back to linux was handy.  But since windows 95/98 aren't
common anymore, the need to reinstall windows every 3 to 6 months to keep
it working seems to have gone away, so now I just have grub in the MBR.
But that's just how I do things.

> 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.

As far as I am aware, you can tell grub to force using the blockmap,
but it does require passing the appropriate force argument to do it.

> 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.

gpt does have a specific partition type to use for bootloaders, and grub
will use it automatically.  It works great.

Of course that again gives you back the problem of chainloading,
since there can be only one such partition on a given system I suspect.
I could be wrong, perhaps you could have multiple, but keeping track of
which is which sounds complicated.

> 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.

I believe gptmbr is to allow a legacy bios system to load the mbr and
execute code that will go do the right thing for a gpt disk (which a
legacy bios doesn't understand of course).

> >
> > 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. :)

Well someone did.  I mainly use grub, and report bugs when I find them
(mostly on IBM powerpc since x86 generally just works).  After much
discovery of endianess bugs and other fun stuff grub2 actually works
quite well on ibm powerpc machines now.  The serial console display is a
bit messed up for the menu still, although I haven't looked into why yet.
Perhaps I should.  I think they use ANSI rather than vt100 or something.

-- 
Len Sorensen



reply via email to

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