Gordon Tetlow wrote: > > I still think you're not thinking the processes associated with this > > feature through carefully enough. > > Very possible. This was just a first cut of the feature and I'll be the > first to admit that it's not pretty. I don't know forth so I was happy > to get as far as I did. > > There isn't a notion of a recovery boot in this implementation. It either > tries the new options (specified in /boot/nextboot.conf) or it doesn't and > sticks to the defaults.
You need to listen to Mike. The primary reason this code was originally written was to permit field upgrades by having a "ping-pong" boot. If the boot of the newly installed system failed a number of times in a row, then it fell back to using the old "root" device, which contained the previous revision. The point of the exercise is to not turn a working machine into a doorstop with a field upgrade that fails, or happens to be a bad and/or hacked load. What problem are you trying to solve? If it isn't the one that the code was originally intended to solve, then it must be some other problem that we just aren't seeing? Thanks, -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
