Red Hat Bugzilla – Bug 256241
Kexec reboot will fail if /usr is on separate partition
Last modified: 2013-09-29 22:08:09 EDT
Description of problem:
Kexec reboot will not work if /usr is on separate partition, because /sbin/kexec
is linked against /usr/lib/libz.so.1 which is unmounted when kexec is called in
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Use machine with /usr on separate partition than root.
2. Preload new kernel with "kexec -l" and appropriate parameters.
(3. Modify /etc/init.d/halt to remove ">& /dev/null" from kexec_command
execution line for debugging)
4. Reboot with "reboot" or "init 6"
Traditional BIOS reboot will follow. With modified /etc/init.d/halt script an
error message about missing "/usr/lib/libz.so.1" be shown.
Fast kexec reboot.
Tested with CentOS 5. Reported to CentOS Bug Tracker at
Relocate libz to /lib:
cp -a /usr/lib/libz.so.1.2.3 /lib; ldconfig
Bill, what do you think here? This seems to be a problem only in the
initscripts, when we shut down the system, and necessecarily have to unmount all
the file systems. The workaround about isn't really great, since /lib could
just as easily be mounted elsewhere, leading to the same problem. The only real
solutions that I see are:
1) Building kexec statically so as to remove its dependencies on other filesystems
2) Add some logic to copy the needed dso's to temporary space (perhaps /dev/shm)
and update LD_LIBRARY_PATH before calling kexec -e.
I'm really not excited about building kexec statically, because some people
build custom initrd with kexec included and it becomes a space hog then. What
are your thoughts regarding option 2?
Accoring to Linux Filesystem Hierarchy Standard (man hier) "/lib should hold
those shared libraries that are necessary to boot the system and to run the
commands in the root filesystem". I think it is rather safe to assume /lib is on
A third solutions that I would suggest:
3) Compile kexec-utils without zlib. It will disable camecube support, but is it
but kexec isn't in the root filesystem, nor does this (arguably) have anything
to do with booting the system, but rather rebooting the system during shutdown.
Option 3 isn't acceptible as zilb is used to decompress bzImages to obtain
kernel image information during image load time.
We either need (1) build kexec-tools statically, or (2) modify the halt script
to do the magic to preserve zlib after unmount. Alternatively we could avoid
supporting kexec reboot.
My preference would be for option (2). due to my previously expressed concerns.
kexec is in the root filesystem - it's in /sbin. So just link zlib statically.
"kexec is in the root filesystem"
My bad I wasn't thinking there. I was thinking it was in /usr/sbin
"So just link zlib statically"
I'm really not interested in doing that, given that people use kexec in space
constrained environments, but if you're unwilling to move a library around to
some shared memory immediately prior to a reboot, I don't see that I have much
I suppose zlib could be moved - I don't think the copying really helps because
it involves making a two-stage kexec process, one that runs before any network
filesystems could be unmounted and one after.
FWIW, linking zlib statically increases the size of kexec from 163416 to 228488
in a brief test.
Well, I've fixed it up now. kexec now statically links libz in my 5.2 branch
for kexec-tools. I'll merge it when 5.1 ships.
As for the zlib move approach, I hadn't really considered that we would have to
do it in two stages. You're right, but the time /etc/init.d/halt runs, libz is
inaccessible, which is badness. That probably makes it more of a headache than
its worth. If those packaging kexec in a initramfs can't afford an extra 65k
they can open a bug, and we'll come to that bridge when we cross it :)