The current Boot module tries to boot even if the os9boot file is fragmented. However in looking at the code for Boot, it looks to me that there must be an entry in LSN0 for DD.BT. The problem with this is that cobbler erases both DD.BT and DD.BSZ during the process of creating a new os9boot file. Cobbler will exit without adding a DD.BT if the os9boot file is fragmented so the new Boot won't help.
I've found that certain types of very large disks are prone to os9boot fragmentation. It would be nice if we could get Boot and Cobbler to work together better. Should Cobbler be changed to write out DD.BT regardless of fragmentation? Can Cobbler be changed to prevent fragmentation in some fashion?
The strange thing about the disks that Cobbler won't work with is that if one copies the new os9boot file manually, the result is not fragmented and can be used as a good os9boot file.
I haven't used cobbler in ages. However, my favorite trick to prevent fragmentation is to set a dmode sas=FF, which will force disk allocations to be in that large size, sufficient to do an os9boot sized file in one piece. Os9/Nitros9, when closing the file, will then de-allocate that which is not used, setting a valid file size and FAT bits. $FF might be a bit big for boot files, but I would pick a value that could contain a 40k sized bootfile in one FD.SEG. Something around 9F maybe.
In fact, I usually have my descriptors set at a minimum of sas=20, or 32 sectors.
Give a large sas, its a hex value BTW, a shot and see if that will fix cobbler. If it does, it would be a lot easier to add that call to the entry of cobbler, and to be complete, a reset back to sas=08 at the exit. OTOH, we have the cobbler dis already, so maybe the logic error could be spotted. I haven't looked at that src ever, so could be just blowing smoke.
I personally think its best at attack the problem external to cobbler, by setting sas to a value that will allocate contiguous disk if its available, and if not then cobbler should get a failure before its destroyed the old data on the disk by wiping DD.BT and DD.BSZ. On big disks with lots of free space, I'm with you, it should Just Work, but probably doesn't because it put the first FD.SEG sized alloc of 8 sectors up front, then had to allocate farther into the disk for subsequent pieces, maybe even multiple times. FD.SEG number 0 should contain the whole thing. Then you have no fragmentation and a fragmented boot file won't happen.