Frieder108
Anmeldungsdatum: 7. März 2010
Beiträge: 8989
|
Guten Morgen, Folgendes Problem: auf einem Multiboot mit 18.04 als "Hauptsystem laufen mehrere Linuxe → seit einer Testinstallation von Debian 10 "spinnt" mein Bootloader. Das zeigt sich in einer sehr langen Bootzeit Jetzt hab ich das Debian durch 19.10 ersetzt - installiert wurde ohne Bootloader (ubiquity -b). Ein update-grub zeigt 19.10 auch an, beim Booten taucht es allerdings nicht im Menü auf.
:~$ sudo update-grub
Sourcing file `/etc/default/grub'
GRUB-Konfigurationsdatei wird erstellt …
Linux-Abbild gefunden: /boot/vmlinuz-5.0.0-31-generic
initrd-Abbild gefunden: /boot/initrd.img-5.0.0-31-generic
Linux-Abbild gefunden: /boot/vmlinuz-5.0.0-29-generic
initrd-Abbild gefunden: /boot/initrd.img-5.0.0-29-generic
Found memtest86+ image: /boot/memtest86+.elf
Found memtest86+ image: /boot/memtest86+.bin
Windows 7 auf /dev/sda1 gefunden
Ubuntu Eoan Ermine (development branch) (19.10) auf /dev/sda10 gefunden
Windows 7 auf /dev/sda2 gefunden
Ubuntu 19.04 (19.04) auf /dev/sda9 gefunden
erledigt ~$ systemd-analyze time
Startup finished in 5.196s (kernel) + 3min 577ms (userspace) = 3min 5.774s
graphical.target reached after 1min 36.884s in userspace Wenn man sich die grub.cfg anschaut, wird einem schwindlig - da sind endlos viele Einträge drin, die da so definitv nicht reingehören. Was ich versucht habe, ist Grub 2 zu löschen und neu installieren, das hat aber keine Änderung gebracht → jetzt ist die Idee, den gesamten MBR mittels dd zu löschen und Grub erneut installieren, ich weiß aber nicht so recht, wo ich da ansetzen muss, bzw., ich trau mich nicht so richtig.
~$ sudo fdisk -lu
Festplatte /dev/sda: 931,5 GiB, 1000204886016 Bytes, 1953525168 Sektoren
Einheiten: Sektoren von 1 * 512 = 512 Bytes
Sektorgröße (logisch/physikalisch): 512 Bytes / 512 Bytes
E/A-Größe (minimal/optimal): 512 Bytes / 512 Bytes
Festplattenbezeichnungstyp: dos
Festplattenbezeichner: 0x9326945c
Gerät Boot Anfang Ende Sektoren Größe Kn Typ
/dev/sda1 * 2048 206847 204800 100M 7 HPFS/NTFS/exFAT
/dev/sda2 206848 422803455 422596608 201,5G 7 HPFS/NTFS/exFAT
/dev/sda3 422805502 1953523711 1530718210 729,9G 5 Erweiterte
/dev/sda5 422805504 1692334079 1269528576 605,4G 83 Linux
/dev/sda6 1692336128 1750927359 58591232 28G 83 Linux
/dev/sda7 1750929408 1767528447 16599040 7,9G 82 Linux Swap / Solaris
/dev/sda8 1767530496 1865185279 97654784 46,6G 83 Linux
/dev/sda9 1865187328 1914462207 49274880 23,5G 83 Linux
/dev/sda10 1914464256 1953523711 39059456 18,6G 83 Linux Oder würde es reichen, einfach mal den Inhalt der grub.cfg manuell zu löschen und danach ein update-grub laufen zu lassen? nachfragende Grüße Frieder Nachtrag: bevor ich es vergesse - ein Abschalten von os-prober + manueller Eintrag in etc/grub.d/40_custom geht leider auch nicht → die manuellen Einträge werden ignoriert.
|
black_tencate
Anmeldungsdatum: 27. März 2007
Beiträge: 10955
|
Hej Frieder108, Frieder108 schrieb: ...
Wenn man sich die grub.cfg anschaut, wird einem schwindlig - da sind endlos viele Einträge drin, die da so definitv nicht reingehören.
"menuentry 'Ubuntu Eoan Ermine (development branch) (19.10) (auf /dev/sda10) (auf /dev/sda9) (auf /dev/sda6) (auf /dev/sda9) (auf /dev/sda6) (auf /dev/sda9)'..." so etwas hatten wir hier schon mal, finde es aber auf die Schnelle nicht und erinnere auch die damalige Lösung nicht Was ich versucht habe, ist Grub 2 zu löschen und neu installieren, das hat aber keine Änderung gebracht → jetzt ist die Idee, den gesamten MBR mittels dd zu löschen und Grub erneut installieren, ich weiß aber nicht so recht, wo ich da ansetzen muss, bzw., ich trau mich nicht so richtig.
Du mußt nicht mit dd in den ersten Sektoren "rumrühren", Du kannst auch einfach grub mittels GRUB 2/Reparatur (Abschnitt „Root-Directory-Methode“) reparieren, dabei werden die ersten Sektoren auch neu geschrieben.
Nachtrag: bevor ich es vergesse - ein Abschalten von os-prober + manueller Eintrag in etc/grub.d/40_custom geht leider auch nicht → die manuellen Einträge werden ignoriert.
sehr suspekt, aber das ist u.a. ein Grund, warum ich von der ganzen Skripterei nichts halte Gruß black tencate
|
TK87
Anmeldungsdatum: 8. Juli 2019
Beiträge: 216
Wohnort: Aachen
|
Frieder108 schrieb: jetzt ist die Idee, den gesamten MBR mittels dd zu löschen und Grub erneut installieren, ich weiß aber nicht so recht, wo ich da ansetzen muss, bzw., ich trau mich nicht so richtig.
Ein einfaches
überschreibt den kompletten MBR. Den vorher noch mit dd zu überschreiben wäre nur doppelt gemoppelt. Oder würde es reichen, einfach mal den Inhalt der grub.cfg manuell zu löschen und danach ein update-grub laufen zu lassen?
Die grub.cfg wird ja durch update-grub erst erzeugt. Du kannst sie also natürlich löschen... ich bezweifel allerdings, dass du nach einem anschließenden update-grub einen anderen Inhalt vorfindest.
menuentry 'Debian GNU/Linux 10 (buster) (auf /dev/sda10) (auf /dev/sda6) (auf /dev/sda9) (auf /dev/sda6) (auf /dev/sda9)' --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-/vmlinuz--
menuentry 'Ubuntu Eoan Ermine (development branch) (19.10) (auf /dev/sda10) (auf /dev/sda9) (auf /dev/sda6) (auf /dev/sda9) (auf /dev/sda6) (auf /dev/sda9)' --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-/vmlinuz--5
Du sagtest, du hast Debian durch Ubuntu ersetzt, da sind aber defitiv noch Fragmente des Debianbootloaders vorhanden. Ich nehme an /dev/sda1 ist eine seperate Boot-Partition?! Vermutlich liegt das Problem eher dort. Wie sieht der Inhalt aus?
|
Frieder108
(Themenstarter)
Anmeldungsdatum: 7. März 2010
Beiträge: 8989
|
Hi, black_tencate schrieb: … Du kannst auch einfach grub mittels GRUB 2/Reparatur (Abschnitt „Root-Directory-Methode“) reparieren, dabei werden die ersten Sektoren auch neu geschrieben.
das ändert leider auch nichts - das Chaos in der grub.cfg bleibt erhalten ☺ Wie erwähnt, m.E. war Debian, bzw., der Debian-Installer, der Übeltäter - aber frag mich nicht, wie das passieren konnte. Normalerweise darf bei einer Installation ohne Grub ja nichts geschrieben werden irgendwie wurde aber etwas geschrieben. Der einzige Schnittpunkt ist, soweit ich das einschätzen kann, der MBR und da ich die "üblichen Methoden" bereits alle durch habe, fällt mir nix besseres dazu ein. Das verrückte ist ja, dass update-grub zwar korrekt wiedergegeben wird
frieder@T420:~$ sudo update-grub
[sudo] Passwort für frieder:
Sourcing file `/etc/default/grub'
GRUB-Konfigurationsdatei wird erstellt …
Linux-Abbild gefunden: /boot/vmlinuz-5.0.0-31-generic
initrd-Abbild gefunden: /boot/initrd.img-5.0.0-31-generic
Linux-Abbild gefunden: /boot/vmlinuz-5.0.0-29-generic
initrd-Abbild gefunden: /boot/initrd.img-5.0.0-29-generic
Found memtest86+ image: /boot/memtest86+.elf
Found memtest86+ image: /boot/memtest86+.bin
Windows 7 auf /dev/sda1 gefunden
Ubuntu Eoan Ermine (development branch) (19.10) auf /dev/sda10 gefunden
Windows 7 auf /dev/sda2 gefunden
Ubuntu 19.04 (19.04) auf /dev/sda9 gefunden
erledigt
frieder@T420:~$
aber so nicht in die grub.cfg geschrieben wird. Frage: wenn ich den MBR löschen will, reicht da dann ein
dd if=/dev/zero of=/dev/sda bs=1 count=446
oder löscht mir das die gesamte Festplatte? TK87 schrieb: Frieder108 schrieb: jetzt ist die Idee, den gesamten MBR mittels dd zu löschen und Grub erneut installieren, ich weiß aber nicht so recht, wo ich da ansetzen muss, bzw., ich trau mich nicht so richtig.
Ein einfaches
überschreibt den kompletten MBR.
das ist aber genau das, was nicht funktioniert Zum Verständniss
~$ sudo parted -l
Modell: ATA Samsung SSD 850 (scsi)
Festplatte /dev/sda: 1000GB
Sektorgröße (logisch/physisch): 512B/512B
Partitionstabelle: msdos
Disk-Flags:
Nummer Anfang Ende Größe Typ Dateisystem Flags
1 1049kB 106MB 105MB primary ntfs boot #Windows-Recovery
2 106MB 216GB 216GB primary ntfs #Windows
3 216GB 1000GB 784GB extended
5 216GB 866GB 650GB logical ext4 #Daten
6 866GB 896GB 30,0GB logical ext4 #18.04 System
7 896GB 905GB 8499MB logical linux-swap(v1)
8 905GB 955GB 50,0GB logical ext4 #18.04 Home
9 955GB 980GB 25,2GB logical ext4 #19.04
10 980GB 1000GB 20,0GB logical ext4 #19.10 - hier war vorher das Debian
|
TK87
Anmeldungsdatum: 8. Juli 2019
Beiträge: 216
Wohnort: Aachen
|
Frieder108 schrieb: Frage: wenn ich den MBR löschen will, reicht da dann ein
dd if=/dev/zero of=/dev/sda bs=1 count=446
oder löscht mir das die gesamte Festplatte?
Jup, das löscht die komplette Festplatte. Den MBR löschen geht so
| dd if=/dev/zero of=/dev/sda bs=512 count=1
|
|
Frieder108
(Themenstarter)
Anmeldungsdatum: 7. März 2010
Beiträge: 8989
|
TK87 schrieb: Den MBR löschen geht so
| dd if=/dev/zero of=/dev/sda bs=512 count=1
|
upps - Danke schön 👍 Dann aktualisiere ich jetzt mal meine Datensicherung und erstelle noch ein Livesystem mit 18.04 - man weiß ja nie. Und ja, vielleicht hat ja noch jemand eine Idee, wie ich mir das mit dem dd doch noch ersparen kann - vor dem Tool hab ich mächtig Respekt. 😲
|
black_tencate
Anmeldungsdatum: 27. März 2007
Beiträge: 10955
|
Hej Frieder108, HALT STOPP TK87 schrieb: Frieder108 schrieb: Frage: wenn ich den MBR löschen will, reicht da dann ein
dd if=/dev/zero of=/dev/sda bs=1 count=446
oder löscht mir das die gesamte Festplatte?
Jup, das löscht die komplette Festplatte. Den MBR löschen geht so
| dd if=/dev/zero of=/dev/sda bs=512 count=1
|
es ist natürlich genau umgekehrt, denn in den Bytes 446-512 steht u.A. die Partitionstabelle! EDIT.: und ob nun ...bs=1 count=446, oder bs=446 count=1 ist Hose wie Jacke. Man schau mal unter MBR Gruß black tencate
|
TK87
Anmeldungsdatum: 8. Juli 2019
Beiträge: 216
Wohnort: Aachen
|
black_tencate schrieb: es ist natürlich genau umgekehrt, denn in den Bytes 446-512 steht u.A. die Partitionstabelle!
Richtig, danke. Eine Empfehlung sollte das aber ohnehin nicht sein, denn wie gesugt, grub-install überschreibt den MBR Frieder108 schrieb: das ist aber genau das, was nicht funktioniert
Woran machst du das fest? Der MBR sagt doch nur, wo der Bootloader zu finden ist - dein System bootet, also wurde er gefunden. Den Inhalt bestimmt die grub.cfg.
|
Frieder108
(Themenstarter)
Anmeldungsdatum: 7. März 2010
Beiträge: 8989
|
TK87 schrieb: Eine Empfehlung sollte das aber ohnehin nicht sein, denn wie gesugt, grub-install überschreibt den MBR Frieder108 schrieb: das ist aber genau das, was nicht funktioniert
Woran machst du das fest? Der MBR sagt doch nur, wo der Bootloader zu finden ist - dein System bootet, also wurde er gefunden. Den Inhalt bestimmt die grub.cfg.
jo, aber grub-install hab ich in allen Varianten durchexerziert und an der grub.cfg ändert sich nun mal trotzdem nichts. Grub-Install läuft fehlerfrei durch und auch update-grub zeigt alles richtig an - trotzdem bleibt der Fehler bestehen. ☹
|
charly-ax
Anmeldungsdatum: 19. März 2013
Beiträge: 1749
|
Frieder108 schrieb: jo, aber grub-install hab ich in allen Varianten durchexerziert und an der grub.cfg ändert sich nun mal trotzdem nichts.
Hast du grub-install versehentlich in einem der Nebensysteme laufen lassen, so dass du einen anderen Grub angezeigt bekommst? menuentry 'Ubuntu Eoan Ermine (development branch) (19.10) (auf /dev/sda10) (auf /dev/sda9) (auf /dev/sda6) (auf /dev/sda9) (auf /dev/sda6) (auf /dev/sda9)' --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-/vmlinuz--5
Solch einen Eintrag hatte ich vor längerer Zeit mal auf einem zusätzlich installierten System, bei dem ich den Grub in den PBR installiert hatte und der OS-Prober noch nicht abgeschaltet war.
|
TK87
Anmeldungsdatum: 8. Juli 2019
Beiträge: 216
Wohnort: Aachen
|
Frieder108 schrieb: jo, aber ´grub-install´ hab ich in allen Varianten durchexerziert und an der grub.cfg ändert sich nun mal trotzdem nichts.
grub-install verändert die grub.cfg ja auch nicht - der MBR ist nicht das Problem.
Ich vermute das Problem immer noch auf sda1 → hier müssen ja zumindest noch Teile des Debianbootloaders vorhanden sein, wenn dieser in der grub.cfg auftaucht. Mach doch mal ein Image von sda1, dann formatiere diese und installiere Grub anschließend erneut.
|
Frieder108
(Themenstarter)
Anmeldungsdatum: 7. März 2010
Beiträge: 8989
|
Nein, es gibt keinen Grub im PBR - ich installiere Sekundäsysteme immer ohne Grub - ein update-grub im Hauptsystem nimmt dann die Sekundärsysteme ins Grubmenü auf → aber genau das funktioniert jetzt nicht mehr. :~$ sudo fdisk -l 2>/dev/null | egrep "Disk /|/dev/" | sed "s#^/dev/#Part /dev/#" | awk '{print $2}' | sed 's/://' | xargs -n1 -IX sudo sh -c "hexdump -v -s 0x80 -n 2 -e '2/1 \"%x\" \"\\n\"' X | xargs -n1 -IY sh -c \"case \"Y\" in '48b4') echo X: GRUB 2 v1.96 ;; 'aa75' | '5272') echo X: GRUB Legacy ;; '7c3c') echo X: GRUB 2 v1.97 oder v1.98 ;; '020') echo X: GRUB 2 v1.99 ;; *) echo X: Kein GRUB Y ;; esac\""
/dev/sda: GRUB 2 v1.99
/dev/sda1: Kein GRUB 55aa
/dev/sda2: Kein GRUB 55aa
/dev/sda3: Kein GRUB 74eb
/dev/sda5: Kein GRUB 00
/dev/sda6: Kein GRUB 00
/dev/sda7: Kein GRUB 00
/dev/sda8: Kein GRUB 00
/dev/sda9: Kein GRUB 00
/dev/sda10: Kein GRUB 00 Auch eine Neuinstallation in den MBR bringt keine Änderung
frieder@T420:~$ sudo grub-install /dev/sda && sudo update-grub
i386-pc wird für Ihre Plattform installiert.
Installation beendet. Keine Fehler aufgetreten.
Sourcing file `/etc/default/grub'
GRUB-Konfigurationsdatei wird erstellt …
Linux-Abbild gefunden: /boot/vmlinuz-5.0.0-31-generic
initrd-Abbild gefunden: /boot/initrd.img-5.0.0-31-generic
Linux-Abbild gefunden: /boot/vmlinuz-5.0.0-29-generic
initrd-Abbild gefunden: /boot/initrd.img-5.0.0-29-generic
Found memtest86+ image: /boot/memtest86+.elf
Found memtest86+ image: /boot/memtest86+.bin
Windows 7 auf /dev/sda1 gefunden
Ubuntu Eoan Ermine (development branch) (19.10) auf /dev/sda10 gefunden
Windows 7 auf /dev/sda2 gefunden
Ubuntu 19.04 (19.04) auf /dev/sda9 gefunden
erledigt
frieder@T420:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 18.04.3 LTS
Release: 18.04
Codename: bionic
frieder@T420
die grub.cfg bleibt so chaotisch, wie im Link zu sehen ist. Vor allem bleibt auch immer dieses "blöde" Debian erhalten, obwohl es gar nicht mehr installiert ist. Und wie erwähnt, wenn ich os-prober ausschalte, dann verschwinden alle Einträge, auch diejenigen aus der /etc/grub.d/40_custom und 18.04 startet durch (3 Min.) bis zur Passwortabfrage.
|
black_tencate
Anmeldungsdatum: 27. März 2007
Beiträge: 10955
|
Hej TK87, TK87 schrieb: ...
grub-install verändert die grub.cfg ja auch nicht
ach ja? Ach neee, er schreibt sie nur neu. Solltest mal nachlesen. Ein grub-install schließt z.B. ein grub-mkconfig mit Ziel /boot/grub/grub.cfg ein. ( ▶ GRUB 2/Terminalbefehle (Abschnitt „grub-mkconfig“) ◀ ) Gruß black tencate EDIT.: Frieder108 schrieb: Nein, es gibt keinen Grub im PBR
da muß man mal erforschen, was denn Debian so treibt? Ein RESULTs.txt könnte das evt. erhellen?
|
TK87
Anmeldungsdatum: 8. Juli 2019
Beiträge: 216
Wohnort: Aachen
|
black_tencate schrieb: grub-install verändert die grub.cfg ja auch nicht
ach ja? Ach neee, er schreibt sie nur neu. Solltest mal nachlesen. Ein grub-install schließt z.B. ein grub-mkconfig mit Ziel /boot7grub/grub.cfg ein. ( ▶ GRUB 2/Terminalbefehle (Abschnitt „grub-mkconfig“) ◀ )
Es kommt aber bei einem grub-install schlichtweg kein anderes Ergebnis raus als bei einem update-grub aka grub-mkconfig . Moment mal... Frieder108 schrieb: Zum Verständniss
~$ sudo parted -l
Modell: ATA Samsung SSD 850 (scsi)
Festplatte /dev/sda: 1000GB
Sektorgröße (logisch/physisch): 512B/512B
Partitionstabelle: msdos
Disk-Flags:
Nummer Anfang Ende Größe Typ Dateisystem Flags
1 1049kB 106MB 105MB primary ntfs boot #Windows-Recovery :?:
2 106MB 216GB 216GB primary ntfs #Windows
3 216GB 1000GB 784GB extended
5 216GB 866GB 650GB logical ext4 #Daten
6 866GB 896GB 30,0GB logical ext4 #18.04 System
7 896GB 905GB 8499MB logical linux-swap(v1)
8 905GB 955GB 50,0GB logical ext4 #18.04 Home
9 955GB 980GB 25,2GB logical ext4 #19.04
10 980GB 1000GB 20,0GB logical ext4 #19.10 - hier war vorher das Debian
sda1 ist also nur eine Windows-Recovery und keine Bootpartition?! Dann ist bei dir doch der Bootflag falsch gesetzt, der müsste auf sda6
|
Lidux
Anmeldungsdatum: 18. April 2007
Beiträge: 15843
|
Hallo Frieder108, Dann zeige doch mal den kompletten Inhalt deiner 40_custom und 41_custom ..... Gruss Lidux
|