# kexec [done & working]

## idella4

I have emerged kexec because I'm curious about kernels and booting.  I've not taken notice of it before, would just like to learn.  I've followed the man, and tried;

```

idella@gentoo64 /mnt/genny/usr/src $ sudo kexec -l /boot/kernel-2.6.31-xen-gentoo-r10-AMD64  --append="root=/dev/hdd1 ro console=tty0"  --initrd=/boot/initrd-2.6.31-xen-gentoo-r10

idella@gentoo64 /mnt/genny/usr/src $ sudo kexec -l /boot/kernel-2.6.31-gentoo-r6-amd64  --append="root=/dev/hdd1 ro console=tty0"  --initrd=/boot/initrd-2.6.31-gentoo-r6-AMD64

setup_linux_vesafb: 640x480x16 @ eb000000 +e00000

idella@gentoo64 /mnt/genny/usr/src $

idella@gentoo64 /mnt/genny/usr/src $ sudo kexec -l /boot/kernel-2.6.32-xen-gentoo-r1-AMD64  --append="root=/dev/hdd1 ro console=tty0"  --initrd=/boot/initrd-2.6.32-xen-amd64-domU

Invalid memory segment 0xffffffff80100000 - 0xffffffff8062afff

```

I have a fault, followed by an effective load, followed by a flaw.

Can someone explain the meaning of 

Base address: 16514e0 is not page aligned

&

Invalid memory segment 0xffffffff80100000 - 0xffffffff8062afff

----------

## BradN

Base address not page aligned means the kernel must be loaded at a 4KB boundary.  I have no idea why this would occur since that kind of granularity comes almost without even trying, especially in kernel mode.  Maybe it's a side effect of it not being able to allocate the memory position it wants (does this ever happen on the first attempt?)

Invalid memory segment is a little confusing since it appears if it would be trying to use fffffxxxxxx, this would be a virtual address since it's above any region RAM could otherwise occupy.

I don't know how to troubleshoot those messages, but make sure the kernel you built to kexec is set as relocatable in the kernel config.  Post all the changes you made for the 2nd kernel and maybe someone that's used kexec can help you debug what's happening.

----------

## idella4

BradN

thanks for that. How do you set the kernel kexec to relocatable?

Like I said, this is a learning curve.

 *Quote:*   

> 
> 
> Post all the changes you made for the 2nd kernel 
> 
> 

 

You mean changes made to the kernel I was booted in at the time of executing the cited examples?

----------

## BradN

Nope, the kernel you were trying to switch to.  Unless of course it's the same kernel  :Smile: 

I'm not at a machine with kernel source installed at the moment so I'll have to wait till I get back home to help you find the option, but I believe it's under one of the first few items in the first menu.  It has options to either change the load address of the kernel (this would only help you if you use 2 kernels since it wouldn't be able to load itself again), but there's another option to build it to be relocatable so that it can even load itself, it'll just pick a new spot.  I don't believe this impacts performance in any way, but the kernel on disk will be larger since it must contain a list of fixups to adjust for position in memory.

----------

## idella4

BradN

got it.  Under processor types.  Should have looked before I asked.

 *Quote:*   

> 
> 
>     [*]   Set the default setting of memory_corruption_check                   │ │
> 
>   │ │    [*] Reserve low 64K of RAM on AMI/Phoenix BIOSen                           │ │
> ...

 

Do you know how to nominate a memory address?  One attempt returned requesting to nominate a memory address.

How do you go about selecting one?

It was to do with nominating a --load-panic option.

You said for the kernels I was loading.  Just as well I selected three.  Two of them  are xen kernels.

It appears I might have to restrict the kexec call to regular kernels.

 *Quote:*   

> 
> 
> .config - Linux Kernel v2.6.31-xen-r10 Configuration
> 
>  ────────────────────────────────────────────────────────────────────────────────────────
> ...

 

```

idella@gentoo64 ~ $ sudo kexec -l /boot/kernel-2.6.34-xen-gentoo-amd64 --append="root=/dev/sdd1 ro console=tty0" --initrd=/boot/initrd.img-2.6.34-xen-gentoo-amd64

Ramdisks not supported with generic elf argumentsidella@gentoo64 ~ $

```

Here is a brand new error message.  Can this be rectified?

The options are  slightly different; no such option.  That's fine.  

Those errors were attributable to the xen kernels.

----------

## BradN

(0x1000000) Physical address where the kernel is loaded

This is the option you would have to change to make the zen kernels load then (if you intend to switch between them you might want two of each kernel at different addresses).

The value above corresponds to 16MB, so using 0x2000000 would be 32MB and should work fine as long as you've got at least ~40MB RAM.

I'm not sure how to nominate a load address (I suspect it might be an entry in /proc or /sys) or if and how an initrd can be loaded.  You'll have to find some more examples I think.

----------

## idella4

BradN

thanks, very  helpful

You beat me by 5 minutes, was just going to edit and add this.

```

idella@gentoo64 ~ $ sudo kexec -p /boot/kernel-2.6.34-gentoo-r2-amd64 --append="root=/dev/sdd1 ro console=tty0" --initrd=/boot/initrd.img-2.6.34-gentoo-r2-amd64

Memory for crashkernel is not reserved

Please reserve memory by passing "crashkernel=X@Y" parameter to the kernel

Then try loading kdump kernel

```

"crashkernel=X@Y"    ????!!!  ??

----------

## BradN

Ahh, probably it's expecting a size and location of space to reserve for a second kernel.

Try crashkernel=8M@32M in conjunction with a relocatable kernel or load address 0x2000000.  Remember that parameter has to be for the initial kernel loaded to make sure the space is reserved - in the one you kexec to, you would want  8M@16M to use the other spot.  It's possible you have to increase the size futher to allow an initrd - but it's quite possible it can place that anywhere, I'm not sure.

----------

## idella4

BradN

I think we'll have to take this a small step at a time.

```

idella@gentoo64 /mnt/genny/usr/src/linux-2.6.34-gentoo-r2 $ sudo kexec -l /boot/kernel-2.6.34-gentoo-r2-amd64 --append="crashkernel=8M@32M ro root=/dev/sdd1 console-tty0" --initrd=/boot/initrd.img-2.6.34-gentoo-r2-amd64

setup_linux_vesafb: 640x480x16 @ eb000000 +e00000

idella@gentoo64 /mnt/genny/usr/src/linux-2.6.34-gentoo-r2 $ sudo kexec -l -p /boot/kernel-2.6.34-gentoo-r1-amd64 --append="ro root=/dev/sdd1 console-tty0" --initrd=/boot/initrd.img-2.6.34-gentoo-r1-amd64

Memory for crashkernel is not reserved

Please reserve memory by passing "crashkernel=X@Y" parameter to the kernel

Then try loading kdump kernel

```

I may have this wrong, it's new that parameter has to be for the initial kernel loaded   so I placed it in the kexec -l.   load address 0x2000000.   I still don't see where or how I stipulate that as a parameter.

At this stage I can't see it work.  It either re-boots or hangs with kexec -e

thanks for your input

----------

## BradN

I think I was a little unclear about the config option (0x2000000) and the parameter (crashkernel=)

The config option in the kernel config affects where that kernel must be placed in memory.  The crashkernel= in grub (not on the kexec command) tells the running kernel to reserve memory for a 2nd kernel.

So kernel 1, booted with crashkernel=16M@32M should be able to kexec a kernel that was built with load address 0x2000000.  When kexecing that kernel, you'd want to give it a new crashkernel=16M@16M that will let the 2nd kernel kexec a third kernel built with load address 0x1000000.

The load address from kexec's point of view should be provided by the running kernel (and the crashkernel= it was booted with), not the kexec command line if I understand this correctly.

----------

## idella4

BradNl

yes I had to think about it.  I did figure that you  intended for the grub entry for the bootup kernel.

 *Quote:*   

> 
> 
>  The crashkernel= in grub (not on the kexec command) tells the running kernel to reserve memory for a 2nd kernel
> 
> 

 

I have;

```

title Gentoo64  ide (2.6.30-r8) (on /dev/sdd1)

    root (hd3,0)

    kernel /boot/kernel-2.6.30-gentoo-r8-amd64 ro root=/dev/sdd1 crashkernel=16@32

    initrd /boot/initrd.img-2.6.30-gentoo-r8-amd64

title Gentoo64  ide (2.6.31-r6) (on /dev/sdd1)

    root (hd3,0)

    kernel /boot/kernel-2.6.31-gentoo-r6-amd64 ro root=/dev/sdd1 crashkernel=16@32 

    iitrd  /boot/initrd.img-2.6.31-gentoo-r6-amd64

title Gentoo64  ide (2.6.34-gentoo-r1) (on /dev/sdd1)

    root (hd3,0)

    kernel /boot/kernel-2.6.34-gentoo-r2-amd64 ro root=/dev/sdd1 crashkernel=16@32

    iitrd  /boot/initrd.img-2.6.34-gentoo-r2-amd64

# This entry automatically added by the Debian installer for an existing

# linux installation on /dev/hda1

title Xen  Gentoo64  ide (2.6.31-xen) (on /dev/sdd1) kernel 2.6.31-xen 

    root (hd3,0)

    kernel  /boot/xen-3.4.3-rc6-pre.gz

    module  /boot/kernel-2.6.31-xen-gentoo-r10-AMD64 ro root=/dev/sdd1 console=tty0 crashkernel=16@32

    module  /boot/initrd-2.6.31-xen-gentoo-r10  

    serial --unit=0 --speed=115200 --word=8 --parity=no --stop=1

    terminal --timeout=10 serial console  

title Xen  Gentoo64  ide (2.6.32-xen) (on /dev/sdd1) kernel-2.6.32-xen

    root (hd3,0)

    kernel  /boot/xen-3.4.3-rc6-pre.gz

    module  /boot/kernel-2.6.32-xen-gentoo-r1-AMD64 ro root=/dev/sdd1 console=tty0 crashkernel=16@32

    module  /boot/initrd-2.6.32-xen-r1-AMD64 

    serial --unit=0 --speed=115200 --word=8 --parity=no --stop=1

title Xen  Gentoo64  ide (2.6.34-xen) (on /dev/sdd1) kernel-2.6.32-xen

    root (hd3,0)

    kernel  /boot/xen-3.4.3-rc6-pre.gz

    module  /boot/kernel-2.6.34-xen-gentoo-amd64 ro root=/dev/sdd1 console=tty0 crashkernel=16@32

    module  /boot/initrd.img-2.6.34-xen-gentoo-amd64 

    serial --unit=0 --speed=115200 --word=8 --parity=no --stop=1

```

a selection of kernels to kexec thru.  

 *Quote:*   

> 
> 
> kexec a kernel that was built with load address 0x2000000.
> 
> 

 

is where I stare and wonder... you say built, to me that says was compiled with info that stiplulates a load address a/a in the case of a kexec -e.   ???  

So I think I'm not getting that at all.  I don't think you're meaning compiling in. 

 I think you mean load address 0x2000000 is represented by or equtes to 16M@32M.  

Anyway, I have booted a couple of times from the above grub entries.  I have entered e.g.

```

idella@gentoo64 /mnt/suse/boot/grub $ sudo kexec -l /boot/kernel-2.6.30-gentoo-r8-amd64 --append="ro root=/dev/sdd1" --initrd=/boot/initrd.img-2.6.30-gentoo-r8-amd64

setup_linux_vesafb: 640x480x16 @ eb000000 +e00000

```

So this loads whether or not I've included crashkernel=16@32 in the grub entry.

I thought the idea of entering this in grub was to facilitate the loading of the kernel designated by

-p (--load-panic)

              Load the new kernel for use on panic.

i.e.

```

idella@gentoo64 /mnt/suse/boot/grub $ sudo kexec -p /boot/kernel-2.6.31-gentoo-r6-amd64 --append="ro root=/dev/sdd1" --initrd=/boot/initrd.img-2.6.31-gentoo-r6-amd64

Password:

Memory for crashkernel is not reserved

Please reserve memory by passing "crashkernel=X@Y" parameter to the kernel

Then try loading kdump kernel

```

This tells me the entry in grub does nothing towards getting the above to be accepted.  What is a kdump kernel?

Executing kexec -e has attempted to switch kernels.  The kernel-2.6.34 was selected.  When run, it kernel panniced with can't mount root with any file system.  This is more confusing because booting with it from grub it's perfectly well equipped to mount all required file systems.

Oh well, shall keep trying.

----------

## BradN

Try it as crashkernel=16M@32M - the M's are important and may need to be in caps.  Otherwise if it doesn't accept that, try it in hex like crashkernel=0x1000000@0x2000000.  Without the M's it's certainly interpreting it as reserving 16 bytes at address 32 bytes and might be ignoring it entirely since it's not page aligned.

I have a feeling kexec and kernel-on-crash are using the same mechanism - kexec basically loads into the reserved spot the kernel, and then starts off the rest of the chain of events the same way as if the kernel crashes and has to switch.  With kernel on crash, the kernel's just placed in memory and waiting until something goes wrong.

The load address of a kernel is determined (or more accurately constrained) by the "(0x*******) Physical address where the kernel is loaded" option when it was compiled, unless it's built as a relocatable kernel, and then this load address probably doesn't matter.

 *Quote:*   

> Executing kexec -e has attempted to switch kernels. The kernel-2.6.34 was selected. When run, it kernel panniced with can't mount root with any file system. This is more confusing because booting with it from grub it's perfectly well equipped to mount all required file systems.

 

This is the symptom of a missing ramdisk.  Had you tried to load a 2.6.34 kernel?  Is it perhaps just restarting the current kernel?  I'm not entirely sure how all this works as I haven't used kexec before either.

----------

## idella4

BradN

thanks.  I just realised, my entry was wrong.  I missed the Ms I read and thought it was 16@32  !!!.  O shall try again and re-post.

----------

## idella4

BradN;

 *Quote:*   

> 
> 
> Without the M's it's certainly interpreting it as reserving 16 bytes at address 32 bytes
> 
> 

 

Indeed.  some progress.  After the last post I got caught up with some updating stuff that put me back to a  console for a while, now back in kde.

I have;

```

idella@gentoo64 /mnt/suse/boot/grub $ sudo kexec -l /boot/kernel-2.6.34-gentoo-r2-amd64 --append="ro root=/dev/sdd1 crashkernel=8M@32M" --initrd=/boot/initrd.img-2.6.34-gentoo-r2-amd64

setup_linux_vesafb: 640x480x16 @ eb000000 +e00000

idella@gentoo64 /mnt/suse/boot/grub $ sudo kexec -p /boot/kernel-2.6.34-gentoo-r1-amd64 --append="ro root=/dev/sdd1 crashkernel=8M@32M" --initrd=/boot/initrd.img-2.6.34-gentoo-r1-amd64

BzImage is not relocatable. Can't be used as capture kernel.

Cannot load /boot/kernel-2.6.34-gentoo-r1-amd64

idella@gentoo64 /mnt/suse/boot/grub $ sudo kexec -p /boot/kernel-2.6.31-gentoo-r6-amd64 --append="ro root=/dev/sdd1 crashkernel=8M@32M" --initrd=/boot/initrd.img-2.6.31-gentoo-r6-amd64

BzImage is not relocatable. Can't be used as capture kernel.

Cannot load /boot/kernel-2.6.31-gentoo-r6-amd64

```

which is a bit puzzling.  Having loaded kernels, it cites bzImage.  So is it renaming the kernel back to bzImage, or is it tracking the bzImage back to the kernel source and testing it??  I'm re-checking but I had intentionally recompiled these kernels to include the relocatable config.  It looks as if I might have missed 6.31.

2.6.31 is re-compiling now, I must have something awry since it seems to be doing everything again.

Alternatively, 

```

idella@gentoo64 /mnt/suse/boot/grub $ sudo kexec -p /boot/kernel-2.6.30-gentoo-r8-amd64 --append="ro root=/dev/sdd1" --initrd=/boot/initrd.img-2.6.30-gentoo-r8-amd64

Password:

setup_linux_vesafb: 640x480x16 @ eb000000 +e00000

```

It is in.  Shall submit and try it and probably edit this to add.

[edit]

 *Quote:*   

> 
> 
> This is the symptom of a missing ramdisk.
> 
> 

 

It seems my system has a problem with initrd.  They don't work.  They're not missing, they're broken.  This explains them faultering with attempts at kexec -e.

Standard gentoo doesn't require an initrd on boot.  With these three kernels, I have to dismiss the initrd on boot.

I can only update or re-emerge mkinitrd and retry.

Well, after rechecking and therefore re-compiling my kernels, I have confirmed that mkinitrd is broken.

All three entries in grub have the initrd, and each and evert one kernel panics with the previously cited error. It's not a missing ramdisk, it's a broken ramdisk.  I thought the initrd was required for kexec, but it seems it's no more necessary than a normal boot, which is what kexec does without the bios.

```
idella@gentoo64 /mnt/suse/boot/grub $ uname -a

Linux gentoo64 2.6.34-gentoo-r2-amd64 #4 SMP Tue Jul 27 05:10:53 Local time zone must be set--see zic  x86_64 Intel(R) Core(TM)2 Duo CPU E6550 @ 2.33GHz GenuineIntel GNU/Linux

idella@gentoo64 /mnt/suse/boot/grub $ sudo kexec -l /boot/kernel-2.6.31-gentoo-r6-amd64 --append="ro root/dev/sdd1 console=tty0"

Password:

setup_linux_vesafb: 640x480x16 @ eb000000 +e00000

idella@gentoo64 /mnt/suse/boot/grub $ sudo kexec -e

```

which would have worked three posts ago had I tried it.

The new topic of this thread is how to repair mkinitrd.! !  The initrd for the regular kernels are flawed.  Curiously, the initrds for the xen kernels do work.

----------

## BradN

I think part of the problem is that you're loading a ramdisk (which might work fine and contain all the drivers), but the root= is set to a hard drive not ram0 (and then realroot= must be your root partition if I remember, I haven't used gentoo's initrd).  But, this should still work how you have it right now if the disk controller and root filesystem driver are compiled in the kernel and not as a module though (or in other words if the kernel can boot the system without an initrd from grub).

A ramdisk shouldn't be necessary for kexec in any situations where it's not necessary for a normal boot.

----------

## idella4

BradN

 *Quote:*   

> 
> 
> and then realroot= must be your root partition if I remember,
> 
> 

 

Gentoo style is real_root, which I will try next.  I haven't used gentoo's initrd much until now.  So I've got it working, so thanks BradN.  I shall have to test if the initrd requires real_root and nit root, it's a possibility.

----------

