Following a failed kernel upgrade of a remote linux box im looking for a replacement to my current boot loader (GRUB) that will fall back to a previous kernel if the new one is corrupt and was wondering if filo could fit the bill (either as is or with some changes) ?
The system in question has software raided disk for redunancy but this doesnt help when the boot kernel is corrupt.
What I hope to achieve is that once the boot loader is running, it will scan the systems boot devices for files containing boot information (the files would either be text files with a known extension or binary files with a magic number) that contain the kernel/ramdisk filenames, the kernel/ramdisk checksums, a boot priority and the checksum of the file itself.
It should then be possible to select the highest priority kernel/ramdisk to boot, checksum it and if this checksum fails fall back to the next kernel/ramdisk pair.
Does this sound like a reasonable approach to the problem ?
___________________________________________________________ New Yahoo! Mail is the ultimate force in competitive emailing. Find out more at the Yahoo! Mail Championships. Plus: play games and win prizes. http://uk.rd.yahoo.com/evt=44106/*http://mail.yahoo.net/uk
On Thu, Mar 29, 2007 at 10:02:09PM +0100, Capt Beany wrote:
The system in question has software raided disk for redunancy but this doesnt help when the boot kernel is corrupt.
This requires support in the boot loader too.
What I hope to achieve is that once the boot loader is running, it will scan the systems boot devices for files containing boot information (the files would either be text files with a known extension or binary files with a magic number) that contain the kernel/ramdisk filenames, the kernel/ramdisk checksums, a boot priority and the checksum of the file itself.
It should then be possible to select the highest priority kernel/ramdisk to boot, checksum it and if this checksum fails fall back to the next kernel/ramdisk pair.
Does this sound like a reasonable approach to the problem ?
That depends on the threat.
If the kernel can be corrupted "on purpose" the checksum could be changed as well, and this scheme would provide no protection.
For bit errors in the storage the checksum would be fine. (Or you could get a hardware RAID controller and get that, and better performance, for less cost than developing the boot loader.)
//Peter
On Thu, Mar 29, 2007 at 10:02:09PM +0100, Capt Beany wrote:
Following a failed kernel upgrade of a remote linux box im looking for a replacement to my current boot loader (GRUB) that will fall back to a previous kernel if the new one is corrupt and was wondering if filo could fit the bill (either as is or with some changes) ?
GRUB can do that just fine if you leave your old vmlinuz and initrd files in place (in addition to the new ones)... Am I missing something?
Uwe.
Quoting Capt Beany captbeany@yahoo.co.uk:
Following a failed kernel upgrade of a remote linux box im looking for a replacement to my current boot loader (GRUB) that will fall back to a previous kernel if the new one is corrupt and was wondering if filo could fit the bill (either as is or with some changes) ?
The system in question has software raided disk for redunancy but this doesnt help when the boot kernel is corrupt.
What I hope to achieve is that once the boot loader is running, it will scan the systems boot devices for files containing boot information (the files would either be text files with a known extension or binary files with a magic number) that contain the kernel/ramdisk filenames, the kernel/ramdisk checksums, a boot priority and the checksum of the file itself.
It should then be possible to select the highest priority kernel/ramdisk to boot, checksum it and if this checksum fails fall back to the next kernel/ramdisk pair.
Does this sound like a reasonable approach to the problem ?
Have you checked out the nuni bootloader?
http://freshmeat.net/projects/nuni/
It is a bios independent bootloader that has fallback boot methods. I am not sure what this has to do with LinuxBIOS??
But hey it is open source, and again bios independent, possible payload??
Thanks - Joe
On Fri, Mar 30, 2007 at 11:49:18AM -0400, joe@smittys.pointclark.net wrote:
http://freshmeat.net/projects/nuni/
It is a bios independent bootloader
Not really..
--8<-- nunimbr.asm start iobase equ start-8 ;overlay some variables ext_start equ start-4 mov AH,2 ;check for shift, ctrl, or alt int 0x16 and AL,0xF jz f1 ;use default if none pressed prompt ;errors jump to command prompt call Input -->8--
It uses BIOS interrupt services to read and write characters.
While the code is trivial and easy enough to replace with serial io nuni is in no way completely independent of a BIOS.
//Peter
Quoting Peter Stuge stuge-linuxbios@cdy.org:
On Fri, Mar 30, 2007 at 11:49:18AM -0400, joe@smittys.pointclark.net wrote:
http://freshmeat.net/projects/nuni/
It is a bios independent bootloader
Not really..
--8<-- nunimbr.asm start iobase equ start-8 ;overlay some variables ext_start equ start-4 mov AH,2 ;check for shift, ctrl, or alt int 0x16 and AL,0xF jz f1 ;use default if none pressed prompt ;errors jump to command prompt call Input -->8--
It uses BIOS interrupt services to read and write characters.
While the code is trivial and easy enough to replace with serial io nuni is in no way completely independent of a BIOS.
//Peter
Hmm, than the project details are a little bit misleading. It would be kind of cool to see it as a payload though....
Thanks - Joe
On Fri, Mar 30, 2007 at 12:22:05PM -0400, joe@smittys.pointclark.net wrote:
Hmm, than the project details are a little bit misleading. It would be kind of cool to see it as a payload though....
Sure, someone should check it out. But the last release was 6-7 years ago, it seems. Looks pretty unmaintained.
Uwe.
Quoting Uwe Hermann uwe@hermann-uwe.de:
On Fri, Mar 30, 2007 at 12:22:05PM -0400, joe@smittys.pointclark.net wrote:
Hmm, than the project details are a little bit misleading. It would be kind of cool to see it as a payload though....
Sure, someone should check it out. But the last release was 6-7 years ago, it seems. Looks pretty unmaintained.
Uwe.
nuni bootloader is written in 16 bit assembly and compiled with nasm. Does that matter? From what I can tell it does have it's own hd drivers built in. Would it need to be converted to 32 bit C to work as a payload?
Thanks - Joe
On Sat, Mar 31, 2007 at 11:48:56AM -0400, joe@smittys.pointclark.net wrote:
nuni bootloader is written in 16 bit assembly and compiled with nasm. Does that matter?
Yes, actually. Good point.
From what I can tell it does have it's own hd drivers built in. Would it need to be converted to 32 bit C to work as a payload?
It doesn't have to be C, but it needs to be compiled into 32-bit machine code, all payloads are ELF file, started in protected mode.
Also, (keyboard) input and (VGA) output needs to be rewritten to not depend on interrupt services. One could look at the FILO source for ideas, or just settle with using serial for example.
Note this last I/O part is difficult if not impossible to test if running nuni as a standalone program in Linux since there will already be other drivers using the same resources. (But you could unload the serial driver and work on nuni serial port support.)
//Peter
-
Capt Beany -
joe＠smittys.pointclark.net -
Peter Stuge -
Uwe Hermann