I have just started reading up on LinuxBIOS and am keen to use it on my EPIA-M powered Linux server (for... speed! - ok, and coolness-factor)... and wondered why GRUB isn't listed (or suggested) as a payload option... seems an obvious choice to me (not knowing the inner workings of LinuxBIOS), also, has anyone started working on a keyboard based config utility such as is found by pressing F2 or similar at bootup in proprietory BIOS'?
J.
* Jamey jamey@vodafone.net.nz [060904 12:59]:
I have just started reading up on LinuxBIOS and am keen to use it on my EPIA-M powered Linux server (for... speed! - ok, and coolness-factor)... and wondered why GRUB isn't listed (or suggested) as a payload option...
The problem with grub (v0.9x) is that it makes heavy use of 16bit bios callbacks that do not work with 32bit LinuxBIOS. But you can use FILO as LinuxBIOS payload. FILO has an option to display a grub menu by reading menu.lst. Check out http://www.linuxbios.org/index.php/FILO
seems an obvious choice to me (not knowing the inner workings of LinuxBIOS), also, has anyone started working on a keyboard based config utility such as is found by pressing F2 or similar at bootup in proprietory BIOS'?
Such a configuration utility exists. But since the CMOS format is open and can be changed at compile time, the utility is not built into LinuxBIOS but available as a (Linux) userspace program, so you can use it in shell scripts and programs to automatically trigger certain behavior. It is called lxbios. See http://lxbios.sourceforge.net/
Stefan Reinauer wrote:
- Jamey jamey@vodafone.net.nz [060904 12:59]:
I have just started reading up on LinuxBIOS and am keen to use it on my EPIA-M powered Linux server (for... speed! - ok, and coolness-factor)... and wondered why GRUB isn't listed (or suggested) as a payload option...
The problem with grub (v0.9x) is that it makes heavy use of 16bit bios callbacks that do not work with 32bit LinuxBIOS. But you can use FILO as LinuxBIOS payload. FILO has an option to display a grub menu by reading menu.lst. Check out http://www.linuxbios.org/index.php/FILO
Grub has a chainloader. Can FILO chainload?
Thanks!
-- Al
* Al Boldi a1426z@gawab.com [060923 07:30]:
Stefan Reinauer wrote:
- Jamey jamey@vodafone.net.nz [060904 12:59]:
I have just started reading up on LinuxBIOS and am keen to use it on my EPIA-M powered Linux server (for... speed! - ok, and coolness-factor)... and wondered why GRUB isn't listed (or suggested) as a payload option...
The problem with grub (v0.9x) is that it makes heavy use of 16bit bios callbacks that do not work with 32bit LinuxBIOS. But you can use FILO as LinuxBIOS payload. FILO has an option to display a grub menu by reading menu.lst. Check out http://www.linuxbios.org/index.php/FILO
Grub has a chainloader. Can FILO chainload?
Load Windows? No. Windows uses 16bit interrupt callbacks. Not possible in 32bit LinuxBIOS.
Have a look at "ADLO", it was designed to solve this problem.
Stefan Reinauer wrote:
- Al Boldi a1426z@gawab.com [060923 07:30]:
Stefan Reinauer wrote:
- Jamey jamey@vodafone.net.nz [060904 12:59]:
I have just started reading up on LinuxBIOS and am keen to use it on my EPIA-M powered Linux server (for... speed! - ok, and coolness-factor)... and wondered why GRUB isn't listed (or suggested) as a payload option...
The problem with grub (v0.9x) is that it makes heavy use of 16bit bios callbacks that do not work with 32bit LinuxBIOS. But you can use FILO as LinuxBIOS payload. FILO has an option to display a grub menu by reading menu.lst. Check out http://www.linuxbios.org/index.php/FILO
Grub has a chainloader. Can FILO chainload?
Load Windows? No. Windows uses 16bit interrupt callbacks. Not possible in 32bit LinuxBIOS.
I was thinking more like loading another bootloader. This way, there is no need to fuss around with user-interface, image-type, or fs-level access, but instead just load a no-frills MBR.
Have a look at "ADLO", it was designed to solve this problem.
Thanks for the pointer, but it looks like the sourceforge cvs is dead, and ADLO seems to be some sort of a 16bit BIOS compatibility layer, when all that is needed is a simple MBR chainloader.
I even looked into OpenBIOS, but it seems even this one tries to be another bootloader on its own.
I am probably missing something...
Thanks!
-- Al
* Al Boldi a1426z@gawab.com [060924 06:46]:
I was thinking more like loading another bootloader. This way, there is no need to fuss around with user-interface, image-type, or fs-level access, but instead just load a no-frills MBR.
why would you want to "load an mbr" if you can easily read files from all kinds of existing filesystems as well? This is opensource. If a new filesystem comes into existance, you can boot from it.
Thanks for the pointer, but it looks like the sourceforge cvs is dead, and ADLO seems to be some sort of a 16bit BIOS compatibility layer, when all that is needed is a simple MBR chainloader.
No, "a simple MBR chainloader" is not all that is needed. The code that you will find in an MBR will do bios callbacks, and you need to answer those, or you will jump to nirvana.
What is your requirement? Loading Windows?
Stefan
Stefan Reinauer wrote:
- Al Boldi a1426z@gawab.com [060924 06:46]:
I was thinking more like loading another bootloader. This way, there is no need to fuss around with user-interface, image-type, or fs-level access, but instead just load a no-frills MBR.
why would you want to "load an mbr" if you can easily read files from all kinds of existing filesystems as well?
Modularization.
This is opensource. If a new filesystem comes into existance, you can boot from it.
So maybe leave the bootloader chainloaded as a separate module from the block-driver.
Thanks for the pointer, but it looks like the sourceforge cvs is dead, and ADLO seems to be some sort of a 16bit BIOS compatibility layer, when all that is needed is a simple MBR chainloader.
No, "a simple MBR chainloader" is not all that is needed. The code that you will find in an MBR will do bios callbacks, and you need to answer those, or you will jump to nirvana.
Ok, that's why we need a block-driver to chainload the MBR.
What is your requirement? Loading Windows?
Loading Linux, on an i440bx with a brain-dead AwardBIOS that can't boot USB, nor can it boot disks >32GB. Filo does the trick, but has its issues wrt APM and its inability to remember boot commands like LiLo can.
Would chainloading LiLo be possible?
Thanks!
-- Al
Al Boldi wrote:
Stefan Reinauer wrote:
Thanks for the pointer, but it looks like the sourceforge cvs is dead, and ADLO seems to be some sort of a 16bit BIOS compatibility layer, when all that is needed is a simple MBR chainloader.
No, "a simple MBR chainloader" is not all that is needed. The code that you will find in an MBR will do bios callbacks, and you need to answer those, or you will jump to nirvana.
Ok, that's why we need a block-driver to chainload the MBR.
No. Please reread Stefan's answer. Chainloading is not possible without ADLO. Even with a block driver. You need a *complete* 16-bit BIOS emulation for chainloading. And that's what ADLO gives you.
Regards, Carl-Daniel
Al Boldi wrote:
Stefan Reinauer wrote:
What is your requirement? Loading Windows?
Loading Linux, on an i440bx with a brain-dead AwardBIOS that can't boot USB, nor can it boot disks >32GB.
Ah, the factory BIOS versions back then. Usually applying the latest upgrade helped a bit. But even if the 32 GB barrier remained, there were two ways to boot from larger harddisks: * Clipping the capacity of the drive with a jumper and und clipping it via software while Linux was booting. * Installing the Linux /boot partition into the first 8 GB.
I haven't seen any factory BIOS with 32 GB limit which didn't work with at least one of the tricks above.
Regards, Carl-Daniel
* Al Boldi a1426z@gawab.com [060924 21:14]:
why would you want to "load an mbr" if you can easily read files from all kinds of existing filesystems as well?
Modularization.
With parsing filesystems you can load any modules directly from a partition.
So maybe leave the bootloader chainloaded as a separate module from the block-driver.
In theory possible but fragile. Of course you can load any number of intermediary loaders from disk.
No, "a simple MBR chainloader" is not all that is needed. The code that you will find in an MBR will do bios callbacks, and you need to answer those, or you will jump to nirvana.
Ok, that's why we need a block-driver to chainload the MBR.
No, the block driver is there. It is Grub/LILO itself that calls 16bit bios code. And LinuxBIOS doesnt have 16bit bios code. This has nothing to do with a block driver.
What is your requirement? Loading Windows?
Loading Linux, on an i440bx with a brain-dead AwardBIOS that can't boot USB, nor can it boot disks >32GB.
Filo does the trick, but has its issues wrt APM and its inability to remember boot commands like LiLo can.
How does APM come into play here?!?
So one requirement is: - remembering boot commands. So you want to choose which OS to boot on the next reset?
This is a 3 liner patch to FILO..
Would chainloading LiLo be possible?
No, as I mentioned. Its a 16bit bootloader that requires a 16bit bios. (Or ADLO.)
Stefan Reinauer wrote:
- Al Boldi a1426z@gawab.com [060924 21:14]:
So maybe leave the bootloader chainloaded as a separate module from the block-driver.
In theory possible but fragile. Of course you can load any number of intermediary loaders from disk.
No, "a simple MBR chainloader" is not all that is needed. The code that you will find in an MBR will do bios callbacks, and you need to answer those, or you will jump to nirvana.
Ok, that's why we need a block-driver to chainload the MBR.
No, the block driver is there. It is Grub/LILO itself that calls 16bit bios code. And LinuxBIOS doesnt have 16bit bios code. This has nothing to do with a block driver.
LinuxBIOS is 32bit. AwardBIOS is 16bit. Grub/LILO is 16bit. ADLO is a 32bit/16bit BIOS call translation layer needed for 16bit BIOS calls to succeed on a 32bit LinuxBIOS.
ADLO should not be necessary on a 32bit-BIOS with 32bit bootloader bioscalls, nor should it be necessary on a 16bit-BIOS with 16bit Grub/Lilo bioscalls.
Correct?
What is your requirement? Loading Windows?
Loading Linux, on an i440bx with a brain-dead AwardBIOS that can't boot USB, nor can it boot disks >32GB.
Filo does the trick, but has its issues wrt APM and its inability to remember boot commands like LiLo can.
How does APM come into play here?!?
When loading vmlinuz using Filo, on an i440bx with a 16bit AwardBIOS, APM mysteriously disappears. I am hoping by chainloading Grub/Lilo to load vmlinuz properly for APM to survive.
So one requirement is: - remembering boot commands. So you want to choose which OS to boot on the next reset?
This is a 3 liner patch to FILO..
Great feature!
Would chainloading LiLo be possible?
No, as I mentioned. Its a 16bit bootloader that requires a 16bit bios.
AwardBIOS is a 16bit bios. No?
Thanks for enduring my questions!
-- Al
On Mon, Sep 25, 2006 at 07:52:37AM +0300, Al Boldi wrote:
Stefan Reinauer wrote:
- Al Boldi a1426z@gawab.com [060924 21:14]:
Filo does the trick, but has its issues wrt APM and its inability to remember boot commands like LiLo can.
How does APM come into play here?!?
When loading vmlinuz using Filo, on an i440bx with a 16bit AwardBIOS, APM mysteriously disappears. I am hoping by chainloading Grub/Lilo to load vmlinuz properly for APM to survive.
Doesn't APM require various entry points in the BIOS? Does LinuxBIOS even have these at present?
J.
* Jonathan McDowell noodles@earth.li [060925 09:51]:
Doesn't APM require various entry points in the BIOS? Does LinuxBIOS even have these at present?
No. LinuxBIOS uses ACPI for power management
We have chosen a different tactic to maintain GRUB compatibility with our existing products. We use LinuxBIOS to load kboot, which environment then runs a modified version of the Linux userland GRUB that runs the UI for selecting a boot target. The results are passed back to kboot which then invokes the kernel/initrd using kexec().
This has turned out to be a pretty slick solution, as our BOOT LOADER has a full (mini) Linux environment, so we can use VI to edit grub.conf, load BIOS defaults and update the BIOS right from the kboot command line. We get enough of Linux to support USB and network loading/booting in a first class way.
Does anyone else have this sort of system going? I would be interested in exchanging ideas if you do.
Thanks to all of you who have created this fine system - we find it very flexible and powerful.
Alan Mimms, Senior Architect F5 Networks, Inc. Spokane Development Center 1322 North Whitman Lane Liberty Lake, Washington 99019 v: 509-343-3524 f: 509-343-3501
-----Original Message----- From: linuxbios-bounces@linuxbios.org [mailto:linuxbios-bounces@linuxbios.org] On Behalf Of Stefan Reinauer Sent: Friday, September 22, 2006 5:21 PM To: Jamey Cc: linuxbios@linuxbios.org Subject: Re: [LinuxBIOS] Using GRUB as a payload
* Jamey jamey@vodafone.net.nz [060904 12:59]:
I have just started reading up on LinuxBIOS and am keen to use it on
my
EPIA-M powered Linux server (for... speed! - ok, and
coolness-factor)...
and wondered why GRUB isn't listed (or suggested) as a payload
option...
The problem with grub (v0.9x) is that it makes heavy use of 16bit bios callbacks that do not work with 32bit LinuxBIOS. But you can use FILO as LinuxBIOS payload. FILO has an option to display a grub menu by reading menu.lst. Check out http://www.linuxbios.org/index.php/FILO
seems an obvious choice to me (not knowing the inner workings of LinuxBIOS), also, has anyone started working on a keyboard based
config
utility such as is found by pressing F2 or similar at bootup in proprietory BIOS'?
Such a configuration utility exists. But since the CMOS format is open and can be changed at compile time, the utility is not built into LinuxBIOS but available as a (Linux) userspace program, so you can use it in shell scripts and programs to automatically trigger certain behavior. It is called lxbios. See http://lxbios.sourceforge.net/
-
Al Boldi -
Alan Mimms -
Carl-Daniel Hailfinger -
Jamey -
Jonathan McDowell -
Stefan Reinauer