Bug 256241 - Kexec reboot will fail if /usr is on separate partition
Kexec reboot will fail if /usr is on separate partition
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kexec-tools (Show other bugs)
5.0
All All
medium Severity medium
: ---
: ---
Assigned To: Cong Wang
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-08-27 07:49 EDT by Cristian Seres
Modified: 2013-09-29 22:08 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-04-18 06:41:45 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Cristian Seres 2007-08-27 07:49:51 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
/etc/init.d/halt.

Version-Release number of selected component (if applicable):
kexec-tools-1.101-164.el5

How reproducible:
Always.

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"

Actual results:
Traditional BIOS reboot will follow. With modified /etc/init.d/halt script an
error message about missing "/usr/lib/libz.so.1" be shown.

Expected results:
Fast kexec reboot.

Additional info:
Tested with CentOS 5. Reported to CentOS Bug Tracker at
http://bugs.centos.org/view.php?id=2291

Workaround:
Relocate libz to /lib:
cp -a /usr/lib/libz.so.1.2.3 /lib; ldconfig
Comment 1 Neil Horman 2007-08-27 09:24:25 EDT
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?
Comment 2 Cristian Seres 2007-08-28 09:54:23 EDT
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
root filesystem.

A third solutions that I would suggest:

3) Compile kexec-utils without zlib. It will disable camecube support, but is it
that necessary?
Comment 3 Neil Horman 2007-08-28 11:15:09 EDT
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.
Comment 4 Bill Nottingham 2007-08-29 13:54:18 EDT
???

kexec is in the root filesystem - it's in /sbin. So just link zlib statically.
Comment 5 Neil Horman 2007-08-29 14:38:49 EDT
"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
choice.
Comment 6 Bill Nottingham 2007-08-29 15:39:09 EDT
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.
Comment 7 Neil Horman 2007-08-29 15:54:15 EDT
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 :)

Note You need to log in before you can comment on or make changes to this bug.