Upgrade von 10.2 auf 10.3 unvollständig?

[willy4711]

Ja, habe ich! Obwohl das "händisch" nicht ganz richtig ist, zum Ändern habe ich den "Grub Customizer" genutzt.

Die Ausgabe ist ellenlang, kann ich die vielleicht irgendwie auf das wesentliche reduzieren?

Zuerst müsste man mal wissen, ob du da ein Multiboot-System hast.

Man kann das auch im Customizer machen, aber da muss man genau wissen, was man tut. Ich möchte dazu nicht raten.

[fischig]

Die Ausgaben der beiden apt-Befehle wären möglicherweise schon sehr hilfreich.

Na zumindest hat er das behauptet, und wohl diverse Male einen Neustart gemacht.

Hat er nicht! Wenn ich nichts überlesen habe, ist nach wie vor unklar, ob via

Code: Alles auswählen

apt-get update

die Paketverwaltung vor dem dist-upgrade auf den neuesten Stand gebracht wurde.
Weiterhin ist unklar, was überhaupt drin steht in seiner /etc/apt/sources.list.

Der TE benutzt(e) apt-get, nicht apt und auch nicht synaptic. Zur Vermeidung neuer Baustellen sollte man sich jenseits persönlicher Präferenzen darauf erst mal einlassen.

[willy4711]

Ob ich das direkt im Anschluss gemacht habe, kann ich nicht mehr sagen. Seitdem wurde das System aber schon diverse male neu gestartet.

Reicht das ?
In /boot ist auch alles da.
Es liegt mit maximaler Wahrscheinlichkeit an Grub. Und das sollte man jetzt versuchen zu reparieren.

Und zu dem update Vermutungen:
Du kannst kein wie auch immer geartetes upgrade machen, bevor du nicht vorher ein update gemacht hast
zu Illustration:

Code: Alles auswählen

root@XFCE:/home/willy# apt full-upgrade
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.       
Statusinformationen werden eingelesen.... Fertig
Paketaktualisierung (Upgrade) wird berechnet... Fertig
0 aktualisiert, 0 neu installiert, 0 zu entfernen und 0 nicht aktualisiert.

aber:

Code: Alles auswählen

root@XFCE:/home/willy# apt update && apt full-upgrade
....
....
Es wurden 548 kB in 7 s geholt (81,3 kB/s).                                                        
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.       
Statusinformationen werden eingelesen.... Fertig
Aktualisierung für 1 Paket verfügbar. Führen Sie »apt list --upgradable« aus, um es anzuzeigen.
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.       
Statusinformationen werden eingelesen.... Fertig
Paketaktualisierung (Upgrade) wird berechnet... Fertig
Die folgenden Pakete werden aktualisiert (Upgrade):
  libhandy-0.0-0
1 aktualisiert, 0 neu installiert, 0 zu entfernen und 0 nicht aktualisiert.
Es müssen 118 kB an Archiven heruntergeladen werden.
Nach dieser Operation werden 0 B Plattenplatz zusätzlich benutzt.
Möchten Sie fortfahren? [J/n] 

[fischig]

Ob ich das direkt im Anschluss gemacht habe, kann ich nicht mehr sagen. Seitdem wurde das System aber schon diverse male neu gestartet.

Reicht das ?

Ich weiß nicht an, wen die Frage gerichtet ist. Falls an mich, dann ist meine Antwort "Nein". Begründung findest du im Threadverlauf.

[willy4711]

Ich weiß nicht an, wen die Frage gerichtet ist. Falls an mich, dann ist meine Antwort "Nein". Begründung findest du im Threadverlauf.

Sorry, aber das stimmt einfach nicht. Eine sinnvolle Begründung dafür finde ich auch nirgends.
Wann und wie du das System neu startest ist vollkommen egal. Solange du nicht neu startest,
fährst du halt mit dem alten Kernel, den du ja auch hinterher noch starten kannst.

Und ob man nun apt , apt-get, Synaptic, oder Muon oder ... nimmt ist hier auch von sekundärer Bedeutung.

[fischig]

Willy, mir und, wenn ich recht sehe, zuletzt auch TomL geht's um das "vorher" nicht um das, was im "Anschsluss" gemacht wurde. Dieses "vorher" ist nicht geklärt. Und das "vorher" kommt nun mal vor dem "nachher". Wenn er VOR dem dist-upgrade die Paketverwaltung nicht auf den aktuellen Stand gebracht hat, dann kann er HINTERHER noch so oft rebooten oder am grub basteln, dann kriegt er nicht den erwarteten aktuellen Systemstand.

[willy4711]

Und zu dem update Vermutungen:
Du kannst kein wie auch immer geartetes upgrade machen, bevor du nicht vorher ein update gemacht hast
zu Illustration:

Und was erwartest du für Erkenntnisse aus dem Befehl systemctl reboot
Er fährt runter und startet dann mit der falschen intrd, weil das so im Grub steht.
Ob da was nicht stimmt sieht man doch erst, wenn man das im Grub korrigiert hat.

[TomL]

Sorry, aber das stimmt einfach nicht. Eine sinnvolle Begründung dafür finde ich auch nirgends.

Doch, die gibts hier. Das Problem ist, wenn er die Paketlisten nicht vorher aktualisiert hat, hat er meiner Meinung nach mit dist-upgrade einen quasi undefinierten Systemzustand.... der durchaus auch für das beschriebene Problem verantwortlich sein kann.

Und zu dem update Vermutungen:
Du kannst kein wie auch immer geartetes upgrade machen, bevor du nicht vorher ein update gemacht hast

Da habe ich aber eine andere Meinung. Natürlich kann man ein Upgrade ohne vorheriges Update machen. Das bedeutet aber, dass ggf. Pakete runterkommen, die andere Abhängigkeiten haben, z.B. eine neuere Lib, aber die alte Paketliste zeigt noch auf die vorherige Lib, die ja sogar existiert und vielleicht sogar teilweise funktioniert... keine Ahnung.

[willy4711]

Hast du mein Beispiel gelesen ? viewtopic.php?f=12&t=176853&start=15#p1233571

[TomL]

Ja, und ich kann das nicht widerlegen... vielleicht habe ich mich getäuscht....

Ich habe gerade mal auf meinen Server geguckt, der definitiv was zum updaten listen müsste.... es stimmt, ohne Update findet er nichts. So eine Situation ist also scheinbar nur durch groben Unfug herzustellen.... man aktualisiert z.B. an einem Abend die Paketlisten und guckt nach, ob was vorliegt... und denkt sich "ach, kein Bock mehr, ist zu spät und dauert zu lange, mach ich morgen oder übermorgen" *lol* Und wenn mans dann übermorgen tut .,.. und dann ohne update, scheint mir die Möglichkeit zu bestehen, dass es nun strubbelig ist.

[willy4711]

Noch prägnanter in Siduction (musste erstmal einen VM suchen, die nicht gleich beim Hochfahren nach Updates sucht ):

Das schreibe ich aber lieber nach NoPaste 41008

Die eine Datei sshfs war Bestand, weil ich neulich dazu keinen Bock hatte

[willy4711]

@ Oystercatcher
Um mal schnell zu testen, ob alles funktioniert, ohne Grub jetzt zu "renovieren"
könntest du mal auf die erste Zeile im Grub -Customizer Rechts- Klicken und Editieren.
Dann kopiere das mal und stelle es hier ein, ohne erstmal was zu ändern.

[fischig]

Genau an sowas (TomLs letztes Beispiel) hatte ich als Möglichkeit gedacht. In TomLs Beispiel würde aktualisiert werden, was die Paketverwaltung in den Repos gemäß ihrem Stand als möglich zu aktualisieren findet, aber nichts sonst. Das MUSS nicht in einer Fehlermeldung enden - denke ich. Offenbar ist Willys These: kein upgrade ohne update, wie er in nopaste selbst zeigt, unzutreffend. (Habe ich das auf die Schnelle richtig gelesen?)

edit:
Ich würde nach wie vor früher ansetzen: apt-get update und dann schauen, was apt zum dist-upgrade meint. Zur Erinnerung, alles was der TE bemägelt, ist ein seiner Meinung nach veraltetes kernel-image.

[willy4711]

Na ja ist aus meiner Sicht auch kein Beinbruch. (siehe die Datei sshfs). Hätte ich das jetzt gemacht, ohne erneutes Update,
hätte ich den Stand der Paketverwaltung von diesem Tag, wo sie gerne das Paket sshfs upgedatet hätte.
Dann ist mein System eben nicht aktuell, aber trotzdem ok.

[willy4711]

Ich würde nach wie vor früher ansetzen: apt-get update und dann schauen, was apt zum dist-upgrade meint. Zur Erinnerung, alles was der TE bemägelt, ist ein seiner Meinung nach veraltetes kernel-image.

Richtig und das liegt am Grub, der es nicht startet.

[Oystercatcher]

Guten Morgen!

@ Oystercatcher
Um mal schnell zu testen, ob alles funktioniert, ohne Grub jetzt zu "renovieren"
könntest du mal auf die erste Zeile im Grub -Customizer Rechts- Klicken und Editieren.
Dann kopiere das mal und stelle es hier ein, ohne erstmal was zu ändern.

Code: Alles auswählen

load_video
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
insmod part_msdos
insmod ext2
set root='hd0,msdos1'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
else
  search --no-floppy --fs-uuid --set=root xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
fi
echo	'Linux 4.19.0-6-amd64 wird geladen …'
linux	/boot/vmlinuz-4.19.0-6-amd64 root=UUID=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx ro  quiet
echo	'Initiale Ramdisk wird geladen …'
initrd	/boot/initrd.img-4.19.0-6-amd64

Ich war mir nicht sicher, was die Zahlen-Buchstaben Kombinationen bedeuten und ob man diese öffentlich posten sollte, daher habe ich sie durch "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" ersetzt.

[willy4711]

Ich war mir nicht sicher, was die Zahlen-Buchstaben Kombinationen bedeuten und ob man diese öffentlich posten sollte, daher habe ich sie durch "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" ersetzt.

Das sind die UIID's der Festplatte Für Außenstehende weniger Relevant, aber für Grub essentiell, damit er weiß, welche Platte
er bemühen soll.

So. Und jetzt ersetzt du die 6 mit der 8 und zwar so:

Code: Alles auswählen

echo	'Linux 4.19.0-8-amd64 wird geladen …'
linux	/boot/vmlinuz-4.19.0-8-amd64 root=UUID=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx ro  quiet
echo	'Initiale Ramdisk wird geladen …'
initrd	/boot/initrd.img-4.19.0-8-amd64

Dabei aufpassen, dass du keine Leerzeichen oder sonstiges unverdauliches rein zauberst.
Speichern ---> Neustart

Code: Alles auswählen

uname -a

[Oystercatcher]

So. Und jetzt ersetzt du die 6 mit der 8 und zwar so:

Code: Alles auswählen

echo	'Linux 4.19.0-8-amd64 wird geladen …'
linux	/boot/vmlinuz-4.19.0-8-amd64 root=UUID=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx ro  quiet
echo	'Initiale Ramdisk wird geladen …'
initrd	/boot/initrd.img-4.19.0-8-amd64

Dabei aufpassen, dass du keine Leerzeichen oder sonstiges unverdauliches rein zauberst.
Speichern ---> Neustart

Code: Alles auswählen

uname -a

Nun bootet der aktuelle Kernel:

Code: Alles auswählen

Linux deb-xfce 4.19.0-8-amd64 #1 SMP Debian 4.19.98-1 (2020-01-26) x86_64 GNU/Linux

Wie es zu dem Problem gekommen ist, kann ich leider nicht nachvollziehen. Ich bin mir "relativ" sicher, dass ich vor dem Upgrade ein

Code: Alles auswählen

apt-get update

durchgeführt habe.

Eine Frage hierzu noch: Ich habe den nicht aktuellen Kernel jetzt ja eher zufällig entdeckt. Wie stelle ich denn am besten regelmäßig sicher, dass das ganze System aktuell ist? Gibt es neben Paketen und Kernel noch andere Komponenten, die aktuell gehalten werden müssen?

[willy4711]

Bevor ich dir jetzt rate, brauche ich noch ein paar Angaben.
1) hast du ein Multi-Boot System oder ist das das einzige OS, was du startest ?
2) Ist os-prober installiert ?

willy4711 hat geschrieben:
26.03.2020 14:43:00
was ergibt:

Code: Alles auswählen

 cat /boot/grub/grub.cfg |grep /boot/vmlinuz-

Die Ausgabe ist ellenlang, kann ich die vielleicht irgendwie auf das wesentliche reduzieren?

Das sollte das "Machwerk" von os-prober" sein, allerdings habe ich das nur bei multiboot - Systemen erlebt.
Kannst du im Customizer an sich auch sehen, denn da ist immer vermerkt, wer was geschrieben hat.
Bitte die Ausgebe von

Code: Alles auswählen

dpkg -l *grub*|grep ii

Wenn du nur ein System hast, ist der Grub-Customizer ziemlich überflüssig.
Aber das wäre erstmal der nächste Schritt.

[Oystercatcher]

1) hast du ein Multi-Boot System oder ist das das einzige OS, was du startest ?

Ja, ist ein Multi-Boot System:

Hast du eventuell am Grub etwas händisch verändert ?

Ja, habe ich! Obwohl das "händisch" nicht ganz richtig ist, zum Ändern habe ich den "Grub Customizer" genutzt.
Auf dem von der Problematik betroffenen Rechner sind neben Buster mit XFCE auch noch Buster mit MATE, mit Cinnamon, mit KDE und mit Gnome installiert. Hintergrund ist der, dass sich meine Lebensgefährtin noch nicht für einen "Lieblingsdesktop" entschieden hat und jetzt seit ca. 3 Monaten die unterschiedlichsten Varianten durchtestet.

2) Ist os-prober installiert ?

Ja, ist es

Bitte die Ausgebe von

Code: Alles auswählen

dpkg -l *grub*|grep ii

Wenn du nur ein System hast, ist der Grub-Customizer ziemlich überflüssig.
Aber das wäre erstmal der nächste Schritt.

Code: Alles auswählen

ii  grub-common      2.02+dfsg1-20 amd64        GRand Unified Bootloader (common files)
ii  grub-customizer  5.1.0-1       amd64        GUI to configure GRUB2 and BURG
ii  grub-pc          2.02+dfsg1-20 amd64        GRand Unified Bootloader, version 2 (PC/BIOS version)
ii  grub-pc-bin      2.02+dfsg1-20 amd64        GRand Unified Bootloader, version 2 (PC/BIOS modules)
ii  grub2-common     2.02+dfsg1-20 amd64        GRand Unified Bootloader (common files for version 2)

[willy4711]

willy4711 hat geschrieben: ↑ zum Beitrag ↑
28.03.2020 16:28:06
1) hast du ein Multi-Boot System oder ist das das einzige OS, was du startest ?

Ja, ist ein Multi-Boot System:

Da wäre jetzt mal die Ausgabe von

Code: Alles auswählen

 lsblk -f 

interessant.
Dann: was hast du noch für Systeme installiert ?

Grundsätzlich ist die Aktivität von os-prober nicht sehr empfehlenswert. hab noch nie erlebt, dass da nicht irgendwann
ne menge Mist in der grub-cfg gelandet ist.

Auf jeden Fall: os-prober sollte nur auf dem System installiert sein, das in den MBR der 1. Platte schreibt.

Ich habe mehere Jahre ein Multiboot System gehabt.
Die letzten Jahre hab ich bei einem Kernel-Update das im Grub-Customizer per Hand geändert,
und os-prober eliminiert.
Denn: Die UIID's der Platten ändern sich in der Regel ja nicht, man bracht also nurdie Versionsnummern ändern.

Die anderen Systeme hatte alle ihren eigenen Grub im jeweiligen MBR der eigenen Platte.
So konnte sie man in jedem Fall auch aus dem BIOS starten, ohne den "zentralen" Grub auf der ersten Platte.

Ich würde aber dich doch nochmals bitten, die Ausgabe von

Code: Alles auswählen

cat /boot/grub/grub.cfg |grep /boot/vmlinuz-

hier einzustellen, zur Not nach Pastebin
Bei mir sieht die so aus:

Code: Alles auswählen

~$ cat /boot/grub/grub.cfg |grep /boot/vmlinuz-
	linux	/boot/vmlinuz-5.4.0-4-amd64 root=UUID=051b95a4-f99d-4808-9237-5a7d0b976423 ro  quiet
		linux	/boot/vmlinuz-5.4.0-4-amd64 root=UUID=051b95a4-f99d-4808-9237-5a7d0b976423 ro  quiet
		linux	/boot/vmlinuz-5.4.0-4-amd64 root=UUID=051b95a4-f99d-4808-9237-5a7d0b976423 ro single 

Erste Zeile: Default
Die beiden Darunter: Erweiterte Optionen.

Wenn wir dann wissen was auf deinem Rechner ist (Hoffentlich kein Windows ), würde ich so vorgehen:
Auf den anderen Systemen (wenn nicht Windows) nachsehen , ob os-prober vorhanden ist.

Wenn ja purgen und ein update-grub durchführen. Testen ob die noch starten.

Dann erst der ersten Platte zuwenden.

Ich würde hier wahrscheinlich die radikale Lösung anwenden:
alles purgen (grub usw.) und Neu installieren. Dann hast du erstmal einen saubere grub.cfg.

Kannst ja mal sagen, wofür du den Grub-Customizer gebraucht hast -- gibt auch andere Lösungen.

[Oystercatcher]

Guten Abend!

Dann: was hast du noch für Systeme installiert ?

Öhm, ich schreibe es gerne noch ein drittes mal :
Auf dem von der Problematik betroffenen Rechner sind neben Buster mit XFCE auch noch Buster mit MATE, mit Cinnamon, mit KDE und mit Gnome installiert. Hintergrund ist der, dass sich meine Lebensgefährtin noch nicht für einen "Lieblingsdesktop" entschieden hat und jetzt seit ca. 3 Monaten die unterschiedlichsten Varianten durchtestet.

Ich kürze hier mal ab: Diese Installation wird eh nicht mehr lange existieren und ich (bzw. sie) kann mit der aktuellen Situation leben. Mir ging es eher darum zu erfahren, wie ich so etwas in Zukunft vermeiden kann. Da auf dem Rechner demnächst nur noch ein System (Buster mit XFCE als Neuinstallation) laufen wird, wird auch der Grub Customizer nicht mehr zum Einsatz kommen. Das Problem ist für mich damit gelöst!

Ich möchte aber gerne noch auf eine Frage aus meinem vorletzten Beitrag zurück kommen:

Ich habe den nicht aktuellen Kernel jetzt ja eher zufällig entdeckt. Wie stelle ich denn am besten regelmäßig sicher, dass das ganze System aktuell ist? Gibt es neben Paketen und Kernel noch andere Komponenten, die aktuell gehalten werden müssen?

Ich war ehrlich gesagt etwas verwundert, dass Debian keine Anstalten gemacht hat, mich darauf hinzuweisen, dass die Version des Kernels nicht aktuell ist bzw. nicht zur installierten Debian Version 10.3 "passt". Ähnlich ging es mir mit dem Paket "intel-microcode" welches beim T420 erforderlich ist (aber manuell installiert werden muss), um gegen Spectre und Co. gewappnet zu sein. Da wäre doch ein Tool ganz nett, welches das System auf bekannte Sicherheitsprobleme überprüft.

[willy4711]

Öhm, ich schreibe es gerne noch ein drittes mal :

Ja sorry, hab ich irgendwie aus dem Focus verloren.

Ich habe den nicht aktuellen Kernel jetzt ja eher zufällig entdeckt. Wie stelle ich denn am besten regelmäßig sicher,
dass das ganze System aktuell ist? Gibt es neben Paketen und Kernel noch andere Komponenten, die aktuell gehalten werden müssen?

Deine Installation besteht nur aus Paketen. Bei einem update werden alle Pakete aktualisiert.
Bei Stable wird es aus meiner Sicht reichen, wenn man das einmal pro Woche macht.

Code: Alles auswählen

apt update && apt full-upgrade

Ich selbst benutze aptitude, weil dabei wesentlich übersichtlichere Logs geschrieben werden.

Zum Kernel - Normalerweise funktioniert das so:
Wenn ein neuer Kernel installiert wird, rückt der an die erste Stelle im Grub-Menü, wird also nach der entsprechenden
Wartezeit automatisch gestartet.
Der alte , sowie die Option für den Recovery- Modus für beide Kernel ist dann im Untermenü (Erweiterte Optionen) zu finden.

Dass das bei dir nicht passiert ist, liegt wahrscheinlich daran, das du im Customizer was falsch gemacht hast.
Wenn du da suchst, wirst du wahrscheinlich auch diese Zeile irgendwo finden,, die du jetzt per Hand editiert hast.

Ich war ehrlich gesagt etwas verwundert, dass Debian keine Anstalten gemacht hat, mich darauf hinzuweisen, dass die Version des Kernels nicht aktuell ist bzw. nicht zur installierten Debian Version 10.3 "passt".

Warum sollte Debian dich da informieren ? Man kann so ziemlich jeden Kernel (neuere und ältere) installieren.
Das ist Debian so ziemlich egal, solange es funktioniert, und deine Freiheit.
Außerdem bin ich sehr sicher, dass diese Meldung auch nach der Installation des Kernels kam, mit der Aufforderung,
einen Neustart zu machen.
Grundsätzlich sollte man immer ein Update beobachten. Soviel Aufwand ist das ja nun auch nicht.
Das mache ich selbst bei Windows.
Hast du aber wohl verschlafen.

Ähnlich ging es mir mit dem Paket "Intel-microcode" welches beim T420 erforderlich ist

intel-microcode ist Non-Free Software und muss deshalb nach Freischalten der Ressourcen händisch installiert werden.

[Oystercatcher]

Ich habe den nicht aktuellen Kernel jetzt ja eher zufällig entdeckt. Wie stelle ich denn am besten regelmäßig sicher,
dass das ganze System aktuell ist? Gibt es neben Paketen und Kernel noch andere Komponenten, die aktuell gehalten werden müssen?

Deine Installation besteht nur aus Paketen. Bei einem update werden alle Pakete aktualisiert.
Bei Stable wird es aus meiner Sicht reichen, wenn man das einmal pro Woche macht.

Code: Alles auswählen

apt update && apt full-upgrade

Ich selbst benutze aptitude, weil dabei wesentlich übersichtlichere Logs geschrieben werden.

Danke für den Hinweis, werde ich gleich mal ausprobieren!

Ich war ehrlich gesagt etwas verwundert, dass Debian keine Anstalten gemacht hat, mich darauf hinzuweisen, dass die Version des Kernels nicht aktuell ist bzw. nicht zur installierten Debian Version 10.3 "passt".

Warum sollte Debian dich da informieren ? Man kann so ziemlich jeden Kernel (neuere und ältere) installieren.
Das ist Debian so ziemlich egal, solange es funktioniert, und deine Freiheit.

Debian soll mich ja nicht daran hindern, alten Kram zu nutzen. Aber den Hinweis, dass da gerade ein nicht aktueller Kernel läuft fände ich schon angebracht. Oder ist das etwa nicht sicherheitsrelevant?

Außerdem bin ich sehr sicher, dass diese Meldung auch nach der Installation des Kernels kam, mit der Aufforderung,
einen Neustart zu machen.
Grundsätzlich sollte man immer ein Update beobachten. Soviel Aufwand ist das ja nun auch nicht.
Das mache ich selbst bei Windows.
Hast du aber wohl verschlafen.

Eigentlich sass ich während des Updates vorm Rechner und habe mir den Vorgang angeguckt. Sehr lange hat das nicht gedauert. Kann ich die Ausgaben des Updatevorgangs nicht in irgendeiner Log Datei nachvollziehen?
Wo Du gerade den Vergleich mit Windows bemühst: Wenn ich mich recht erinner, würde Windows bei jedem folgenden Updatevorgang erneut versuchen, ein vorher gescheitertes Update zu installieren.

Ähnlich ging es mir mit dem Paket "Intel-microcode" welches beim T420 erforderlich ist

intel-microcode ist Non-Free Software und muss deshalb nach Freischalten der Ressourcen händisch installiert werden.

Auch hier fände ich einen Hinweis angebracht. Der Installer schafft es doch auch mich während der Installation darauf hinzuweisen, dass zum Betrieb meiner WLAN Hardware Pakete aus non-free notwendig sind. Hardware die gar nicht funktioniert (WLAN) ist mir deutlich lieber als solche, die unsicher funktioniert (CPU ohne microcode Update). Im ersten Fall merken auch weniger aufmerksame Personen sofort, dass etwas nicht stimmt. Im zweiten Fall merkt es nur derjenige, der sich tiefer mit der Materie befasst hat.

Gibt es unter Debian irgendeine Möglichkeit, das System auf bekannte aber nicht gefixte Sicherheitsprobleme zu untersuchen?

[willy4711]

Kann ich die Ausgaben des Updatevorgangs nicht in irgendeiner Log Datei nachvollziehen?

Für apt:
Ausfühlich:/var/log/apt/term.log ---> ältere:/var/log/apt/term.log.1.gz usw
nur Pakete: /var/log/apt/history.log ---> älter analog term.log

für Aptitude:
/var/log/aptitude

Gibt es unter Debian irgendeine Möglichkeit, das System auf bekannte aber nicht gefixte Sicherheitsprobleme zu untersuchen?

Eventuell:
https://security-tracker.debian.org/tracker/
und für die Tägliche Lektüre:
https://www.cert-bund.de/overview/AdvisoryShort

Er kommen dann selbstverständlich noch Sicherheitslücken dazu, die nicht veröffentlicht werden, weil der Staat und
ähnliche Institutionen diese gerne erhalten würden. Anfrage beim BND oder ähnlichen Vereinen. Geben gerne Auskunft.

Und dann:
Alle Türen verschließen / sorgfältig alle zusätzlichen Riegel betätigen / Alarmanlage scharf machen / Stecker von Rechner / Router entfernen / Handy entsorgen bzw in einer Blei - Schatulle deponieren / Kopf unters Kopfkissen und aufpassen, dass man dabei nicht erstickt