[Gelöst] Debian Buster: Kann primärer Partition keinen Boot-Flag zuweisen

[prox]

Update:

In meinem BIOS gibt es eine Option, die nennt sich "Select an UEFI file as" (keine Angabe dahinter).

Die Option "Secure Boot" ist "disabled". Ich nehme an, wenn ich diese Option auf "enabled" setzen würde, würde Debian Stretch nicht mehr booten.

"CMS/Legacy" habe ich dort nicht gefunden. Ist das das Gleiche wie "Secure Boot"?

[willy4711]

Da du wahrscheinlich ein Gerät mit UEFI hast (so alt wird die Kiste ja nicht sein), installiere unter UEFI und GPT (moderner und gegenüber MBR vorteilhaft, z. B. 128 primäre Partitionen), CSM als Zusatzmodul macht UEFI nur noch komplexer und ist für Debian unnötig. Damit nichts schief geht, schalte CSM/Legacy im BIOS ab oder wähle in der Bootreihenfolge mit Bedacht das zu bootende Image. Während der Suche nach entsprechenden BIOS-Einstellungen bzw. Bootreihenfolge bei Hybrid-Installationsimages (doppelt angezeigt bei aktivem CSM) wirst schon du merken, ob die Kiste UEFI hat.

Es ist aber schon klar, das eine Installation (BIOS- Modus) besteht, und auf einer weiteren Partition noch eine Installation angelegt werden soll?
Die Anzahl der Partitionen ist auch nicht vom UEFI abhängig sondern von der Partitions Tabelle (hier GPT)

Liest eigentlich jemand was ich geschrieben Habe ? Wohl nicht.

Von einer Neuinstallation war nie die Rede. Wie soll man dann bei einer Festplatte von einer BIOS Installation auf UEFI umschalten ???

Ich hab keine Bock auf so was. Macht mal weiter.

[jessie]

Macht doch einfach was ihr wollt, für richtig erachtet ... zu lange Threads nerven ... zumal alles geschrieben wurde.
Ach Willi: Sei doch nicht böse! Wird schon wieder - mit uns und anderen - irgendwann.

[prox]

Ich werde gleich mal die Hinweise von @willy4711's letztem Beitrag umsetzen. Bin dann erst mal nicht mehr online hier.

[jessie]

Schön! Dann brauche ich wenigstens nicht mehr umsonst für Legastheniker schreiben ...

[prox]

Schön! Dann brauche ich wenigstens nicht mehr umsonst schreiben ...

Wieso das? Du schreibst doch gar nicht umsonst. Ich habe das BIOS überprüft, und für mich spricht nichts gegen eine Installation von Debian Buster mit KDE in /dev/sda4. Den Bootloader schreibe ich ja nicht neu während der Installation, weil ich ja bei der Installation nicht Grub in Debian Buster installieren werde.

[jessie]

Na dann ist doch alles klar. Sorry - manche Threads nerven einach - dann schreitet man/frau ein. Kannste gern anders sehen und mir ist vieles mittlerweile auch recht egal - einfach nur Hilfe/Abkürzung - wenn Threads zu offenbar sinnlos/endlos werden. Im vorherigen Beitrag habe ich alles Notwendige geschrieben. Mache was draus oder nicht- an noch X Seiten Thread habe ich Null Interesse - zumal wenn ein Debian-Installer von Debian-Experten für jedermann (mit und ohne Ahnung) bereit gestellt wurde. Aus etlichen, leicht absehbaren Ewig-Lang-Threads werde ich mich künftitg raushalten. Danke für entsprechendes Verständnis.

Mit etwas Intelligenz und Suchvermögen wird man hier und ohne Willis Halbwissen bezüglich GPT und UEFI fündig: https://wiki.debianforum.de/Installation_von_Debian
Nach noch X Seiten Thread wegen eines unbenötigten Flags schreibt eh kein Anderer mehr was Vernünftiges.

[prox]

Moin,

die Installation von Debian Buster (Version 10) in /dev/sda4 mit KDE war erfolgreich. Bei der Installation habe ich auf die Frage, ob Grub installiert werden soll, mit "Nein" geantwortet. im nächsten Fenster des Installationsprogramms wurde ich trotzdem gefragt, wo der MBR geschrieben werden soll. Habe /dev/sda (dessen Herstellerbezeichnung) angegeben. Eine andere Antwortmöglichkeit außer "Gerät per Hand angeben" gab es nicht.

Nach der Installation habe ich Debian Stretch (Version 9) gestartet und dort "update-grub" ausgeführt => dieser Befehl erkennt das neu installierte Debian Buster und erstellt einen entsprechenden Booteintrag.

Allerdings verhält sich Debian Stretch (Version 9) beim Booten jetzt anders als bisher:

Nach der Auswahl von Debian Stretch im Bootmanager blinkt der Cursor ne Weile, ohne dass irgendwas auf dem Bildschirm angezeigt wird. Dann erscheint die Meldung "Gave up waiting for suspend/resume device". Danach erkennt der Rechner irgendwelche Partitionen (was bisher auf der Fall war), führt einen Dateisystemcheck durch und gibt dann erst mal für ne Weile nichts aus.

Dann erscheint die Meldung:

"A start job is running for dev-disk-by-<Zeichenkolonne>.device (Rechner zählt hoch bis 1 Min 30 Sekunden)"

Danach gibt Debian eine Time-Out-Meldung aus und fährt dann wie gewohnt hoch.

Dieses Verhalten tritt jetzt bei jedem Start von Debian Stretch auf. Der Startvorgang verzögert sich deswegen in einer nicht unbeträchtlichen Weise.

Hat jemand ne Idee, wie dieses Verhalten behoben werden kann?

Nachtrag: Soll ich die Ausgabe von dmesg hier einstellen, im NoPaste-Bereich?

[jph]

Allerdings verhält sich Debian Stretch (Version 9) beim Booten jetzt anders als bisher:

Nach der Auswahl von Debian Stretch im Bootmanager blinkt der Cursor ne Weile, ohne dass irgendwas auf dem Bildschirm angezeigt wird. Dann erscheint die Meldung "Gave up waiting for suspend/resume device". Danach erkennt der Rechner irgendwelche Partitionen (was bisher auf der Fall war), führt einen Dateisystemcheck durch und gibt dann erst mal für ne Weile nichts aus.

Wahrscheinlich hast du bei der Installation von Debian 10 die vorhandene und bereits von Debian 9 verwendete Swap-Partition angegeben (ich lese jetzt nicht den ganzen Thread durch). Deren UUID hat sich in dem Zuge möglicherweise verändert. Abhilfe findest du im Wiki (Grub reparieren unter „Booten dauert lange“).

[prox]

Wahrscheinlich hast du bei der Installation von Debian 10 die vorhandene und bereits von Debian 9 verwendete Swap-Partition angegeben

Jupp. Stimmt.

Deren UUID hat sich in dem Zuge möglicherweise verändert.

Ja, das stimmt, denn in der /etc/initramfs-tools/conf.d/resume stand eine andere UUID drin als der Befehl blkid mir für die Swap-Partition jetzt ausgibt:

Code: Alles auswählen

root@punk:/home/xxx# blkid
/dev/sda1: LABEL="ROOT" UUID="ba46a922-b60a-42ef-952b-6d9867fdd0ee" TYPE="ext4" PARTUUID="372a3071-b630-4ad4-bc7d-399f0358227d"
/dev/sda2: LABEL="BOOT" UUID="7b930433-f409-411f-bab5-5815207fd8b7" TYPE="ext4" PARTUUID="9be5fd79-e36c-4283-9f41-f485dc5f15a0"
/dev/sda3: LABEL="HOME" UUID="87f61bf7-66c2-4116-87b3-fed862d733dc" TYPE="ext4" PARTUUID="795d9e6a-9947-4ac5-a90b-2285e584abcd"
/dev/sda4: LABEL="DEBIAN_BUSTER" UUID="8cdcd293-4ae3-4a7c-a43d-cf54cbcc8b4b" TYPE="ext4" PARTLABEL="DEBIAN_TEST" PARTUUID="3107e5ed-3376-4b83-8bb4-224ce2376ba9"
/dev/sda5: LABEL="TMP" UUID="a4dea4f9-58d7-4552-9e0b-610821d3d0cc" TYPE="ext4" PARTUUID="e856b25e-2c65-4793-86c2-5c1e2a64bd9a"
/dev/sda6: LABEL="USR" UUID="1114fb0e-2d0e-457d-aadb-0ca2d8021469" TYPE="ext4" PARTUUID="bc9a683f-3d39-4467-a4cf-5a7f28b27547"
/dev/sda7: LABEL="VAR" UUID="7f1673e4-b435-4414-bb4a-0f176c9009be" TYPE="ext4" PARTUUID="27a84384-95e9-481d-b278-f0320168fa21"
/dev/sda8: UUID="ffa786a2-8e4a-4753-b74d-985323d78af9" TYPE="swap" PARTUUID="819f6397-fa60-43e3-afd9-01b20f600c05"
/dev/sda9: LABEL="OPT" UUID="fb7e5e46-a3e9-47ec-958e-231c230414bb" TYPE="ext4" PARTUUID="c5e5bd8f-184d-47e5-ade7-9d14eafa9a97"
root@punk:/home/xxx#

=> /dev/sda8 ist die swap-Partition.

Die ermittelte UUID habe ich in die /etc/initramfs-tools/conf.d/resume eingetragen. Jetzt steht in ihr drin:

root@punk:/home/xxx# cat /etc/initramfs-tools/conf.d/resume
RESUME=ffa786a2-8e4a-4753-b74d-985323d78af9
root@punk:/home/xxx#

Der Befehl "update-initramfs -u -k all" gibt aber merkwürdigerweise das hier aus:

root@punk:/home/xxx# vi /etc/initramfs-tools/conf.d/resume
root@punk:/home/xxx# update-initramfs -u -k all
update-initramfs: Generating /boot/initrd.img-4.9.0-9-amd64
W: initramfs-tools configuration sets RESUME=ffa786a2-8e4a-4753-b74d-985323d78af9
W: but no matching swap device is available.
I: The initramfs will attempt to resume from /dev/sda8
I: (UUID=ffa786a2-8e4a-4753-b74d-985323d78af9)
I: Set the RESUME variable to override this.
update-initramfs: Generating /boot/initrd.img-4.9.0-8-amd64
W: initramfs-tools configuration sets RESUME=ffa786a2-8e4a-4753-b74d-985323d78af9
W: but no matching swap device is available.
I: The initramfs will attempt to resume from /dev/sda8
I: (UUID=ffa786a2-8e4a-4753-b74d-985323d78af9)
I: Set the RESUME variable to override this.
root@punk:/home/xxx#

Abhilfe findest du im Wiki (Grub reparieren unter „Booten dauert lange“).

Vielen Dank für Deinen Hinweis. Dein Tipp hat dazu geführt, dass zumindest die Meldung "Gave up waiting for suspend/resume device" beim Booten nicht mehr erscheint. Die Meldung

"A start job is running for dev-disk-by-<Zeichenkolonne>.device (Rechner zählt hoch bis 1 Min 30 Sekunden)"

erscheint jedoch immer noch, danach wird irgendein in gelber Schrift gehaltener Startstatus in Bezug auf Swap ausgegeben (konnte ich nicht genau lesen, weil zu schnell andere Bootmeldungen danach ausgegeben wurden).

Da fällt mir ein, in der /etc/fstab könnte die alte UUID für die swap-Partition noch drinstehen. Und ja, da steht sie noch drin, ich habe jetzt die alte UUID gegen die neue UUID ffa786a2-8e4a-4753-b74d-985323d78af9 ersetzt, führe noch mal "update-initramfs -u -k all" aus und mache dann einen Reboot. Berichte danach.

[prox]

Der Neustart war erfolgreich. Die Meldung

"A start job is running for dev-disk-by-<Zeichenkolonne>.device (Rechner zählt hoch bis 1 Min 30 Sekunden)"

erscheint nicht mehr. Debian Stretch startet jetzt in gewohnter Weise.

Soll ich diesen Thread jetzt auf [Gelöst] im Thread-Titel setzen?

[willy4711]

J

Soll ich diesen Thread jetzt auf [Gelöst] im Thread-Titel setzen?

Kannst du machen.
Ich würde aber gerne noch wissen, ob du nun auf deinem neuen System (/dev/sda4) nun Grub hast oder nicht.
Kann man leicht überprüfen, indem man in
/boot/ nachschaut, ob es da /boot/grub gibt.
Wie gesagt, wenn auf beiden Partitionen Grub und eventuell noch os-prober "wüten" kann es Probleme geben,
wenn mal ein Update von Grub kommen sollte.
Wie ich das verstehe, hast du nun Stretch und Buster installiert. Bei Stretch (jetzt Old-Stable) werden wohl kaum
noch Updates kommen. Tendenziell würde ich Grub dann auf dem alten System lassen.

[prox]

Ich würde aber gerne noch wissen, ob du nun auf deinem neuen System (/dev/sda4) nun Grub hast oder nicht.
Kann man leicht überprüfen, indem man in
/boot/ nachschaut, ob es da /boot/grub gibt.

Hier Info darüber:

Code: Alles auswählen

xxx@punk:/boot/grub$ ls
grub.cfg  unicode.pf2
xxx@punk:/boot/grub$ cat /etc/debian_version 
10.0
xxx@punk:/boot/grub$

Wie gesagt, wenn auf beiden Partitionen Grub und eventuell noch os-prober "wüten" kann es Probleme geben,
wenn mal ein Update von Grub kommen sollte.

Erfahrungsgemäß ändert sich im Grub-Bootloader nur die Reihenfolge der bootbaren Betriebssysteme. Und dasjenige BS, das per Default automatisch startet, ändert sich in das BS, in dem aufgrund eines Kernelupdates zuletzt update-grub ausgeführt wurde.

Wie ich das verstehe, hast du nun Stretch und Buster installiert. Bei Stretch (jetzt Old-Stable) werden wohl kaum
noch Updates kommen. Tendenziell würde ich Grub dann auf dem alten System lassen.

Ich glaube, da kommen noch genügend Updates für Stretch bis Juni 2020. So was das jedenfalls der Fall mit den jeweiligen oldstable-Versionen, die ich bisher benutze, bis keine Updates mehr erschienen. Ich mache den Upgrade von oldstable auf stable eigentlich immer erst dann, wenn das End of Life des oldstable Releases erreicht ist.

[prox]

Komisch, ich dachte, ich hätte diesen Thread auf "[Gelöst]" gesetzt ... gut, dann mache ich das dann (noch) mal in der Threadüberschrift.