Slashdot Mirror
Booting Linux In Three Seconds
cramhead writes: "Some very cool technology that motherboard manufacturers should consider adopting. Using Linux to boot a system allows flexibility and speed. Thought the world deserved a look at [the LinuxBIOS homepage]"
This project sounds similar to the OpenBios project which has mentioned before on Slashdot, but a lot has happened since then, and even since CmdrTaco last posted about LinuxBIOS. The news page indeed reveals that (with certain motherboards), adventurous flashers-of-RAM can have Linux up in three seconds, and they promise improvements even on that. They also note that LinuxBIOS is working with an Alpha DS10 and with an Athlon / SiS730S combination. (This may also remind you of the etherboot project).
It takes about 10 seconds for my palm to boot, with about 20 programs and hacks installed. But you're probably thinking about the near instantaneous wake up when you press the power button, because the power button is more accurately a sleep button. The article above is about a cold boot, so if you'd like to compare apples to apples, press the reset button on your palm and see how long it takes to get to the main menu.
No, BeOS doesn't do that. It does a full boot every time.
However, EROS works just like you've described.
Very fast boot times isn't the only great feature of LinuxBIOS. LinuxBIOS can boot Linux and other OS's like Be or QNX, though it's not for Dos or Windows since they rely heavily on the legacy BIOS for certain features of operation that LinuxBIOS doesn't bother with. LinuxBIOS has a very stripped down linux kernel that just sets up some basic features of a PC better than many OEM BIOSes (memory, cache, super I/O) and then jumps to loading whatever kernel you wish to take the system from there.
Quidquid latine dictum sit altum viditur
I don't know much about what has or has not done- low level OS stuff hasn't really been an interest of mine, but I do know the way fork() works in GNU/Linux. With fork() in this environment, you don't actually do a copy of the entire data segment of the program, you just reference it and make copies of each bit as it's needed. Would it not be possible to do this upon booting of a BeOS system? ( and of course any other operating system that implements the system memory dump feature)
It seems to me that you'd only have to boot the very core features and just load the rest off the memory dump on the drive as you need them, as opposed to reading the whole thing on startup.
I've seen a few posts to this story that seem like they assume a computer with more memory would take longer to boot up with the RAM-image system. This way wouldn't. However, it would give you more sluggish performance. It might make other things feasible, like 'undoing' your system back to a certain state (although you'd have to consider data persistance because you couldn't undo changes that have already been written to storage devices)
Just some food for thought.
I figure turning the computer off is the worst thing you can do to it.
I agree.
I've had to turn off my computer for a few days twice in the last few months. Both times it got so angry with me that when I started the computer (in Linux, of course), it crashed just before giving a login prompt!
I suspect that some of my tweaked hardware doesn't like running cold (referring to temperature). When it's gotten through the fsck on the second boot (I've got several gigs to check), it always works perfectly...
I doubt, therefore I may be.
I've gotten even old, slow machines to boot very quickly (under 10 seconds after LILO prompt) by compiling a non-module kernel and replacing the /etc/rc.d/... stuff with a single /etc/rc script. Of course, none of the standard admin tools know what to do with that sort of thing.
I think rethinking and redoing everything from the time the Linux kernel loads to the time the user gets a prompt or login screen could both simplify administration and speed up booting without sacrificing flexibility.
ram access is faster than hd access.
True. But most computers I've seen take a good bit even before they access the hard drive. Checking ram, scanning PCI bus, etc...
you forget that most people turn their computers off at night. It saves power and is simply practical if you're not running any servers. While the bootup time isn't horrible on linux, it's certainly noticeable. I would gladly welcome a setup that booted quickly and shut down quickly.
There are enough variations in hardware configs that I wonder how much of it needs to be handled in the bios, and how much can be set aside until you start loading drivers?
A good bit is handled in the LinuxBIOS. The first thing that has to be set up is the memory controller and the DIMMs! Then copy the Disk on Chip access code to RAM, copy out the LinuxBIOS proper, and jump to it. That has to happen in the first 512 bytes since that's all that's available at powerup from a Disk on Chip. Then the bridges must be turned on. Some chipsets have a watchdog timer that must be turned off to avoid a hard reset. For debugging, it's good to get the legacy bus and serial ports up as well. Finally, turn on the various built in devices like ethernet and IDE, basically anything that is normally configured in the CMOS.
After all of that, gunzip the kernel into place, set up a page with the kernel commandline and such and jump to it. The system will look more or less normal at that point except that the IDE driver expects that the drive has had time to spin up and init (it hasn't). A couple of small patches take care of that. In the 2.4 kernel, there's a framebuffer driver that knows how to turn on the built-in video in the SiS 630 chipset. In 2.2, you get no video.
It's interesting to study the code. You'll gain a huge appreciation of how complex things have gotten since the days of tweaking registers in the Apple or Commodore 64, or the old PC,XT, and AT for that matter.
It will be interesting to see how it handles the various chipsets. Each one has it's own odd quirks, and it's not unusual for hardware bugs to be hidden behind some BIOS magic work-arounds (In some cases, the BIOS just keeps resetting the chip until it decides to come up). Many vendors jealously guard their register level specs for whatever reason, especially video cards.
Fortunatly, SiS has been very helpful and open about it's specs.
The problem, as I see it, is that this BIOS can *ONLY* boot Linux, since you flash the kernel image into the boot ROM. This would mean you couldn't dual boot (even different versions of Linux) without reflashing your BIOS every time.
With two kernel monte, the kernel in the ROM can directly boot another kernel loaded from disk or network (even serial for that matter).
It definatly won't boot Windows. I like to think of that as a feature :-). It is nice to get rid of the last bit of proprietary software.
Creating heat is the one place where efficiency doesn't matter much at all. Second law of thermodynamics -- energy is neither created nor destroyed. The energy in light ultimately ends up as heat -- the light rays bounce off of surfaces, each time becoming dimmer and slightly heating the surfaces.
There might be a certain inefficiency to this -- maybe the surfaces aren't what needs to be heated, and while some of the heat of the walls goes to the air, some goes through the wall and outside. But I doubt that really matters much.
If you are burning fuel, efficiency does matter. You have to burn the fuel completely, and you want to lose as little heat as possible through exaust. But for electricity it's not really an issue -- all those efficiency issues have been taken care of at the power plant, and the electical energy is pretty much guaranteed to become heat in the end.
http://www.scyld.com/products/beowulf/software/mon te.html
It's called Two Kernel Monte. It's a module that loads a new kernel into memory, does a little do-si-do dance to get it where it needs to be in the mode it needs to be in, then simply jumps to it. (Yes, you need to do
umount -a;mount -o ro,remount /
before doing this, since it doesn't do any of that...) No, it's not an in situ change, since all your processes die, but for systems with multiple SCSI or RAID cards, it can mean the difference in a few seconds for reboot and a few long minutes....
On a side note, make sure and grab my link; the one on Google is wrong (until they fix it), and it took me a while to find the right thing...
--
Never assume TFM is right.
This would be useful for Windows, considering how often you need to reboot.
Why would you need it for Linux, though? I mean, who reboots more than once every major kernel upgrade? What would be really cool is a way to upgrade your kernel without rebooting, like QNX...
If anyone out there who has any say in next generation BIOSes that are not intended to boot windows or other OSs that requires primary and extended partitions, then please implement this.
I would a system with unlimited partitions, no legacy hard drive rubbish etc. Instead of mounting / on sd1s3a1 etc, why not mount / on "root", mount /var on "var", mount /usr on "usr" etc, just like the Amiga ("Work", "Workbench", "System 3.0" etc. The same goes for removable media - the Amiga has "CD0", "Zip0", "DF0", "DF1", etc for various types of removable media. Instead of mounting a floppy as /mnt/floppy from /dev/fda or whatever, mount a floppy as /mnt/floppy from "fd0" or "floppy", or "zip" or "playdisk" or "dvd" or whatever.
Add naming to disks themselves. Then when you do cd /mnt/backup, the system will ask you to insert the disk named "backup", which could be in any drive. The OS would autoload the disk when inserted, see that the disks name was "backup", and everything would continue fine.
Computers have gone a long way backwards since the elegant solutions that existed and died in the past with the likes of the Amiga, etc. This can mostly be blamed directly on Microsoft and Unix systems where usability was put last on the list of priorities. Now it is important, there are a whole load of nasty hacks to get around the crufty old PC system that just doesn't work nicely. The sooner it dies, the better.
Actually on my laptop Windows ME boots faster than it comes out of hibernation.
On my old laptop I could use 'apm --suspend' and leave it like that for days, so far this new Toshiba 2805-S201 isn't coming back from a suspend in Linux (let me know if you see anything about it).
Go to their site and read some of the pages. This started at Los Alamos _for_ their Beowulf clusters exactly for that reason.
the good ground has been paved over by suicidal maniacs
This would be useful in building internet/compute appliances with standard PC motherboards. People have come to expect a device to be on instantly when they hit the power button. How successful do you think a modern TV would be if it took 20-30 seconds before the user could do anything? In their case, they wanted to have the ability to add a compute node to their Beowulf cluster, turn it on, and have it ready for work in a few seconds.
the good ground has been paved over by suicidal maniacs
Speaking as the person who started linuxbios and runs the project from here at LANL, I thought I would mention a few things.
... oh, and of course, EFI only works on one architecture; LinuxBIOS already works on two, and PowerPC is on the horizon.
3 second boot. Trust me, it's nice. And no matter how fast you make your boot, mine will probably always be faster, since you'll always be stuck with that crazy BIOS doing all that unnecessary work so that DOS will run.
3 second boot: it's nice but it's not our primary reason for doing this. We need to replace the BIOS
because of its many stupidities:
- zeroing memory on boot, so you can never REALLY know what happened when your machine crashed
- Those 'no keyboard, hit F1 to continue' messages on nodes that have no keyboard. Think this is only happening on old machines? Guess again! It happens even now on a rack of Compaq DL360 machines we just bought. Every once in a while, they ignore the 'no keyboard' bios setting. Imagine trying to deal with this if you had 256 nodes with no display. No fun.
- Current BIOSes allow no good way to boot without disk, floppy, or CDROM. I'm well aware of PXE, but the many defects of that standard make it only partially useful.
- BIOSes are getting worse. Intel's next-generation BIOS, the EFI, will require that you have a FAT-32 formatted partition somewhere, and as part of the boot process you will have to run CHKDSK. Nice, Huh? If you have a strong stomach download the 400-page standard, read it, and then wonder why this is better than just loading Linux from flash
Our main use of LinuxBIOS is for clusters. That said, I have a LinuxBIOS machine as my desktop and it is really nice. When you're doing kernel work you tend to reboot now and then, and LinuxBIOS takes the pain away.
Even cooler: we have an 8 MB Millenium Disk On Chip on one of our clusters. Ollie Lho and David Woodhouse worked out how to make the last 7MB into a root partition. We put the Scyld root file system onto that partition, so that the nodes boot up right into the Scyld cluster environment. Voila, silicon cluster nodes. Life is much easier.
See http://www.linuxlabs.com/linuxbios for a ompany that will be selling these as cluster nodes. Also see http://www.lnxi.com for another use of LinuxBIOS. For other systems that boot Linux from flash, you can check out synergy, CSPI, and API.
For an embedded use, booting in 3 seconds is pretty helpful. Do you really want to wait 15-30 seconds for your stereo to come up? I've talked to a few companies that want to use this for set-top boxes, and one that is probably going to use it for a CD player.
For a really interesting embedded use, check out http://www.cachier.com
OpenBoot: Yes, if you don't mind writing all your own protocol stacks, drivers, etc., etc., all of which Linux will do better, then go for it. But we've found here that Linux makes a beautiful bootstrap. We currently only boot Linux from Linux, but both Plan 9 and OpenBSD are in the works. Linux is a good bootstrap.
I've only scratched the surface here for reasons and uses of LinuxBIOS. I hope this helps a bit.
True - maybe. But if they're on the bleeding edge of profit, using Linux vs. Windows or developing your own is an easy start.
:)
As for the multi-user - does it really matter what is on there. I suppose they could always start it with init 1 and not worry about that.
Besides...I'm not making a consumer device, I'm making something for me, and Linux I understand...eproms and dsp's - I know what they are!
The PROM is not UNIX based, rather it is Forth.
And, yes it is very handy. I prefer the Sun PROM console to BIOSes anyday, it's so much more powerful.
For the record, I run Win2k, Linux, and BeOS.
BeOS boots in literally 3 seconds. Linux 2.4 about 10, and Win2k in about 45 (stupid long @$$ boot time)
Why do you need a new BIOS just to boot Linux faster??
... how about replacing this really stupid, crappy and annoying partition-scheme that seems to cripple the x86-architecture?
... what *is* that?
Primary, extended... etc.
I *really* miss the way Amiga did it. Partition your drive as you see fit. Use *naming* instead of numbering of partitions. Remove, add, split, join partition without affecting the other partitions and needs to reconfigur (eg. hda9 suddenly become hda8 or hda10 or something).
Just my 2 cents....
If such a thing went through, having a open source bios image to flash might be the only thing that saves us from Dumb/Prejudical/Just-Plain-Evil(TM) HD access restictions.
EX: The BIOS refuses see LILO in the boot sector...
Trivial now, Vital Later.
Novel theory: Modern Man evolved from psychopath
Nobody seemd to mention that LinuxBios could be a big plus on embedded systems and internet appliances.
We can't just think about geeks who keep their computers on all the time, but other folks who might be switching them on and off several times a day, and for different system designs where fast bootup is a big plus. Things that people may not think of as a "computer," like Tivo, etc.
Also, being able to boot to a more flexible maintennance state, including network, and a bash prompt, even if the hard disk fails.
Use your imagination!
But why use hibernate - that still has to read all the memory off the disk - since it's done in the BIOS it's OS independant - while I could use it my 3 yr old DELL/redhat/KDE system just suspends - virtual instant-on - batterys last days in suspend state (but it lives in the dock anyway when I don't use it) - only time I ever truely hibernate it is when I'm oing on a plane
API Networks (http://www.api-networks.com/products/cs20.shtml) has built this same capibility for their dual 833 Alpha CS20 1 U server. Which includes a flash managment/failsafe/diagnostics firmware (that fits in under 200k) called "Alpha Diagnostics Environment" or ADE for short. So for example if you say burn a bad kernel you can still just start your system and enter ADE and flash in a new one. You can also write to flash from Linux. Makes firmware upgrades and kernel changes alot more convenient. Average boot time on a box that doesnt have to do a VGA bios init is under 10 secs. From power on to login prompt.
Peter
--
www.alphalinux.org
www.alphalinux.org
Yeah, there a a few non-volatile memory technologies on the horizon. I think FRAM (ferro-electric RAM) is a bit more advanced than MRAM - it's been shipping for a while.
I guess you could to the same no-boot thing on a regular PC by having the shutdown code just write the memory image to disk, and read it back in when you restart (i.e turn the power back on). Of course with todays common memory sizes of 128-256M and up, it'd still take a few seconds with a fast disk to read it back in.
Nowadays I just leave my PC on all the time anyway.
http://www.scyld.com/products/beowulf/software/mo
It's called Two Kernel Monte. It's a module that loads a new kernel into memory, does a little do-si-do dance to get it where it needs to be in the mode it needs to be in, then simply jumps to it.
Two Kernel Monte is a cool trick, but it's not really "upgrading your kernel without rebooting" -- it's "rebooting without BIOS reinitialization". It's a Linux equivalent to the LOADLIN program under DOS, allowing Linux to load and run a new OS, handing over control of the entire machine.
This is a good and useful trick, but it's a far cry from upgrading the kernel without rebooting. Since the old OS is entirely defunct and the new one has to initialize itself from scratch, this remains a reboot, albeit a faster one...
Deven
"Simple things should be simple, and complex things should be possible." - Alan Kay
Beyond that, there is a patch for the 2.2 kernel called "swsusp" IIRC. It allows the kernel to suspend itself to disk by flushing all its buffers and writing process memory out to the swap file. When the machine reboots, the kernel recognizes a special signature on the swap file and reinitializes from where it was suspended. Last I checked, this hadn't been ported to 2.4 yet.
Rebooting upon kernel upgrade is ... HOW often?
If you've been tracking the ac releases [0], and compile for more than one machine (and yes, sleep occasionally, heh) you'll realize that it's been an almost constant process of recompiling lately. 2.4.2-ac11 is out, and possibly later revisions by the time you read this. (Alan has been prolific of late.)
I can't begin to think of the number of reboots I've done in the past week, once you start counting testing various combinations of kernel options and their interactions.
As for kernel upgrades without rebooting, no thank you.
I've been bitten by boot-time errors recently, things that would not have been discovered until the next power failure mysteriously caused hangs. At least this way there is a chance of catching the error within a reasonable proximity of the time the cause was created. There is more to good system administration than some penis-waving, "my uptime is bigger than yours," mentality seen on some IRC channels and web sites.
If you care about your system's reliability, you'll test its boot sequence every so often, even if inadvertantly. (If all you care about is penis-waving, please take your immaturity somewhere that it won't harm my systems until you grow up.)
[0] because 2.4.x doesn't support your 2.0.x- and 2.2.x-supported hardware
. . . why the plastic liner inside you microwave shrivelled, your house burned up after a gas explosion, but was put out by the flooding washing machine . . .
:)
hawk
Built-in hardware hibernation works fine on my vaio z505le too. If I recall, it uses the fat32 partition at the beginning of the disk to store state information. you only have to make sure this partition is the appropritae size.
It doesn't have to be that way.
In the same way that you can go into Linux from DOS (loadlin), is it possible to change operating systems without a full reboot.
Remember, the BIOS itself can be considered to be "an operating system", it's just a rather rudimentary one. Mine has "applications" such as Hard Disk tools, and is "preemptive" as when I'm on the basic BIOS settings screen the real time clock on screen is updates whilst I'm editing other fields.
The 'unusual' thing (for an OS) needed for this OS flipping to work is that the bootstrap OS must be willing to _give up_ its control. This must be done with great care. Remember, the kernel is there in order to keep control in a traditional scenario. However all you really need to do in the general case is to request a GDT code segment with Ring 0 permission, get yourself full I/O port permission, and a new segment the the IVT (interrupt vector table) then disable interrupts, change Interrupt table, and jump to your new code, and reenable interrupts again.
Voila!
FatPhil
--
Also FatPhil on SoylentNews, id 863
I love the fast boot from hibernation, especially when battery time is already less than a transcontinental flight.
You must not have much memory in your laptop <grin>. Mine has 512MB of RAM and it takes W2K much longer to read/write that half gig that it does just to boot normally. Think about it, it's common for drives to deliver 3-4 MB per second of throughput. Divide 512 by that and you get 2-3 minute boot times. Not fast.
Oh, and yes I do need that much RAM.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
I've got my old Mac 512K (1985) in the closet these days... pull it out every now and then to show off boot times. My MacWrite/MacPaint floppy (which also has a System Folder on it) boots to fully functional Finder (the Mac desktop) in about 7 seconds after the power switch is flicked on. Not too shabby.
Certainly this is cool, and I'm sure it would be very useful for some embedded applications.
However, most serious linux users would gain much more time by switching to reiserfs, or any other journalling filesystem, instead of waiting for ext2 to take an interminable amount of time to fsck its drives, and possibly lose data...
I know. Ask anyone who, say, had a SCSI card go bad on them.
Will the real Bruce Perens Please Stand Up
Why not build an Open Firmware clone? There are free Forth systems readily available, the extensions necessary for OF are not excessive. Doing a byte-code compiler using the OF specs would be interesting, but not particularly difficult (starting with a normal Forth environment).
I don't see any reason at all it couldn't work. The real issues are more based on need. Arguably, the same result can be had for a fraction of the effort by just booting a stripped kernel and running the Forth environment (or any other boot environment) instead of init. With 7 Meg of flash available and using busybox for many of the basic functions, there's a lot of potential there.
Of course, there is definatly hack value to be had in going directly from the LinuxBIOS loader into FORTH.
...WinBIOS? "Boot in 3 hours!"
--
--
silence is poetry.
Sorry, but you're wrong.
Have you heard of the Dell Digital Audio reciever? It actually runs Linux. It does a little more than just play MP3s, though. It reads files from the network. A pretty cool thing.
Might be cool to see a special boot PROM on a network card. Fool the computer into booting off a chip, but make it think it's booting off another computer on the network.
Might be a tough hack, but it sure would be cool
If a compute node takes two minutes to boot, you can't risk it being powered off when you need it. If it only takes a few seconds for a compute node to rejoin the cluster you can freely power down idle nodes. If you look at the average utilization for medium sized clusters, you'll see that this could save a lot of power.
Scyld Beowulf
Sure it's cool but:
- most of the time involved with booting goes into starting operating services. My kernel takes about 1/2 seconds to get to the part where it starts doing stuff with modules and inetd, those live on my HD.
- it seems to be linux exclusively
- should you be booting that often?
I think all this is a start of what might be a good solution to an existing problem: the current BIOS is slow, does stuff that could be considered redundant and does so in a suboptimal way.
I would like to see sing a bit speedier, however my PC spends only 5 seconds or so in the BIOS. If this project can save me about 2 seconds (which is what they claim), that sure is great but I still have to sit through the rest of the booting process. Can't we speed that up? I would love to see a hibernate function as in W2k appear in linux for instance.
Jilles
The 'unusual' thing (for an OS) needed for this OS flipping to work is that the bootstrap OS must be willing to _give up_ its control. This must be done with great care. Remember, the kernel is there in order to keep control in a traditional scenario. However all you really need to do in the general case is to request a GDT code segment with Ring 0 permission, get yourself full I/O port permission, and a new segment the the IVT (interrupt vector table) then disable interrupts, change Interrupt table, and jump to your new code, and reenable interrupts again.
That's more or less exactly what happens in Linux with two kernel monte. The module does all of that itself without any cooperation from the rest of the kernel.
I forget which old Mac is was, but you could boot from a system image in ROM with the right kind of Vulcan nerve pinch.
I want it to work like my CD and DVD player - turn it on, and a few seconds later it is ready to go.
I set up a PC/104 with Linux, it booted (from its Solid State disc) in about 10-15 seconds.
Check out the PC/104 website.
Isn't MRAM (Magnetic RAM) supposed to do away with the booting procedure? From what I understand, you turn off the computer and whatever's in memory stays there, as it is magnetically. Which would (I assume), reduce the booting time to damn near nothing. Can anyone verify this?
Seriously, I wonder how this would handle all of the various chip sets out there. There are enough variations in hardware configs that I wonder how much of it needs to be handled in the bios, and how much can be set aside until you start loading drivers?
"It is a greater offense to steal men's labor, than their clothes"
But I want it now!
--
Je t'aime Stéphanie
Maybe I've been out of the Linux distro comparison charts, but do any of the Linux kernels or distributions have hibernate support?
(Hibernate: all power goes off, and the hard drive's boot sector is set to load memory and processor state directly from a memory mapped chunk of the disk, avoiding all the individual component loading time.)
My laptop's now a few months old, and I have never truly rebooted it: every day I just open the lid and up pops Windows 2000, right where I left it. It's never bluescreened(*). I use a 11Mbps wireless LAN to read in bed. I love the fast boot from hibernation, especially when battery time is already less than a transcontinental flight.
(*) It's the drivers that'll kill Windows 95/98/NT/2K. The system isn't well-written to deal with shitty third parties like ATI, but a laptop's setup is pretty simple and doesn't depend on flaky bizarre upgrades of drivers all the time. Months of uptime (minus hibernate at night and driving), no bluescreen.
[
I have a old ppro200 server which uses MrBios, and it takes approximately 0.5 seconds to go through post and start booting. Linux kernel takes another few seconds. This is not much of an improvement. Most BIOS's that come with new computers these days are too slow and show a lot of crap during post, which can't be disabled. Check out www.mrbios.com, they make replacement bioses for a lot of different motherboards, and they usually have a lot more options to tune for a particular chipset, etc
I have been working on getting LinuxBIOS ready for sale in commercial systems. The three second boot is interesting, but really isn't a major attraction for servers. The real advantages are reliability, full configurability over serial console, diskless operation, built in rescue disk, and an OpenFirmware like capability.
A Flash chip is much more reliable and convieniant than a boot floppy. It is possable to use a flash boot image remotely over a serial console even if the root filesystem on the HD is damaged to the point of being unmountable. The kernel in the Flash just has to mount a rescue root fs in the chip (using the nftl driver in the MTD patch).
In normal operation, the LinuxBIOS kernel will boot up, and either mount the boot partition or load the final kernel image from a boot server. Then it used the two kernel monte module (kmonte) to boot into the final running kernel. Should that step fail, the rescue image can page the sysadmin for help.
For diskless operation, the final kernel loads from the server and mounts it's root via NFS. GFS over fibre channel is also a possability.
Currently, I have a prototype Scyld cluster where the slave nodes boot from LinuxBIOS. The slave nodes are not capable of video. I also have prototype with a 2.4 kernel that comes up with a fb_console.
<PLUG nature="shameless">Go to http://www.linuxlabs.com/linuxbios.html for FAQ on our 1U server and Scyld cluster systems using LinuxBIOS. They will be ready for sale in a few days.</PLUG>