Re: [PATCH 3/5] msdos-part: allow embedding in extended partition
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 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH 3/5] msdos-part: allow embedding in extended partition
2012/9/5 Vladimir 'φ-coder/phcoder' Serbinenko phco...@gmail.com: On 09.07.2012 22:02, Jiri Slaby wrote: From: Michael Chang mch...@suse.com The same as in the previous patch, add a support for installing grub into an extended partition. Here, we do not ignore extended partitions anymore. Instead we call a hook that makes sure we have the partition when installing. This is a kludge and extended partition is just a technical artifact. It needs a very good reason to allow installing on those. 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. Thanks, Michael -- Regards Vladimir 'φ-coder/phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH 3/5] msdos-part: allow embedding in extended partition
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. 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? 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. -- Len Sorensen ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH 3/5] msdos-part: allow embedding in extended partition
2012/9/13 Lennart Sorensen lsore...@csclub.uwaterloo.ca: 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 Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH 3/5] msdos-part: allow embedding in extended partition
On 09.07.2012 22:02, Jiri Slaby wrote: From: Michael Chang mch...@suse.com The same as in the previous patch, add a support for installing grub into an extended partition. Here, we do not ignore extended partitions anymore. Instead we call a hook that makes sure we have the partition when installing. This is a kludge and extended partition is just a technical artifact. It needs a very good reason to allow installing on those. -- Regards Vladimir 'φ-coder/phcoder' Serbinenko signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
