Probleme mit Debian nach Windows 11 Update

[HansHiasl]

Hallo Gemeinde
Gestern hab ich auf meinem Dualboot-PC mit Windows 11 und Debian 13 ein Update von Windows 11 laufen Lassen.
Das hat dazu geführt, dass der UEFI-Booteintrag für Windows im PC-Bios ganz nach ober geschoben wurde, wo normalerweise der Grub-Bootmanager steht und geladen werden sollte.
Es startet also Windows automatisch und nicht der Grub-Bootmanager. Ich hab einfach den Windows-Eintrag im Bios wieder eine Zeile nach unter gerückt, so dass jetzt Grub wieder automatisch geladen wird. Meine Frage hierzu: Kann man das verhindern, dass Windows Booteintrage im Bios verschiebt?
Ist das hier überhaupt das passende Forum für diese Frage?


Das nächste Problem ist, dass seit diesem Windows-Update, wenn ich aus dem Grub-Menü heraus Debian 13 starte, viele Meldungen auftauchen mit folgendem (oder fast identischem) Inhalt:
"Scanning for Btrfs filesystems" "blkid: -t needs NAME=value pair" "Begin: Waiting for suspend/resume device ... Begin: Running /scripts/local-block ....mdadm: No arrys foung in config file or... done".
Es dauert dann ca. 30 Sekunden und Debian startet ganz normal.
Woran liegt das? Da diese Verhalten erst seit dem Windows-Update auftritt, gehe ich davon aus, dass Windows auch in die Debian-Installation reinpfuscht?
Kennt jemand von Euch diese Verhalten und wie kann ich es beheben und dann verhindern?

[pcdoc]

Meine Frage hierzu: Kann man das verhindern, dass Windows Booteintrage im Bios verschiebt?

So viel ich weiß leider nicht. Das einzige wäre auf Windows ganz zu verzichten oder über eine VM zu verwenden (wenn das für deine Ansprüche möglich ist).

Ist das hier überhaupt das passende Forum für diese Frage?

Kann ich mir nicht vorstellen.

Das nächste Problem ist, dass seit diesem Windows-Update, wenn ich aus dem Grub-Menü heraus Debian 13 starte, viele Meldungen auftauchen mit folgendem (oder fast identischem) Inhalt:
"Scanning for Btrfs filesystems" "blkid: -t needs NAME=value pair" "Begin: Waiting for suspend/resume device ... Begin: Running /scripts/local-block ....mdadm: No arrys foung in config file or... done".
Es dauert dann ca. 30 Sekunden und Debian startet ganz normal.
Woran liegt das? Da diese Verhalten erst seit dem Windows-Update auftritt, gehe ich davon aus, dass Windows auch in die Debian-Installation reinpfuscht?
Kennt jemand von Euch diese Verhalten und wie kann ich es beheben und dann verhindern?

Dazu kann ich dir leider nichts konkretes sagen, aber du solltest auf jeden Fall mal ein Grub repair starten. Normal macht man das von einer Live-Version, aber wenn du noch rein kommst kannst du das auch direkt aus Debian heraus machen:

sudo apt-get install --reinstall grub-efi [sollte nicht nötig sein, schadet aber auch nichts]
sudo update-grub

Danach neu starten.

Was du auch noch versuchen kannst ist eine manuelle Überprüfung vom Dateisystem anstoßen. Das musst du allerdings von einer Live Session aus machen, da das Laufwerk nicht gemountet sein darf:

btrfsck /dev/sda1

"sda1" bitte mit der richtigen Partition ersetzen.

[HansHiasl]

Hab vergessen zu erwähnen, dass auf der gesamten SSD keinerlei Btrfs ist.

[MSfree]

Hab vergessen zu erwähnen, dass auf der gesamten SSD keinerlei Btrfs ist.

Das hatte ich beim Lesen des Eingangsposts schon fast vermutet, danke für die Bestätigung.

Kann es sein, daß dein Linux beim Booten versucht, das NTFS-Dateisystem deines Windows zu mounten?
Das geht grob schief, wenn Windows nicht sauber runtergefahren wurde, also praktisch immer. Denn Windows läßt sich nur unter bestimmten Voraussetzungen sauber runterfahren, normalerweise geht Windows in Suspend-to-Disk.

Vermutlich erkennt Linux die nicht sauber runtergefahrene NTFS-Partition als btrfs.

[HansHiasl]

Hallo
"Suspend To Disk" habe ich bereits abgeschaltet. powerconfig /hibernate off
Hab ich gestern auch nochmal kontrolliert.
Ich schau mal, ob man am Debian irgendwo einstellen kann, dass nur die relevanten Partitionen gemountet werden.
Bei mir wären das in der aktuellen Konfiguration:
/dev/nvme0n1p4 als Root /
/dev/nvme0n1p5 als Home /home
/dev/nvme0n1p6 als Swap
/dev/nvme0n1p7 als EFI /boot/efi

/dev/nvme0n1p1 gehört zu Windows (EFI-Partition)
/dev/nvme0n1p2 gehört zu Windows (NTFS-Partition)
/dev/nvme0n1p3 gehört zu Windows (Wiedergerstellungspartition)

Ich habe zwei EFI-Partitionen, weil Debian bei der Installation mindesten 300 MB fordert, die Windows-EFI aber nur 250 MB hat.
Und die 250 MB mit GParted zu vergrößern war mir dann doch zu heikel.

Da fällt mir noch was ein.
Würde es etwas helfen, wenn ich beim Grub-Update bzw. beim Erstellen der grub-mkcofig os-prober abschalte?
Im Prinzip brauche ich den Windows-Eintrag im Grub-Bootmenü gar nicht, weil ich das im Falle des Falles, dass ich Windows verwende (eher selten) das Bios-Bootmenü eh auswählen kann.

[MSfree]

Ich schau mal, ob man am Debian irgendwo einstellen kann, dass nur die relevanten Partitionen gemountet werden.

Die beim Booten zu mountenden Partitionen stehen in der Datei /etc/fstab.

Ich habe zwei EFI-Partitionen, weil Debian bei der Installation mindesten 300 MB fordert, die Windows-EFI aber nur 250 MB hat.

Debian installiert in die EFI-Partition Daten im Umfang von ca. 6MB. Meine Systeme haben in der Regel auch nur eine 50MB kleine EFI-Partition. Da es eine FAT32 formatierte Partition sein muß, muß diese auch meines Wissens mindestens 32MB groß sein, sonst wird automatisch FAT16 verwendet. Wenn man bei noch kleineren Partitionen als 32MB FAT32 erzwingen will, muß man das zu Fuß auf der Kommandozeile machen.

Jendefalls "fordert" Debian definitiv keine 300MB. Der Installer setzt einen Standardwert von 500MB, was aber kein Zwang ist.

Will man allerdings über systemd statt grub booten, wird der Linuxkernel samt der initial RAM-Disk auf die EFI-Partition installiert, so daß in diesem Fall 500MB durchaus sinnvoll sind, um mindestens zwei Kernel (der aktuelle und den vorherigen als Reserve falls der aktuelle nicht bootet) und initrd speichern zu können.

[kreuzschnabel]

Jendefalls "fordert" Debian definitiv keine 300MB. Der Installer setzt einen Standardwert von 500MB, was aber kein Zwang ist.

Vielleicht eine Verwechslung: Kubuntu weigert sich zu installieren, wenn die ESP kleiner als 300 MB ist. Warum auch immer.

--ks

[HansHiasl]

Hallo
Ich habe jetzt zumindest den zweiten Teil meiner Frage ganz am Anfang lösen können.
Ich habe das brtfs-Paket entfernt. Brauch ich nicht.
Ich habe das mdadm-Paket entfernt. Brauch ich nicht.
Führte aber beides nicht zum Erfolg.
"blkid: -t needs NAME=value pair" war immer noch da.
Da ich blkid in Zusammenhang mit Partitionen gebracht habe, habe ich den Swap-Eintrag in der fstab vermutet. Diese Partition war mit /dev/nvmexxxx eingetragen. Das hab ich dann in UUID= xxxxxxx geändert. "blkid: -t needs NAME=value pair" War immer noch da.
Zwischendurch hab ich immer Grub geupdatet.
Zuguterletzt hab ich die initramfs neu erstellt. Und das hat geholfen.
Jetzt ist "blkid: -t needs NAME=value pair" endlich weg und das System startet endlich wieder wie es soll. Vermutlich hab ich da einen Fehler gemacht, als ich die Swap- Partition eingerichtet habe und das Windows Update war gar nicht schuld.
Die relativ neue „Suchmaschine“ Perplexity.ai hat mir am Ende die richtigen Antworten geliefert.
Das Ding kann ich jedem nur wärmstens ans Herz legen. Ist genial!