Bug 522486 (dracut-kexec) - dracut module 99kdumpbase installs by default
Summary: dracut module 99kdumpbase installs by default
Keywords:
Status: CLOSED RAWHIDE
Alias: dracut-kexec
Product: Fedora
Classification: Fedora
Component: kexec-tools
Version: rawhide
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Neil Horman
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 522964 523415 523751 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-09-10 14:03 UTC by Harald Hoyer
Modified: 2009-10-13 14:02 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-10-13 14:02:08 UTC


Attachments (Terms of Use)

Description Harald Hoyer 2009-09-10 14:03:35 UTC
if you install kexec-tools the initrd built by dracut in kernel %post will be unusable and the user can't boot

Please add 99kdumpbase/check with the following contents:
#!/bin/sh

# do not add this module by default
exit 1


so the module has to be added explicitly in /etc/dracut.conf or on the dracut command line.

Comment 1 Neil Horman 2009-09-10 14:36:42 UTC
fixed in -25.f12.  Thanks!

Comment 2 Harald Hoyer 2009-09-15 15:27:43 UTC
check does not have the executable bit set... please change to mode 0755

Comment 3 Harald Hoyer 2009-09-15 15:28:31 UTC
also a "/" is missing for "/bin/reboot"

Comment 4 Harald Hoyer 2009-09-15 15:29:55 UTC
in check you should also check for 

"/etc/kdump-adv-conf/init" and exit != 0 if it does not exist.

Comment 5 Harald Hoyer 2009-09-15 15:31:59 UTC
also I cannot find anything which provides "/etc/kdump-adv-conf/init" you probably mean "/etc/kdump-adv-conf/kdump_initscripts/init"

/etc/kdump-adv-conf/kdump_initscripts/ also contains .#init.1.1

Comment 6 Harald Hoyer 2009-09-15 15:34:12 UTC
also there is no reason to completely change init... why not install a simple "pre-pivot" script?

Comment 7 Harald Hoyer 2009-09-15 15:37:15 UTC
(In reply to comment #3)
> also a "/" is missing for "/bin/reboot"  

in "install" that is

Comment 8 Neil Horman 2009-09-15 17:00:38 UTC
yes, herald, there is a reason to completely change init, because thats where the implementation of kdump happens.  kdump doesn't nominally mount the rootfs and start any services.  kdumps purpose is to copy the /proc/vmcore file to a location of a users choosing, as well as do any other site specific work needed to successfully complete a vmcore capture.  Thats all done in the init script.  I provide sample init scripts, but its the user that needs to write it in the end. 

So yes, there is a reason to completely change init.  I'll fix up the other nits shortly.

Comment 9 Harald Hoyer 2009-09-16 06:45:53 UTC
(In reply to comment #8)
> So yes, there is a reason to completely change init.  I'll fix up the other
> nits shortly.  

No, it isn't ... all the changes you did in the example init script can be done as a pre-pivot script. So any changes in the whole dracut infrastructure would not really matter to the user.

Comment 10 Harald Hoyer 2009-09-16 06:51:06 UTC
*** Bug 522964 has been marked as a duplicate of this bug. ***

Comment 11 Harald Hoyer 2009-09-16 06:52:04 UTC
*** Bug 523415 has been marked as a duplicate of this bug. ***

Comment 12 Quentin Armitage 2009-09-16 08:16:50 UTC
In kexec-tools-2.0.0-27, in kdump_dracut_modules/99kdumpbase/check, the test
if [ ! -f /etc/kdump-adv-conf/init ]
will always be true since init is in /etc/kdump-adv-conf/kdump_initscripts/ and not in /etc/kdump-adv-conf/.

Similarly, as Comment #5 above, kdump_dracut_modules/99kdumpbase/install needs to be modified so that the line
inst "/etc/kdump-adv-conf/init" "/init"
reads
inst "/etc/kdump-adv-conf/kdump_initscripts/init" "/init"

Comment 13 Harald Hoyer 2009-09-16 08:33:07 UTC
As far as I understand /etc/kdump-adv-conf/kdump_initscripts/init is just an example and the user has to provide /etc/kdump-adv-conf/init.

Though I really would suggest to just add pre-pivot hook script

99kdumpbase/install:
inst_hook pre-pivot 01 my-pre-pivot-hook.sh

all /etc/kdump-adv-conf/kdump_initscripts/init does can be done with:

99kdumpbase/my-pre-pivot-hook.sh:
# We have the root file system mounted under $NEWROOT, so copy 
# the vmcore there and call it a day
#
DATEDIR=`date +%d.%m.%y-%T`
mkdir -p $NEWROOT/var/crash/$DATEDIR
cp /proc/vmcore $NEWROOT/var/crash/$DATEDIR/vmcore
# Once the copy is done, just reboot the system
reboot -f

........

Note: there is a bug in /etc/kdump-adv-conf/kdump_initscripts/init:
- cp /proc/vmcore /var/crash/$DATEDIR/vmcore
+ cp /proc/vmcore $NEWROOT/var/crash/$DATEDIR/vmcore

Comment 14 Neil Horman 2009-09-16 12:16:41 UTC
You're not reading closely enough Harald.  The idea behind that that initscript is that its just an example.  People can use it if they like, but they are expected to modify it to suit their needs.  Most importantly they are expected to write their modified copy of the initscript to /etc/kdump-adv-conf/init.  Thats why I don't have one there immediately.

Note that this kdump config rewrite is a work in progress, I'll be writing docs for how to use the kdump dracut module as soon as I'm able as part of bz 466392

Comment 15 Harald Hoyer 2009-09-16 13:04:50 UTC
(In reply to comment #14)
> You're not reading closely enough Harald.  The idea behind that that initscript
> is that its just an example.  People can use it if they like, but they are
> expected to modify it to suit their needs. 


Comment #13 From  Harald Hoyer (harald@redhat.com) :

As far as I understand /etc/kdump-adv-conf/kdump_initscripts/init is just an
example and the user has to provide /etc/kdump-adv-conf/init.

Comment 16 Harald Hoyer 2009-09-17 13:58:35 UTC
*** Bug 523751 has been marked as a duplicate of this bug. ***

Comment 17 stan 2009-09-17 23:14:30 UTC
The updates from 9/16 seem to have fixed this problem.  I am now able to compile a redhat kernel from the source rpm package, and it creates a valid initramfs that boots the system properly once the rpms are installed.  Thank you.

kexec-tools-2.0.0-27.fc12.x86_64
dracut-001-9.git6f0e469d.fc12.noarch
dracut-generic-001-9.git6f0e469d.fc12.noarch
dracut-network-001-9.git6f0e469d.fc12.noarch
dracut-kernel-001-9.git6f0e469d.fc12.noarch
dracut-tools-001-9.git6f0e469d.fc12.noarch
kernel-2.6.31-14.fc12.x86_64

Comment 18 Quentin Armitage 2009-09-18 08:19:14 UTC
I have tried the approach using pre-pivot as set out in comment #13, and there seem to be a couple of issues. The first is that there needs to be a /bin/date and /bin/reboot, which presumably need to be copied in 99kdumpbase/install, as was done in the non pre-pivot version.

The second problem seems a bit more fundamental: 
The root filesystem is mount read-only on $NEWROOT, and so the two commands:
mkdir -p $NEWROOT/var/crash/$DATEDIR
cp /proc/vmcore $NEWROOT/var/crash/$DATEDIR/vmcore
both fail due to attempting to write to the root filesystem.

The above is what I have seen after a normal reboot; unfortunately I cannot try a crash reboot due to bug #524172, so I cannot see if the root filesystem is mounted read-write in that circumstance, but I cannot see anything that would do that.

A further minor point - would it be better to check for the existence of /proc/vmcore prior to the mkdir and cp above?

I would also be very grateful if someone could explain how the "reboot -f" works. During a normal boot, it does not appear to do anything, but I assume that somehow after a crash reboot it does.

Comment 19 Harald Hoyer 2009-09-18 09:32:15 UTC
(In reply to comment #18)
> I have tried the approach using pre-pivot as set out in comment #13, and there
> seem to be a couple of issues. The first is that there needs to be a /bin/date
> and /bin/reboot, which presumably need to be copied in 99kdumpbase/install, as
> was done in the non pre-pivot version.

of course, it needs to be copied.. just add them to install

> 
> The second problem seems a bit more fundamental: 
> The root filesystem is mount read-only on $NEWROOT, and so the two commands:
> mkdir -p $NEWROOT/var/crash/$DATEDIR
> cp /proc/vmcore $NEWROOT/var/crash/$DATEDIR/vmcore
> both fail due to attempting to write to the root filesystem.

you can remount it writable.. or specify "rw" on the kernel command line

mount -o remount,rw /

> 
> The above is what I have seen after a normal reboot; unfortunately I cannot try
> a crash reboot due to bug #524172, so I cannot see if the root filesystem is
> mounted read-write in that circumstance, but I cannot see anything that would
> do that.
> 
> A further minor point - would it be better to check for the existence of
> /proc/vmcore prior to the mkdir and cp above?
> 
> I would also be very grateful if someone could explain how the "reboot -f"
> works. During a normal boot, it does not appear to do anything, but I assume
> that somehow after a crash reboot it does.  

       -f     Does  not invoke shutdown(8) and instead performs the actual action you would expect from the name.  This is generally used from the event
              handler itself.

Comment 20 Michal Jaegermann 2009-09-18 16:29:42 UTC
It looks to me that another troubling issue is that 'root=....' from a boot command appears totally ignored and that means no recovery in case of problems; even if, for example, such thing as a backup disk would exist.  Is a location of / just hardwired into initramfs?  It should be possible to look at /proc/cmdline and extract that parameter from there.  In bash that can be done with:

r=$(</proc/cmdline) ; n=${r#* root=} ;
[ "$n" != "$r" ] && n="root="${n%% *} || n="" ; echo $n

Comment 21 Harald Hoyer 2009-09-19 07:38:40 UTC
"root=" is definitely _NOT_ hardcoded in dracut generated initramfs images!

Comment 22 Michal Jaegermann 2009-09-19 16:07:28 UTC
> "root=" is definitely _NOT_ hardcoded in dracut generated initramfs images!

OK. I thought about that possibility because, as described in bug 522964, when I tried to pass in whatever form 'root=...' in attempts to recover there this was spectacularly ineffective.


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