staging.inyokaproject.org

Hallo Experten,

seit 2021 hab ich einen Dell Latitude 3320 (i5 Notebook, 13,3 Zoll). Besonderheit ist, dass Dell als anscheinend einziger größerer Anbieter eine genaue Beschreibung liefert, wie man auf seinen Geräten zu dem vorinstallierten Windows 10 pro noch Linux, d. h. hier (K)Ubuntu als Dualboot-Lösung, installiert. Mir ist das damit als EFI- und Linux-Laie auf Anhieb gelungen, erfreuliche Erfahrung. In der ersten Zeit gab es manchmal Ärger, der PC ging ohne ersichtlichen Grund einfach aus. Über EFI oder aus Windows heraus kann man als Laie leicht ein EFI „BIOS“ Update machen, nach dem ersten Update lief der PC lange Zeit einwandfrei mit beiden Systemen.

Vor einigen Monaten erlebte ich dann eine Überraschung: Über die normalen Kubuntu-Aktualisierungen kam plötzlich auch ein „Dell Firmware Update“. Wie ist das möglich, wie kommt diese Verbindung mit Dell zustande bzw. wie weiß der Ubuntu-Updateserver, dass der PC eine Dell Firmware hat?

Unvorsichtigerweise habe ich das mit installiert, Ergebnis war, dass das Win. 10 nicht mehr startete und seinen mühseligen lange Wiederherstellungscode verlangt. Am Anfang hat das geholfen, nun aber ist es so, dass Win. nie mehr normal startet, jedes mal die „Störung“ mit der Wiederherstellungsprozedur, offenbar verträgt es das Dell EFI Firmware-Update über Linux nicht und wird beschädigt. Ich hab das dann vermieden und das Firmware Zeug bei den Kubuntu Updates abgewählt. Windows startet aber trotzdem nun nicht mehr normal.

Nun wird in Kubuntu auch immer gemeldet, die angebotenen Firmware-Update seien „nicht im Cabinet Format“, was offenbar eine bei Win. bekannte Dateiform von solchen Updates zu sein scheint, die in Linux nicht funktioniert oder so etwas, jedenfalls scheitert nun regelmäßig, was einmal ging und den beschriebenen Effekt hatte.

Kann jemand diese Zusammenhänge etwas klären, was müsste man tun, um die Win Störung weg zu bekommen, so dass Dualboot wieder richtig läuft?

Vielen Dank für Hinweise

Gruß

Stefan

https://wiki.ubuntuusers.de/fwupd/

Das steht alles drin, soll aber mit 22.04 deutlich besser geworden sein! Der (Grund)Gedanke ist gut, keine Herstellertools mehr sonder ein zentraler Dienst.

Wäre natürlich ein Ding, wenn der deine Lizenz gekillt hätte. 😎

seinen mühseligen lange Wiederherstellungscode

Wäre mir zu gefährlich beim Mainbord, daher keine persönliche Erfahrung! 🐸

Hallo,

Newubunti schrieb:

Bei Deinem Latitude mit Windows Pro hast Du mit Sicherheit Bitlocker standardmäßig aktiviert.

Genau das.

ceag, mit aktiviertem BitLocker wird man unter Windows durch den originalen Dell-Flasher gewarnt, den entsprechenden Haken im Flasher-Frontend nicht 'rauszunehmen. Anderenfalls muß man eben den BitLocker-Key danach eingeben. Dasselbe .exe-File mit dem im UEFI integrierten Flasher genutzt hat diese Möglichkeit nicht, danach muß man garantiert den 48stelligen Key eingeben - oder man deaktiviert vor dem Flashen BitLocker für sämtliche Partitionen. fwupd schert sich auch nicht um BitLocker, wie Du gesehen hast.

Du hast aber den BitLocker-Key eingegeben, kommst also auf die Windows-Partitionen bzw. ins Windows. Disable BitLocker für jede Windows-Partition über Kontextmenu! Nicht ungeduldig werden, durchlaufen lassen! Für Vollständigkeit mußt Du rebooten.

Funktioniert das dann alles ohne BitLocker-Verschlüsselung, kannst Du, falls gewünscht, dann auch wieder über Rechtsklick BitLocker-verschlüsseln. Die Keys sind dann andere.

Sollte das über Kontextmenu nicht (mehr) möglich sein (ich habe das gerade diese Woche bei einem HP-NB mit Win10Enterprise im Service gehabt, BitLocker im Kontextmenu nicht mehr drin), kann man das auch über cmd oder PowerShell durchführen.

Btw., Dein KFocal ist in einem Monat End of Support.

Newubunti schrieb:

Und falls nicht dann wende Dich an Dell.

Was geht das Dell an, wenn man BitLocker gesetzt hat und das nicht beachtet? Hat der User zuvor den BitLocker-Key gespeichert oder fehlerfrei abgeschrieben (bei Rechnern in einer Windows-Domäne wird der im übrigen im Active Directory gespeichert), muß er den eingeben. Hat er das nicht, Pech gehabt. Eine Verschlüsselung ist dafür da, daß man unbefugt nicht 'reinkommt. Den Schlüssel nicht zu haben, auch wenn man nur getrant hat, ist gleichbedeutend. Niemand kann diese Verschlüsselung derzeit aushebeln.

Die müssten eigentlich die nötige Kompetenz zur Hilfe haben, da sie Linux ja eigentlich relative ernsthaft - im Vergleich zu anderen Herstellern - unterstützen.

Urban legend. Nein, dem ist nicht so (und es geht bei BitLocker auch nicht um Linux, auch wenn er fwupd genutzt hat). Was Du da vielleicht mal bzgl. Linux-Unterstützung gelesen hast, betrifft die "Dell-Community", die ist nicht Dell. Die vereinzelten Modelle mit angestaubten Distributionsversionen ändern an Dells Grundhaltung nichts.

Im übrigen bekommt man von Dell ohne zu zahlen (vorher teuer mit Support-Vertrag oder, wenn's dann doch nötig wird, für diesen Fall im voraus) eh keinen Support.

hakel2022 schrieb:

Wäre natürlich ein Ding, wenn der deine Lizenz gekillt hätte. 😎

Mit dem Windows-ProductKey hat das überhaupt nichts zu tun.

von.wert schrieb:

Was geht das Dell an, wenn man BitLocker gesetzt hat und das nicht beachtet? Hat der User zuvor den BitLocker-Key gespeichert oder fehlerfrei abgeschrieben (bei Rechnern in einer Windows-Domäne wird der im übrigen im Active Directory gespeichert), muß er den eingeben. Hat er das nicht, Pech gehabt. Eine Verschlüsselung ist dafür da, daß man unbefugt nicht 'reinkommt. Den Schlüssel nicht zu haben, auch wenn man nur getrant hat, ist gleichbedeutend. Niemand kann diese Verschlüsselung derzeit aushebeln.

Ich habe ceag so verstanden, dass er den Wiederherstellungscode seit dem Firmware-Update von Kubuntu aus über fwupd bei jedem Windows-Start eingeben muss. Und das ist AFAIK nicht normal. Einmalige Eingabe erstmalig beim nächsten Neustart von Windows nach dem Firmwareupdate, ja, dauerhafte Eingabe des Wiederherstellungscodes aber nicht.

Die Frage - die ich an dieser Stelle nicht beantworten kann - ist, ob der Endanwender beim Firmware-Update über fwupd über solche möglichen Komplikationen und deren Vermeidung mit Bitlocker unter einem etwaig vorhanden Windows hingewiesen wird oder nicht. Wird er das nicht, dann ist das ein Versäumnis von den Programmieren der Firmware-Flashprozedur unter Linux. Wie gesagt, ob es so ist, weiß ich nicht, aber ich könnte mir hier durchaus vorstellen, dass eine Warnung bezüglich Bitlocker unter Linux fehlt, weil es ja Linux erst mal nicht betrifft.

Und das ginge Dell dann schon etwas an, zumal es hier nur ergänzender Informationen vor dem Update bräuchte.

Informationen oder entsprechend günstige Voreinstellungen alleine unter Windows bringen dem Endanwender nichts, wenn er ein Firmwareupdate bei einem Dualboot-System zuerst unter Linux angeboten bekommt, bevor er es bei Windows herunterlädt.

Ob sich Dell dann letztlich dafür verantwortlich fühlt oder nicht, ist eine andere Frage. Darauf aufmerksam machen würde ich aber als Dell-Nutzer schon.

LG, Newubunti

https://www.dell.com/support/kbdoc/de-de/000134415/aktualisieren-des-bios-auf-dell-systemen-mit-bitlocker-aktiviert

Man könnte ja auch einfach mal bei Dell nachlesen. Da steht alles drin ... 👍

Wenn ich das richtig verstehe, ist die Schleife ein Fehler von Dell. Das Dell Tool scheint allerdings Bitlocker vorher zu stoppen, so daß der Fehler erst gar nicht auftritt.

Da freue ich mich auf 2025. 🙄

hakel2022 schrieb:

https://www.dell.com/support/kbdoc/de-de/000134415/aktualisieren-des-bios-auf-dell-systemen-mit-bitlocker-aktiviert

Man könnte ja auch einfach mal bei Dell nachlesen. Da steht alles drin ... 👍

Ja, die Frage bleibt aber, welche Hinweise der Endanwender beim Einspielen des Firmwareupdates unter Linux diesbezüglich erhält. Wenn Dell dort z.B. im Rahmen des Firmwareupdates auf das Dokument verlinkt oder besser neben der üblichen Warnung, dass das Laptop am Strom hängen muss und während des Updates die Stromzufuhr keinesfalls zu unterbrechen sei einen direkten Hinweis gibt, dass bei einem Dualboot mit Windows, das Firmware-Update besser von Windows einzuspielen sei, weil dann das Windows-Dell-Tool Bitlocker entsprechend konfigurieren kann, dann hätte Dell sein Schuldigkeit getan.

Fehlt dieser Hinweis aber, dann sollte Dell hier nachbessern und das wäre ja auch sehr leicht umsetzbar, da es sich um reine Informationsübermittlung handelt.

Der normale Endanwender kann von sich aus nicht wissen, dass es beim Einspielen des Firmwareupdates unter Linux zu Problemen bei Windows kommt.

Wenn ich das richtig verstehe, ist die Schleife ein Fehler von Dell. Das Dell Tool scheint allerdings Bitlocker vorher zu stoppen, so daß der Fehler erst gar nicht auftritt.

Ja entweder liegt der Fehler bei Dell oder bei Windows.

Für einen Latitude bezahlt man ja einen nicht unerheblichen Betrag. Da macht es IMO schon Sinn beim Hersteller mal zu meckern. Wenn sich keiner "beschwert" bzw. das Problem meldet, dann ändert sich auch nichts. Ist wie bei BUG-Medlungen. Melden ist dabei natürlich kein Gewähr für Beseitigung, aber deren Grundvoraussetzung.

Aber wie bereits erwähnt, ich weiß nicht, was ceag tatsächlich an Hinweisen vor dem Update bekommen hat. Ich kann mir aber sehr gut vorstellen, dass unter Linux der Bitlockerhinweis fehlt.

LG, Newubunti

Dell gibt ja zu, daß es mit gewissen Bios Versionen "Probleme" gibt. Der standardisierte Linux Dienst hat an dieser Stelle -MB mit Bitlocker- einen Nachteil. Ein Hersteller Tool ist da flexibler.

Natürlich ist das eine üble Geschichte 🐸 , ausgerechnet MB.

Hinweise der Endanwender beim Einspielen des Firmwareupdates

Meines Wissens ist 22.04 deutlich besser, vielleicht sind wir da jetzt ungerecht. MB würde ich immer auf unterer Ebene flashen.

hakel2022 schrieb:

Natürlich ist das eine üble Geschichte 🐸 , ausgerechnet MB.

Damit wir uns hier nicht missverstehen und falls "MB" hier für Main- oder Motherboard steht:

An dem Latitude ist durch das Firmware-Update von Linux aus kein MB-Schaden eingetreten! Wie von.wert schrieb:

Du hast aber den BitLocker-Key eingegeben, kommst also auf die Windows-Partitionen bzw. ins Windows. Disable BitLocker für jede Windows-Partition über Kontextmenu! Nicht ungeduldig werden, durchlaufen lassen! Für Vollständigkeit mußt Du rebooten.

Funktioniert das dann alles ohne BitLocker-Verschlüsselung, kannst Du, falls gewünscht, dann auch wieder über Rechtsklick BitLocker-verschlüsseln. Die Keys sind dann andere.

Das sollte dann zum Würgaround in der Regel reichen. Denn in dem Moment, wo sich die Keys von Bitlocker durch das Deaktivieren und Aktivieren ändern, werden dann die entsprechenden Register des TPM mit den neuen Infos gefüttert und damit auch der als ab dann geltende vertrauenswürdige Zustand des Gesamtsystems geändert. Und ab dann sollte auch nicht mehr bei jedem Neustart der Bitlocker-Wiederherstellungs-Schlüssel abgefragt werden.

Was hier aus irgendeinem Grund schief geht ist, dass der TPM-Chip die Änderung - neue Firmware wurde eingespielt, und das Einspielen wurde durch einmalige Eingabe des Bitlocker-Recovery-Keys durch den Endanwender legitmiert - nicht dauerhaft zu registrieren scheint, was eigentlich der Fall sein sollte. Ob das am TPM-Chip, selbst an der Firmware oder an Windows liegt - keine Ahnung. Es scheint hier wohl eher an "Dell" zu liegen, was nicht heißt, dass es ausschließlich auf Dell reduziert wäre.

hakel2022 schrieb:

Meines Wissens ist 22.04 deutlich besser,

Also für das erfolgreiche Erkennen des Einspielens von dbx-Updates - die wesentlich weniger risikoreich, wie Firmwareupdates sind - musste ich unter 22.04 auf einem Rechner kürzlich das stable Snap installieren. Die Version von Jammy aus den Paketquellen spielt das dbx-Update zwar sauber ein, ist aber nach einem Neustart der Meinung, dass das Einspielen gescheitert sei.

hakel2022 schrieb:

Da freue ich mich auf 2025.

Neuere Rechner sollten Capsule-Updates können. D.h. da spielt der Rechner das Firmwareupdate nach dem Neustart über eine entsprechende EFI-App ein. Da man EFI-Apps ja auch einfach über GRUB starten kann, lässt das hoffen, dass man die EFI-App aus den Herstellerpaketen notfalls extrahieren, dann über GRUB starten und so auch unabhängig von Windows einspielen können sollte. fwupd hat diesbezüglich die Unterstützung auch schon integriert. Wie gut das dann in der Praxis alles läuft, ist dann halt wieder eine andere Frage.

Wäre aber ein Fortschritt gegenüber den nur unter Windows laufenden Firmware-Update-Routinen.

Das Problem an dem fwupd und im übrigen auch alternative Firmware wie Coreboot scheitert ist, wie man die Funktionsfähigkeit der Routinen in der breiten Praxis testet. Denn während ich gar kein Problem habe, eine Distribution XY auf mein System zu spielen und Notfalls bei Fehlfunktion wieder von der Platte zu putzen, ist das bei einem Firmware-Update des MB halt dann nicht mehr - ohne extreme Anstrengunen - möglich und in der Regel habe ich dann bei Fehlfunktion ein mehr oder minder teures Dekoobjekt.

Deswegen ist meine Einstellung zu fwupd zwiegespalten. Eigentlich sehr unterstützenswert, nur wie kann man da die Qualität (mit) vorantreiben, ohne unter Umständen seine Hardware zu schrotten?

LG, Newubunti

Newubunti schrieb:

Fehlt dieser Hinweis aber, dann sollte Dell hier nachbessern

Ich bin ja nun kein Dell-Freund, aber was geht das Dell an?

Der Threadstarter hat fwupd verwendet und noch nicht mal direkt, sondern über die Ubuntu-Aktualisierungsverwaltung. Wenn überhaupt, beschwert Euch dort!

Das Dell Tool scheint allerdings Bitlocker vorher zu stoppen,

Wie's dabei bzgl. BL intern funktioniert, weiß ich nicht, aber ich habe eine zeitlang jeden Tag x Dell-Rechner geflasht - und Dell ist die einzige Fa., die wirklich auf permanent aktuelles UEFI dringt, was mir sehr entgegen kommt. In der Fa. ist auch über PXE vor der Installation und auch zusammen mit Windows- und sonstigen Updates vom lokalen Server geflasht worden.

Newubunti schrieb:

hakel2022 schrieb:

Da freue ich mich auf 2025.

Neuere Rechner sollten Capsule-Updates können.

(Davon abgesehen, daß sich hakel wahrscheinlich auf das Win10-EoS bezieht...) Das ändert aber nichts an der BitLocker-Problematik.

Das UEFI-Flashen an sich ist bei Dell wirklich gut gelöst mit 1 File unter Windows oder eben aus dem UEFI heraus, Zitat, "Dieses Dateiformat umfasst eine unter BIOS ausführbare Datei. Das universelle (Windows/MS-DOS) Format kann zur Installation aus jeder Windows oder MS DOS-Umgebung verwendet werden.""

"Das universelle (Windows/MS-DOS) Format"... 😀 "Unter BIOS ausführbar" ist das .exe-File auch nicht, es ist ein UEFI, das .exe-File ist ein Archiv (unter Windows selbstextrahierend und selbstausführend), das im UEFI einfach nur entpackt wird, damit der integrierte Flasher es laden kann.

Einfacher geht's nur bei HP (die ich derzeit täglich supporte, eine große Transition steht aber an), dessen Flasher im UEFI zieht und flasht automatisch das für das Modell aktuelle UEFI über LAN (mit DHCP) oder bei aktuellen zBooks auch über WLAN. Freilich geht das nur so. Eine bestimmte Version oder offline flashen scheitert daran, daß HP das nicht oder zumindest nicht ohne weiteres findbar zum manuellen Ziehen bereitstellt.

von.wert schrieb:

Newubunti schrieb:

Fehlt dieser Hinweis aber, dann sollte Dell hier nachbessern

Ich bin ja nun kein Dell-Freund, aber was geht das Dell an?

Von https://fwupd.org/:

The Linux Vendor Firmware Service is a secure portal which allows hardware vendors to upload firmware updates.

Wenn das Update von Dell auf LVFS bereitgestellt wird, dann tragen sie auch die Verantwortung dafür - meine bescheidene Meinung. Das soll übrigens gar kein Dell-Bashing sein, andere Hersteller machen sich da die Mühe erst gar nicht.

Der Threadstarter hat fwupd verwendet und noch nicht mal direkt, sondern über die Ubuntu-Aktualisierungsverwaltung. Wenn überhaupt, beschwert Euch dort!

Warum sollen die Macher von fwupd für den Inhalt der Updates gerade stehen müssen? Ob es bei einem Update etwas spezielles zu beachten gibt, weiß nun mal am besten der Hersteller. Und hier würde es wie schon erwähnt einfach nur - unter Umständen, falls er fehlen würde - eines informellen Hinweises bedürfen. Wie sollen die bei fwupd.org denn die Updates alle inhaltlich prüfen? Dazu bräuchten sie ja von jeder unterstützten Hardware ein Exemplar.

Also wenn es den von mir beschriebenen Mangel im Fall von ceag tatsächlich so geben sollte, dann wäre da Dell sehr wohl der richtige Adressat.

Den Machern von fwupd teile ich so Mängel mit, wie von mir im vorigen Post bezüglich der dbx-Updates beschrieben. Das liegt in deren Verantwortungsbereich. fwupd.org stellt die technische Infrastruktur und verantworten diese - und haben damit sicher genug zu tun. Die Updates an sich und deren inhaltliche Ausgestaltung ist dagegen Sache der Hersteller.

Ob das den Hersteller am Ende interessiert oder nicht, steht dann auf einem anderen Blatt und war und ist auch nicht der Punkt um den es mir ging.

LG, Newubunti

Hallo Experten,

ich darf mich für Eure aufschlussreichen Beiträge herzlich bedanken.

Dieser Befehl zum Firmware-Update war mir gar nicht bekannt, eure Empfehlung, die Firmware-Updates wegen der möglichen Konflikte mit den Sicherheitsfunktionen besser im Windows zu machen, leuchtet mir ein.

Windows 10 ist mir an sich nur wegen der nach meiner Erfahrung stabileren Online-Konferenzen wichtig, ansonsten brauche ich das selten. Ich habe ein gemeinsames Laufwerk für den Datenaustausch mit Kubuntu, dort und bei den externen LW hatte ich Bitlocker schon immer AUS.

Nun hatte ich wieder den lästigen langen Code in Windows eingegeben und das anstehende Dell Firmwareupdate dort ausgeführt. Danach ging Windows genau einmal auf die normale Art neu starten, ich habe gesehen, dass während des Update offenbar Bitlocker vorübergehend ausgesetzt wird, was dann offenbar genau noch einen normalen Start ermöglicht, bevor das wieder aktiv wird.

Ich hab dann auch für Laufwerk C: Bitlocker AUS gestellt, seit dem ist das Problem weg, ich kann wieder Kubuntu und Windows wechselweise normal verwenden. Die Informationen über TPM haben mich zusätzlich sensibilisiert, ich hatte das bisher nicht groß beachtet, für Laien ist es auch nicht so einfach zu verstehen, was das genau macht.

Was die Ubuntu-Unterstützung durch Dell betrifft gibt es verschiedene Meinungen, ich kann nur sagen, dass der Dell der einzige Hersteller ist/war, der in seinen normalen Hilfeseiten diese genaue Anweisung zum Hinzuinstallieren von Ubuntu zu Windows 10 gibt und dass man es damit als unerfahrener Anwender schaffen kann.

Die nicht Geräte-spezifischen Grundsatzartikel zum Thema Linux/Windows-Dualboot unter EFI usw., die man hier in den Wikis und sonstwo findet, sind vermutlich gut, zeigen aber sofort die volle Komplexität auf und sind daher für unbedarfte Benutzer leider vor allem abschreckend. Ein Hauptproblem ist schon, dass dieses EFI anscheinend bei jedem Hersteller anders aussieht und mit anderen Begriffen verwirrt.

Gruß

Stefan

ceag schrieb:

Dell der einzige Hersteller ist/war, der in seinen normalen Hilfeseiten

Sieh genau hin! Auch, wenn es unter Dells Domain liegt, das ist nicht Dell, sondern die "Dell Community". Das ist Absicht, schon rechtlich.