How should 30_os-prober be working?
This deals with 30_os-prober and the os-prober package itself. In days of old, it was linux and initrd for linux systems (ignoring linuxefi and initrdefi). Fedora 21 is in the process of starting up and it brings in grub2-2.02-0.3 and os-prober-1.58-7. While these updates bring in improved support for /boot on btrfs subvols and LVMlvs, they also introduce using linux16 instead of linux and initrd16 instead of initrd. This last change breaks 30_os-prober so that no output is produced even when appropriate systems are identified. The problem is that os-prober was only recognizing linux/initrd and the grub.cfg had linux/16/initrd16. I have created an update for os-prober which now identifies the "type" of linux | linux16 (actually linux*) and initrd | initrd16 (actually initrd*) and linux-boot-prober now returns whatever linux* and initrd* matches to 30_os-prober. The question is: what should 30_os-prober do with this information? Currently, I simply use the "linux_type" and initrd_type" returned by linux-boot-prober (40grub2) as "operation" to be performed? Is this correct? Another approach would be to force the use of linux16 and initrd16 for the menuentry elements. BTW, since I have your attention, with GRUB_DISABLE_SUBMENU=true specified in /etc/default/grub, should 30_os-prober be generating submenus? Gene ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: How should 30_os-prober be working?
On 13 Jun 2014 13:47, "Gene Czarcinski" wrote: > > This deals with 30_os-prober and the os-prober package itself. > > In days of old, it was linux and initrd for linux systems (ignoring linuxefi and initrdefi). Fedora 21 is in the process of starting up and it brings in grub2-2.02-0.3 and os-prober-1.58-7. While these updates bring in improved support for /boot on btrfs subvols and LVMlvs, they also introduce using linux16 instead of linux and initrd16 instead of initrd. > > This last change breaks 30_os-prober so that no output is produced even when appropriate systems are identified. The problem is that os-prober was only recognizing linux/initrd and the grub.cfg had linux/16/initrd16. I have created an update for os-prober which now identifies the "type" of linux | linux16 (actually linux*) and initrd | initrd16 (actually initrd*) and linux-boot-prober now returns whatever linux* and initrd* matches to 30_os-prober. > > The question is: what should 30_os-prober do with this information? Currently, I simply use the "linux_type" and initrd_type" returned by linux-boot-prober (40grub2) as "operation" to be performed? Is this correct? > Just ignore if it's linux16. Fedora uses it only for some obscure hardware with obscure drivers for obscure reasons. Moreover their way of using it breaks compatibility with anything but BIOS. I tried to sit with them to find proper solution or at very least limit it to BIOS systems were unfruitful (mostly Fedora and Red Hat don't care) > Another approach would be to force the use of linux16 and initrd16 for the menuentry elements. > > BTW, since I have your attention, with GRUB_DISABLE_SUBMENU=true specified in /etc/default/grub, should 30_os-prober be generating submenus? > > Gene > > ___ > 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
multi-boot
In second 5.3 of the GNU GRUB 2.00 manual, there is a statement "Currently autogenerating config files for multi-boot environments depends on os-prober and has several shortcomings." I agree. Os-prober and the way it works with 30_os-prober is fragile at best and sometimes produces incorrect configurations. Personally, I use a variation of the manually configured option described in section 5.3: I install a very small system and then use /etc/grub.d/40_custom to provide my multi-boot options ... mostly by chainloading configfile. In section 5.3, there is also mention of "fixing it is scheduled for the next release" and "it" refers to os-prober. OK, what is the story? Is anything being done to improve easy configuration for multi-boot? Just what is the status of using/depending-on os-prober? Some distributions such as SUSE, Fedora, RHEL, Ubuntu (?) believe that users want some type of auto-config which enables them to bootup their old systems when a new install replaces the MBR and points to this newly install system. Comments? Gene ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
