|
ProtonM
Anmeldungsdatum:
29. Dezember 2014
Beiträge: 166
|
Hallo Profis Ich habe mir vermutlich den MBR zerschossen und bin mir für die Reparatur nicht sicher.
Seit der Installation von 20.04 sind mehrfach neue Kernel in /boot erzeugt worden, aber das Grub-Menu zeigt nur die ersten zwei zur Auswahl. Auch die neue Reihenfolge wird nicht übernommen. Ich vermute, dass das alte Grub-Menu auf /dev/sda1 immer verwendet wird. Der Vergleich von fdisk und parted macht mich noch mehr stutzig. Denn fdisk erkennt ein ntfs und parted ein ext4 auf /dev/sda1. # sudo fdisk -lu
Festplatte /dev/sda: 298,9 GiB, 320072933376 Bytes, 625142448 Sektoren
Festplattenmodell: WDC WD3200BEKT-7
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: 0x86181828
Gerät Boot Anfang Ende Sektoren Größe Kn Typ
/dev/sda1 * 2048 1026047 1024000 500M 7 HPFS/NTFS/exFAT
/dev/sda2 1026048 315545599 314519552 150G 7 HPFS/NTFS/exFAT
/dev/sda3 315547646 625141759 309594114 147,6G 5 Erweiterte
/dev/sda5 315547648 323936255 8388608 4G 83 Linux
/dev/sda6 323938304 328132607 4194304 2G 83 Linux
/dev/sda7 328134656 361689087 33554432 16G 83 Linux
/dev/sda8 361691136 395245567 33554432 16G 83 Linux
/dev/sda9 395247616 412024831 16777216 8G 83 Linux
/dev/sda10 412026880 420415487 8388608 4G 83 Linux
/dev/sda11 428804096 432998399 4194304 2G 83 Linux
/dev/sda12 433000448 449777663 16777216 8G 83 Linux
/dev/sda13 565551104 596799487 31248384 14,9G 83 Linux
/dev/sda14 596801536 625141759 28340224 13,5G 82 Linux Swap / Solaris
/dev/sda15 458166272 466554879 8388608 4G 83 Linux
/dev/sda16 466556928 470751231 4194304 2G 83 Linux
/dev/sda17 470753280 487538687 16785408 8G 83 Linux
/dev/sda18 487540736 521095167 33554432 16G 83 Linux
/dev/sda19 521097216 529485823 8388608 4G 83 Linux
/dev/sda20 529487872 533682175 4194304 2G 83 Linux
/dev/sda21 533684224 537878527 4194304 2G 83 Linux
/dev/sda22 537880576 554657791 16777216 8G 83 Linux
Partitionstabelleneinträge sind nicht in Festplatten-Reihenfolge. sudo parted -l
Modell: ATA WDC WD3200BEKT-7 (scsi)
Festplatte /dev/sda: 320GB
Sektorgröße (logisch/physisch): 512B/512B
Partitionstabelle: msdos
Disk-Flags:
Nummer Anfang Ende Größe Typ Dateisystem Flags
1 1049kB 525MB 524MB primary ext4 boot
2 525MB 162GB 161GB primary ntfs
3 162GB 320GB 159GB extended
5 162GB 166GB 4295MB logical ext4
6 166GB 168GB 2147MB logical ext4
7 168GB 185GB 17,2GB logical ext4
8 185GB 202GB 17,2GB logical ext4
9 202GB 211GB 8590MB logical ext4
10 211GB 215GB 4295MB logical ext4
11 220GB 222GB 2147MB logical ext4
12 222GB 230GB 8590MB logical ext4
15 235GB 239GB 4295MB logical ext4
16 239GB 241GB 2147MB logical ext4
17 241GB 250GB 8594MB logical ext4
18 250GB 267GB 17,2GB logical ext4
19 267GB 271GB 4295MB logical ext4
20 271GB 273GB 2147MB logical ext4
21 273GB 275GB 2147MB logical ext4
22 275GB 284GB 8590MB logical ext4
13 290GB 306GB 16,0GB logical ext4
14 306GB 320GB 14,5GB logical linux-swap(v1)
Kann ich da einfach mit
sudo dpkg-reconfigure grub-pc
das Problem beheben? Und welche Partitionsangabe ist die richtige, sda oder sda1?
|
|
Lidux
Anmeldungsdatum:
18. April 2007
Beiträge: 14945
|
Hallo ProtonM, Bei MBR ist der Bootloader in der sda bzw. in der / Partition des installierten System. PS: Wie viele Systeme hast du da installiert und welche ist der Führende ? Gruss Lidux
|
|
ProtonM
(Themenstarter)
Anmeldungsdatum:
29. Dezember 2014
Beiträge: 166
|
Hallo Lidux Es gibt 3, bzw 4 Systeme:
sda2 mit W10, aber nicht mehr im Grub-Menue
sda5 mit Lubuntu 18.04 mit 3 Kerneln (soll mal verschwinden)
sd13 mit kali-linux
sda15 mit Lubuntu 20.04. mit 4 Kerneln Alle Linux-Systeme sind lauffähig, aktuell 20.04 aktiv und auch das Zielsystem, wenn die Umstellung abgeschlossen ist.
? Im Grub-Customizer gibt es einen Menu-Punkt: Grub im MBR speichern. Würde der das reparieren?
|
|
ProtonM
(Themenstarter)
Anmeldungsdatum:
29. Dezember 2014
Beiträge: 166
|
Habe mal das bootinfoscript mehrfach ausgeführt und diverse grub-kommandos ausprobiert. RESULT.txt:
=> Grub2 (v2.00) is installed in the MBR of /dev/sda and looks at sector 1 of
the same hard drive for core.img. core.img is at this location and looks
for (,msdos6)/grub. It also embeds following components:
modules
---------------------------------------------------------------------------
fshelp ext2 part_msdos biosdisk
---------------------------------------------------------------------------
sda1: __________________________________________________________________________
File system: ext4
Boot sector type: -
Boot sector info:
Operating System:
Boot files: Der erste output ist immer gleich. msdos6 ist das alte 18.04-System. Also habe ich update-grub auf diesem System ausgeführt. Jetzt sind alle Systemeinträge da (bis auf w10 auf sda2).
Allerdings hätte ich gerne, dass das grub-menue von msdos16 (20.04) geladen wird. Das ist mir noch nicht gelungen. Auch dass die boot-partition sda1 so leer ist, gefällt mit nicht. Gibt es noch eine Idee?
|
|
black_tencate
Anmeldungsdatum:
27. März 2007
Beiträge: 10674
|
Hej ProtonM, ProtonM schrieb: ...Gibt es noch eine Idee?
klar, die erste wäre mal eine vollständige Results.txt, was sollen wir denn aus dem verstümmelten Rest hier noch sehen können (außer, daß das führende system gerade auf sda6 liegt)? Daneben darfst Du auch "verraten", wie es so mit der Verteilung der Partionen zu den O/sen denn aussieht, wie sollen wir da bisher einen Durchblick erhalten? Wenn Du Label vergeben hast, reicht ein lsblk -f gruß black tencate
|
|
ProtonM
(Themenstarter)
Anmeldungsdatum:
29. Dezember 2014
Beiträge: 166
|
Ich habe mich gescheut, den riesigen output von result.txt hochzuladen;-( Hier die vorgeschlagene Kurzfassung mit den Labeln, die Langfassung als Anhang.
lsblk -f
sda
├─sda1 ext4 36c1e888-6ac4-4686-9d52-021ab3e8f5dc
├─sda2 ntfs Windows 10 8CAC9C61AC9C479A
├─sda3
├─sda5 ext4 32root 36c1e888-6ac4-4686-9d52-021ab3e8f5dc
├─sda6 ext4 32boot 21e7b8cc-b194-40ef-b1ec-f18be8ed2335
├─sda7 ext4 32home d6288778-3d01-45f2-8042-8f0f9eb34e7a
├─sda8 ext4 32usr fbfad78f-efc6-47c3-929e-a890fc955953
├─sda9 ext4 32var 5b10637d-0125-448e-ab4e-e27c9249ed4a
├─sda10 ext4 32tmp d3dc7cdf-d956-49fc-a7b4-7caa9ca605c0
├─sda11 ext4 32srv a96a3ca8-567f-4521-ba42-8aaf356f4fae
├─sda12 ext4 32opt de1fe773-00f1-4014-8cb9-000ff08a8d37
├─sda13 ext4 64kali 2a2147f1-ae1f-4c10-97fd-8f6a7aa64b22
├─sda14 swap 6fa8f78e-ba22-482a-8fb0-55ea17d355c3
├─sda15 ext4 64root fc67224c-c442-451f-a898-b53cf86a6a0a 3,6G 1% /
├─sda16 ext4 64boot 0eab02d5-7292-414c-8fc0-f1de22772f73 1,4G 21% /boot
├─sda17 ext4 64home 6eb4a9dc-772e-4256-ab34-70de3ee1c09c 5,9G 20% /home
├─sda18 ext4 64usr e35820b2-0c8c-4157-9164-aa6d08805c95 9,1G 37% /usr
├─sda19 ext4 64var 140fcbdc-dc9e-4561-9ff2-eb5cbc5a7b51 2,2G 38% /var
├─sda20 ext4 64tmp cf1f0296-6cd8-4805-b602-e176c410416b 1,8G 0% /tmp
├─sda21 ext4 64srv 5f0c0a4f-f1d3-4a06-844f-a318a7094628 1,8G 0% /srv
└─sda22 ext4 64opt 6072f275-5f2e-4c3e-bf35-b24196b645a2 6,6G 10% /opt
- RESULTS.txt (93.3 KiB)
- Download RESULTS.txt
|
|
black_tencate
Anmeldungsdatum:
27. März 2007
Beiträge: 10674
|
Hej ProtonM, ProtonM schrieb: ...Also habe ich update-grub auf diesem System ausgeführt.
da scheint auch sowas wie bootrepair im Spiel gewesen zu sein (?, sonst gäb 's wohl nicht die PBR grubs auf sda5 und 6?) ...Jetzt sind alle Systemeinträge da (bis auf w10 auf sda2).
sollte eigentlich dennoch erkannt werden, auch wenn offensichtlich an der sda1 manipuliert wurde (das ist aber ein Windows Problem) teste mal ein os-prober, wenn es da auch nicht auftaucht, müßtest Du eine /etc/grub.d/40_custom bearbeiten, und dort einen Eintrag menuentry "Windows" {
set root=(hd0,2)
chainloader +1
}anlegen Allerdings hätte ich gerne, dass das grub-menue von msdos16 (20.04) geladen wird.
Du hast hier ein klassisches MBR/MPT System, da kann nur einer "das Sagen haben". Starte das 20.04 und führe dort eine Neuinstallation von grub aus (Grub 2/Reparatur). ab dann mußt Du auch weitere Änderungen mit den Konfigurationsdateien nur noch im Beaver durchführen. PS.: Wer hat Dir zu dieser sonderbaren Partitionsaufteilung geraten? Gruß black tencate
|
|
ProtonM
(Themenstarter)
Anmeldungsdatum:
29. Dezember 2014
Beiträge: 166
|
ok, das werde ich jetzt gerade biegen. Und recht vielen Dank für Deine Erklärungen. In der grub-Doku kann man sich schnell verlaufen und so ist wahrscheinlich auch mal eine Tipp von mir falsch verstanden worden und die Panne war passiert.
PS.: Wer hat Dir zu dieser sonderbaren Partitionsaufteilung geraten?
Schlechte eigene Erfahrung. Unter 14.04 und 16.04 war immer eine Partition zu klein. Also habe ich mit 18.04 und auf dem neuen Notebook W10 halbiert, und lauter 16GB-Partitionen erstellt und das Wachstum beobachtet. Jetzt, vor 20.04, sind die 16GB auf das Nötige geschrumpft worden und für die 20.04-Partitionen haben ich das übernommen.
|
|
black_tencate
Anmeldungsdatum:
27. März 2007
Beiträge: 10674
|
Hej ProtonM, ProtonM schrieb: ... PS.: Wer hat Dir zu dieser sonderbaren Partitionsaufteilung geraten?
Schlechte eigene Erfahrung. Unter 14.04 und 16.04 war immer eine Partition zu klein.
gewöhlich teilt man – wenn man will – in "/" und "/home", all die anderen Aufteilungen, z.B für "/boot" 2147 MB ist schon sehr skuril (meinetwegen, wenn Du par tout mehr als 2 kernel aufheben möchtest, dann eben 500 MB oder auch 1 GB), aber jede solche Aufteilung bringt automatisch Platzverschwendung mit sich. Falls da irgendwie auf eine 32 GB Platte möglichst auch noch 2,3 Systeme sollen, dann ist klar, da muß dann "outgesourced" werden, aber dann bitte auf eine andere Platte. Aber, mit Partitionen hat halt jeder so seine eigenen Vorstellungen; ich wünsche Dir, daß Du nicht in die Verlegenheit kommst, "schubsen" zu müssen. Gruß black tencate
|
|
ProtonM
(Themenstarter)
Anmeldungsdatum:
29. Dezember 2014
Beiträge: 166
|
naja, die Daten liegen sowieso alle auf dem 20.04 raid1-server und nicht auf dem notebook. Und wenn 20.04 Desktop richtig läuft und Platz gebraucht wird, wird 18.04 geplättet, z.B. für 22.04..
|