From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050922 Fedora/1.0.7-1.1.fc4 Firefox/1.0.7
Description of problem:
Version 4.0.12-5.FC4 of shadow-utils hangs under busybox.
I use an updated install directory for a cluster to ensure that the freshly installed nodes are current as of the install date. If I use the latest update to shadow-utils the install hangs whenever groupadd or useradd is called. If I use the orignal shadow-utils package from FC4 the install works. I can switch to vt2 on the hung node, kill the shell o the hung command, either useradd or groupadd, and the install will continue to the next invocation and hang again. The useradd and groupadd commands never complete. Tested under ppc64 and x86_64. May be a 64 bit bug as haven't tested with a 32 bit system.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. create install directory (I use http install)
2. update install directory to latest updates (recreate hdlists)
3. try to perform an install (I use kickstart)
4. install will hang
Actual Results: Install hangs, never proceeds
Expected Results: Install should complete
It looks like 173241 solves the useradd problem, but does not address groupadd.
Does this problem still exist?
Yes. Tested both x86_64 and ppc64. I have not had the time to test any 32 bit
platforms against this issue. This must be fixed for FC5test1 or the installer
would never complete.
Could u send strace output?
I'm seeing this on the current set of FC4 packages (as of today) -- and not just
in busybox. After a fresh minimal install from scratch on an x86_64 system, then
doing a yum upgrade, yum freezes in the install script for slocate -- unkillably
hug on the groupadd.
So, I tried generating an install tree with all the updated packages merged in,
but this results in an uninstallable tree: somewhere in the rpm transaction, a
useradd or groupadd will hang. (Unlike what Shawn reports above, the process
won't die with kill or kill -9.) Oddly, this isn't at the _first_ useradd or
groupadd -- generally several succeed before one hangs.
I must admit, I am terribly perplexed.
I have an identical system which I've installed with i386 FC4, and that works fine.
It's hard to strace the hangs-during-install case 'cause strace isn't in the
install image. But I'll see what I can do....
I can confirm that regressing to the shadow-utils that comes with FC4 (4.0.7-9)
makes this issue go away. Not that that's a solution. :)
Shawn, if I understand your comments, you're also seeing hangs when called
directly from the pre and post-install scripts of rpms as installed by anaconda,
not just when run from busybox, right?
If so, I'd like to change the bug summary here to match.
Also, in my experience, it works _some_ of the time but then inevitably hangs.
(In a somewhat repeatable way -- always in the same place if the conditions are
the same, but change the setup and that same call might succeed....) Does this
match what you're saying, or do you always get a hang on the first package to
call one of these utils?
Hmmm -- I think this may be a dup of bug #170087 (except not really a dup, as
that problem was resolved in RHEL4 but the problem persists in FC4. And also,
very different shadow-utils versions....)
So, bug #170087 implies that if run under a newer kernel, the problem won't
occur. So, theoretically, if one rebuilds the installer with the new kernel,
this problem will go away too. (That's a sufficient workaround for me, although
without an update, this still may bite someone who does a new install of stock
FC4 and then tries yum upgrade.)
Now, if only I can get bug #173296 to keep me from actually _booting_ a new
kernel on this system. :)
Sorry to be so slow updating/tracking this bug.
I believe that if I coould make a usable updated installer image, then I would
not be plagued by this bug. I have been completely unsuccessful in creating an
update PPC64 install image, so have resorted to _not_ updating shadow-utils on
my compute nodes in my cluster.
I see the hang during install from an updated install tree using a stock install
image, after shadow-utils is installed, and the first rpm install that calls
either useradd or groupadd.
AFAIK, all major audit patches were done by 2.6.14. What kernel are you using?
Presumably the 2.6.11 used by the shipped installer image.
2:4.0.12-2 is the beginning of audit support in shadow-utils for FC-4. This was
Aug 30. Another adjustment was made around Sept 20. So, it was an upgrade and
depends on the kernel that was shipping at that time. kernel-2.6.12-1.1456 seems
like the candidate. Hope this helps.
Well, it helps a little bit, but unless there's going to be a respin of the FC4
isos, for most people, that means the answer is "um, FC4 is broken for new
installs now; wait for FC5".
All the pieces that were in the shipped FC-4 isos were tested together and work.
So, it should not broken for new installs. If you replace packages in the isos
yourself, you have to know all the dependencies between userspace and kernel or
you could have problems.
I suppose a patch could be created that works around the problem, but its better
to be running on a newer kernel.
Steve -- except it breaks when you first do a yum upgrade (and presumably
up2date, although I didn't test that), unless you know that you must exclude
shadow-utils from the update, reboot with the new kernel, and only then do
another update which installs the new shadow-utils.
At the very least, shadow-utils should have a Conflicts: kernel < 2.6.12, which
should at least provide the clue that this needs to happen.
However, it also breaks any kickstart installs which do "yum -y upgrade" in the
postinstall. And the conflicts statement won't help that.
Anything further on this? Thanks.
A kind of disturbing update:
Everything works fine with kernel-2.6.15-1.1833_FC4 and
shadow-utils-4.0.12-8.FC4, but when I updated to kernel-2.6.16-1.2069_FC4, the
installer reliably completely hangs when doing a groupadd at some point. Unlike
the previous, the system is completely hung -- can't move the mouse cursor or
I haven't seen this running groupadd on a installed system that was merely
updated to the new kernel, so that's a bit weird. But the freeze is reliable
across a lot of different hardware (i686, x86_64, SMP/single, ATI/Intel/nv
I'm currently rebuilding with the FC5 version of shadow-utils to see if that helps.
Argh. That turns out to be a pain because of the libselinux stuff.
Instead, will first try rebuilding with the 4.0.3 shadow-utils package.
(4.0.7, I mean.)
I'm going to file a new bug for this new issue.
Oh, hey, reverting to 4.0.7 totally _did not_ fix the problem. So this _is_ a
new thing. So in short, never mind comments 19-22. But that doesn't mean the
original problem is fixed....
I'm going to go ahead and close this as "wontfix", as FC4 is reaching the end of
core support, and not fixing it is clearly the bug assignee's decision here.
But in the future, PLEASE try not to release any more updates which make it
impossible to simply install a fresh Fedora Core system and bring it up to
current patchlevel with one update. (See comment #17.)
This update really was broken and it's disappointing that it wasn't fixed.