es wurde nicht angegeben welches "paket" einen Fehler beim Update erzeugt hat.
Bei einem Update der letzten Zeit (< 2 Wochen) war auch eine Aktualisierung von grub2 dabei und dabei wurde z.B. auf der EFI-Boot-Partition bei mir ein Unterordner "fw" (also ? firmware) angelegt, der allerdings leer blieb. Dazu zeigte mir "efibootmgr -v" im Vergleich zu einer älteren Version (die ich mir notiert hatte) etwas andere Einträge an. Wenn der Fehler also beim Update vom grub passiert, dann könnte es schon sein, dass die Änderungen an den EFI-Booteinträgen nicht richtig funktionierten. Für mich sieht es so aus, als wenn beim grub-Update zusätzliche Einträge für "Removable Device..." hinzugekommen sind.
Änderungen (negative) bei Updates sind manchmal schwer zu finden. Mit hat mal ein eigenes Kernel-Update Probleme bereitet ohne dass ich es bemerkt habe, weil es ein Fehler war, der nicht immer aufgetreten ist und in den ersten Tagen nach dem Update nicht auftrat. Als ich anfing zu suchen merkte ich, dass das Log von kern.log nicht weit genug zurück reichte. An dem Punkt half mir das neue journalctl weiter.
journalctl --no-pager | grep "blocked for more than 120\|generic (kernel" | less
zeigte mir deutlich an, dass dieser "blocked" Fehler nur bei einer ge-booteten Kernel-Version (nicht immer) auftrat, aber nie bei anderen Kernel-Versionen.
ps. muss ich erwähnen, dass ich es mir angewöhnt habe genauer auf die Update-Meldungen zu schauen und auch mir mal die Liste der pakete anzusehen und dazu lasse ich das Update nicht automatisch im Hintergrund laufen und habe mir auch angewöhnt den Rechner danach neu zu starten (einfach um solche Effekte zu verhindern, dass ich ein Problem erst beim nächsten boot merke, wenn ich vielleicht gar keine Zeit habe dem nachzugehen). Eine funktionierende Live-Version (vielleicht mit greifbarer extra Sicherung wichtiger Daten) sollte eigentlich selbstverständlich sein, damit man im schlimmsten Fall (Hardware-Komplettausfall) z.B. seine mails auch mal von einem anderen Rechner aus einsehen kann.