[SOLVED] Corrupt partition table

A couple days ago I was transferring large files to my 1TB external Seagate USB drive (NTFS).  It was going smooth then on one file it stopped and Thunar gave an error.
When looking at the directory with ls -l the file's attributes were question marks (?)
I was able to access all the other files fine, but was unable to delete or access the corrupt directory.
Now, days later, I am unable to mount the USB drive.
sudo fdisk -l gives this:
Disk /dev/sdc: 931.5 GiB, 1000204885504 bytes, 1953525167 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x6e697373
This doesn't look like a partition table. Probably you selected the wrong device.
Device Boot Start End Blocks Id System
/dev/sdc1 ? 1936269394 3772285809 918008208 4f QNX4.x 3rd part
/dev/sdc2 ? 1917848077 2462285169 272218546+ 73 Unknown
/dev/sdc3 ? 1818575915 2362751050 272087568 2b Unknown
/dev/sdc4 ? 2844524554 2844579527 27487 61 SpeedStor
Partition table entries are not in disk order.
I run sudo ntfsck /dev/sdc:
$ sudo ntfsck /dev/sdc
file record corrupted at offset 3221225472 (0xc0000000).
Loading $MFT runlist failed. Trying $MFTMirr.
First attribute must be after the header (0).
and it just seems to be stuck there, I've left it running for a few hours...
Is my disk screwed?
*edit*: I got it! Check my other post further down this thread
Last edited by uberscientist (2014-12-16 19:15:57)

I fixed it finally!
I had set the drive aside and was sad about it for a while, and decided to give another shot at googling and repair, here's what I did to get it working:
install testdisk: https://www.archlinux.org/packages/extr … /testdisk/
sudo testdisk
[ Create ] (new log file)
selected the corrupted drive
>[Proceed]
>[Intel ] ( By default it picked None... I just guessed Intel/PC)
>[Analyse]
>[Quick Search]
>[Continue]
>[Deeper Search]
>Stop (press enter to stop after it finds another entry)
>Down arrow, then right arrow to set it Primary partition (non-bootable for my case)
>[Write ]
Mount your drive

Similar Messages

  • [Solved] corrupted partition table

    Yours truly was experimenting with alternative bootloaders today and ended up with a corrupted partition table. Yours truly had backed up the bootloader part of the MBR today but neglected to copy the rest. Guess who is feeling very stupid right now.
    Here is what fdisk has to say about my disk,
    root@sysresccd /root % fdisk -l /dev/sdb
    Warning: ignoring extra data in partition table 5
    Warning: ignoring extra data in partition table 5
    Warning: ignoring extra data in partition table 5
    Warning: invalid flag 0x2404 of partition table 5 will be corrected by w(rite)
    Disk /dev/sdb: 30.0 GB, 30020272128 bytes
    255 heads, 63 sectors/track, 3649 cylinders
    Units = cylinders of 16065 * 512 = 8225280 bytes
    Disk identifier: 0x4b36bdea
    Device Boot Start End Blocks Id System
    /dev/sdb1 * 895 3444 20482875 7 HPFS/NTFS
    /dev/sdb2 1 894 7181023+ b W95 FAT32
    /dev/sdb3 3445 7476 32387040 5 Extended
    /dev/sdb5 ? 142349 151007 69551332+ 19 Unknown
    Partition table entries are not in disk order
    This looks somewhat promising. I had only three partitions on the disk (I don't remember if any were logical), one swap, one large thing for pacman stuff and of course root.
    By suggestion of this I will try testdisk (version 6.11 from Sys Resc CD).
    Last edited by fsckd (2011-09-17 21:22:59)

    Unfortunately my copy of sys resc cd does not have fixparts.
    testdisk worked like a charm and my partitions were recovered, one swap, one JFS and one ext4.
    (Incidentally it was Windows which damaged the MBR in the first place.)

  • How to recover corrupted partition table?

    I have a disk that somehow got the partition table corrupted. I am getting lots of "Bad Geometry" errors that state the label says one size while the drive says something different.
    I have tried running the TestDisk (http://www.cgsecurity.org) application, and it seems to find the partitions just fine and I believe that my data is in tact. I just need to correct the partition table and access the UFS file system. The TestDisk reports that "write_part_sun" is not implemented, so it cannot correct the problem. I have checked the source code for the current and beta versions of the program and the function still has not been written.
    Is there another application that I can use to rescue my corrupted partition table? I am not finding much support for Solaris out on the net.
    Thanks.

    Is there another application that I can use to rescue my corrupted partition table? I am not finding much support for Solaris out on the net.Hi
    There is some, but you have to look hard.
    I wrote a partition table editor:
    http://paulf.free.fr/pfdisk.html
    If your LBA values are good, you should be able to restore the CHS values from them. If both the LBA and CHS values are corrupt, and you have a good idea of the sizes of the partitions, then with a calculator you should be able to work out what the values should have been.
    Paul

  • [SOLVED] Deleted partition table on drive, how to rescue?

    Hello,
    I accidentally dd'd the first 512 bytes using:
    dd if=/dev/zero of=/dev/sdb bs=512 count=1
    and the partition table is now gone. Is there ANY way to re-create the partition table and rescue the still existing partition? I read up on parted's manual, and found the following commands:
    mklabel - to create a new label on the disk (but does it also create a new partition table?)
    rescue - to try and rescue the partition around the given START and END
    My hard drive is 500GB and has only 1 partition on it, in NTFS file format.
    Any help would be much appreciated.
    Silentz0r
    Last edited by silentz0r (2011-03-27 16:17:36)

    Thanks everyone for your help, I have managed to solve this. Here's what I did:
    (I had no backup of the MBR)
    I used:
    parted /dev/sdb
    sdb was my broken drive, and did the following:
    (parted) print
    Error: /dev/sdb: unrecognised disk label
    (parted) mklabel
    (parted) mklabel msdos
    (parted) rescue
    Start? 0
    End? 976773168 // This was just a random guess.
    Information: A ntfs primary partition was found at 32.3kB -> 500GB. Do you want to add it to the partition table?
    Yes/No/Cancel? yes
    (parted) quit
    Information: You may need to update /etc/fstab.
    And everything works now.
    For the record, I am making MBR backups for all my drives while I'm typing this.
    Hope this helps someone in the future! Marked as solved.

  • Recover corrupted partition

    I corrupted a partition on my HD and am now looking to recover some files.
    I was expanding a partition from 300GB to 320GB in parted and the power went out at ~25%. Using TestDisk I was able to recover the first 107GB, however the middle 170GB are unallocated and the final 20GB are unallocated separately. The first partition was originally the 107GB+170GB, so would it be possible to annex the two? I understand that the data at the seam will be corrupted but is it possible to recover through this method? Should I try to use photorec instead to recover the files from the 170GB?

    Is there another application that I can use to rescue my corrupted partition table? I am not finding much support for Solaris out on the net.Hi
    There is some, but you have to look hard.
    I wrote a partition table editor:
    http://paulf.free.fr/pfdisk.html
    If your LBA values are good, you should be able to restore the CHS values from them. If both the LBA and CHS values are corrupt, and you have a good idea of the sizes of the partitions, then with a calculator you should be able to work out what the values should have been.
    Paul

  • [SOLVED] The best way to recover a Partition Table. (LVM)

    I just did something really stupid I accidently had a typo in gdisk and changed the wrong hard drive partition table.
    So before I do something really stupid I post here.
    The hard drive is still mounted and I luckily have the output of the former partition table, this is it:
    fdisk -l /dev/sdb
    Festplatte /dev/sdb: 2,7 TiB, 3000558944256 Bytes, 732558336 Sektoren
    Einheiten: Sektoren von 1 * 4096 = 4096 Bytes
    Sektorgröße (logisch/physikalisch): 4096 Bytes / 4096 Bytes
    E/A-Größe (minimal/optimal): 4096 Bytes / 4096 Bytes
    Festplattenbezeichnungstyp: dos
    Festplattenbezeichner: 0x00028375
    Device Boot Start End Sectors Size Id Type
    /dev/sdb1 256 366211193 366210938 1,4T 83 Linux
    /dev/sdb2 366211194 732558335 366347142 1,4T 83 Linux
    The partition table was a LVM partition table.
    This is the current one:
    gdisk -l /dev/sdb
    GPT fdisk (gdisk) version 0.8.10
    Partition table scan:
    MBR: protective
    BSD: not present
    APM: not present
    GPT: present
    Found valid GPT with protective MBR; using GPT.
    Disk /dev/sdb: 732558336 sectors, 2.7 TiB
    Logical sector size: 4096 bytes
    Disk identifier (GUID): DA7956E1-B120-4F78-925A-B5DDE14E7C9C
    Partition table holds up to 128 entries
    First usable sector is 6, last usable sector is 732558330
    Partitions will be aligned on 256-sector boundaries
    Total free space is 250 sectors (1000.0 KiB)
    Number Start (sector) End (sector) Size Code Name
    1 256 131327 512.0 MiB EF00 EFI
    2 131328 13238527 50.0 GiB 8E00 Arch
    3 13238528 732558330 2.7 TiB 8300 EXT
    I really hope someone can help me with that, I'm currently a total nerve wrack.
    If its a more or less impossible task (well or there is no guarantee that it works) I will buy a new Drive tomorow to save the currently still mounted files.
    Thank You!
    [EDIT]
    Forget about copying the file system isn't really accessible, I can open a few folders but everything in there are 0byte files
    Last edited by theblackdog (2015-03-10 14:16:59)

    So because no one gave me a answer so far (ok it's already pretty late and I was a bit imatient) I took the leap of faith and used fdisk to recreate the partition sheme,  so far everything seems to work.
    There is only one thing that would interest me, as far as I know a GPT partition table is bigger than a dos partition table, how big is the risk that data got corrupted because of the bigger table?
    I will mark the thread as solved after that.

  • X200 Boot Configurat​ion Corrupt !! How do I partition table repair ........he​lp please

    Hopefully someone can help me as I'm about to go mad......
    My x200 says that my Boot configuration is corrupt and that to repair it I have do a 'partition table repair' error code 0x490
    I have tried to use the recovery cd's but each time they try and restore to factory original settings it says becuase there had been a previous attemp to restore which was stopped early the Boot Configuration isn't complete and I dont have enough room on the partition swload c: to carryon - again its saying to increase the size of the partition swload c: but I don't know how !!!!!!!
    I've looked in the BIOS setup but cant see anything in there about partitions......
    Can anybody help please :-((
    Message Edited by Christian333 on 01-18-2009 06:06 AM

    Christian333, welcome to the forum,
    I personally have never heard of your problem, others may have, but I would start by running Drive Fitness Test from Hitachi to check the hard drive. Even if you don't have an Hitachi drive it will say whether or not the drive is OK. I always run it from CD.
    If the drive is OK I would then run Secure Data Disposal at it's lowest level in order to eliminate anything in the boot sectors and then afterwards the recovery discs. If problems are then experienced it's time to call service.
    Hope this helps
    Andy  ______________________________________
    Please remember to come back and mark the post that you feel solved your question as the solution, it earns the member + points
    Did you find a post helpfull? You can thank the member by clicking on the star to the left awarding them Kudos Please add your type, model number and OS to your signature, it helps to help you. Forum Search Option T430 2347-G7U W8 x64, Yoga 10 HD+, Tablet 1838-2BG, T61p 6460-67G W7 x64, T43p 2668-G2G XP, T23 2647-9LG XP, plus a few more. FYI Unsolicited Personal Messages will be ignored.
      Deutsche Community     Comunidad en Español    English Community Русскоязычное Сообщество
    PepperonI blog 

  • Does a truncate table solve corrupt blocks in a table

    Hi Guys,
    Got a question:
    Does a truncate table solve corrupt blocks in a table?
    I have found corrupt blocks in rman, located them, they are in 1 table.
    And contacted the business, and have permission to drop and recreate the table,
    but my question is does truncate table drop storage also solves my problem?
    And will it let me to do a full backup without set max corrupt blocks?
    To my knowledge does a truncate table moves the high watermark to 0 + 1 extend, but I am unsure how this will effect the corrupt blocks.
    Thanks in advance for your advice

    Hi,
    Yes truncate/drop table fixes the corruption at the database level. You may like to take the backup(if you have index on it) of that table so that you may restore it later if anything goes wrong.
    Note: This would not fix any corruption at the disk level (like bad sectors).
    Regards
    Anurag

  • [SOLVED] UEFI system booting from MBR partition table and GRUB legacy

    I'm trying to understand once and for all the process by which Arch can be booted from a system with UEFI firmware and an MBR partition table. Some of the information on the wiki seems conflictual / non-nonsensical at times. Apologies in advance if this has been answered time and time again, but I did search around and all I found was fixes to get Arch to boot rather than comprehensive explanations of the boot process.
    Now, the way I would imagine it works is that it's just completely identical to the way it would work with a BIOS firmware. The UEFI firmware detects an MBR partitioning scheme (or is configured to know it's an MBR partitioning scheme), activates some "legacy" mode and executes the MBR boot code, just like a BIOS firmware would.
    The wiki however, says different. From the Macbook article: "Do not install GRUB onto /dev/sda !!! Doing so is likely to lead to an unstable post-environment."?
    So what is there in the MBR boot sector? Nothing?
    How does the firmware know what to boot if there's no 0xEF BIOS boot partition and no Grub stage 1 in the MBR boot sector?
    Also, how does installing Grub stage 1 to a partition work? Does it have to be at the beginning of the partition? Wouldn't that overwrite some existing data?
    I'm especially puzzled since many guides to installing Vista on a macbook recommend simply formatting as MBR, and installing as normal, which I suppose entails having the Windows installation process write its boot code to the MBR, ie the equivalent of installing grub stage 1 to /dev/sda rather than to the /boot partition, as the Macbook article suggests.
    Any input is appreciated.
    P.S. I realize it's probably simpler, if I just want to dual boot Windows and Arch, to install Windows 7 in UEFI-GPT mode, let it create the EFI System Partition, and then install GRUB 2 to that partition, but I'm still curious about the UEFI-MBR boot process.
    Last edited by padavoine (2012-06-06 09:35:10)

    padavoine wrote:
    CSM in UEFI firmwares do the exact same job as normal BIOS firmware.
    So it's something specific to the Mac that it's able to boot from a partition's VBR while ignoring the MBR?
    The reason that warning is given is because grub-legacy modifies more than just the MBR boot code region.  It can overwrite some parts of GPT header.
    Not true, the instruction is given in the context of an MBR format, not in the context of a GPT format, so there's nothing to overwrite and Stage 1.5 should be safely embeddable in the post-MBR gap.
    In BIOS boot (normal case in non-UEFI firmwares or CSM in UEFI firmwares) does not read the partitition table (atleast it is supposed to be dumb in this regard), it simply launches whatever boot code exists in the 1st 440-byte of the MBR region.
    So again, you're saying it's specific to the Mac UEFI that it lets you choose a partition whose VBR to load, regardless of what's in the MBR?
    I haven't used Macs so I can't comment on Mac firmware behaviour. But normal BIOS firmwares (legacy and CSM) launch only the MBR boot code and not the partition boot code. We need some chainload capable boot manager in the MBR to launch the partition VBR.
    grub-legacy does not know anything about GPT. So when you install grub-legacy to /dev/sda, it install the MBR boot code (stage1) and stage 1.5 code to the (supposed) post MBR gap. Since there is no actual post MBR gap in GPT (which has been taken over by the header and partition table), grub-legacy does not check for GPT and it assumes the post MBR gap actually exists which is invalid in case of GPT. grub-legacy embeds the stage 1.5 code in GPT header and table region (which grub assumes to be unused post MBR gap) and thus corrupts it.
    0xEF is the MBR type code for UEFISYS partition. grub stage 1 (used in grub-legacy, not in grub2) is the 440-byte boot code stored in MBR for use in BIOS boot.
    That's precisely my point: with neither proper executable code in the MBR (since grub was installed to a partition, not to the MBR) nor a UEFI system partition, what does the firmware default to, and how does it know what partition to boot from?
    In that case it might fallback to UEFI Shell (if it exists)  or give an error similar to the case where BIOS does not find any bootable code in 440-byte MBR region.
    So even with bootcamp/CSM, the disk also needs to be MBR partitioned. So Macs use something called "Hybrid GPT/MBR" ( http://rodsbooks.com/gdisk/hybrid.html ) where the MBR table is synced to match the first 3 partitions in the GPT table.
    I know what Bootcamp does, and that's not what I was referring to. I was referring to standalone Vista installs. I wasn't puzzled at the fact that they were using MBR, I was puzzled at the fact that contrary to the recommendations for the standalone Arch install on the wiki (with MBR partitioning, not GPT), they didn't do anything to try and prevent Windows from writing to the MBR.
    You can't prevent Windows from overwriting the MBR region. You have to re-install the bootloader (grub2/syslinux etc.) after installing Windows. That is the reason why it is recommended to install Windows first and linux later.
    Thats not true. I actually find it is much easier to install Windows UEFI-GPT using USB rather than a DVD.
    I haven't done it since the only UEFI system I own has no DVD drive, but I was under the impression that it was simply a matter of choosing DVD UEFI boot in the firmware's boot menu.
    format the USB as FAT32 and extract the iso to it. That it.
    No, thats not it, precisely, it doesn't work out of the box with a standard Windows install USB, you need to fiddle around:
    2.3 Extract bootmgfw.efi from [WINDOWS_x86_64_ISO]/sources/install.wim => [INSTALL.WIM]/1/Windows/Boot/EFI/bootmgfw.efi (using 7-zip aka p7zip for both the files), or copy it from C:\Windows\Boot\EFI\bootmgfw.efi from a working Windows x86_64 installation.
    2.4 Copy the extracted bootmgfw.efi file to [MOUNTPOINT]/efi/microsoft/boot/bootmgfw.efi .
    Most of the Windows isos already have /EFI/BOOT/BOOTX64.EFI file, so no need to extract the bootmgfw.efi file.
    There is no difference between in BIOS booting in UEFI firmwares and BIOS booting with legacy firmware.
    There has to be a difference, at least in the Mac firmware (sorry, I keep switching), since legacy firmware, AFAIK, cannot chainload a bootloader in a partition's VBR without there being some sort of "stage1" code in the MBR.
    No idea about Mac EFI. Apple made a spagetti out of UEFI Spec. To actually understand how Mac firmwares work, read the blog posts by Matthew Garrett of Redhat, about his efforts in getting Fedora to boot in Macs.

  • Is my partition table corrupt? Why does Boot Camp hate me?

    Hi folks
    I have an iMac (27-inch, Mid 2010) (iMac11,3, with Boot ROM IM112.0057.B01).
    I replaced the internal SuperDrive with an SSD, which is now my primary boot device:
    iMac:/ michthom$ diskutil list
    /dev/disk0
       #:                       TYPE NAME                    SIZE       IDENTIFIER
       0:      GUID_partition_scheme                        *250.1 GB   disk0
       1:                        EFI EFI                     209.7 MB   disk0s1
       2:                  Apple_HFS SSD                     248.1 GB   disk0s2
       3:                 Apple_Boot Recovery HD             650.0 MB   disk0s3
    iMac:/ michthom$ sudo gpt -r -vv show disk0
    Password:
    gpt show: disk0: mediasize=250059350016; sectorsize=512; blocks=488397168
    gpt show: disk0: PMBR at sector 0
    gpt show: disk0: Pri GPT at sector 1
    gpt show: disk0: Sec GPT at sector 488397167
          start       size  index  contents
              0          1         PMBR
              1          1         Pri GPT header
              2         32         Pri GPT table
             34          6       
             40     409600      1  GPT part - C12A7328-F81F-11D2-BA4B-00A0C93EC93B
         409640  484620800      2  GPT part - 48465300-0000-11AA-AA11-00306543ECAC
      485030440    1269536      3  GPT part - 426F6F74-0000-11AA-AA11-00306543ECAC
      486299976    2097159       
      488397135         32         Sec GPT table
      488397167          1         Sec GPT header
    So far so good.
    I want to use the original internal HDD both to run Windows in Boot Camp mode, and to have a partition for my bulk data that doesn't need to be on the SSD.
    I reformatted the HDD as a single HFS+ partition, GUID partition table.
    I used BCA to create a Windows USB boot device from the Windows 8.1 media after following the hacking in this link.
    When the iMac restarted after creating the 250Gb Windows partition on the internal HDD, I got the "no boot device" screen.
    I restarted holding Option/Alt and booted from EFI Boot on the USB stick. Windows installer started, at least. Serial number accepted, on to picking a location.
    The installation balked when I tried to select the BOOTCAMP partition, with the warning that the disk was formatted as MBR - eh? Why?
    So, the current state of the internal HDD must be wrong somehow, but I don't see how to fix it (confidently) and would like someone to point me in the right direction (please!)
    iMac:/ michthom$ diskutil list
    /dev/disk1
       #:                       TYPE NAME                    SIZE       IDENTIFIER
       0:      GUID_partition_scheme                        *1.0 TB     disk1
       1:                        EFI EFI                     209.7 MB   disk1s1
       2:                  Apple_HFS Internal                751.9 GB   disk1s2
       3:       Microsoft Basic Data BOOTCAMP                248.0 GB   disk1s3
    iMac:/ michthom$ sudo gpt -r -vv show disk1
    gpt show: disk1: mediasize=1000204886016; sectorsize=512; blocks=1953525168
    gpt show: disk1: Suspicious MBR at sector 0
    gpt show: disk1: Pri GPT at sector 1
    gpt show: disk1: Sec GPT at sector 1953525167
           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  1468478336      2  GPT part - 48465300-0000-11AA-AA11-00306543ECAC
      1468887976      263256        
      1469151232   484372480      3  GPT part - EBD0A0A2-B9E5-4433-87C0-68B6B72699C7
      1953523712        1423        
      1953525135          32         Sec GPT table
      1953525167           1         Sec GPT header
    gdisk has this to say:
    iMac:/ michthom$ sudo gdisk /dev/disk1
    Password:
    GPT fdisk (gdisk) version 0.8.10
    Warning: Devices opened with shared lock will not have their
    partition table automatically reloaded!
    Partition table scan:
      MBR: hybrid
      BSD: not present
      APM: not present
      GPT: present
    Found valid GPT with hybrid MBR; using GPT.
    Command (? for help): x
    Expert command (? for help): o
    Disk size is 1953525168 sectors (931.5 GiB)
    MBR disk identifier: 0x4F5BB38B
    MBR partitions:
    Number  Boot  Start Sector   End Sector   Status      Code
       1                     1       409639   primary     0xEE
       2                409640   1468887975   primary     0xAF
       3            1469151232   1953523711   primary     0x0B
    Expert command (? for help): p
    Disk /dev/disk1: 1953525168 sectors, 931.5 GiB
    Logical sector size: 512 bytes
    Disk identifier (GUID): 3E1D7EF9-F86E-4552-8F40-BE9754C3C73F
    Partition table holds up to 128 entries
    First usable sector is 34, last usable sector is 1953525134
    Partitions will be aligned on 8-sector boundaries
    Total free space is 264685 sectors (129.2 MiB)
    Number  Start (sector)    End (sector)  Size       Code  Name
       1              40          409639   200.0 MiB   EF00  EFI System Partition
       2          409640      1468887975   700.2 GiB   AF00  Internal
       3      1469151232      1953523711   231.0 GiB   0700  BOOTCAMP
    Any help / pointers gratefully accepted!
    Mike

    Thanks to Loner T and some more reading, I think I'm now sorted out.
    I found that marking the first partition on the USB stick as Active made no difference - my only option was to boot from the "EFI boot" option at startup (when holding down the alt/option key).
    So to get the Windows installer to behave, I used gdisk to write a new protective MBR before rebooting to the USB stick, as shown below.
    With the protective MBR in place (rather than hybrid), the Windows installer was happy to reformat the chosen partition and the installation began.
    I'll try to report back once all is installed and working, but once again I owe my sanity to the generosity and patience of strangers!
    Mike
    bash-3.2# gdisk /dev/disk0
    GPT fdisk (gdisk) version 0.8.10
    Warning: Devices opened with shared lock will not have their
    partition table automatically reloaded!
    Partition table scan:
      MBR: hybrid
      BSD: not present
      APM: not present
      GPT: present
    Found valid GPT with hybrid MBR; using GPT.
    Command (? for help): x
    Expert command (? for help): o
    <snipped>
    Number  Boot  Start Sector  End Sector  Status      Code
      1                    1      409639  primary    0xEE
      2                409640  1468887975  primary    0xAF
      3            1469151232  1953523711  primary    0x0B
    Expert command (? for help): p
    <snipped>
    Number  Start (sector)    End (sector)  Size      Code  Name
      1              40          409639  200.0 MiB  EF00  EFI System Partition
      2          409640      1468887975  700.2 GiB  AF00  Internal
      3      1469151232      1953523711  231.0 GiB  0700  BOOTCAMP
    Expert command (? for help): v
    No problems found. 264685 free sectors (129.2 MiB) available in 3
    segments, the largest of which is 263256 (128.5 MiB) in size.
    Expert command (? for help): x
    <snipped>
    n create a new protective MBR
    <snipped>
    Expert command (? for help): n
    Expert command (? for help): w
    Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING
    PARTITIONS!!
    Do you want to proceed? (Y/N): y
    OK; writing new GUID partition table (GPT) to /dev/disk0.
    Warning: Devices opened with shared lock will not have their
    partition table automatically reloaded!
    Warning: The kernel may continue to use old or deleted partitions.
    You should reboot or remove the drive.
    The operation has completed successfully.
    bash-3.2# gdisk /dev/disk0
    GPT fdisk (gdisk) version 0.8.10
    Warning: Devices opened with shared lock will not have their
    partition table automatically reloaded!
    Partition table scan:
      MBR: protective
      BSD: not present
      APM: not present
      GPT: present
    Found valid GPT with protective MBR; using GPT.
    Command (? for help): x
    Expert command (? for help): o
    Disk size is 1953525168 sectors (931.5 GiB)
    MBR disk identifier: 0x00000000
    MBR partitions:
    Number  Boot  Start Sector  End Sector  Status      Code
      1                    1  1953525167  primary    0xEE
    Expert command (? for help): p
    <snipped>
    Number  Start (sector)    End (sector)  Size      Code  Name
      1              40          409639  200.0 MiB  EF00  EFI System Partition
      2          409640      1468887975  700.2 GiB  AF00  Internal
      3      1469151232      1953523711  231.0 GiB  0700  BOOTCAMP

  • Create a GPT partition table and format with a large volume (solved)

    Hello,
    I'm having trouble creating a GPT partition table for a large volume (~6T). It is a RAID 5 (hardware) with 3 hard disk drives having a size of 3T each (thus the resulting 6T volume).
    I tried creating a GPT partition table with gdisk but it just fails at creating it, stopping here (I've let it run for like 3 hours...):
    Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING
    PARTITIONS!!
    Do you want to proceed? (Y/N): y
    OK; writing new GUID partition table (GPT) to /dev/md126.
    I also tried with parted but I get the same result. Out of luck, I created a GPT partition table from Windows 7 and  2 NTFS partitions (15G and the rest of space for the other) and it worked just fine. I then tried to format the 15G partition as ext4 but, as for gdisk, mkfs.ext4 will just never stop.
    Some information:
    fdisk -l
    Disk /dev/sda: 256.1 GB, 256060514304 bytes, 500118192 sectors
    Units = sectors of 1 * 512 = 512 bytes
    Sector size (logical/physical): 512 bytes / 512 bytes
    I/O size (minimum/optimal): 512 bytes / 512 bytes
    Disk label type: dos
    Disk identifier: 0xd9a6c0f5
    Device Boot Start End Blocks Id System
    /dev/sda1 * 2048 104861695 52429824 83 Linux
    /dev/sda2 104861696 466567167 180852736 83 Linux
    /dev/sda3 466567168 500117503 16775168 82 Linux swap / Solaris
    Disk /dev/sdb: 3000.6 GB, 3000592982016 bytes, 5860533168 sectors
    Units = sectors of 1 * 512 = 512 bytes
    Sector size (logical/physical): 512 bytes / 4096 bytes
    I/O size (minimum/optimal): 4096 bytes / 4096 bytes
    Disk label type: dos
    Disk identifier: 0x00000000
    Device Boot Start End Blocks Id System
    /dev/sdb1 1 4294967295 2147483647+ ee GPT
    Partition 1 does not start on physical sector boundary.
    Disk /dev/sdc: 3000.6 GB, 3000592982016 bytes, 5860533168 sectors
    Units = sectors of 1 * 512 = 512 bytes
    Sector size (logical/physical): 512 bytes / 4096 bytes
    I/O size (minimum/optimal): 4096 bytes / 4096 bytes
    Disk /dev/sdd: 3000.6 GB, 3000592982016 bytes, 5860533168 sectors
    Units = sectors of 1 * 512 = 512 bytes
    Sector size (logical/physical): 512 bytes / 4096 bytes
    I/O size (minimum/optimal): 4096 bytes / 4096 bytes
    Disk label type: dos
    Disk identifier: 0x00000000
    Device Boot Start End Blocks Id System
    /dev/sdd1 1 4294967295 2147483647+ ee GPT
    Partition 1 does not start on physical sector boundary.
    Disk /dev/sde: 320.1 GB, 320072933376 bytes, 625142448 sectors
    Units = sectors of 1 * 512 = 512 bytes
    Sector size (logical/physical): 512 bytes / 512 bytes
    I/O size (minimum/optimal): 512 bytes / 512 bytes
    Disk label type: dos
    Disk identifier: 0x5ffb31fc
    Device Boot Start End Blocks Id System
    /dev/sde1 * 2048 625139711 312568832 7 HPFS/NTFS/exFAT
    Disk /dev/md126: 6001.1 GB, 6001143054336 bytes, 11720982528 sectors
    Units = sectors of 1 * 512 = 512 bytes
    Sector size (logical/physical): 512 bytes / 4096 bytes
    I/O size (minimum/optimal): 65536 bytes / 131072 bytes
    Disk label type: dos
    Disk identifier: 0x00000000
    Device Boot Start End Blocks Id System
    /dev/md126p1 1 4294967295 2147483647+ ee GPT
    Partition 1 does not start on physical sector boundary.
    WARNING: fdisk GPT support is currently new, and therefore in an experimental phase. Use at your own discretion.
    gdisk -l on my RAID volume (/dev/md126):
    GPT fdisk (gdisk) version 0.8.7
    Partition table scan:
    MBR: protective
    BSD: not present
    APM: not present
    GPT: present
    Found valid GPT with protective MBR; using GPT.
    Disk /dev/md126: 11720982528 sectors, 5.5 TiB
    Logical sector size: 512 bytes
    Disk identifier (GUID): 8E7D03F1-8C3A-4FE6-B7BA-502D168E87D1
    Partition table holds up to 128 entries
    First usable sector is 34, last usable sector is 11720982494
    Partitions will be aligned on 8-sector boundaries
    Total free space is 6077 sectors (3.0 MiB)
    Number Start (sector) End (sector) Size Code Name
    1 34 262177 128.0 MiB 0C01 Microsoft reserved part
    2 264192 33032191 15.6 GiB 0700 Basic data partition
    3 33032192 11720978431 5.4 TiB 0700 Basic data partition
    To make things clear: sda is an SSD on which Archlinux has been freshly installed (sda1 for root, sda2 for home, sda3 for swap), sde is a hard disk drive having Windows 7 installed on it. My goal with the 15G partition is to format it so I can mount /var on the HDD rather than on the SSD. The large volume will be for storage.
    So if anyone has any suggestion that would help me out with this, I'd be glad to read.
    Cheers
    Last edited by Rolinh (2013-08-16 11:16:21)

    Well, I finally decided to use a software RAID as I will not share this partition with Windows anyway and it seems a better choice than the fake RAID.
    Therefore, I used the mdadm utility to create my RAID 5:
    # mdadm --create --verbose /dev/md0 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1
    # mkfs.ext4 -v -m .1 -b 4096 -E stride=32,stripe-width=64 /dev/md0
    It works like a charm.

  • Partition table corrupted after installing OSX10.8.3

    I installed OSX 10.8.3 from the Mac App Store on Friday and after installing, my macbook rebooted and a grey bar appeared at the bottom of the screen like it was updating the EFI...
    After waiting the bar to be full (apprx 45 minutes), it simply stopped...
    I tried restarting and the bar reappeared... So I decided to reboot in Verbose and saw my disk being repaired once, twice, 3 times and then nothing more...
    I then booted on my one week old clone on an external disk (thank god I had one) and checked the internal disk with the following :
    Disk util (GUI)
    Disk util (Terminal)
    Testdisk and pdisk
    Data Rescue 3
    Everything seems ok with reading the information on the disk, but impossible to mount/unmount the OS X partition
    But the partition table is not right...
    I need to be able to use my computer so I might erase and reinstall everything today,
    But if someone has an explanation to this mess I want to know it...
    Macbook Pro early 2011
    2.7GHz Intel i7
    RAM 8Go

    I tried burning the firmware updater to disc, but I when I try to boot from it, it says "No bootable device — insert boot disk and press any key.” This is with a an external firewire dvd burner. But I also tried the same disc with another MBP that still has its original internal superdrive, and I got the same error there. That MBP can boot from the Crucial SSD firmware disc though, so I don't know what the deal is.
    I'd gotten rid of my bootcamp partition a good while ago since VMWare had been taking care of any Windows needs I had just fine, but I still had a Winclone backup of my old bootcamp partition. So I restored it to a new partition, booted into Windows 7, and installed the Intel SSD Toolkit. But every time I tried to run it, it just crashed on me. I watched it in the task manager, and it would appear in the process list for a while and then just disappear.
    I've already ordered a bigger Crucial M4 to replace the X-25M (it was getting a bit full anyway), so I hope things go better with it. Thanks for trying to help though, everybody.

  • [SOLVED] The best partition table for Archlinux?

    Hi.
    I am very confused whit the partition table which I sould use.
    So, which partition table is the best? Which you use?
    Have a nice day
    Last edited by feler (2008-10-19 10:41:20)

    I am a fan of reiserfs so I use it for everything except boot (where I use ext2).
    I strongly advice you to use ReiserFS for your /var/ because it is the fastest when dealing with small files, which greatly improves pacman performance.
    For everything else - it depends on what type of files does your system mostly hold...

  • [SOLVED] RAID0 Array - Unknown Partition Table

    I recently reinstalled my Arch system with a RAID0 array, and I've noticed something different this time around during boot.
    When the mdadm hook is initialized it will stop the array, check it, then start it. Once it's started it will say,
    md0: unknown partition table
    And continue to the next array.
    I believe this is fine since the system doesn't stall or anything during bootup. The concern I have is when the system then tries to activate the RAID arrays. It will show,
    Activating RAID Arrays [FAIL]
    I've looked this up, http://bbs.archlinux.org/viewtopic.php?id=90415 and apparently it's nothing to be worried about. However, it didn't do that when I had my system installed not 20 minutes before (up to date).
    I've created the mdadm configuration file as such,
    rm /mnt/etc/mdadm.conf
    mdadm --examine --scan >> /mnt/etc/mdadm.conf
    Apparently, this message can be removed so it doesn't show fail on startup by commenting out the part in /etc/rc.sysinit where it assembles the RAID, lines 121-123. I'm still uneasy with it though, I'm just looking for some further insight on this subject.
    Why doesn't my md0 device have a partition table and what is the system doing that causes the assembly to fail?
    Edit - It might be important to note that I'm trying to make 3 partitions of the following size,
    /                      10GB
    /home         ~4TB
    /boot              50MB
    Thanks!
    Last edited by nerditup (2010-06-14 04:39:35)

    Update: This behaviour is normal.
    The partition table for a RAID array is not specified anywhere because the partition table is setup on the actual devices. In my case I have two partition tables set on /dev/sda and /dev/sdb, therefore /dev/md0 doesn't need any partition table.
    The code,
    #If necessary, find md devices and manually assemble RAID arrays
    if [ -f /etc/mdadm.conf -a "$(/bin/grep ^ARRAY /etc/mdadm.conf 2>/dev/null)" ];
    then
    status "Activating RAID arrays" /sbin/mdadm --assemble --scan
    fi
    will check mdadm.conf for any arrays that are setup and try to assemble them. Since the arrays are assembled already by the mdadm hook, then the --assemble parameter will return an error. This is the reason for the [FAIL] message.
    Since this is understood and not an actual "error", it is safe to comment out these lines in rc.sysinit. In fact, these lines are useless and should be taken out completely.
    The reason why it didn't show up last time was because I didn't properly setup my mdadm.conf file on the previous install. This process made sure they were loaded, but if you follow the wiki and properly setup the mdadm.conf file then you don't need this line of code at all in your rc.sysinit.
    Last edited by nerditup (2010-06-14 04:39:21)

  • Partition table messed up [SOLVED]

    So my problem is that the other one of my hard disks losed it's partition table after I installed Windows XP on it. I deleted partition to get space for XP and installed it on empy partition. Then in Arch I did grub-install. This got me into this so I can't view my partitons on either gParted or QTParted (which crashes when trying to watch hda). Also I can't use command "ls" in /home or it's subdirectories which is on different, fully working disk.
    So, I can use and mount these partitons which I can't see with gParted.
    fdisk tells me this:
    Disk /dev/hda: 203.9 GB, 203928109056 bytes
    255 heads, 63 sectors/track, 24792 cylinders, total 398297088 sectors
    Units = sectors of 1 * 512 = 512 bytes
    Device Boot Start End Blocks Id System
    /dev/hda1 * 63 40965749 20482843+ 7 HPFS/NTFS
    /dev/hda2 40965750 398267414 178650832+ f W95 Ext'd (LBA)
    /dev/hda3 286728183 398267414 55769616 b W95 FAT32
    /dev/hda5 40965876 286728119 122881122 83 Linux
    hda3 should be ext3 like hda5.
    So is there any way to get my partitons back without losing any data?

    Harr1l wrote:But is there any help for that I can't use "ls" in certain directories?
    I don't know. Are you sure that filesystem has no errors? Did you do fsck?
    IIRC testdisk can rebuild filesystem from scratch.

Maybe you are looking for