Am I understanding this correctly: instead of having the boot partitions configured as a (MD?) RAID set, you had somehow manually cloned them between two disks? A mirrored boot partition works just fine if you're legacy booting... With EFI I guess you have to do manual cloning (which is fragile) or rely on hardware RAID.
Did you use some tool to do that? How do you expect the upgrade process to even be able to take that kind of thing into account?
Without knowing any details it's hard to say if it was an actual bug or just plain old human error, but it sounds like the latter.
I've long forgotten exactly why these systems were first set up that way. Presumably it was because at the time someone was leaving their options open about the RAID set-up for the main drives/partitions and bootloaders of that generation didn't support MD well so keeping boot as a non-RAID set-up was not uncommon. Whatever the history, the fact is that before the automated part of the 6-to-7 upgrade there was a fully working system, and after it there wasn't.
How do you expect the upgrade process to even be able to take that kind of thing into account?
I don't think it's rocket science to suggest that if you're migrating to a new bootloader, and you've got a system with multiple drives in it (RAIDed or otherwise), and you're installing an OS that is widely used in server or multiple-OS environments, just assuming that you should upgrade the bootloader on one specific drive and ignore anything else is not a great idea. What if the sysadmin installing the update wasn't the person who installed the original and simply hadn't realised how the /boot was set up?
Without knowing any details it's hard to say if it was an actual bug or just plain old human error, but it sounds like the latter.
There was no "error". The situation before the upgrade was what it was, and after the upgrade the problem was quickly detected and fixed. But it took time and effort to do that, instead of having a smooth, fully automated upgrade process. Again, the fact is that before the automated part of the 6-to-7 upgrade there was a fully working system, and after it there wasn't.
Will the 7-to-8 update now expect everyone performing it to be intimately familiar with the implications of things like systemd? Because I'm betting plenty of people will encounter it for the first time as part of this upgrade cycle.
What about package compatibility? Some packages have been entirely removed in Jessie; see the political debates about FFmpeg vs. Libav for a relatively high-profile example. That is inevitably going to break some people's install scripts/tool recipes/etc.
My point here is that there are significant changes as part of the upgrade, and upgrades always carry a degree of risk, and my personal experience (based on several different projects) of the 6-to-7 upgrade process was that the risk was real and the fully automated part of the process was not able to do everything necessary itself. Consequently I would not recommend that anyone assume a 7-to-8 upgrade will necessary go completely smoothly and be fully automated either.
[Edit: To be clear, I'm not saying you shouldn't do it or something awful will happen. Nor am I criticising Debian for not anticipating every possible scenario and handling everything completely automatically. I'm just saying my experience last time around was different to kasabali's experience, and as one data point, projects I work on where the experience was not as smooth last time but the desire is to move to 8 quite quickly are generally favouring a clean install and application migration strategy rather than an in-place upgrade. The expectation of those teams is that this will incur less risk and might be faster anyway once you take all implementation and testing effort into account.]
Hmm, this sounds like a difference in expectations. I don't think anyone said that Debian upgrades are fully automated; the package manager does what it can (and it usually does a good job) but it's always the sysadmin's job to verify that the configuration at reboot is sane, especially if there's even a hint of something special in the configuration.
Upgrade scripts certainly could try to predict every crazy thing people do with their computers, but past a certain point, it's not very productive. People are creative.
In the end, the admin must make the decision whether reinstalling and reconfiguring a server has a lower general cost than verifying and potentially fixing an upgraded installation.
Of course in the end it's the sysadmin's job to administer the system, but that's also a convenient way to shift responsibility for problems away from the tools. As I mentioned, the problems were quickly detected and subsequently fixed in the cases I'm aware of. But that still required time and effort, and since realistically no sysadmin is going to be an expert on every part of their system that might be affected by an OS upgrade on this scale, I still think it's fair to highlight the risk.
Did you use some tool to do that? How do you expect the upgrade process to even be able to take that kind of thing into account?
Without knowing any details it's hard to say if it was an actual bug or just plain old human error, but it sounds like the latter.