Re: Can the bootloader create a file or set a flag in the bootblocks?
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 assurance that I'll eventually be able to get back to a kernel I could use. In case in that discussion it wasn't clear, there *is* a way to do this: see man nextboot. Nextboot is woefully inadequate (and not supported anymore anyway). -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Can the bootloader create a file or set a flag in the bootblocks?
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 that doesn't involve nasty hacks like the 'nextboot' code did. It's kinda tricky if you don't want write implemented in all your filesystems (bloat!) Maybe I don't understand the problem here, but something akin to how kernel configuration changes are handled seems like a good way to deal with this problem. /boot/loader could stuff something into memory (sort of like the way you can stuff a splash screen into memory), and a user-level program can read that information and stuff it wherever it needs to be stuffed. That may be a little hard with tftp, but with most of the other media types it seems like it should be relatively straightforward. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Can the bootloader create a file or set a flag in the bootblocks?
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 eventually be able to get back to a kernel I could use. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Can the bootloader create a file or set a flag in the bootblocks?
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 eventually be able to get back to a kernel I could use. We're trying to work out a clean way of managing that sort of persistent state that doesn't involve nasty hacks like the 'nextboot' code did. It's kinda tricky if you don't want write implemented in all your filesystems (bloat!) -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Can the bootloader create a file or set a flag in the bootblocks?
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 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 eventually be able to get back to a kernel I could use. We're trying to work out a clean way of managing that sort of persistent state that doesn't involve nasty hacks like the 'nextboot' code did. It's kinda tricky if you don't want write implemented in all your filesystems (bloat!) -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message -- Poul-Henning Kamp FreeBSD coreteam member p...@freebsd.org Real hackers run -current on their laptop. FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Can the bootloader create a file or set a flag in the bootblocks?
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 - iso9660 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 workable. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Can the bootloader create a file or set a flag in the bootblocks?
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 want anyone getting a 'false sense of confidence' out of this ;-) - A lot of the machines we use don't even reboot on a 'shutdown -r' :-( -Kp To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Can the bootloader create a file or set a flag in the bootblocks?
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: - UFS on local disk - (V)FAT(32) - NFS - TFTP - iso9660 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 workable. It can't go into free space in a boot block? We still have room left over... It could only be a few bytes, enumerating numbered kernels in /boot/kernels.rc, or something like that -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message Brian Feldman_ __ ___ ___ ___ gr...@unixhelp.org _ __ ___ | _ ) __| \ http://www.freebsd.org/ _ __ ___ | _ \__ \ |) | FreeBSD: The Power to Serve! _ __ ___ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Can the bootloader create a file or set a flag in the bootblocks?
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 workable. It can't go into free space in a boot block? We still have room left over... It could only be a few bytes, enumerating numbered kernels in /boot/kernels.rc, or something like that It needs to be a general solution, and see above, again, for the things it needs to be able to do. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Can the bootloader create a file or set a flag in the bootblocks?
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 overwrite. It's not beautiful, but it's workable. It can't go into free space in a boot block? We still have room left over... It could only be a few bytes, enumerating numbered kernels in /boot/kernels.rc, or something like that 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 name? TFTP and NFS are both non-local, but still have writing capabilities built in. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com Brian Feldman_ __ ___ ___ ___ gr...@unixhelp.org _ __ ___ | _ ) __| \ http://www.freebsd.org/ _ __ ___ | _ \__ \ |) | FreeBSD: The Power to Serve! _ __ ___ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Can the bootloader create a file or set a flag in the bootblocks?
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: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Can the bootloader create a file or set a flag in the bootblocks?
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 name? TFTP and NFS are both non-local, but still have writing capabilities built in. No, it needs to be in a file so that it can be simply manipulated from userland. Remember, the writable list is: - FFS - FAT - NFS - TFTP -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Can the bootloader create a file or set a flag in the bootblocks?
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 assurance that I'll eventually be able to get back to a kernel I could use. In case in that discussion it wasn't clear, there *is* a way to do this: see man nextboot. -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Can the bootloader create a file or set a flag in the bootblocks?
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, and have at least some assurance that I'll eventually be able to get back to a kernel I could use. In case in that discussion it wasn't clear, there *is* a way to do this: see man nextboot. Oops, sorry.. nextboot of course doesn't work with the new bootblocks.. -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
