kexec-loader

Hi, I found this forum due to it referrering several hits to my site

kexec-loader

This place seems like a good place to get opinions on kexec-loader and what should be done next
One of the things currently in the works is an online service for generating disk images for those who want a custom disk image but don't know howto build Linux or a toolchain.

Yep.

Welcome to the Forum

Your project looks very interesting , but as evidenced in the related posts here:
http://www.boot-land...?showtopic=4307
http://www.boot-land...?showtopic=4266

it is at the moment lacking of documentation , to the point that it is not clear even what could be it's use.

Please do post whatever you can explaining what it does, how it does it, and what it can be used for.



jaclaz

Currently I've only tried booting Linux kernels with it, others might work so if anyone's got a BSD, etc machine could they try using kexec-loader to boot it?

Since v1.2 (2008-04-26) kexec-loader has also included a pretty thorough README.html in the source tarball, and v1.3+ also has a copy in the floppy image.

Point was that most users won't get into the "trouble" of downloading a gzipped image, access it with winimage or mount it in a Virtual Disk, just to know what the heck it is .

So, for the benefit of such users, here it's what it is:

kexec-loader is a boot loader which loads a Linux kernel, then displays a GRUB-like menu so you can select a kernel to boot using kexec. It is designed for systems where the BIOS does not support booting from some devices (e.g. your kernel is on a USB memory key which the BIOS does not support).

(Attached the full README.html)

Now the questions....

1) Can it chainload grub4dos grub.exe on a USB device through kexec loading?

And back to square 1:
http://www.boot-land...?showtopic=4307



jaclaz

Sadly chainloading is currently impossible as there's no Linux patch I'm aware of to support chainloading and I'm not a kernel hacker so there's no way I could implement one

Another similar topic:

Booting with kexec hangs after "Launching GRUB..."

Maybe I misused the verb "chainloading".

Let's see if I have understood at least partly what actually kexecloader is....

1) it is a VERY minimal Linux distro that has support for USB
2) once booted to this mini-Linux it can load a (another) Linux kernel using kexec (I have NO idea of what kexec is)

3) in the grub4dos readme it is said that grub.exe is BOTH:
a. a MS-DOS executable
b. a loadable-through-Linux-kexec kernel

Update 2: GRUB for Linux is also introduced along with 0.2.0. You can
boot grub using a linux loader KEXEC, LILO, SYSLINUX or another
GRUB. (GRUB4LIN has merged into GRUB.EXE)

To boot GRUB off Linux, use this pair of commands:

kexec -l grub.exe
kexec -e

To boot GRUB via GRUB, use commands like the following:

kernel (hd0,0)/grub.exe
boot

To boot GRUB via LILO, use these lines in lilo.conf:

image=/boot/grub.exe
label=grub.exe

To boot GRUB via SYSLINUX, use these lines in syslinux.cfg:

label grub.exe
kernel grub.exe

LOADLIN may encounter problems when loading grub.exe, because
grub.exe requires some unchanged original BIOS interrupt
vectors, but DOS has destroyed them, and loadlin does not
recover them before it transfers control to grub.exe.

and later the following is specified:

******************************************************************************
*** Direct transition to DOS/Win9x from within Linux ***
******************************************************************************

By using kexec, we can easily boot into DOS/Win9x from a running Linux system.

If WIN98.IMG is a bootable hard-disk image, do as follows:

kexec -l grub.exe --initrd=WIN98.IMG --command-line="--config-file=map (rd) (hd0); map --hook; chainloader (hd0)+1; rootnoverify (hd0)"

kexec -e

If DOS.IMG is a bootable floppy image, do this way:

kexec -l grub.exe --initrd=DOS.IMG --command-line="--config-file=map (rd) (fd0); map --hook; chainloader (fd0)+1; rootnoverify (fd0)"

kexec -e

Note that in this manner, we can boot DOS/Win9x without using a real DOS/Win9x
disk. We need no FAT partition but an image file.

We have noticed that Linux itself can act as a big boot manager by using kexec
and grub.exe. This may be convenient to developers who write installation or
bootstrap or initialization programs.

So the question(s) become:
1) Is it possible to replicate the above loading of grub.exe through kexec-loader
2) If yes, how?

jaclaz

Well, if grub4dos can be executed as a kernel you could probably use somthing like:

title GRUB4DOS
rootfs /dev/hda1
kernel /grub.exe

Well, if grub4dos can be executed as a kernel you could probably use somthing like:

title GRUB4DOS
rootfs /dev/hda1
kernel /grub.exe

Confirmed!

Removing from the floppy the README.html, grub.exe and a menu.lst BARELY fit in the 1.44 Mb floppy image.

Adding to kexec-loader.conf the lines:

title grub4dos

rootfs /dev/fd0

kernel /grub.exe

kexecloader can load grub.exe. (tested in Qemu)

(you need to use "configfile (fd0)/menu.lst" in grub4dos command line to load menu.lst)

grub4dos can loop back to (fd0) and load kexec-loader again:

title kexec-loader on floppy (bootsector)

root (fd0)

chainloader (fd0)+1



title kexec-loader on floppy (kernel)

kernel (fd0)/linux.upx

jaclaz

Well, coffee started to work.

solemnwarning, welcome and thanks for kexec-loader

A few questions-

Placed linux.upx along with kexec-loader.conf from latest version on FAT32 USB formatted stick. Testing in QEMU.
Grub4Dos loads linux.upx

root (hd0,0)
kernel /linux.upx

Linux starts, kexec-loader cannot find kexec-loader.conf. Where is it looking for it? Is there a command line option so I can issue those commands to launch grub4dos manually?


I had the same result, when using previous kexec-loader versions for PATA and USB.

edit: Found some answers in readme, nice to have it.

root (hd0,0)

kernel /linux.upx kexec_config=/dev/hda1

worked.

Nearing release of v1.4, play around with the shell if you have time, it's not documented yet but it will be soon, the command "help" prints a list of available commands.

kexec-loader-r297.img.gz

Changes since v1.3.1 so far include a cmdline directive which sets the --command-line kexec argument, a shell, a reset-vga directive to enable --reset-vga and some bugfixes.

Resurrecting thread for comments on new version, 1.6.1

kexec-loader-1.6.1-floppy.img.gz

There have been many changes since I last posted, the shell has been rewritten with autocompletion and line editing, many bugs have been fixed, the README has been partially rewritten and some stuff has been done.

Hi

Have a few gripes, but first of all a request for help, to do indirectly with using kexec-loader. Have been referred here from an MSFN forum by jaclaz.

Over the last couple of weeks I have been trawling the net, Hard disk on the blink, old motherboard, old BIOS, from last millenium ... Have been temporising with the Kanotix(flavour of Knoppix) Live CD. Managed to set up the distribution on a 4Gb USB Stick. Absolutely no BIOS support, so the PLoP USB boot floppy did not help at all, and could not boot PLoP Linux from a USB stick.

Finally came to 'kexec-loader' boot floppy, which seems to be just the ticket! Downloaded kexec-loader-1.6.1-floppy.img.gz.

Booting Kanotix from USB stick reached:-

VFS: Mounted root (ext2 filesystem) {I believe is end of kernel}
...
initrd-tools: 0.1.77 {within initrd?}
mount: unknown filesystemtype 'devfs'
usbcore: registered new driver usbfs
usbcore: registered new driver hub
USB Mass Storag support registered
FATAL: Module sd_mod not found
...
Kernel panic ...

I presume 'devfs' is also on a module which could not be downloaded from USB, because USB support had not yet been enabled, and likewise module 'sd_mod' could not be downloaded from USB because 'sd_mod' was required for USB support.

(Have reached a solution of sorts consisting of a two-boot process. First of all boot PLoP from USB and then change root to the Kanotix distribution. It's not ideal, but at least it frees 32Mb of my 64Mb RAM, which was before occupied by the Live CD's RAM disk, and I can even get X up! So now have Kanotix on first partition of USB stick, then swap partition and finally on last 64Mb partition PLoP Linux.)

The ideal solution would be to be able to load a kernel which can then see the USB stick and manage the command:
'kernel root=/dev/sda1'. So I really need to be able to buid such a kernel, or better still just be able to load the appropriate modules to enable a kernel to search the USB drives, like PLoP does.

Would be grateful for help in this enterprise.

vindoze

The kexec-loader floppy image includes USB support, you shouldn't need a module for it. That error looks like knoppix is missing modules, does it have an initrd? What version of kexec-loader are you using?

The kexec-loader floppy image includes USB support, you shouldn't need a module for it.

I have already mentioned in the MSFN forum that it appears I have a USB hub with 2 ports. However from this hub and even from an extension hub with 4 ports attached to this hub I have been able to load PLoP Linux from a USB stick using 'kexec-loader'.

The question is how you have included USB support. Have you had to compile in the the USB modules or do you just load the modules dynamically? Knowing this would give me a lead in solving my problem.

That error looks like knoppix is missing modules, does it have an initrd?

Yes, it has one. But maybe the code has to be altered so that the USB and SCSI modules are already in the initrd.

What version of kexec-loader are you using?

The latest 1.6.1?

Comments to 1.6.1

• The Manual. It is not made clear that a shell statement like 'mount /dev/sda1 usb' expands into the 2 Unix statements 'mkdir usb; mount/dev/sda1 usb'.
  
• Pressing 'L' or invoking 'disks' in the shell shows devices detected by Linux, and in my instance having shown that '/dev/sda1' has a reiserfs file system the statement 'mount /dev/sda1 usb' comes back with the error message 'Device not found', which is completely misleading. This had me trying every grub combination like 'hd0','hd1','hd0,1','hd1,1' etc. The more appropriate message would be something like 'No reiserfs module found'. Finally downloaded the modules gzip file, and succeeded upon loading the reiserfs module there.
  
• The shell statements 'cmdline' and 'append'. The kernel command line 'root=/dev/sdb1 ro ramdisk_size=100000 lang=us apm=power-off nomce vga=791' is too long for the shell statement 'cmdline' and needs to line wrap i.e.
  cmdline root=/dev/sdb1 ro ramdisk_size=100000 lang=us apm=power-off nomce vga=791
  Tried:
  cmdline 'root=/dev/sdb1 ro ramdisk_size=100000 lang=us apm=power-off nomce vga=791'
  cmdline "root=/dev/sdb1 ro ramdisk_size=100000 lang=us apm=power-off nomce vga=791"
  to no avail, because upon reachig end of line 'kexec-loader' just freezes. So also tried:
  cmdline root=/dev/sdb1 ro ramdisk_size=100000 lang=us apm=power-off nomce \
  but did not get the shell continuation symbol '>'.
  
• Manual omits mention of a 'boot' shell statement
  
• As I could not get a line continuation within the shell, tried a mix of:
  cmdline root=/dev/sdb1 ro ramdisk_size=100000 lang=us apm=power-off nomce
  append vga=791
  but upon booting only saw the second statement reproduced in green colour. append vga=791(By the way like the colour combination). Does that mean that only the last statement of 'append' and 'cmdline' is honoured?
  
• 'cmdline' & 'append' keyword values. Using just the end sequence:
  cmdline root=/dev/sdb1 ro ramdisk_size=100000 lang=us apm=power-off nomce
  boot
  within the green statements which follow there is only one keyword argument and value to be seen 'cmdline root=/dev/sdb1'. Does this mean the remaining keywords and their values have been lost?
  
• This statement sequence in 'kexec-loader.conf' does not work:
  rootfs /dev/sda1
  kernel bzimage
  mount /dev/sdb1 u
  initrd u/boot/initrd.img
  i.e. fetching initrd from a filesystem different from the kernel's.

The Manual. It is not made clear that a shell statement like 'mount /dev/sda1 usb' expands into the 2 Unix statements 'mkdir usb; mount/dev/sda1 usb'.

I don't mention this in the manual as it's irrelevent to users, filesystems are mounted read-only, so the mkdir() call fails for mounts on a mounted filesystem. The mkdir() call is only for creating mount points in the kexec-loader initramfs.

Pressing 'L' or invoking 'disks' in the shell shows devices detected by Linux, and in my instance having shown that '/dev/sda1' has a reiserfs file system the statement 'mount /dev/sda1 usb' comes back with the error message 'Device not found', which is completely misleading. This had me trying every grub combination like 'hd0','hd1','hd0,1','hd1,1' etc. The more appropriate message would be something like 'No reiserfs module found'. Finally downloaded the modules gzip file, and succeeded upon loading the reiserfs module there.

The error messages displayed by kexec-loader are those returned by Linux, I can't reliably fix ambiguity in the error messages, if I assume that lack of a 'reiserfs' module means the module is missing, that will break kernels that have it built in.

The shell statements 'cmdline' and 'append'. The kernel command line 'root=/dev/sdb1 ro ramdisk_size=100000 lang=us apm=power-off nomce vga=791' is too long for the shell statement 'cmdline' and needs to line wrap i.e.
cmdline root=/dev/sdb1 ro ramdisk_size=100000 lang=us apm=power-off nomce vga=791
Tried:
cmdline 'root=/dev/sdb1 ro ramdisk_size=100000 lang=us apm=power-off nomce vga=791'
cmdline "root=/dev/sdb1 ro ramdisk_size=100000 lang=us apm=power-off nomce vga=791"
to no avail, because upon reachig end of line 'kexec-loader' just freezes. So also tried:
cmdline root=/dev/sdb1 ro ramdisk_size=100000 lang=us apm=power-off nomce \
but did not get the shell continuation symbol '>'.

Crap, bugs. I'll fix them soon.

Manual omits mention of a 'boot' shell statement

I'll add that to the manual.

As I could not get a line continuation within the shell, tried a mix of:
cmdline root=/dev/sdb1 ro ramdisk_size=100000 lang=us apm=power-off nomce
append vga=791
but upon booting only saw the second statement reproduced in green colour. append vga=791(By the way like the colour combination). Does that mean that only the last statement of 'append' and 'cmdline' is honoured?

They should both be used, I'm not sure why that happened.

'cmdline' & 'append' keyword values. Using just the end sequence:
cmdline root=/dev/sdb1 ro ramdisk_size=100000 lang=us apm=power-off nomce
boot
within the green statements which follow there is only one keyword argument and value to be seen 'cmdline root=/dev/sdb1'. Does this mean the remaining keywords and their values have been lost?

Yes, it's another bug in the shell, I will fix it before the next release.

This statement sequence in 'kexec-loader.conf' does not work:
rootfs /dev/sda1
kernel bzimage
mount /dev/sdb1 u
initrd u/boot/initrd.img
i.e. fetching initrd from a filesystem different from the kernel's.

Can you give me more information? What error do you get? Is there anything about it in the debug console? (alt+f2)

Support for UUID or LABEL besides /dev/sd* to define devices would be nice.
blkid can show the values that you must use for it.

An example from my PC (blkid on Ubuntu):

/dev/sda1: UUID="7017EB7E01C618FC" TYPE="ntfs" /dev/sda5: UUID="73da2d29-6e9e-40ac-96c3-fd94b51a3b62" TYPE="reiserfs" /dev/sda6: TYPE="swap" UUID="23379f27-715f-43a1-8afa-3ab7a8bf1984" /dev/sda7: UUID="27BCCCDE5529115D" TYPE="ntfs" /dev/sda8: UUID="30ACA5FE731CB004" TYPE="ntfs" /dev/sdb1: UUID="e7e2bc22-ef95-416f-83e4-d7219edb007b" SEC_TYPE="ext2" TYPE="ext3" /dev/sdb5: UUID="2a6b0e97-edc1-478b-a498-774de122126a" TYPE="reiserfs" /dev/sdb6: TYPE="swap" UUID="e66bb651-ba3f-4f3b-87a5-cce5df501f33" /dev/sdb7: UUID="ac39a92a-1ca5-4c60-bf66-1263bc77281b" SEC_TYPE="ext2" TYPE="ext3" /dev/sdc1: UUID="4ddfe54b-a3c9-4df3-94de-d1b47c1663db" TYPE="ext3" /dev/sdc5: UUID="ec8f9b19-49ab-4e3e-8fd9-ca635cf99ef9" TYPE="ext3" /dev/sdc6: UUID="a324e1bf-0ca0-4fe0-9a16-0066fed97894" TYPE="ext3" /dev/sdc7: TYPE="swap" UUID="afcb07b5-f105-4e0b-a287-15864cbc1cec" /dev/sdc8: UUID="A238E48838E45D33" LABEL="External HD" TYPE="ntfs" /dev/loop0: SEC_TYPE="msdos" UUID="4840-780D" TYPE="vfat"

This is useful because you don't have to change the config file when you add devices to your PC (extra USB drives, hard drives, ...)
or when you move the USB drive to another PC.

QUOTE (vindoze @ Jan 7 2009, 06:29 PM) *
The Manual. It is not made clear that a shell statement like 'mount /dev/sda1 usb' expands into the 2 Unix statements 'mkdir usb; mount/dev/sda1 usb'.

I don't mention this in the manual as it's irrelevent to users, filesystems are mounted read-only, so the mkdir() call fails for mounts on a mounted filesystem. The mkdir() call is only for creating mount points in the kexec-loader initramfs.

Trouble is, as an umble user I have no idea about the innards of the beast. So I goes about making a directory on which to hang me a file system, but can't.

IMHO it would be helpful to say in the manual that a directory is automatically created, on to which the file system is mounted.

QUOTE (vindoze @ Jan 7 2009, 06:29 PM) *
Pressing 'L' or invoking 'disks' in the shell shows devices detected by Linux, and in my instance having shown that '/dev/sda1' has a reiserfs file system the statement 'mount /dev/sda1 usb' comes back with the error message 'Device not found', which is completely misleading. This had me trying every grub combination like 'hd0','hd1','hd0,1','hd1,1' etc. The more appropriate message would be something like 'No reiserfs module found'. Finally downloaded the modules gzip file, and succeeded upon loading the reiserfs module there.

The error messages displayed by kexec-loader are those returned by Linux, I can't reliably fix ambiguity in the error messages, if I assume that lack of a 'reiserfs' module means the module is missing, that will break kernels that have it built in.

An error message can't crash what has already crashed. Error message ambiguity is normally implied by prefixing a "Maybe " to the error message. It is then up to the user to decide if this has been of help or not.

if I assume that lack of a 'reiserfs' module means the module is missing, that will break kernels that have it built in.

However in this particular instance the kernel in question is the one which drives kexec-loader, so there should be no question about not knowing if the kernel "has it built in" or not.

QUOTE (vindoze @ Jan 7 2009, 06:29 PM) *
This statement sequence in 'kexec-loader.conf' does not work:
rootfs /dev/sda1
kernel bzimage
mount /dev/sdb1 u
initrd u/boot/initrd.img
i.e. fetching initrd from a filesystem different from the kernel's.

Can you give me more information? What error do you get?

title PLoP & Kan a,b
rootfs /dev/sda3
kernel bzimage
mount /dev/sdb1 u
initrd u/boot/initrd.img
append root=/dev/sdb1 ro ramdisk_size=100000 lang=us apm=power-off nomce vga=791
title PLoP Linux on 'sda1'
rootfs /dev/sda1
kernel bzimage
initrd initrfs.gz
append vga=791

>Loading
>Mounting /dev/sda3 at /mnt/target/v
>Mounting /dev/sdb1 at /mnt/target/u
>>Mount failed. No such file or directory.

It's clear here that fetching initrd from a different filesystem excludes the use of the 'rootfs' statement

title Initramfs residing on a file system different from Kernel's
mount /dev/sda3 v
kernel v/bzimage
mount /dev/sdb1 u
initrd u/boot/initrd.img
append root=/dev/sdb1 ro ramdisk_size=100000 lang=us apm=power-off nomce vga=791


Does not work:
>Loading Initramfs residing on a file system different from Kernel's
>Loading kernel ...
>>kernel: /mnt/target/v/bzimage
>>append: root=/dev/sdb1 ro ramdisk_size=100000 lang=us apm=power-off nomce vga=791
>>initrd: /mnt/target/u/boot/initrd.img
>>Cannot open '/mnt/target/v/bzimage': stream error
>Unmounting /mnt/target/u/

Alt-F2 Console 2 furnished no more additional info.

However the similar statement sequence as shell statements works!

mount /dev/sda3 v
kernel v/bzimage
mount /dev/sdb1 u
initrd u/boot/initrd.img
append root=/dev/sdb1
boot

Is there anything about it in the debug console? (alt+f2)

Could also rate a mention in the manual for those of us who are not quite so clued up.

Trouble is, as an umble user I have no idea about the innards of the beast. So I goes about making a directory on which to hang me a file system, but can't.

IMHO it would be helpful to say in the manual that a directory is automatically created, on to which the file system is mounted.

It only creates directories on the ramdisk though, so the user won't notice it being created

title PLoP & Kan a,b
rootfs /dev/sda3
kernel bzimage
mount /dev/sdb1 u
initrd u/boot/initrd.img
append root=/dev/sdb1 ro ramdisk_size=100000 lang=us apm=power-off nomce vga=791
title PLoP Linux on 'sda1'
rootfs /dev/sda1
kernel bzimage
initrd initrfs.gz
append vga=791

>Loading
>Mounting /dev/sda3 at /mnt/target/v
>Mounting /dev/sdb1 at /mnt/target/u
>>Mount failed. No such file or directory.

OK, unless you've altered the code, that config won't produce that output, rootfs mounts at /, not /v

title Initramfs residing on a file system different from Kernel's
mount /dev/sda3 v
kernel v/bzimage
mount /dev/sdb1 u
initrd u/boot/initrd.img
append root=/dev/sdb1 ro ramdisk_size=100000 lang=us apm=power-off nomce vga=791


Does not work:
>Loading Initramfs residing on a file system different from Kernel's
>Loading kernel ...
>>kernel: /mnt/target/v/bzimage
>>append: root=/dev/sdb1 ro ramdisk_size=100000 lang=us apm=power-off nomce vga=791
>>initrd: /mnt/target/u/boot/initrd.img
>>Cannot open '/mnt/target/v/bzimage': stream error
>Unmounting /mnt/target/u/

What mount lines were before that?

QUOTE (vindoze @ Jan 15 2009, 10:54 PM)
title Initramfs residing on a file system different from Kernel's
mount /dev/sda3 v
kernel v/bzimage
mount /dev/sdb1 u
initrd u/boot/initrd.img
append root=/dev/sdb1 ro ramdisk_size=100000 lang=us apm=power-off nomce vga=791


Does not work:
>Loading Initramfs residing on a file system different from Kernel's
>Loading kernel ...
>>kernel: /mnt/target/v/bzimage
>>append: root=/dev/sdb1 ro ramdisk_size=100000 lang=us apm=power-off nomce vga=791
>>initrd: /mnt/target/u/boot/initrd.img
>>Cannot open '/mnt/target/v/bzimage': stream error
>Unmounting /mnt/target/u/

What mount lines were before that?

Diagnostics in entirety:-

>Loading Initramfs residing on a file system different from Kernel's
>Loading kernel ...
>>kernel: /mnt/target/v/bzimage
>>append: root=/dev/sdb1 ro ramdisk_size=100000 lang=us apm=power-off nomce vga=791
>>initrd: /mnt/target/u/boot/initrd.img
>>Cannot open '/mnt/target/v/bzimage': stream error
>Unmounting /mnt/target/u/
>>Unmount failed: No such file or directory
>Unmounting /mnt/target/v/
>>Unmount failed: No such file or directory
>Executing kernel ...
>>Reboot failed: Invalid argument

As for CONFIGs, I should just lift the code and see for myself.

New version here:
http://www.boot-land...?showtopic=6989

jaclaz

New version here:
http://www.boot-land...?showtopic=7124

Thread closed for good.

jaclaz