Bug 836392 - kexec'ing F15 installer works, but fails with F17
kexec'ing F15 installer works, but fails with F17
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Anaconda Maintenance Team
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2012-06-28 18:08 EDT by joshua
Modified: 2013-01-10 01:50 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2012-10-23 13:51:42 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description joshua 2012-06-28 18:08:24 EDT
Description of problem:

I have kickstarting working well.  Here is my PXELINUX entry:

KERNEL http://server/fedora/path/vmlinuz
APPEND initrd=http://server/path/pxeboot/initrd.img ks=http://server/path/ks.cfg repo=http://server/path/x86_64/os/ ksdevice=bootif kssendmac sshd=1

This works for Fedora 15 and 17.  Fedora 15 even works with kexec, in this manner (assuming a wget download in the cwd of the kernel and initrd):

kexec -l vmlinuz --initrd=initrd.img --append=repo=http://server/path/x86_64/os/ ks=http://server/path/ks.cfg ksdevice=bootif kssendmac sshd=1

This kexec'ing however doesn't work in the F17 world.  The errors look like this:
dracut Warning:  Unable to process initqueue
dracut Warning:  /dev/root does not exist

What is it with kexec and F17 that breaks when doing the exact same thing with kexec and Fedora 15 works?

Version-Release number of selected component (if applicable):

F17 x86_64, kexec-tools-2.0.3-38.fc17.x86_64
Comment 1 Chris Lumens 2012-07-03 09:34:15 EDT
We've never made any promises about anaconda working with kexec.  However there is a whole lot that can go wrong that results in that error message.  I can't tell without seeing your logs though.
Comment 2 joshua 2012-07-06 12:09:59 EDT
Understood, my point here is that it works nicely in Fedora 15, and dies early before even attempting stage two in Fedora 17.   Where does dracut keeps its logs and record kernel-command line inputs?
Comment 3 Jesse Keating 2012-07-13 18:41:26 EDT
If you boot with rd.debug you'll find the logs in /run/initramfs/init.log 

The kernel command line inputs can be found in /proc/cmdline
Comment 4 joshua 2012-07-20 21:03:53 EDT
Wow, there is a lot there.  Any ideas on where I should start looking, or what I should be looking for?
Comment 5 Jesse Keating 2012-07-23 13:22:22 EDT
Honestly I don't know.  kexec isn't a thing we support.  I'd suggest working with the kexec folks to see what looks "normal" and what looks broken.
Comment 6 joshua 2012-07-23 13:47:39 EDT
Is there an easy way to get the logs off such that I could post them here?  I don't seem to have an IP stack inside of dracut debug
Comment 7 Jesse Keating 2012-07-23 13:49:18 EDT
If you exit the debug shell and get into the anaconda shell you should be able to find the logs in /run/initramfs/init.log and should have enough bits to get IP working.
Comment 8 joshua 2012-10-10 15:12:54 EDT
I give up.  It is a mess, and I don't understand dracut's init.log entries enough  to identify the problem.  It looks like a udev settling issue, but I can't be sure.
Comment 9 joshua 2012-10-29 20:56:40 EDT
I figured it out.  It has nothing to do with dracut at all... it is that between F15 and F17, anaconda got much pickier about BOOTIF=MAC

That MAC must now have a "01-" prepended to the beginning ... just like SYSLINUX/PXELINUX does.  Anaconda would take the real MAC with the "01-" in Fedora 15.

Just posting in case this matters to anyone else.

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