On 9/24/2015 1:45 PM, Brian C. Lane wrote: > I've only seen 1 other bug like this in Fedora, and I basically told > them they need to recreate their disk or use some other tool. I'm not > sure we need to support such a corner case.
Given that it doesn't look like this will be easy to fix and how exceedingly rare it is ( which is kind of surprising to be honest ), I'm starting to agree. On the other hand, we should at least throw a proper error message that we don't like your goofy partition table rather than crash with an assertion failure. > The EBR code really needs more comments I think :) What's happening is > it is rewriting the extended partition and each of the logical > partitions in a loop. Note that below that code it calls itself > passing in the new part. So it will run out to the last logical > partition and then start writing tables, so you have to hold things > upside down and backwards to understand it :) Maybe I need to stand on my head? ;) I see that it is iterating over all of the logical partitions using recursion, and at each one, it fills out an EBR with the first slot pointing to that logical partition, and the second slot should be pointing to where the next partition's EBR will go... but that doesn't look like what it is doing because where the next should go is not the previous one's first sector. Also when it calls itself, it should be passing the sector number of the next EBR corresponding to the logical partition that next stack frame will handle. Yet instead it is passing part->prev->geom.start, which is this partition's boot sector. In other words, it is first called on partition 5, then it calls itself on partition 6, but says to itself that the EBR for partition 6 is in the first sector of partition 5.
