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

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!

Upon further reading, not a bad idea...
 

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

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??
anyway, I would like to know how you achieve it?

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 )

I'm just now getting to this...
 

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

Following up on this...
 

I've read part of the first link given. I have this thought in result:
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

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. 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

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?

Not enough information yet to know...
 

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

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

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.

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

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