Description of problem: An attempt to use mkdumprd goes nowhere. Tracing this shell scripts reveals the following infinite loop: .... + device=sdc ++ findone -L /sys/block -maxdepth 2 -type d -name sdc ++ find -L /sys/block -maxdepth 2 -type d -name sdc -print -quit + sysfs=/sys/block/sdc + '[' -z /sys/block/sdc ']' + pushd /sys/block/sdc + findstoragedriverinsys + '[' '!' -L device ']' ++ readlink ./device + cd ../../../5:0:0:0 /sbin/mkdumprd: line 367: cd: ../../../5:0:0:0: No such file or directory + '[' '!' -f modalias ']' + '[' /sys/block/sdc = /sys/devices ']' + cd .. + '[' '!' -f modalias ']' + '[' /sys/block = /sys/devices ']' + cd .. + '[' '!' -f modalias ']' + '[' /sys = /sys/devices ']' + cd .. + '[' '!' -f modalias ']' + '[' / = /sys/devices ']' + cd .. + '[' '!' -f modalias ']' + '[' / = /sys/devices ']' + cd .. + '[' '!' -f modalias ']' + '[' / = /sys/devices ']' + cd .. .... and we go nowehere. The problem is that /sys/block/sdc itself is a symbolic link and 'cd ../../../5:0:0:0' may or may not work depending how we got there. To get around the issue I replaced a calculation of modalias with: modalias=$(cat $(find /sys/devices -name modalias | \ grep $(basename $(readlink ./device)))) This helped to get around this obstacle; but I do not know for sure that results will be always correct. It also looks that KDUMP_CONFIG_FILE has to be assigned one way or another to something valid or an assignment to options2 with get stuck with sed blocking by waiting on stdin. If so then KDUMP_CONFIG_FILE value should be checked Version-Release number of selected component (if applicable): kexec-tools-2.0.0-38.fc15.x86_64 How reproducible: on all attempts to use mkdumprd before I modified it like the above. Additional info: Even more confusing is that trying from a shell prompt 'pushd /sys/block/sdc' with a follow-up 'cd ...' worked just fine and only inside this script there was "No such file or directory" and a subsequent looping.
Just out of curiosity, does the pusd ...; cd .. command sequence work in the shell script if selinux is disabled?
(In reply to comment #1) > Just out of curiosity, does the pusd ...; cd .. command sequence work in the > shell script if selinux is disabled? As a matter of fact selinux was disabled all the time. "pusd ..." looks like a typo. Anyway - after changing that what do you mean by "work"? AFAICS the problem is that backing up with multiple ".." does not allow to predict where we eventually end up. After 'pushd /sys/block/sdc' one would naively think that 'cd "../../../5:0:0:0"' and 'cd ../../..; cd "5:0:0:0"' would be equivalent. Guess what? Sometimes they are, even if you do not want to, and sometimes they don't and I have no idea how to predict what will happen. Maybe something of that sort would work better if you do not want to use find: pushd /sys/block/sdc dname=$(basename $PWD) cd /sys/block # possibly check that $dname gives a link here modalias=$(cat $(dirname $(dirname $( readlink $dname )))/modalias) # likely something like this # modalias=$(cat $(readlink $dname )/../../modalias) # would be ok too echo $modalias [ -n "$modalias" ] || trouble
I'm fine with using the find command, I'm just trying to figure out how cd ../../../5:0:0:0 didn't work, given that we got there through /sys/block/sdc
(In reply to comment #3) > I'm just trying to figure out how cd > ../../../5:0:0:0 didn't work, given that we got there through /sys/block/sdc Why it should work? If you are in /sys/block/sdc then 'cd ../../../' should land you in / and there is no 5:0:0:0 there. That sometimes it does work, due to a symlinks maze, is just an accident which cannot be relied upon (as traces from running "sh -x /sbin/mkdumprd ..." amply demonstrate). There is also an issue of a value of KDUMP_CONFIG_FILE. If this is required then it should be checked. If this is optional then a corresponding sed call should be conditional on [ -r $KDUMP_CONFIG_FILE ].
gah! Sorry, I don't quite know what I was thinking, yes thats perfectly clear now, and it makes sense to me, I'll commit that shortly As for the sed call, yes KDUMP_CONFIG_FILE does need to exist. It shouldn't be a problem as its included in the rpm, but I'll add that check in a separate bug. Thanks!
(In reply to comment #5) > and it makes sense to me, I'll commit that shortly Thinking about that more - in case you would decide to use the first approach, i.e. "find /sys/devices ..." you likely should grep for patterns like "/5:0:0:0" instead of just "5:0:0:0". It is conceivable that on some "enterprise" installation one can have "15:0:0:0", and similar, too. Maybe walking down links from /sys/block is more reliable?
In 'rpm -q --changelog kexec-tools': > * Wed Sep 22 2010 Neil Horman <nhorman> - 2.0.0-39 > - fix finding modalias/mkdumprd hang (bz 635893) A modification in kexec-tools-2.0.0-39 does not work because in findstoragedriverinsys there is still this offending code: cd $(readlink ./device) while [ ! -f modalias ]; do [ "$PWD" = "/sys/devices" ] && return cd .. done and that 'cd' above ends with "No such file or directory" and we quickly end up in an infinite loop + cd .. + '[' '!' -f modalias ']' + '[' /sys = /sys/devices ']' + cd .. + '[' '!' -f modalias ']' + '[' / = /sys/devices ']' + cd .. because there was no 'modalias' around nor we ever ended in /sys/devices. Makes a system with enabled 'kdump' service and no accepted 'initrd...kdump.img' quite unbootable as the whole things is getting stuck. I should have possibly supply a patch but I did not as I was not sure if I had a proper fix. I still think that what I wrote was not good enough (see comment 6). Moreover every time I am trying to run 'sh -x /etc/init.d/kdump start' I see something like that: + echo 'Rebuilding /boot/initrd-2.6.36-0.26.rc5.git4.fc15.x86_64kdump.img' Rebuilding /boot/initrd-2.6.36-0.26.rc5.git4.fc15.x86_64kdump.img + /sbin/mkdumprd -d -f /boot/initrd-2.6.36-0.26.rc5.git4.fc15.x86_64kdump.img 2\ .6.36-0.26.rc5.git4.fc15.x86_64 basename: missing operand Try `basename --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. That is somewhat mysterious as when tracing mkdumprd offending command I am hitting an infinite loop before that "basename: missing operand" has a chance to show up. Commenting an offending loop makes /sbin/mkdumprd run for me (but again see comment 6).
Oh, after removing that nasty loop I do not see "basename: missing operand" complaints again so this looks like that it was coming from a 'modalias' variable assignment. It will do that as after a few "cd .." we will get nothing from "readlink ./device". That would mean that non-traced /sbin/mkdumprd gets stuck somewhere else but I have no idea where. It surely never terminates.
*** Bug 654431 has been marked as a duplicate of this bug. ***
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 19 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.