> >> > Meaning that the pbr must be updated with the new location. > >> > >> It doesn't just "tend" to move around (ie. tend == "prone to move"). > >> It moves every time, since it is using mkstemp to create a new file. > > > > But isn't this a good thing? > > > > Now it moves around consistently, so people perhaps won't forget and > > be surprised when it moves eventually. They just need some retraining ;). > > I think so. I've always thought the requirement to update openbsd.pbr > existed after every time installboot was run. Certainly, years ago, I > forgot to do it and got ERR M. (Echoes of an earlier conversation > coming back to me...) > > Things that work 95% of the time encourage laziness.
So here's the low-down story. The old code would open the old boot program, and rewrite over top of it. As a result, it would use the same blocks on the disk. Things which "know where those blocks are", would continue working. Unless the bootblock grew. Then uhmmm.......... That new piece is not in a known place..... In the last decade, the bootblock has grown, therefore once in a while people would hit the problem, re-learn the recipie, and activate it. Now fast forward to about 6 months ago. Joel started writing a new installboot that is more machine independent. Lots of good reasons. Very few reasons against it. Too long a story. The new one attempts to solve a different problem, with the unfortunate loss of "reuse the blocks" from before. The new one attempts to try to give safer atomicity, as in, a new file is placed on the disk, then it is hooked up, and then the old one is removed. There are a few narrow cases where this is safer.. but..... I think this new change is fixing a window of risk which is not as important as the common usage case, and new installboot should be changed to use the old re-write technique. In the rare case where the bootblocks grow, oh well, recipe book time for people.
