http://bugzilla.suse.com/show_bug.cgi?id=1011529 http://bugzilla.suse.com/show_bug.cgi?id=1011529#c1 --- Comment #1 from Michel Normand --- Created attachment 703148 --> http://bugzilla.suse.com/attachment.cgi?id=703148&action=edit logs from /var/log -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1011529 Michel Normand changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |k0da@opensuse.org -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1011529 http://bugzilla.suse.com/show_bug.cgi?id=1011529#c4 --- Comment #4 from Michel Normand --- (In reply to Michel Normand from comment #3)

[CUT]

I would need help to continue investigation.

if I try to chroot to /mnt and kill hung ofpathname then parent is making cleanup that umount, so unable to manually call ofpathname to better understand original hung failure. === 2:linux-ac6f:~ # chroot /mnt linux-ac6f:/ # ps axf ... 17473 pts/0 S+ 0:00 | \_ /usr/sbin/grub2-install --target=powerpc-ieee1275 --force --skip-fs-probe /dev/disk/by-id/scsi-0QEMU_QEMU_HARDDISK_mpath1-part1 17489 pts/0 S+ 0:00 | \_ /bin/bash /usr/sbin/ofpathname /dev/mapper/0QEMU_QEMU_HARDDISK_mpath1 17505 pts/0 S+ 1:38 | \_ /bin/bash /usr/sbin/ofpathname /dev/mapper/0QEMU_QEMU_HARDDISK_mpath1 ... linux-ac6f:/ # kill -9 17505 linux-ac6f:/ # ls /usr/sbin/ofpathname /usr/sbin/ofpathname linux-ac6f:/ # /bin/bash /usr/sbin/ofpathname /dev/mapper/0QEMU_QEMU_HARDDISK_mpath1 sed: can't read /proc/cpuinfo: No such file or directory grep: /proc/cpuinfo: No such file or directory grep: /proc/cpuinfo: No such file or directory grep: /proc/cpuinfo: No such file or directory /usr/bin/find: '/sys/class/net': No such file or directory ofpathname: Could not retrieve Open Firmware device path for logical device "/dev/mapper/0QEMU_QEMU_HARDDISK_mpath1". === -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1011529 http://bugzilla.suse.com/show_bug.cgi?id=1011529#c6 --- Comment #6 from Michel Normand --- yast parameter passed to grub2-install /dev/disk/by-id/scsi-0QEMU_QEMU_HARDDISK_mpath1-part1 is changed by this last one as passed to ofpathname /dev/mapper/0QEMU_QEMU_HARDDISK_mpath1 so next step is to understand why this change in grub2-install === linux-0uxa:/ # ps axf ... 15670 ? S+ 0:00 | \_ /usr/sbin/grub2-install --target=powerpc-ieee1275 --force --skip-fs-probe /dev/disk/by-id/scsi-0QEMU_QEMU_HARDDISK_mpath1-part1 15686 ? S+ 0:00 | \_ /bin/bash /usr/sbin/ofpathname /dev/mapper/0QEMU_QEMU_HARDDISK_mpath1 15703 ? S+ 7:48 | \_ /bin/bash /usr/sbin/ofpathname /dev/mapper/0QEMU_QEMU_HARDDISK_mpath1 === linux-0uxa:/ # ls -l /dev/mapper total 0 lrwxrwxrwx 1 root root 7 Nov 23 15:00 0QEMU_QEMU_HARDDISK_mpath1 -> ../dm-0 lrwxrwxrwx 1 root root 7 Nov 23 15:00 0QEMU_QEMU_HARDDISK_mpath1-part1 -> ../dm-1 lrwxrwxrwx 1 root root 7 Nov 23 15:00 0QEMU_QEMU_HARDDISK_mpath1-part2 -> ../dm-2 lrwxrwxrwx 1 root root 7 Nov 23 15:00 0QEMU_QEMU_HARDDISK_mpath1-part3 -> ../dm-3 lrwxrwxrwx 1 root root 7 Nov 23 15:00 0QEMU_QEMU_HARDDISK_mpath1_part1 -> ../dm-1 lrwxrwxrwx 1 root root 7 Nov 23 15:00 0QEMU_QEMU_HARDDISK_mpath1_part2 -> ../dm-2 lrwxrwxrwx 1 root root 7 Nov 23 15:00 0QEMU_QEMU_HARDDISK_mpath1_part3 -> ../dm-3 crw------- 1 root root 10, 236 Nov 23 14:59 control linux-0uxa:/ # ls -l /dev/disk/by-id/scsi-* lrwxrwxrwx 1 root root 9 Nov 23 14:59 /dev/disk/by-id/scsi-0QEMU_QEMU_CD-ROM_cd0 -> ../../sr0 lrwxrwxrwx 1 root root 10 Nov 23 15:00 /dev/disk/by-id/scsi-0QEMU_QEMU_HARDDISK_mpath1 -> ../../dm-0 lrwxrwxrwx 1 root root 10 Nov 23 15:00 /dev/disk/by-id/scsi-0QEMU_QEMU_HARDDISK_mpath1-part1 -> ../../dm-1 lrwxrwxrwx 1 root root 10 Nov 23 15:00 /dev/disk/by-id/scsi-0QEMU_QEMU_HARDDISK_mpath1-part2 -> ../../dm-2 lrwxrwxrwx 1 root root 10 Nov 23 15:00 /dev/disk/by-id/scsi-0QEMU_QEMU_HARDDISK_mpath1-part3 -> ../../dm-3 lrwxrwxrwx 1 root root 9 Nov 23 14:59 /dev/disk/by-id/scsi-SQEMU_QEMU_HARDDISK_mpath1 -> ../../sdb === linux-0uxa:/ # rpm -qf /usr/sbin/grub2-install grub2-2.02~beta3-15.2.ppc64le === -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1011529 Michel Normand changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mchang@suse.com -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1011529 http://bugzilla.suse.com/show_bug.cgi?id=1011529#c9 Michel Normand changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |msuchanek@suse.com --- Comment #9 from Michel Normand --- (In reply to Michel Normand from comment #8)

I have an RFC patch for ofpathname https://github.com/nfont/powerpc-utils/pull/14

but I do not know if this is the correct way to solve this problem.

I verified with a DUD file that the above patch is sufficient to avoid the Yast hung on "Saving bootloader configuration" -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1011529 http://bugzilla.suse.com/show_bug.cgi?id=1011529#c11 --- Comment #11 from Michael Chang --- (In reply to Michel Normand from comment #7)

Created attachment 703548 [details] grub2-install debug trace

I am wondering if the attached xx3.log debug trace would explain why grub2-install changed from input /dev/disk/by-id/scsi-0QEMU_QEMU_HARDDISK_mpath1-part1

It's udev device name (for a partition)

to /dev/mapper/0QEMU_QEMU_HARDDISK_mpath1

It's (kernel's) "canonical" device name (for a disk) The udev names are translated into "canonical" names under /dev/... and then processed internally for their name patterns being "known" to grub2. Otherwise you have to teach grub to know each and every different name patterns changing all the time with user-land tools applying different rules/policies .. The device mapper is probably the only exception to use names under/dev/mappper/... as it's more human readable than /dev/dm-[0-9]+ and also the pattern is understood.

when calling ofpathname script.

Why does the name matter here ? Thanks. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1011529 http://bugzilla.suse.com/show_bug.cgi?id=1011529#c13 --- Comment #13 from Michal Suchanek --- 'firmware' here is Linux most likely The problem is with ofpathname and turned up by a change to grub scripts that started calling it afaik. So what does the grub script expect to get if there are multiple ways to reach the disk (provided it's not a deficiency of ofpath and there are in fact multiple equally canonical of names of the disk)? -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1011529 Imobach Gonzalez Sosa changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |igonzalezsosa@suse.com Flags| |needinfo?(msuchanek@suse.co | |m) -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1011529 http://bugzilla.suse.com/show_bug.cgi?id=1011529#c16 Michal Suchanek changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|yast2-maintainers@suse.de |k0da@opensuse.org --- Comment #16 from Michal Suchanek --- Assigning maintainer. Please integrate patch from comment #8 or reassign to me. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1011529 Michael Chang changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jloeser@suse.com -- You are receiving this mail because: You are on the CC list for the bug.