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

grub2, 30_os-prober, os-prober: A Proposal



While not specifically anaconda released, this mailing list was suggested to have a discussion on a proposal I would like to make. While I am writing this message, another individual has also been involved: Heydayat Vatankhah <hedayatv gmail com> who happens to be the Fedora package maintainer for the os-prober package.

Currently, grub2's 30_os-prober and the os-prober package as implemented in rawhide are seriously broken. They simply do not work and an OS newly installed by anaconda based on the current rawhide will be unable to boot previously installed OSs. The BZ reports and attached patches to fix the problem are here:
https://bugzilla.redhat.com/show_bug.cgi?id=1108296
https://bugzilla.redhat.com/show_bug.cgi?id=1108344

It takes both updates to fix things. Either one by themselves will not break things any worse than they are.

This is not the first time that Heydayat and I have had problems with os-prober and we have sent the fixes upstream but they have been ignored. For example:
https://bugzilla.redhat.com/show_bug.cgi?id=888341
and note the response from upstream debian.

Anyway, Heyayat has previously mentioned forking os-prober and I believe that the time has com to do just that.

1. Create a new package os-prober-ng which takes the current os-prober-1.58-7 in rawhide plus my new patch plus a couple of the patches in the debian os-prober repository and use that as the basis for os-prober-ng-0.1. Naturally, lots of files will be renamed so that they are different from the files in os-prober. The intent is not to exactly replace os-prober but simply offer what I believe will be a better product. Any better suggestions for a different name are welcome.

2. The new os-prober-ng will be an information gathering tool intended to help configure a bootloader. For the most part, the current "os-prober" program looks to be fairly complete as is (except for a bug I am working on). However, it runs a number of tests for obscure operating systems which lengthen the time that it takes to run grub2-mkconfig. This includes qnx, lsb, hurd, minux, and Haiku. I suggest these be dropped or, at the very least, put into a separate binary rpm for optional installation.

3. An integral part of the current os-prober is the linux-boot-prober which gathers the information needed to create all those wonderful menuentry items by 30_os-prober. I have an alternative to propose (see below) and therefor intend to make this another optional binary rpm.

4. A significant new program will use the path to a systems rootfs and return the path to the grub.cfg for that system instance. This info will be used to "chain load" grub2 configuration files.

5. It is interesting that extlinux (syslinux) also has the capability to chain-load configuration files. Therefore, another optional program will return the information needed to create chain-loading extlinux configuration files.

6. Thanks to some prodding and information provided by Chris Murphy, I believe I have figured out a way to chain-load UEFI configuration files so that you will be able to have multi-boot fedora installations on a UEFI system. Right now this is based on some hand-crafted grub2 files but it does appear to work and I have a qemu-kvm-ovmf UEFI system with both Fedora 20 and Fedora 21 installed on a single disk (naturally it is BTRFS partitioned ;) ). Both boot and run in secure-boot mode.

Beside os-prober-ng, I am proposing a new package which I call 'multi-boot-configtool". This package will use the outputs of os-prober-ng to create grub2 and (later) extlinux configurations capable of booting previously installed systems.

1. The software will use /etc/grub.d/* files to support most of the automation. However, there will be the capability to run some of it independent of grub2 and grub2-mkconfig.

2. The package will have a /etc/default/multi-boot-configtool file to store optional runtime variables.

3. The package will support creating configurations to "chainloader +1" MBR, BIOS Boot partitions and EFI system partitions.

4. There will be three types of (optional) configuration files:
a) custom.cfg which is in the same directory as grub.cfg and is invoked dynamically by /etc/grub.d/41_custom,
  b) inline in a manner similar to the way 30_os-prober does, and
  c) into a file similar to /etc/grub.d/40_custom.

5. There will be a 30_multi-boot which will be a somewhat re-written 30_os-prober. I am also proposing that grub2 drop 30_os-prober and that its functionality be picked up by multi-boot-configtool. Actually, I would prefer to just drop the creation of these menuentry items pointing to kernels and initrds and simply chainload configuration files. Comments here would be appreciated.

Timeline: I would like to see this in Fedora 21 but that is likely wishful thinking on my part. As I see them, you will be able to install both os-prober-ng and multi-boot-configtool in parallel with existing packages so they will not be on a critical path.

Comments?  Suggestions?

BTW, I plan to attempt establishing some communication with the upstream developers/maintainers of os-prober as well as the grub2 developers to get their reaction to my proposals. Anyone wishing to be part of those discussions, please name yourselves.

Gene


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