Can you kexec at boot from a 32-bit (x86) to 64-bit (x86_64) kernel?
Linux - KernelThis forum is for all discussion relating to the Linux kernel.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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.
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 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!
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 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
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.
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!
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.
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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.