Mit deiner Problembeschreibung lieferst du aber selbst die Erklärung für das von mir bevorzugte Vorgehen mit den symbolischen Links.
Ein weiterer Grund ist, dass es mit den automatisch erstellten Booteinträgen zB typischerweise so abläuft:
Angenommen man hat zwei Systeme (A und B) mit jeweils eigenem grub und gebootet wird mit dem grub von A. Macht man in B ein Kernelupdate, wird nur dessen grub.cfg neu geschrieben, aber der grub von A erhält erst einen Booteintrag für den neueren Kernel, wenn man dort ebenfalls update-grub ausführt, etwa mit Rahmen eines Kernelupdates oder manuell. Richtig lästig wird das Verhalten, wenn man in B den alten Kernel deinstallieren, weil es dann in A keinen funktionierenden Booteintrag für B mehr gibt.
Nun könnte man einfach selbst einen Booteintrag in A erstellen, der nicht direkt den Kernel von B startet sondern nur auf die grub.cfg von B verweist, aber dann hat man immer noch das Problem, dass sich die Grubs von A und B bei Updates von grub selbst um die "Pole-Position" im MBR streiten. Dagegen kann man zwar mit
Code: Alles auswählen
# dpkg-reconfigure -p low grub-pc
Die symbolischen Links haben den Vorteil, dass sie immer auf den aktuellen und die mit .old hintendran auf den vorigen Kernel (samt initrd) zeigen und man so Booteinträge schreiben kann, die nicht mit update-grub aktualisiert bzw. neu geschrieben werden müssen sondern immer aktuell sind.
Man erspart sich also nicht nur das fehlerträchtige Erkennen der anderen Installationen mit os-prober und damit eventuell fehlende oder überflüssige Einträge sondern startet die Systeme, die über keinen eigenen grub verfügen (weil man ihn dort deinstalliert hat) automatisch mit dem aktuellen Kernel.
Auf Hardware die beim Booten gerne Probleme verursacht, habe ich das auch schon auf die Spitze getrieben, indem ich auf keinem der installierten Systeme grub installiert habe, sondern nur, zB von einem Livesystem aus, einen von den Systemen unabhängigen Grub auf einer eigenen Partition installiert und dessen Konfigurationsdatei selbst die nötigen Booteinträge geschrieben habe, die nur auf die Symlinks zu aktuellen Kernel+initrd des jeweiligen Systems verweisen.
Damit erspart man sich nicht nur das update-grub und bei grub-efi-... das ständige Neuschreiben der Booteinträge im nvram sondern auch ganz grundsätzlich die (automatische) Neuinstallation von grub bei Updates von grub.
@stage1, stage1_5, stage2
Soweit ich weiß kann oder konnte man bei grub-pc auch unter gewissen Umständen auf einen stage1_5 verzichten und grub-efi-... und weitere grub-Varianten wie grub-ieee1275 kommen ohnehin ohne stage1_5 aus - eventuell ein weiterer Grund weshalb man diesem stage keine eigene ganze Zahl gegönnt hat.