Description of problem: In bug 143046, we tracked down a problem with the 32-bit compatibility glibc %post script calling "telinit u" -- and running from the context of firstboot, called from an init script. We will probably come up with a temporary hack to fix this for RHEL4 pre-rc2 or GA, but it sounds like the right fix is in init.
To clarify, what we think is the reduced basic test case is an init script that does "telinit u". That makes init re-exec itself, and then it does something like go on to the "rc 2" while the "rc 1" is still running or something along those lines. This came up in the context of firstboot installing the i386 glibc rpm on ia64, where there really was never going to be any need to restart the init since it doesn't actually use the 32-bit libraries. But this would also come up in any situation where an inittab script caused "telinit u" for any other reason, such as if firstboot were to do over-the-network rpm updates and possibly upgrade glibc from inside an init script. I looked at init and it seems to me that the re-execing code could actually handle this case fine, but I have only a cursory understanding of init's real control flow. It looks to me like it might be sufficient just to add the WAITING flag to the `flags' table of flags that get pickled into the state preserved across re-execs. That is, the re-execing init would just know that it was in the middle of running the "rc 1" inittab command or whatever it is, and should wait for it to finish before doing anything else. Unless we do intend to have glibc upgrades from firstboot in RHEL4 at some point, then the workaround of avoiding the telinit u is the safe bet. Noone is in a hurry to perturb init's subtle behaviors. But for future versions, it's worth looking into whether my suggestion seems to do the trick.
Moving to an enhancement for FC; there's nothing in the current RHEL 4 plans that will cause this to show up there.
Fixed in 2.86-8.
Package name is now sysvinit in Fedora.