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.

Similar Messages

[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.

Snow leopard messed up my external drives HFS partition table.

I bought a 500gb Verbatim external store 'n' go hard drive already formated in HFS+ with FW and USB3 interface and had been using fine with over FW for a couple of months. Once when the cable was unplugged by mistake (The sockets are all jigly, don't know why) I couldn't mount the drive but then I used the USB cable and it worked fine.
I kept on using in on FW till one day I was low on battery while I was using the external drive and my mac just switched off! It doesn't, for a misterious reason give me the low on power message anymore. When switched the computer back on my mac couldn't read the drive. I was getting an actual error message saying that the drive was not readable. Tried the usb cable but I was getting the same message. I went to the genius bar and by using disk warrior we were able to get the folders and the files on the root of the drive but nothing inside those folders and there should be 4 levels of folders.
Now my guess is that something somehow messed up the partition table but I might be wrong. Does anyone know of any tool or any way I could restore my lost data?
Any help will be very appreciated!

It is still an NTFS partition and it cannot be read to reformat unless the disk is repartitioned . An entire NTFS disk could be repartitioned but I don't think one existing non readable partition can be converted to an HFS partition which is why OSX has the error.
Message was edited by: Kangaroos on the prowl

[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.

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.

[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

[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.)

[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.

[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)

Ubuntu wrecked partition table. Help to fix?

(Macbook Pro 2013 15" Crystalwell 4 Core, 500GB SSD 16GB RAM)
I should have known that installing Ubuntu next to Bootcamp was a bad idea.
So here's what's up... Before this whole debacle began I had two separate partitions on my SSD. The primary partition was for Mavericks with 300GB. The second partition was to a Bootcamped Windows 7 with 150 GB of space. I left 50GB free between the two, which still left me at
disk0s1 for EFI, ~200 MB
disk0s2 for Macintosh HD, 300 GB
disk0s3 for Recovery HD 650 MB
disk0s4 for Bootcamp 148 GB
Here's where my problem began. Genius me decided to attempt to install Ubuntu via live USB onto the 50GB space in between. I have reFIT installed so this wasn't a problem. After loading into Ubuntu and realizing that it wouldn't load into the 50GB space, I rebooted and installed alongside Windows (through the Ubuntu live usb) following the install GUI Prompt.
The installation failed after it got hung on a CRON command and drained the battery from my unplugged computer sitting next to me in my bed (I fell asleep waiting for it to finish, even though it was at 100% battery when it started the installation). When I woke up my computer was dead, so I plugged it in. I started reFIT and booted into Windows after seeing that Ubuntu wasn't there. I was given the "Choose OS" prompt from Windows and Ubuntu wouldn't load, so I said screw it and went back to Mavericks. When I opened my Disk utility partitions table to see where it might have gone wrong....
Great Odin's Raven.
I now had ext4 partitions sitting above my bootcamp partition and linux-swap partitions below it. Absolutely no free space. I switched back to Windows, avoiding the failed Ubuntu OS, and uninstalled wubi from Windows (the universal uninstall for ubuntu, I used the Windows "uninstall application" application from Control Center), hopefully deleting the mess it had made of my drive table.
It didn't.
Since I couldn't delete the partitions back to free space around my bootcamp volume using Disk utility (insufficient hfs+ permissions or something like that), I decided to take a more agressive option. I installed partedMagic onto a live USB and once again rebooted my computer into the live USB. I went in and using gParted removed the partitions in front of the bootcamp volume and behind it reducing them to empty space. Good! Hoping for the best I went back to reFIT and booted into Windows...
"No bootable device -- insert boot disk and press any key"
Well crap.
After some more research into why this wasn't working, I was sure that somehow my EFI wasn't loading the right area of my hard drive. Then I think I found out what happened. I ran diskutil list from terminal and saw this..
IceMan-HomeBase:~ Tim$ diskutil list
/dev/disk0
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *500.3 GB   disk0
   1:                        EFI EFI                     209.7 MB   disk0s1
   2:                  Apple_HFS Macintosh HD            300.2 GB   disk0s2
   3:                  Apple_HFS Recovery HD             650.0 MB   disk0s3
   4:       Microsoft Basic Data BOOTCAMP                148.0 GB   disk0s6
disk0s6. There's the problem. Mac doesn't like anything beyond disk0s4, which is where Bootcamp was originally and where it should be now, at disk0s4.
If it were merely an issue of copying the bootcamp volume and repartitioning the hard drive, that wouldn't be a problem, but even WinClone doesn't like this volume. When I tried to do a copy, it threw an error saying "Invalid partition ID of 6"
Here is my question.
Is there a way to change the IDENTIFIER back to disk0s4 from disk0s6 and save my Windows 7 partition, is there some other way to save my files to a backup and clean install, or is he dead, Jim?
Sorry if this was a little long-winded, but I figured too much information would be better than not enough.
Thank you in advance for anyone brave enough to read this.
TL;DR
Partition table went bogus because of a bad Ubuntu OS install. Windows can't find a bootable device. Disk0s4 is now disk0s6. Possible way to change this?

Problem solved, I used iPartition to resize the partition back to its original size after which I could copy all data off.

How to fix a faulty partition table, How to fix a faulty partition table

I have a 400gb partition on my 500gb HD, the remaining 100gb was split up in 3 partitions. I deleted 2 of these partitions, restarted and now Disk Utility claims my 400gb drive is now 53gb, accessing files has become impossible.
I can still see all the files listed but am unable to open them or copy them, I get a -36 error.
I have thrown Disk Utility, DiskWarrior, TechTool Pro and some lesser known tools at it but none of them wants to repair the volume.
Sounds to me like a busted partition table, after all that was all that was altered, in theory I should be able to access my files. Does anyone have any suggestions on how to fix this?

Problem solved, I used iPartition to resize the partition back to its original size after which I could copy all data off.

How to import partitioned tables in different tablespace

Hi everyone,
I try to import the partitioned tables in different tablespace.
Consider the following situation:
I have a dump file which is created by using "Export" utility. Some data are in partitioned tables, some of them are in non-partitioned tables. Also, all tables are located in "MYTBS" tablesapce. I try to import all data from this dump file to another database. I didn't get error messages when importing the data from non-partitioned tables. However, I got error message when importing the data from partitioned tables. The error message is: tablespace 'MYTBS' does not exist.
I just want to how I can solve this problem other than create 'MYTBS' tablespace for my new database.
Thanks in advance.
Angel

Hi,
I got the following error message:
IMP-00017: following statement failed with ORACLE error 959:
"CREATE TABLE "FACILITYCONNECTION",....., "CONNECTIONTYPE" "
"NUMBER(1, 0) NOT NULL ENABLE) PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 25"
"5 PARALLEL ( DEGREE DEFAULT INSTANCES 1) NOLOGGING STORAGE( PCTINCREASE 0) "
"TABLESPACE "MYTBS" PARTITION BY RANGE ("CONNECTIONTYPE" ) (PARTITION "
""EXT" VALUES LESS THAN (1) PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255 S"
"TORAGE(INITIAL 65536) TABLESPACE "MYTBS" NOLOGGING, PARTITION "FAC" VA"
"LUES LESS THAN (2) PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255 STORAGE(I"
"NITIAL 65536) TABLESPACE "MYTBS" NOLOGGING )"
IMP-00003: ORACLE error 959 encountered
ORA-00959: tablespace 'MYTBS' does not exist
Thanks.
Angel

Analyse a partitioned table with more than 50 million rows

Hi,
I have a partitioned table with more than 50 million rows. The last analyse is on 1/25/2007. Do I need to analyse him? (query runs on this table is very slow).
If I need to analyse him, what is the best way? Use DBMS_STATS and schedule a job?
Thanks

A partitioned table has global statistics as well as partition (and subpartition if the table is subpartitioned) statistics. My guess is that you mean to say that the last time that global statistics were gathered was in 2007. Is that guess accurate? Are the partition-level statistics more recent?
Do any of your queries actually use global statistics? Or would you expect that every query involving this table would specify one or more values for the partitioning key and thus force partition pruning to take place? If all your queries are doing partition pruning, global statistics are irrelevant, so it doesn't matter how old and out of date they are.
Are you seeing any performance problems that are potentially attributable to stale statistics on this table? If you're not seeing any performance problems, leaving the statistics well enough alone may be the most prudent course of action. Gathering statistics would only have the potential to change query plans. And since the cost of a query plan regressing is orders of magnitude greater than the benefit of a different query performing faster (at least for most queries in most systems), the balance of risks would argue for leaving the stats alone if there is no problem you're trying to solve.
If your system does actually use global statistics and there are performance problems that you believe are potentially attributable to stale global statistics and your partition level statistics are accurate, you can gather just global statistics on the table probably with a reasonably small sample size. Make sure, though, that you back up your existing statistics just in case a query plan goes south. Ideally, you'd also have a test environment with identical (or nearly identical) data volumes that you could use to verify that gathering statistics doesn't cause any problems.
Justin

Does sql server could export a partition from a partition table ?

Dear :
Does sql server could export a partition from a partition table ?
For example, I need to export all old partition,which is '2013' and drop them. It is easy in oracle. but how to do with sql
server 2012 ?

where do you want it to be exported to? Another server instance? if yes you can do piecemeal restore if partition is in a separate filegroup and you're on full recovery model
http://msdn.microsoft.com/en-IN/library/ms177425.aspx
Please Mark This As Answer if it helps to solve the issue Visakh ---------------------------- http://visakhm.blogspot.com/ https://www.facebook.com/VmBlogs

Partition table messed up [SOLVED]

Similar Messages

Maybe you are looking for