Mailing List Archive

Andrew Goodbody wrote:
> Is it possible for syslinux to boot a kernel stored on a different
> drive/partition to the one on which syslinux was started from?

No, it's not. You can, however, chainload such a partition.

(Ram has been working on some of that support, however, I'm skeptical to
it as it tends to lead down the Grub road of not handling dynamic
systems properly. I would be very interested in the usage case, i.e.
why do you think you need this.)

-hpa

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX@zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.

H. Peter Anvin wrote:
> Andrew Goodbody wrote:
>> Is it possible for syslinux to boot a kernel stored on a different
>> drive/partition to the one on which syslinux was started from?
>
> No, it's not. You can, however, chainload such a partition.
>
> (Ram has been working on some of that support, however, I'm skeptical to
> it as it tends to lead down the Grub road of not handling dynamic
> systems properly. I would be very interested in the usage case, i.e.
> why do you think you need this.)

OK the basic scenario is this:

syslinux plus a comboot program in a floppy image integrated into a BIOS
which will do some custom processing before launching the kernel which
will be on an hdd. Actually the kernel may have been loaded into RAM
before it is booted but I still need the comboot program to be able to
read files from the hdd.
I know the comboot program can do what it likes and read the hdd
directly but I want to use the file system support in syslinux rather
than writing that from scratch and if I do that I could almost drop
syslinux entirely anyway.
So I would be happy with a new comboot API function to change what
syslinux thinks of as its default drive. From that point I could access
the files on the hdd.

Thanks,
Andrew

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX@zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.

Andrew Goodbody wrote:
>
> syslinux plus a comboot program in a floppy image integrated into a BIOS
> which will do some custom processing before launching the kernel which
> will be on an hdd. Actually the kernel may have been loaded into RAM
> before it is booted but I still need the comboot program to be able to
> read files from the hdd.
> I know the comboot program can do what it likes and read the hdd
> directly but I want to use the file system support in syslinux rather
> than writing that from scratch and if I do that I could almost drop
> syslinux entirely anyway.
> So I would be happy with a new comboot API function to change what
> syslinux thinks of as its default drive. From that point I could access
> the files on the hdd.
>

It's not a trivial thing that you ask for, but it's not undoable,
either. It pretty much comes down to reinitializing most of syslinux,
but without reloading the configuration file or anything like that. As
such, it requires a fairly careful change, but it's not undoable.

Now, it's important to realize that this will have to close any open
file descriptors.

-hpa

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX@zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.

Hey,

I have this support working fine. I'll send some patches out next
week, but I have partition support integrated into open()/read() calls
(i bypass calling into the syslinux intcalls to read/open files,
instead do it all in the C library using the io.c calls I sent a patch
for last week), but you can also do this with any com32 module. I'm
not sure if Peter will have any part of these patches in syslinux, but
I can maintain a patch page on the wiki.

FWIW, my use case is to have a fallback bootloader. So, if a boot
failed from one partition, it would boot from another partition. This
is for an embedded system where the bootloader itself is on a 3rd
partition but firmwares are on two separate partiitons.

thanks.

--
Ram

On 4/13/07, H. Peter Anvin <hpa@zytor.com> wrote:
> Andrew Goodbody wrote:
> >
> > syslinux plus a comboot program in a floppy image integrated into a BIOS
> > which will do some custom processing before launching the kernel which
> > will be on an hdd. Actually the kernel may have been loaded into RAM
> > before it is booted but I still need the comboot program to be able to
> > read files from the hdd.
> > I know the comboot program can do what it likes and read the hdd
> > directly but I want to use the file system support in syslinux rather
> > than writing that from scratch and if I do that I could almost drop
> > syslinux entirely anyway.
> > So I would be happy with a new comboot API function to change what
> > syslinux thinks of as its default drive. From that point I could access
> > the files on the hdd.
> >
>
> It's not a trivial thing that you ask for, but it's not undoable,
> either. It pretty much comes down to reinitializing most of syslinux,
> but without reloading the configuration file or anything like that. As
> such, it requires a fairly careful change, but it's not undoable.
>
> Now, it's important to realize that this will have to close any open
> file descriptors.
>
> -hpa
>
> _______________________________________________
> SYSLINUX mailing list
> Submissions to SYSLINUX@zytor.com
> Unsubscribe or set options at:
> http://www.zytor.com/mailman/listinfo/syslinux
> Please do not send private replies to mailing list traffic.
>
>

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX@zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.

Ram Yalamanchili wrote:
> Hey,
>
> I have this support working fine. I'll send some patches out next
> week, but I have partition support integrated into open()/read() calls
> (i bypass calling into the syslinux intcalls to read/open files,
> instead do it all in the C library using the io.c calls I sent a patch
> for last week), but you can also do this with any com32 module. I'm
> not sure if Peter will have any part of these patches in syslinux, but
> I can maintain a patch page on the wiki.

That sounds great. I will look forward to the patches. I hope Peter will
consider including the patches but downloading patches from the wiki
would also work just fine.

Thanks,
Andrew

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX@zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.