Jaye Mathisen writes:
It would be kind of cool if when managing a remote system if /kernel
failed to boot, then on the next boot, the loader will fire up
/kernel.old, or a /kernel.somethingorother.
Sort of a kernel-clean flag. Then 300 miles away, I can try stuff, and
have at least
Mike Smith writes:
It would be kind of cool if when managing a remote system if
/kernel failed to boot, then on the next boot, the loader will
fire up /kernel.old, or a /kernel.somethingorother.
We're trying to work out a clean way of managing that sort of
persistent state
It would be kind of cool if when managing a remote system if /kernel
failed to boot, then on the next boot, the loader will fire up
/kernel.old, or a /kernel.somethingorother.
Sort of a kernel-clean flag. Then 300 miles away, I can try stuff, and
have at least some assurance that I'll
That particular feature could also be done with once-persistence
as in: On next reboot load this file...
In message 199901151746.jaa01...@dingo.cdrom.com, Mike Smith writes:
It would be kind of cool if when managing a remote system if /kernel
failed to boot, then on the next boot, the
That particular feature could also be done with once-persistence
as in: On next reboot load this file...
Sure. The problem is just implementing any persistence at all.
Consider that we support the following backing-stores for the kernel:
- UFS on local disk
- (V)FAT(32)
- NFS
- TFTP
Poul-Henning Kamp wrote:
Sort of a kernel-clean flag. Then 300 miles away, I can try stuff, and
have at least some assurance that I'll eventually be able to get back to a
kernel I could use.
Hmmm... This does rely on the 'stuffed-kernel' eventually cleanly rebooting
the machine, we don't
On Fri, 15 Jan 1999, Mike Smith wrote:
That particular feature could also be done with once-persistence
as in: On next reboot load this file...
Sure. The problem is just implementing any persistence at all.
Consider that we support the following backing-stores for the kernel:
-
On Fri, 15 Jan 1999, Mike Smith wrote:
Obviously we can't write to CDROMs, but a persistence mechanism needs
to work with each of these others. I've been leaning towards a very
simple solution using a small, preallocated file which we just
overwrite. It's not beautiful, but it's
On Fri, 15 Jan 1999, Mike Smith wrote:
On Fri, 15 Jan 1999, Mike Smith wrote:
Obviously we can't write to CDROMs, but a persistence mechanism needs
to work with each of these others. I've been leaning towards a very
simple solution using a small, preallocated file which we just
I've been thinking about this same thing, and I thought that relatively
static fallback list of environments plus an (persistant) index to tell
you what you've tried so far might work. I was considering stealing a
byte from the RTC CMOS to hold the state between reboots.
louie
To Unsubscribe:
It needs to be a general solution, and see above, again, for the things
it needs to be able to do.
So for FFS, it could be stored in the superblock, label, or one of the other
structures that aren't actually inodes, right? For FAT, couldn't it be stored
in
either the FAT or the volume
Jaye Mathisen writes:
It would be kind of cool if when managing a remote system if /kernel
failed to boot, then on the next boot, the loader will fire up
/kernel.old, or a /kernel.somethingorother.
Sort of a kernel-clean flag. Then 300 miles away, I can try stuff, and
have at least some
Archie Cobbs writes:
Jaye Mathisen writes:
It would be kind of cool if when managing a remote system if /kernel
failed to boot, then on the next boot, the loader will fire up
/kernel.old, or a /kernel.somethingorother.
Sort of a kernel-clean flag. Then 300 miles away, I can try stuff,
13 matches
Mail list logo
