elfboot
I am not able to get linuxbios to load my payload(FILO.elf). Linuxbios went through and jumps to the entry of the payload. 1. Is the elfboot code robust enough(I checked most of the code, it seems good)? 2. Can you suggest any direction for debugging? (everything looks good to me but it won’t boot)? 3. would change the boot loader(rather than elfboot) help? Thanks, Gin
Re: elfboot
On Mon, 29 Nov 2004, Gin wrote:
> When it tries to build the ELF segment list, it checks if the segment
> address is valid by walking through the table of valid memory ranges.
> What is the reason to do this?
Because we don't relocate elf addresses. The addresses in the elf have to
be backed by memory.
> for(i = 0; i < mem_entries; i++) {
> uint64_t mstart, mend;
> uint32_t mtype;
> mtype = mem->map[i].type;
> mstart = mem->map[i].start;
> mend = mstart + mem->map[i].size;
> if ((mtype == LB_MEM_RAM) && (start < mend) && (end >
> mstart)) {
Possibly I'm reading this wrong but ... this test looks somewhat broken.
take a simple case.
memory start 0x1000 memory end 0x2000
elfstart 0x1001 elf end 0x3000
Seems like this test will indicate, incorrectly, that the elf segment will
fit in physical memory and that is not the case.
ron
___
Linuxbios mailing list
[EMAIL PROTECTED]
http://www.clustermatic.org/mailman/listinfo/linuxbios
elfboot
I know it’s probably
been a while since you look into the elfboot code.
In the elfboot.c
When it tries to build the
ELF segment list, it checks if the segment address is valid by walking through the
table of valid memory ranges. What is the reason to do this? Below is the code, the “if ” statement seems only guarantee that the new
addresses INTERSECT with the valid memory range, not fully contained.
for(i = 0; i < mem_entries; i++) {
uint64_t mstart, mend;
uint32_t mtype;
mtype = mem->map[i].type;
mstart = mem->map[i].start;
mend = mstart + mem->map[i].size;
if ((mtype == LB_MEM_RAM)
&& (start < mend) && (end > mstart))
{
break;
}
}
Re: Difference between Linxubios native's Elfboot and Linuxbios native's Filo
Le ven 04/06/2004 Ã 22:34, Peter Stuge a Ãcrit : > On Fri, Jun 04, 2004 at 06:01:56PM +0200, Mathieu Deschamps wrote: > > What I'am gaining with Linuxbios experience I'll try to give back in > > somehow i could, don't you feel this ?. > > I agree! :) I think the lbcc script can be very useful! thank you :) yes maybe it will if it's shared and credited. For now, it needs some pipe work to connect to linuxbios utils and LANL's guidance and everybody's credit/opinion. Le sam 05/06/2004 Ã 03:40, Peter Stuge a Ãcrit : > On Fri, Jun 04, 2004 at 04:06:41PM -0600, ron minnich wrote: > > > I hope this doesn't have to become a big problem, we should be able > > > to just talk about it and straighten any issues out. It has been > > > done online before. > > > > We'll all cool off over the weekend and work it out next week. > > Sounds good. Kick back and enjoy a can or two of beverage here> in the sun, if you happen to live near some summer. :) > > > > thanks > > No problem. Hope you all have a nice weekend! yes it was i got sunburnt but i'am cool off that's ok now :) > > > //Peter > ___ > Linuxbios mailing list > [EMAIL PROTECTED] > http://www.clustermatic.org/mailman/listinfo/linuxbios > > > > > > We had hoped to hash these issues out at the linuxbios summit > > > but were unable to bring that meeting to fruition. > > > > > > Short form: I would ask all involved not to take actions that > > > could lead to consequences we will all regret. > > I hope this doesn't have to become a big problem, we should be able > to just talk about it and straighten any issues out. It has been > done online before. > > Just my EUR .02. :) > > > //Peter > ___ > Linuxbios mailing list > [EMAIL PROTECTED] > http://www.clustermatic.org/mailman/listinfo/linuxbios > ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Difference between Linxubios native's Elfboot and Linuxbios native's Filo
On Fri, Jun 04, 2004 at 04:06:41PM -0600, ron minnich wrote: > > I hope this doesn't have to become a big problem, we should be able > > to just talk about it and straighten any issues out. It has been > > done online before. > > We'll all cool off over the weekend and work it out next week. Sounds good. Kick back and enjoy a can or two of in the sun, if you happen to live near some summer. :) > thanks No problem. Hope you all have a nice weekend! //Peter ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Difference between Linxubios native's Elfboot and Linuxbios native's Filo
On Fri, 4 Jun 2004, Peter Stuge wrote: > I hope this doesn't have to become a big problem, we should be able > to just talk about it and straighten any issues out. It has been > done online before. We'll all cool off over the weekend and work it out next week. thanks ron ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Difference between Linxubios native's Elfboot and Linuxbios native's Filo
On Fri, Jun 04, 2004 at 06:01:56PM +0200, Mathieu Deschamps wrote: > What I'am gaining with Linuxbios experience I'll try to give back in > somehow i could, don't you feel this ?. I agree! :) I think the lbcc script can be very useful! > > We had hoped to hash these issues out at the linuxbios summit > > but were unable to bring that meeting to fruition. > > > > Short form: I would ask all involved not to take actions that > > could lead to consequences we will all regret. I hope this doesn't have to become a big problem, we should be able to just talk about it and straighten any issues out. It has been done online before. Just my EUR .02. :) //Peter ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Difference between Linxubios native's Elfboot and Linuxbios native's Filo
Hum.. I wasn't intended to be a media you use to rise such a polemic.. But from polemic can rise good things, and now that i'am part : Le ven 04/06/2004 Ã 17:29, ron minnich a Ãcrit : > On 4 Jun 2004, Mathieu Deschamps wrote: > > > > The native ``filo'' is scheduled for deletion, it touches hardwaremain > > > which it should not. As implemented it is a maintenance nightmare and > > > an implementation of policy and I refuse to support it, in the core of > > > LinuxBIOS. Until just a little while ago I thought it was much less > > > intrusive so was not forcing the issue. > > > > ok I understand. > > > well, I am afraid I do not. > > No one has contacted any of the other core maintainers of linuxbios and > vetted this suggestion of scheduling components for deletion. This > suggestion of deleting the embedded filo came out of left field, at least > to me. Major changes on this level need discussion! > > LinuxBIOS is a cooperative project. People add things from time to time > that others do not like. Every other core member of this project has added > software, at times, that I was not totally happy with, but I also have not > deleted such software because it is the nature of shared open source > projects that you can't keep everyone 100% happy all of the time. There > are things in both V1 and V2 I dislike very much, but I recognize the > right of authorship and the differences of opinion that come with > different people writing different code. I do agree... even if IMHO mainteners are not clearly identified. > > I should probably remind everyone here that this project was started by > LANL, and that the control of this project remains at LANL. We are a > non-profit, and I hope neutral, third party. I have had questions from > time to time about whether this or that commercial entity has too much > control of the project, and my response has always been: "Don't worry, > calm down, LANL is neutral here and can make sure we play fair". This > type of query is serious. At one point I had a commercial company > hinting about legal action as they felt that another company was > holding back on releasing code to CVS. I was able to calm that one > down too, simply by pointing out the role that LANL plays. Trying to understand the hows and the whys, obvious I'am not targeted... I hope so, or YOUR OpenSource banner you rise means nothing if,for instance, features request can't be clearly openly answered, don't you think ? Anyway, I don't feel targeted concerning making majors changes :-) nor I'am concerned on lack of concertation. For the rest, maybe i'am sensible but I have to say that commercial entity do not all aim at same thing or at least does not behave all the same. What I'am gaining with Linuxbios experience I'll try to give back in somehow i could, don't you feel this ?. mathieu > LANL has a duty to provide a level playing ground for all involved. We can > not and will not allow deletions of subsystems deemed important by users > without some amount of discussion first, followed by some sort of > agreement. We had hoped to hash these issues out at the linuxbios summit > but were unable to bring that meeting to fruition. > > Short form: I would ask all involved not to take actions that could lead > to consequences we will all regret. > > ron > > ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Difference between Linxubios native's Elfboot and Linuxbios native's Filo
ron minnich <[EMAIL PROTECTED]> writes: > > well, I am afraid I do not. > > No one has contacted any of the other core maintainers of linuxbios and > vetted this suggestion of scheduling components for deletion. This > suggestion of deleting the embedded filo came out of left field, at least > to me. Major changes on this level need discussion! Exactly. No ever even discussed including it. No one ever discussed changing our long standing compromise. When I heard about it clear it was on the edge of a line I would not cross. And now that I have actually had a chance to look I see that it is over that line. Now there are some real issues that need to be solved to make it simpler for users and sometime when I am not so mad I can barely talk. I will do something. Eric ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Difference between Linxubios native's Elfboot and Linuxbios native's Filo
On 4 Jun 2004, Mathieu Deschamps wrote: > > The native ``filo'' is scheduled for deletion, it touches hardwaremain > > which it should not. As implemented it is a maintenance nightmare and > > an implementation of policy and I refuse to support it, in the core of > > LinuxBIOS. Until just a little while ago I thought it was much less > > intrusive so was not forcing the issue. > > ok I understand. well, I am afraid I do not. No one has contacted any of the other core maintainers of linuxbios and vetted this suggestion of scheduling components for deletion. This suggestion of deleting the embedded filo came out of left field, at least to me. Major changes on this level need discussion! LinuxBIOS is a cooperative project. People add things from time to time that others do not like. Every other core member of this project has added software, at times, that I was not totally happy with, but I also have not deleted such software because it is the nature of shared open source projects that you can't keep everyone 100% happy all of the time. There are things in both V1 and V2 I dislike very much, but I recognize the right of authorship and the differences of opinion that come with different people writing different code. I should probably remind everyone here that this project was started by LANL, and that the control of this project remains at LANL. We are a non-profit, and I hope neutral, third party. I have had questions from time to time about whether this or that commercial entity has too much control of the project, and my response has always been: "Don't worry, calm down, LANL is neutral here and can make sure we play fair". This type of query is serious. At one point I had a commercial company hinting about legal action as they felt that another company was holding back on releasing code to CVS. I was able to calm that one down too, simply by pointing out the role that LANL plays. LANL has a duty to provide a level playing ground for all involved. We can not and will not allow deletions of subsystems deemed important by users without some amount of discussion first, followed by some sort of agreement. We had hoped to hash these issues out at the linuxbios summit but were unable to bring that meeting to fruition. Short form: I would ask all involved not to take actions that could lead to consequences we will all regret. ron ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Difference between Linxubios native's Elfboot and Linuxbios native's Filo
Le ven 04/06/2004 Ã 02:34, Eric W. Biederman a Ãcrit : > Mathieu Deschamps <[EMAIL PROTECTED]> writes: > > > Hello, > > > > Since i have mostly 'directly choose' Filo, i haven't had > > much time asking for the difference between Linuxbios native's Elfboot > > and Linuxbios native's filo. I know you did made some work around > > theses... > > The native ``filo'' is scheduled for deletion, it touches hardwaremain > which it should not. As implemented it is a maintenance nightmare and > an implementation of policy and I refuse to support it, in the core of > LinuxBIOS. Until just a little while ago I thought it was much less > intrusive so was not forcing the issue. ok I understand. > > > (i have read the doc of Sone Takeshi and i have the features of filo.) > > > > Could you explain me what differences there are and/or whether > > this one best suited for DoC or CF or other types i'am ignoring ? > > Please also let me know what type of filesys elfboot boots, and other > > thing about support > > ELF boot is a minimal loader just good enough to load something real > out off some device. ELF boot just grabs an ELF image at the offset > in a device it is pointed at. The image can be sparse so it can exist > with partition tables and filesystems. The trivial solution is to put > a partition right after partition table for the ELF image. More > interesting forms of coexistance are possible by noone has implemented > more than a proof of concept. > > If you want to use filo which understand filesystems and partitions > get the real one. It has been developing faster and it appears to have > more features. Ok, this week I'am a bit brain-slowed, so I recap to see if I catch the whole meaning: you say that filo shouldn't be inside Linuxbios in the way it forces implementation/maintenance that isn't clean. So that's it : letting payload type program to modify 'Linuxbios core' is not acceptable, is it ? Then you say, what I can is to adopt the outside filo solution 'the real one' that has not the above burden, and that have moreover a lots of feature the inside's filo haven't. (I have made a tool lbcc to build, to configure a rom and I seek also it to do the payload whatever is your payload program. But i felt troubled by coding the 'payload maker' because i hadn't clearly seen the "2 filos" even if I felt them.) Thanks for the explaination but.. err i still can't make myself answer to theses questions. -Can ELF boot onto CF , DoC or even CDROM and others instead of normal hard disk ? -Can it boot kernel from ext2, ext3, iso9660 or others ? -Can it understand image like bzImage or others? You see I would like to make truely a list of payload solutions in a tab, and to tick whatever this solution or this other can this or that. So that somebody's look on my tab, can say "-ok, this is my solution for my build config, and it handles that filesys, support that image format" mathieu > Eric > ___ > Linuxbios mailing list > [EMAIL PROTECTED] > http://www.clustermatic.org/mailman/listinfo/linuxbios > ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Difference between Linxubios native's Elfboot and Linuxbios native's Filo
Mathieu Deschamps <[EMAIL PROTECTED]> writes: > Hello, > > Since i have mostly 'directly choose' Filo, i haven't had > much time asking for the difference between Linuxbios native's Elfboot > and Linuxbios native's filo. I know you did made some work around > theses... The native ``filo'' is scheduled for deletion, it touches hardwaremain which it should not. As implemented it is a maintenance nightmare and an implementation of policy and I refuse to support it, in the core of LinuxBIOS. Until just a little while ago I thought it was much less intrusive so was not forcing the issue. > (i have read the doc of Sone Takeshi and i have the features of filo.) > > Could you explain me what differences there are and/or whether > this one best suited for DoC or CF or other types i'am ignoring ? > Please also let me know what type of filesys elfboot boots, and other > thing about support ELF boot is a minimal loader just good enough to load something real out off some device. ELF boot just grabs an ELF image at the offset in a device it is pointed at. The image can be sparse so it can exist with partition tables and filesystems. The trivial solution is to put a partition right after partition table for the ELF image. More interesting forms of coexistance are possible by noone has implemented more than a proof of concept. If you want to use filo which understand filesystems and partitions get the real one. It has been developing faster and it appears to have more features. Eric ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: elfboot
ron minnich <[EMAIL PROTECTED]> writes: > On 8 Jul 2003, Eric W. Biederman wrote: > > > > > The strange choices in linuxbios main where it decompresses the kernel > > instead of using the kernels own decompressor, are among the many > > reasons it is deprecated. > > no strange at all in 2000, when we figured to boot many other kernels that > did not have their own decompressor. I agree it makes sense from the context in which it was written. I was just to lazy to fill in the context for a deprecated feature. Eric ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: elfboot
On 8 Jul 2003, Eric W. Biederman wrote: > > The strange choices in linuxbios main where it decompresses the kernel > instead of using the kernels own decompressor, are among the many > reasons it is deprecated. no strange at all in 2000, when we figured to boot many other kernels that did not have their own decompressor. ron ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: elfboot
Xavier Pegenaute <[EMAIL PROTECTED]> writes: > Hi, > > > On Tue, 2003-07-08 at 02:03, Eric W. Biederman wrote: > > > 1) We want start an ELF binary (not payload) that is in DoC (p.e.) after > > > LinuxBios. Then we execute elfboot() that look inside the ROM for the > > > next code starting with a valid ELF header, build the segments, copy the > > > segments and give the control to the program. > > > > > > No problem in this case, i think. > > > > Sounds like standard use. > > > > > 2) We want start a Linux Kernel that is recorded (neither payload) after > > > LinuxBios binary in DoC (p.e.), then we execute linuxbiosmain() and in > > > the end of this function we make a long jump to 0x9. > > > > Linuxbiosmain() is deprecated code and it always jumps to 0x10 1MB. > > Anything is not done. And everyone is encouraged not to use linuxbiosmain > > for new deployments. > > > > > Here, i don't see what function in linuxbiosmain() copy the code of > > > Kernel to DRAM.Any one know it ? > > > > It is the gunzip part. But please don't use that. > > The problem, is that, if i follow the instructions of > freebios/HOWTO/SiS630, the linux kernel binary generated doesn't has > elfheader. > > Then if i want to use the standard use, i have apply some external > utility to generate an elf file (mkelfImage) and put in config file > "fileoption USE_ELF_BOOT=1". Is it right ? Essentially correct. MkelfImage takes a standard x86 linux kernel and wraps so it is a bootable ELF executable. The latest mkelfImage can be found at: ftp://ftp.lnxi.com/pub/mkelfImage/ > Another think, i thought that the Linux Kernel alone has the code to > decompress himself (in the same way that we can put Kernel in a floppy > disk and it decompress alone. (dd if=kernel of=/dev/fd0)) The strange choices in linuxbios main where it decompresses the kernel instead of using the kernels own decompressor, are among the many reasons it is deprecated. Eric ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: elfboot
Hi, On Tue, 2003-07-08 at 02:03, Eric W. Biederman wrote: > > 1) We want start an ELF binary (not payload) that is in DoC (p.e.) after > > LinuxBios. Then we execute elfboot() that look inside the ROM for the > > next code starting with a valid ELF header, build the segments, copy the > > segments and give the control to the program. > > > > No problem in this case, i think. > > Sounds like standard use. > > > 2) We want start a Linux Kernel that is recorded (neither payload) after > > LinuxBios binary in DoC (p.e.), then we execute linuxbiosmain() and in > > the end of this function we make a long jump to 0x9. > > Linuxbiosmain() is deprecated code and it always jumps to 0x10 1MB. > Anything is not done. And everyone is encouraged not to use linuxbiosmain > for new deployments. > > > Here, i don't see what function in linuxbiosmain() copy the code of > > Kernel to DRAM.Any one know it ? > > It is the gunzip part. But please don't use that. The problem, is that, if i follow the instructions of freebios/HOWTO/SiS630, the linux kernel binary generated doesn't has elfheader. Then if i want to use the standard use, i have apply some external utility to generate an elf file (mkelfImage) and put in config file "fileoption USE_ELF_BOOT=1". Is it right ? Another think, i thought that the Linux Kernel alone has the code to decompress himself (in the same way that we can put Kernel in a floppy disk and it decompress alone. (dd if=kernel of=/dev/fd0)) Thanks. Xavi. ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: elfboot
Xavier Pegenaute <[EMAIL PROTECTED]> writes: > Hi, > > any one can help me with this ? > > I was thinking that after crt0.S in ROMBASE (0x8 for Matsonic) copy > the LinuxBios (the payload) into DRAM (RAMBASE 0x4000 for Matsonic) > follow the code to hardwaremain() initialitizing all hardware and arrive > in write_tables that prepare the memory to let information about the > hardware to the next O.S., and now we can choose between: > > 1) We want start an ELF binary (not payload) that is in DoC (p.e.) after > LinuxBios. Then we execute elfboot() that look inside the ROM for the > next code starting with a valid ELF header, build the segments, copy the > segments and give the control to the program. > > No problem in this case, i think. Sounds like standard use. > 2) We want start a Linux Kernel that is recorded (neither payload) after > LinuxBios binary in DoC (p.e.), then we execute linuxbiosmain() and in > the end of this function we make a long jump to 0x9. Linuxbiosmain() is deprecated code and it always jumps to 0x10 1MB. Anything is not done. And everyone is encouraged not to use linuxbiosmain for new deployments. > Here, i don't see what function in linuxbiosmain() copy the code of > Kernel to DRAM.Any one know it ? It is the gunzip part. But please don't use that. Eric ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: [PATCH] Fix to elfboot checksum problem
SONE Takeshi <[EMAIL PROTECTED]> writes: > Hi, > I think I've at last found a bug in elfboot.c. > Until this fix, I had always needed to disable verify code in > elfboot.c to get it work. > Now it boots ELF kernel with BOOT_IDE perfectly. > > One of doubly-linked chain was not initialized. > I think it did not cause problem when memory near address 0 comes > up with zeroes. > But my raminit.inc leaves gabages there so some bogus memory ranges > have been included in checksum. Thanks good catch. Another possibility is that the checksum is optional and not all versions of mkelfImage add it, and etherboot does not. So that code path is not exercised quite as much as it should be. Eric ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
elfboot
Hi, any one can help me with this ? I was thinking that after crt0.S in ROMBASE (0x8 for Matsonic) copy the LinuxBios (the payload) into DRAM (RAMBASE 0x4000 for Matsonic) follow the code to hardwaremain() initialitizing all hardware and arrive in write_tables that prepare the memory to let information about the hardware to the next O.S., and now we can choose between: 1) We want start an ELF binary (not payload) that is in DoC (p.e.) after LinuxBios. Then we execute elfboot() that look inside the ROM for the next code starting with a valid ELF header, build the segments, copy the segments and give the control to the program. No problem in this case, i think. 2) We want start a Linux Kernel that is recorded (neither payload) after LinuxBios binary in DoC (p.e.), then we execute linuxbiosmain() and in the end of this function we make a long jump to 0x9. Here, i don't see what function in linuxbiosmain() copy the code of Kernel to DRAM.Any one know it ? Thanks. Xavi. ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
[PATCH] Fix to elfboot checksum problem
Hi,
I think I've at last found a bug in elfboot.c.
Until this fix, I had always needed to disable verify code in
elfboot.c to get it work.
Now it boots ELF kernel with BOOT_IDE perfectly.
One of doubly-linked chain was not initialized.
I think it did not cause problem when memory near address 0 comes
up with zeroes.
But my raminit.inc leaves gabages there so some bogus memory ranges
have been included in checksum.
--
Takeshi
Index: src/lib/elfboot.c
===
RCS file: /cvsroot/freebios/freebios/src/lib/elfboot.c,v
retrieving revision 1.15
diff -u -r1.15 elfboot.c
--- src/lib/elfboot.c 10 Oct 2002 22:23:43 - 1.15
+++ src/lib/elfboot.c 30 Jun 2003 18:11:26 -
@@ -368,6 +368,7 @@
int i;
memset(head, 0, sizeof(*head));
head->next = head->prev = head;
+ head->phdr_next = head->phdr_prev = head;
for(i = 0; i < headers; i++) {
struct segment *new;
/* Ignore data that I don't need to handle */
___
Linuxbios mailing list
[EMAIL PROTECTED]
http://www.clustermatic.org/mailman/listinfo/linuxbios
mkelfImage-2.2 and the kernel exec source code, and the elfboot toolkit
Hello from Gregg C Levine Eric a number of questions have arisen. First of all, in the readme files for the kernel exec source code, you recommend that I obtain the elfboot toolkit. The suggested reason, is that its because there is a client for the kexec function inside it. Obviously the make elfImage version that you just supplied is the recommended version so that's not a problem. But what finally happened with the elfboot toolkit? For that matter, is any work being done regarding the kexec source code? --- Gregg C Levine [EMAIL PROTECTED] "The Force will be with you...Always." Obi-Wan Kenobi "Use the Force, Luke." Obi-Wan Kenobi (This company dedicates this E-Mail to General Obi-Wan Kenobi ) (This company dedicates this E-Mail to Master Yoda ) ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
