Linux Swap nicht löschbar

[choetzu]

Hallo,
ich hatte via Bootcamp Ubuntu 8.1 installiert. NUn wollte ich via Festplatten-Dienstplattenprogramm die Partition löschen.

Nun kann ich die Linux Swap nicht löschen und die Partition nicht vergrössern. Auch der Boot Camp funktioniert nicht. Wie bring ich den Linux Swap weg?

Danke für die Hilfe.

Choetzu

[GunBound]

Gib diesen Code im Terminal ein (Copy & Paste)und bring den Output ins Forum (wenn du wissen willst, wieso, dann schau in meiner Signatur unter "Partitionsprobleme"):

sudo -v;d=$(mount|grep "on / "|sed -e 's,s[[:digit:]].*,,' -e 's,v/d,v/rd,');sudo fdisk $d;sudo gpt -r show $d;sudo -k;

[choetzu]

hallo,
herzlichen Dank. unten mein Code. Da dieser von dem Code aus deinem Beitrag abweicht, habe ich noch keine Massnahmen ergriffen.

Ich möchte auf jeden Fall eine Formatierung der gesamten Festplatte vermeiden, da ich die Daten lange nciht mehr gesichert habe.

Herzlichen Dank für die Hilfe
Lieber Gruss
choetzu

Disk: /dev/rdisk0    geometry: 14593/255/63 [234441648 sectors]
Signature: 0xAA55
         Starting       Ending
 #: id  cyl  hd sec -  cyl  hd sec [     start -       size]
------------------------------------------------------------------------
 1: EE 1023 254  63 - 1023 254  63 [         1 -     409639] <Unknown ID>
*2: AF 1023 254  63 - 1023 254  63 [    409640 -  201064448] HFS+        
 3: 82 1023 254  63 - 1023 254  63 [ 232979879 -    1461736] Linux swap  
 4: 00    0   0   0 -    0   0   0 [         0 -          0] unused      
gpt show: /dev/rdisk0: Suspicious MBR at sector 0
      start       size  index  contents
          0          1         MBR
          1          1         Pri GPT header
          2         32         Pri GPT table
         34          6         
         40     409600      1  GPT part - C12A7328-F81F-11D2-BA4B-00A0C93EC93B
     409640  201064448      2  GPT part - 48465300-0000-11AA-AA11-00306543ECAC
  201474088   31505791         
  232979879    1461736      3  GPT part - 0657FD6D-A4AB-43C4-84E5-0933C84B4F4F
  234441615         32         Sec GPT table
  234441647          1         Sec GPT header

[GunBound]

Disk: /dev/rdisk0    geometry: 14593/255/63 [234441648 sectors]
Signature: 0xAA55
         Starting       Ending
 #: id  cyl  hd sec -  cyl  hd sec [     start -       size]
------------------------------------------------------------------------
 1: EE 1023 254  63 - 1023 254  63 [         1 -     409639] <Unknown ID>
*2: AF 1023 254  63 - 1023 254  63 [    409640 -  201064448] HFS+        
 3: 82 1023 254  63 - 1023 254  63 [ 232979879 -    1461736] Linux swap  
 4: 00    0   0   0 -    0   0   0 [         0 -          0] unused      
gpt show: /dev/rdisk0: Suspicious MBR at sector 0
      start       size  index  contents
          0          1         MBR
          1          1         Pri GPT header
          2         32         Pri GPT table
         34          6         
         40     409600      1  GPT part - C12A7328-F81F-11D2-BA4B-00A0C93EC93B
     409640  201064448      2  GPT part - 48465300-0000-11AA-AA11-00306543ECAC
  201474088   31505791         
  232979879    1461736      3  GPT part - 0657FD6D-A4AB-43C4-84E5-0933C84B4F4F
  234441615         32         Sec GPT table
  234441647          1         Sec GPT header

Grundsätzlich sieht das zwar nicht völlig i.O. aus, aber es könnte schlimmer sein. Gemäss Rastafaris Antwort bei mir kann ich kurz soviel sagen, wie ich weiss:

• Die oberen vier Einträge zeigen alle Partitionen der MBR-Tabelle (MBR=Master Boot Record; diese wird von Windows und Linux benutzt). Dort hat die erste Partition eine "unknown ID": Das ist normal (weil dies die 200 MB EFI-Partition im Format Fat32 ist und nicht richtig erkannt wird). Darunter sind HFS+ (die Mac-Partition) und Linux: Die MBR-Tabelle hat wenig Schaden genommen (bis auf die rote Zeile, welche aber, so wage ich zu behaupten, von der EFI-Partition kommt).
• Darunter sind die Einträge der Festplatte (alle Partitionsschemen) sowie der GPT (oder GUID)-Tabelle, auf der OS X hauptsächlich fusst. Die rote Zeile dort ist quasi das Hauptproblem: Ich weiss nicht, ob die erlaubt ist (das wäre ja ein freier Bereich zwischen den Partitionen).

Was ich vorschlage, ist das hier:
Achtung! Ich weiss nicht, ob der Befehl wirklich stimmt; ich empfehle dir stark, ein Backup deiner Daten zu machen und Rastafari hier im Forum zu fragen! Die Festplatte kann zerstört werden, und ich will keine Haftung übernehmen. Denk daran: Wende dich lieber an einen, der wirklich drauskommt, wenn du kein Bastler bist und die HD wieder intakt haben willst!

Terminal öffnen und das hier eingeben:

resizer="$( find /System/Library/ -type f -iname resizevolume 2>/dev/null | head -n 1 )"; echo $resizer;

Jetzt ins FP-DP wechseln. Dort siehst du deine zu beackernde Platte und das (bzw die) Volumes darauf. Gemountet ("aktiv") sollte ja eigentlich nur dein OS X Volume sein. Dieses markierst du und wählst "deaktivieren" (nicht "auswerfen" bitte). Alle Volumes auf dieser HD müssen deaktiviert sein (grau abgeblendet angezeigt), sonst klappt das folgende nicht.
Jetzt markierst du die gesamte Festplatte und lässt dir die Informationen dazu anzeigen. Unter "Medien-Identifikation" findest du da einen Eintrag wie zB: disk3
Merk dir davon nur die Ziffer am Ende. Die brauchst du gleich, wieder zurück im Terminal.
Dort musst du jetzt erst mal die alten, kaputten Partitionsdaten zum Teufel jagen. Da das Programm selbst ja offensichtlich seine lieben Probleme damit hatte, machen wir das mal auf die Radikaltour mit dem Holzhammer. Gleich am Anfang aber trage anstelle des blauen x schon mal die gerade gemerkte Ziffer ein, das kann man sich ja auch merken lassen. (Wofür hat man denn so ein schlaues Dingens sonst überhaupt?)

num=x;

# ab hier kannst du wieder bequem kopieren 
# ...bis auf weiteres jedenfalls  

hd=/dev/disk$num; 
hd_raw=/dev/rdisk$num;

# jetzt wird das Admin-Kennwort gebraucht
# selbstverständlich von dem Rechner,
# den du als Starthilfe verwendet hast.

sudo dd if=/dev/zero of=$hd count=33 seek=234441615; 
sudo dd if=/dev/zero of=$hd count=34 conv=notrunc;
sync;

# Wenn du vorher alles richtig gemacht hast,
# ist deine HD jetzt so blitzeblank leer
# wie frisch gefallener Schnee.
# Jetzt wird neu aufgebaut.  

sudo gpt create $hd;
sudo gpt add -i 1 -t efi -b 40 -s 409600 $hd;
sudo gpt add -i 2 -t hfs -b 409640 -s 234000000 $hd;

# Jetzt wird das Festplattendienstprogramm versuchen,
# das Mac OS Volume wieder zu aktivieren.
# Warte einen Moment bis das erledigt ist.

Jetzt von der System-DVD starten und "Volume reparieren" aus dem Festplatten-Dienstprogramm ausführen. Eine Reparatur der MBR-Tabelle ist glaube ich nicht nötig.

So, und ich bitte dich nochmals: Wende dich mit dieser Antwort und der ausgespuckten Terminal-Shell an Rastafari. Er wird dir sagen können, ob das stimmt. Was damit nämlich gemacht wird: Die Einträge für die Tabellen 2,3 und den leeren Bereich dazwischen werden neu geschrieben, aber da ich ein Laie bin, weiss ich nicht, ob das stimmt (nur von den Zahlen und Grössen her).

[lionATwork]

Wenn Du Dich mit Linux bissl auskennst, brenn Dir ne Knoppix CD (LiceCD) und lösche die Partition mit gparted. Ist mein Standard App für Partitionsaufgaben.

lg

lion

[GunBound]

Wenn Du Dich mit Linux bissl auskennst, brenn Dir ne Knoppix CD (LiceCD) und lösche die Partition mit gparted. Ist mein Standard App für Partitionsaufgaben.

lg

lion

Yup, ist auch möglich; allerdings hat bei mir damals gparted nicht funktioniert (die Lüfter liefen auf Hochtouren und nichts passierte).

Edit: Niemals, aber auch gar niemals Windows-Tools ranlassen. Grosse Warnung, die mir gerade in den Sinn kam!

[kybdf2]

Edit: Niemals, aber auch gar niemals Windows-Tools ranlassen. Grosse Warnung, die mir gerade in den Sinn kam!

Erweitere diese Warnung noch um die Linux Tools. Beide kommen mit dem Partitions-Schema der Mac Platten nicht klar. Man sollte immer alles von OS X aus machen.

[GunBound]

Ok, ich glaube dir (stimmt, Rastafari hat das auch erwähnt). Ich dachte nur an die Windows-Tools, weil die nicht nur mit GUID und OS X, sondern auch mit MBR nicht richtig umgehen können – die Tabelle wird beim Formatieren unter Win ja komplett überschrieben statt modifiziert.