LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Kernel (http://www.linuxquestions.org/questions/linux-kernel-70/)
-   -   Can you kexec at boot from a 32-bit (x86) to 64-bit (x86_64) kernel? (http://www.linuxquestions.org/questions/linux-kernel-70/can-you-kexec-at-boot-from-a-32-bit-x86-to-64-bit-x86_64-kernel-735628/)

Shingoshi 06-25-2009 02:30 PM

Can you kexec at boot from a 32-bit (x86) to 64-bit (x86_64) kernel?
 
I'm wanting to know if some test can be done to check the processor at boot, and load a kernel best suited to that architecture? I'm thinking of having two versions on an operating system loaded on a single filesystem (on removable disks), which can then select which of the two systems should run on that processor. The advantage being that anyone doing this could move from one system to another, and always have access to their favorite distribution on any processor.

Shingoshi

clvic 06-26-2009 06:20 PM

Although I know very few about kexec, I suppose it's not capable to change the architecture on the fly.
Anyway, I think that another option to choose at load time whether to load a 32bit or a 64 bit os, could be to start a kernel along with a minimal system that: (1) detects whether the CPU is 64bit capable, and (2) modifies grub on the fly to have the right OS loaded at the next reboot. And (3) automatically reboot.
I know this is slow, but that should be effective.

Anyway, this is an interesting question, although I do not really know whether real applications are worth it

Shingoshi 06-26-2009 06:39 PM

I have an application already in place for this. But keep this thread open, as I am still looking for others to contribute here. And it may lead to some very good results.

Shingoshi

Thank you for the thumbs up. I really appreciate it!

Shingoshi 06-26-2009 06:50 PM

Upon further reading, not a bad idea...
 
Quote:

Originally Posted by clvic (Post 3587574)
Although I know very few about kexec, I suppose it's not capable to change the architecture on the fly.
Anyway, I think that another option to choose at load time whether to load a 32bit or a 64 bit os, could be to start a kernel along with a minimal system that: (1) detects whether the CPU is 64bit capable, and (2) modifies grub on the fly to have the right OS loaded at the next reboot. And (3) automatically reboot.
I know this is slow, but that should be effective.

Anyway, this is an interesting question, although I do not really know whether real applications are worth it

I had thought about having one system boot into another quite some time ago. The idea looked something like having a complete busybox system stored in your /boot partition. The purpose of this would be manifold:

1.) Exhaustive systems integrity check on each boot.
2.) The user would always have a rescue system in place to boot the main system and fix any errors that may exist.
3.) A solution like your suggestion is made easily possible.

I don't know if it would be absolutely necessary to reboot or not. I would hope not. I was thinking modifying a setup like that used when booting an installed system from a cd/vd when things aren't working as they should. The completely contained system in /boot would serve the same purpose. It would be used on every boot, having the ability to do a complete systems check before switching over to the main system.

I like your idea, and will give it consideration.

Shingoshi

linus72 06-26-2009 06:58 PM

Hello, how are you doing kexec?

I have used "netbootcd-3.1.1" which comes with(and is based off of) tinycore 2.0.
I am not sure what it means below where it says you need a tce for kexec
as far as I know there is no kexec.tce??
Code:

LABEL nbcd
menu label Start ^NetbootCD 3.1.1
menu default
kernel kexec.bzI
append initrd=nbinit3.gz quiet

#LABEL tinycore-kexec
#menu label Start ^Tiny Core 2.0 with kexec support (you still need the tce)
#kernel kexec.bzI
#append initrd=tinycore.gz quiet

anyway, I would like to know how you achieve it?

linus72 06-26-2009 07:08 PM

Shingoshi, have you read all this?

( http://en.wikipedia.org/wiki/Kexec )

( http://www.ibm.com/developerworks/li...y/l-kexec.html )
( http://www.linux.com/archive/feature/150202 )

Shingoshi 06-26-2009 08:17 PM

I'm just now getting to this...
 
Quote:

Originally Posted by linus72 (Post 3587609)

I've never used kexec. I've only known that it exists. I was asking this question in a general manner, to know what's possible and how to go about it if so. I will now take the time to read the links you've left here. I might have seen some of them before.

Shingoshi

Shingoshi 06-26-2009 08:26 PM

Following up on this...
 
I've read part of the first link given. I have this thought in result:
Quote:

kexec (kernel execution) is a mechanism of the Linux kernel that allows "live" booting of a new kernel over the currently running one. kexec skips the bootloader stage (hardware initialization phase by the firmware or BIOS) and directly loads the new kernel into memory, which starts executing immediately. This avoids the long times associated with a full reboot[1], and is useful on systems with high availability requirements, where minimizing downtime is of essence.
I think the best way to do this, would be before the modules are even loaded. It wouldn't make sense to load modules for a 32-bit kernel, and then have to reload them for a 64-bit kernel. I know that VectorLinux has a nicer way of switching runlevels. Instead of shutting down everything in the old level, only to have to restart the same services in the new, the same logic should be used here. Only start those services which are common to any kernel regardless of their bit form.

That way, we don't waste time shutting down and restarting services that should have been postponed until really needed.

Let's keep this discussion open. This is beginning to get good!

Shingoshi

Shingoshi 06-26-2009 08:45 PM

A more intelligent bootloader is needed...
 
It seems there needs to be a bootloader capable of selecting a kernel for the running architecture. Because based on the following comments, it seems this needs to be done by the bootloader itself.
Quote:

[http://www.ibm.com/developerworks/li.../l-kexec.html] The main components of the bootloader stage are the hardware stage, the firmware stage, the first-level bootloader, and the second-level bootloader. The booting process begins when the hardware is powered on. After some initialization, control goes to the firmware. Firmware, also referred to as "BIOS" on some architectures, detects the various devices on the system, including memory controllers, storage devices, bus bridges, and other hardware. The firmware, based on the settings, hands over control to a minimal bootloader known as the master boot record, which could be on a disk drive, on a removable media, or over the network. The actual job of transferring control to the operating system is performed by the second-stage bootloader (commonly referred to as simply the "boot loader"). This bootloader allows the user to choose the kernel to be loaded, loads the kernel and related parameters onto memory, initializes the kernel, sets up the necessary environment, and finally "runs" the kernel.
Apparently, we need a set of code that detects the processor type, whether it is 32|64-bit. That would be done in the firmware stage as described above. This seems to be universal. When a system is running on a 64-bit processor, but loads a 32-bit kernel, the selection needs to take place before then. This could be done automatically, or manually with another boot menu provided to the user.

Tell me what the rest of you think about this.

Shingoshi

linus72 06-26-2009 08:59 PM

So, do you think it's safe to the computer to do this, no ill effects?

Do you think practicing it in a virtual environment would work too?

Shingoshi 06-26-2009 09:06 PM

Not enough information yet to know...
 
Quote:

Originally Posted by linus72 (Post 3587673)
So, do you think it's safe to the computer to do this, no ill effects?

Do you think practicing it in a virtual environment would work too?

I don't want to give an uninformed response here. This was something that I originally came up with from a "what if?" line of thought. I'm still working this through though. I wish some developers would see and pick up on this. But I definitely think the bootloader must be responsible, not kexec. Because this needs to be done before any kernel is loaded, not switching from one to another like an afterthought.

Shingoshi

linus72 06-26-2009 09:12 PM

Hey, check out all this I just found

( https://lists.linux-foundation.org/p...er/009150.html )

https://wiki.ubuntu.com/RapidReboot

http://www.boot-land.net/forums/inde...st=10&start=10

http://www.solemnwarning.net/kexec-l....1.readme.html

http://www.solemnwarning.net/kexec-loader/

http://wiki.archlinux.org/index.php/Kexec

linus72 06-26-2009 09:20 PM

Actually, here's the 2.0 kexec-loader manual

http://www.solemnwarning.net/kexec-l....0-readme.html

says it's for booting usb's, etc on computers where bios doesn't support that.

Shingoshi 06-26-2009 09:44 PM

It seems, I opened a barrel of worms...
 
These would be the good worms some of us liked to play with as kids. This thread could produce a great deal of fun for a lot of people.

Shingoshi

syg00 06-26-2009 09:45 PM

kexec-loader looks like the answer - must try it.


All times are GMT -5. The time now is 04:56 AM.