In EL5 this was fixed by statically linking kexec against the library it needed which happens to not be on / (libz I think), but the other option was to split the functionality into two pieces since by the reboot time kexec won't need access to the libz routines - but that is much more work.

BTW although I'm a Cc on the bug (presumably because I reported the bug that this got copied from) I'm not allowed to read it so can't tell what has already been said.

 -- Jon

(In reply to comment #1)
> In EL5 this was fixed by statically linking kexec against the library it needed
> which happens to not be on / (libz I think), but the other option was to split
> the functionality into two pieces since by the reboot time kexec won't need
> access to the libz routines - but that is much more work.

Yes, exactly. I am not sure if RHEL6 got changed.

> 
> BTW although I'm a Cc on the bug (presumably because I reported the bug that
> this got copied from) I'm not allowed to read it so can't tell what has already
> been said.
> 

Sorry for this. But this bug is simply a clone of Bug #461551, I am sure you have no interest in that comment. :)

Thanks!

For the record, just as I did with RHEL5 I think this is insane.  Just because the initscripts do something special I don't see why kexec should need to be built statically.  Theres no reason that libz can't be moved such that it install to the rootfs, or any number of other solutions.

That says, no one seems to care, so whatever.  Cai, heres a test build, please confirm that if fixes the problem.
http://brewweb.devel.redhat.com/brew/taskinfo?taskID=2621283

http://brewweb.devel.redhat.com/brew/taskinfo?taskID=2621363

new build, last one had some odd problem

As far as I understand it at reboot time the kexec code doesn't actually need the libz functionality, since by then either a kernel has been loaded (by kexec) or not, but because the two pieces of functionality are in one binary it won't run unless libz.so is present (or statically linked in) or the call to kexec fails and we resort to the slow reboot.

One 'proper' fix is to split kexec into code which does the loading of kernels (which needs libz but won't be run during reboot), and the part that causes a kernel to be booted (which doesn't need libz and needs to be able to run without /usr mounted).

Moving libz may affect other things, but is another options.

Long ago we were essentially a Sun shop, and they had a 'rule' which was that no binary in /sbin should make use of shared libraries which were not on the root fs.  This was presumably to ensure that such tools work iff /usr isn't available e.g. for disaster recovery etc.

A quick check with ldd on an el5.5 box shows a few things which need /usr though none which are likely to be called during shutdown:

$ for i in /sbin/*; do ldd $i | grep -q /usr && echo "$i needs /usr"; done
/sbin/fsck.cramfs needs /usr
/sbin/install-info needs /usr
/sbin/lsusb needs /usr
/sbin/mkfs.cramfs needs /usr
/sbin/mkfs.ntfs needs /usr
/sbin/mksquashfs needs /usr
/sbin/mount.ecryptfs needs /usr
/sbin/mount.ntfs needs /usr
/sbin/mount.ntfs-3g needs /usr
/sbin/multipath needs /usr
/sbin/multipathd needs /usr
/sbin/parted needs /usr
/sbin/partprobe needs /usr
/sbin/umount.ecryptfs needs /usr

(note that though some of those are extras we have added from elsewhere e.g. mount.ntfs).  I don't have an el6 system available to examine atm...

I'll now go back to lurking...

Normally, no kexec doesn't need libz to do what kexec does in the initscripts, so yes, splitting it into two binaries would make sense, thats in effect what I'm proposing.  Im just saying that the initscripts package should carry that functionality with it, not kexec, since kexec rolls both of those functions into one binary, and theres nothing wrong with that.

As for kexec being in sbin, yes, linux often violates the no shared libs used by /sbin binaries rule, and I'd be happy to move it if it would make this problem go away (but it wont).  Of course, fedora has a rule that says in effect, no static linking at all, which this change is now violating rather grossly.

I wasn't suggesting _no_ shared libs for binaries in /sbin (though yes Sun used to do this back in SunOS-4 days), just not ones which live outside the root fs...

Most /sbin binaries are happily using shared/dynamic libs from /lib/

As a matter of interest does kexec in fact work on fedora (if /usr isn't in the root fs)?  Or does almost no-one still keep /usr as a different fs anymore?

An addendum to my earlier test:

$ for i in /sbin/*; do ldd $i | grep -q /usr && echo "$i needs /usr"; done
/sbin/fsck.cramfs needs /usr
/sbin/install-info needs /usr
... <several more lines> ...

$ for i in /sbin/*; do ldd $i | grep -q /usr| grep -v libz.so; done
<no output>

ie all the uses of libraries from /usr/lib that I see happen to be libz, maybe it really should be moved into /lib/ ...

I cannot reproduce this bug with -124.el6. Looks like kexec doesn't need any libs out of /:
[root@dell-pe2800-01 ~]# rpm -q kexec-tools
kexec-tools-2.0.0-124.el6.x86_64
[root@dell-pe2800-01 ~]# rpm -qf /sbin/kexec
kexec-tools-2.0.0-124.el6.x86_64
[root@dell-pe2800-01 ~]# ldd /sbin/kexec
        linux-vdso.so.1 =>  (0x00007fff22bff000)
        libz.so.1 => /lib64/libz.so.1 (0x0000003029200000)
        libc.so.6 => /lib64/libc.so.6 (0x0000003027a00000)
        /lib64/ld-linux-x86-64.so.2 (0x0000003027200000)

So this bug doesn't exist on RHEL6 or I am missing something here?

hmm, you appear to be correct.  I tested on a system with libz in /usr/lib, but it appears RHEL6 has moved it to /lib, so this bug shouldh't exits.  Cai, did you test this bug before you went ahead and cloned it?