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@xxxxxxxxx> 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
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
