Many thanks for the responses and sorry for breaking the chain but im away from my usual PC and need to use a web account.
Peter, The "threat" im looking to prevent is power loss / brain fade during an upgrade rather than deliberate corruption or bit failure of the boot medium. If power is lost during an upgrade, the boot loader would skip the newest (possibly truncated) kernel and boot an older one from (potentially) a different disk and would give me a working system to fix the issue remotely rather than a trip to a remote site.
Uwe, I had previously looked at the fallback features of grub but there appears to be no way to get the system to boot in the case of a corrupted menu.lst file (ok so im paranoid :-)
Joe, I hadnt looked at the nuni loader so thats another one to add to the list of projects to look into. I agree that this may not be directly relevant to LinuxBIOS but my interest was tweeked by the range of devices / filesystems that filo supports and I have no wish to reinvent any filesystem related wheels.
Again many thanks for all your suggestions
___________________________________________________________ Inbox full of unwanted email? Get leading protection and 1GB storage with All New Yahoo! Mail. http://uk.docs.yahoo.com/nowyoucan.html
On Fri, Mar 30, 2007 at 09:28:24PM +0100, Capt Beany wrote:
I had previously looked at the fallback features of grub but there appears to be no way to get the system to boot in the case of a corrupted menu.lst file (ok so im paranoid :-)
GRUB has command line editing functionality (press 'b' in the menu), where you can manually specify the location of the kernel and initrd.
I think this will always work, no matter how broken the menu.lst files is(?) Just make sure you don't delete the old kernel and initrd...
Uwe.
On Fri, Mar 30, 2007 at 09:28:24PM +0100, Capt Beany wrote:
The "threat" im looking to prevent is power loss / brain fade during an upgrade rather than deliberate corruption or bit failure of the boot medium.
Ok! Your checksum scheme would work perfectly for making such atomic kernel updates.
I think adding it to FILO is a good idea.
//Peter
* Peter Stuge stuge-linuxbios@cdy.org [070331 18:11]:
On Fri, Mar 30, 2007 at 09:28:24PM +0100, Capt Beany wrote:
The "threat" im looking to prevent is power loss / brain fade during an upgrade rather than deliberate corruption or bit failure of the boot medium.
Ok! Your checksum scheme would work perfectly for making such atomic kernel updates.
I think adding it to FILO is a good idea.
or rather grub2,.. ?
On Sat, Mar 31, 2007 at 08:14:10PM +0200, Stefan Reinauer wrote:
- Peter Stuge stuge-linuxbios@cdy.org [070331 18:11]:
I think adding it to FILO is a good idea.
or rather grub2,.. ?
How is it coming along? I just know that I'm not using it. :p
//Peter
-
Capt Beany -
Peter Stuge -
Stefan Reinauer -
Uwe Hermann