Top showed that grub2-probe took up 100%+- cpu usage, when running grub2-install, and they never stopped. However sys-boot/grub-2.00-r1 is fine to perform grub2-install. PS. The root partition is of Reiserfs and /boot is not separated. Reproducible: Always Steps to Reproduce: 1. install sys-boot/grub-2.00-r2 2. do grub2-install /dev/sda 3. Actual Results: grub2-install keeps running Expected Results: grub2-install should finish execution and ehco "Installation finished. No error reported."
Are you absolutely certain that -r1 works fine, and -r2 does not?
Grub2 installation fails. grub2-install --no-floppy /dev/sda Path `/boot/grub2' is not readable by GRUB on boot. Installation is impossible. Aborting. Gpt and mdadm soft raid, metadata 0.90. lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 931.5G 0 disk ├─sda1 8:1 0 256M 0 part ├─sda2 8:2 0 256M 0 part │ └─md1 9:1 0 256M 0 raid1 /boot ├─sda3 8:3 0 100G 0 part │ └─md2 9:2 0 100G 0 raid1 / ├─sda4 8:4 0 8G 0 part │ └─md3 9:3 0 8G 0 raid1 [SWAP] └─sda5 8:5 0 823G 0 part └─md4 9:4 0 823G 0 raid1 sr0 11:0 1 389.8M 0 rom loop0 7:0 0 294.9M 1 loop Number Start (sector) End (sector) Size Code Name 1 2048 526335 256.0 MiB EF02 BIOS boot partition 2 526336 1050623 256.0 MiB FD00 Linux RAID 3 1050624 210765823 100.0 GiB FD00 Linux RAID 4 210765824 227543039 8.0 GiB FD00 Linux RAID 5 227543040 1953525134 823.0 GiB FD00 Linux RAID
grub2-probe -t fs /boot/grub2 grub2-probe: error: unknown filesystem.
(In reply to comment #2) Your issue seems to be unrelated. I suggest you ask for help in #grub on Freenode or on the help-grub mailing list. http://www.gnu.org/software/grub/grub-mailinglist.html
Created attachment 345732 [details] log from grub2-probe (2.00-r2) Same bug here as the original poster. I can confirm that grub-2.00-r1 works flawlessly and grub-2.00-r1 hangs infinitely. "grub2-probe -d /dev/sda1 -vvv" from the grub-2.00-r2 version gives the attached output Basically it ends with: grub-core/kern/emu/hostdisk.c:886: reusing open device `/dev/sda1' grub-core/kern/emu/hostdisk.c:886: reusing open device `/dev/sda1' grub-core/fs/zfs/zfs.c:953: check 2 passed here it hangs, so it might be connected to some zfs detection code?
ryao: I believe I said I would be sending any bugs relating to this patch in your direction. :)
Would someone affected by this post the output of `emerge --info grub:2`?
Actually, could we also get a backtrace? # Rebuild grub:2 with debug information: USE=custom-cflags FEATURES='-buildpkg -ccache installsources nostrip splitdebug' CFLAGS='-O0 -ggdb3' emerge -1va grub:2 # Start gdb gdb grub2-probe # Run grub2-probe run -d /dev/sda1 -vvv # Type Ctrl+C to get a prompt back. bt Please post what the `bt` command to gdb prints.
Created attachment 345844 [details, diff] Patch to revert unnecessary nvlist_find_value() rewrite After analyzing the log, it looks like we have an infinite loop in nvlist_find_value(). That was rewritten to better match the Illumos GRUB code in the following patch from the patch set that was squashed to create the feature flags patch: https://github.com/maxximino/grub2/commit/58344034e40218b20500fa2936eb4d7d019e1e88 Unfortunately, I have spotted some subtle issues with the rewrite of this function, which might or might not explain this issue. Without the backtrace, it is difficult to tell for certain. However, this change was unnecessary, so it is safe to revert. I have attached a patch that does this. Please drop it into /etc/portage/patches/sys-boot/grub-2.00-r2/grub-2.00-zfs.patch, rebuild grub:2 and let me know what happens.
With the patch applied grub2-probe works fine. Do you need some debug output?
(In reply to comment #10) > With the patch applied grub2-probe works fine. > > Do you need some debug output? That is everything that we needed to know. Thanks. I am CCing Massimo Maggi. He is the person who ported the feature flags support from Illumos. I have also opened an issue on the maxximino/grub2 bug tracker for this. As I said on the upstream bug tracker: The nvlist_find_value() rewrite caused a regression in grub2-probe on non-ZFS systems. It seems that systems that happen to have a correct magic number in the right place will be handled as if they had proper nvlists, even when the data is nonsense. This can cause an infinite loop. With that said, I would have reverted the nvlist handling changes to avoid affecting grub2-probe had it occurred to me that it relied upon it. I will talk to floppym about how we will correct this issue. It will most likely involve an ebuild revision with a new version of the feature flags patch applied.
I have committed files/grub-2.00-zfs-feature-flag-support-r1.patch to the main tree in preparation for sys-boot/grub-2.00-r3. I am reassigning the bug to Mike Gilbert for resolution.
Created attachment 346592 [details, diff] Tentative patch for fixing the problem with current code. I'm not able to reproduce the problem, however I've found a possibile root cause of this problem. There is someone affected by this problem that wants to help me in testing the attached patch? The problem *might* also affect upstream code. Also, a debug log (grub2-probe -d /dev/sda1 -vvv) of a WORKING grub on the affected partition is appreciated. Thanks.
+*grub-2.00-r3 (27 Apr 2013) + + 27 Apr 2013; Mike Gilbert <floppym@gentoo.org> +files/grub-2.00-dmraid.patch, + +files/grub-2.00-texinfo.patch, +grub-2.00-r3.ebuild: + Resolve infinte-loop in grub-probe #462740 and fix dmraid support #430748. + Also fix issue with texinfo-5.1. +
