OracleVM3 poolfs superblock repair

Hello!
Simple question. :) We have a running production Oracle VM 3 cluster. Accidentally, while adding more volumes from storage system to VM cluster, we labeled OCFS2 poolfs device with GPT using parted. Just missed one letter in device specification. We did not created any partitions on this device just 'label gpt'
+[root@ovsru0240vh011 0004fb0000050000163f4d5d7ce8058b]# parted /dev/sdb+
GNU Parted 1.8.1
Using /dev/sdb
Welcome to GNU Parted! Type 'help' to view a list of commands.
+(parted) p+
Model: IBM 2145 (scsi)
Disk /dev/sdb: 208GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Number Start End Size File system Name Flags
+(parted)+
Of course, now we can not clone any VM, because
Server error message: 'Unable to query ocfs2 device "/dev/mapper/36005076802808245e000000000000073": open: Bad magic number in superblock while opening context for device /dev/mapper/36005076802808245e000000000000073\r\nNo device open\nNo device open\n'
+" on server "c4:42:bb:1d:65:0f:e1:11:8c:76:5c:f3:fc:da:c1:90" associated with object "0004fb0000120000c89af1d774f5ca58.img"+
Is it safe to run
+# fsck.ocfs2 -f -r 2 /dev/sdb+
on mounted drive? We do not want to stop our cluster it hosts about 30 VMs
We are covered with Oracle support but just would like to check here first
Big thanks in advance!!
Regards,
Kirill
P.S. Just submitted an SR 3-5907145111
Edited by: Kirill.Boyko on Jul 3, 2012 12:37 AM

Just an update.SR is resolved
We dismounted poolfs, corrected superblock with fsck.ocfs2 -r 2 and then mounted back
Everything was nice, we did not stop any VM in cluster
Regards
Kirill

Similar Messages

[SOLVED] Arch Linux Duke (2007) Fails to Boot

Folks, I have a unique and challenging problem that has exhausted my Arch Linux skills, and so I am now turning to you.
I have a vintage Pentium Pro 200 system (that’s 200 MHz folks! – 200 MHz 686 architecture – the original 686!), two CPUs, running a dual boot between Windows NT 4.0 and Arch Linux Duke (2007). It has 512 MB of RAM and a 120 GB hard drive, partitioned up between Windows NT and Linux. I built this system new in 2007, hence the dated version of Arch. It has run like a charm all these years, granted not getting that much use. After about a year of no use at all, I fired the system up last week to help with a little research for a blog post I was writing on networking Windows NT 4.0 and Mac OS 8.6. Windows NT 4.0 fired right up with no issue, and after I was done testing what needed to be tested I tried to boot over to Arch.
After a year of disuse, Arch unexpectedly and stubbornly refused to boot. The boot process started up just fine, but towards the end, it declared that it could not mount the root file system on the root device and took a kernel panic and stopped. My Arch skills have gotten a bit rusty in the last few years, but I dusted them off and went to work. My guess was a file system or superblock error. Arch wouldn’t boot, but I dragged out my trusty RIPLinux 2.9 Rescue Live CD and fired it up. It came right up and ran, and I was able to mount the Arch partition and view all the files… everything seemed to be there; it just wouldn’t boot. Windows NT 4.0 AND RIPLinux both boot and run on the machine, so the hardware is fine as well.
A little information on the disk layout. Windows NT 4.0 is in the first partition on the hard drive. The extended partition has a second Windows NT 4.0 partition (sort of a /home partition for Windows NT 4.0), followed by the main Arch partition (the one I am trying to boot), followed by a swap partition and then the largest partition, which I use to share data between Arch and Windows NT 4.0 (I have loaded an ext2/3 driver into Windows NT 4.0 and it happily accesses the Linux partitions on the box).
RIPLinux’s e2fsck did find some issues with the Arch partition and I had it repair them all. I checked again afterwards that all the files were still there, and they were. With the partition now known to be clean, and the superblock repaired from one of the backups, all should have been well. However, Arch still wouldn’t (and still won’t) boot.
RIPLinux has a kind of a chain loader function, so I had it attempt to start up Arch for me. However, this was flummoxed by the fact that Arch addresses all my hard drive partitions as /dev/sdax and RIPLinux addresses them as /dev/hdax. Hence, without a common language, it was hard to get the one to start the other. Still, using this function, I have been able to get a crippled version of Arch running on the machine again. No modules had been loaded, and so it couldn’t do almost anything, but there it was (and is), Arch Linux Duke, at the CLI level. From there, I can see all the files, I can move freely in and out of my user account and the root account, but I can’t make the thing actually boot properly.
If you have read this far, you are a trooper. Summarizing what I know, the hardware is good, the file system is clean, the superblock is good, I can mount it cleanly from a live CD and I can chain load a crippled version of Arch. Here is the boot process blow-by-blow. When I try to do a normal boot, the Windows NT 4.0 loader passes control to the Lilo boot sector I have placed on hda1 (sda1 in Duke’s parlance). Lilo takes over, present a menu and when I select Duke, takes off. Arch Linux Duke starts to boot. It gets a good long way along, all the way along to:
:: Loading udev events [Pass]
:: Mount root Read-only
:: Checking file systems
This is where it stops.
The next thing I see is:
/dev/sda6
The superblock could not be read or does not describe a correct ext2 filesystem. If the device is valid and it really contains an ext2 filesystem (and not swap or ufs or something else) then the superblock is corrupt and you might try running e2fsck with an alternate superblock:
E2fsck –b 8193 <device>
I then get a sort of character based splash screen that says
**********FILE SYSTEM CHECK FAILED ****************************
* Please repair manually and reboot. Note that the root file system
* is currently mounted read-only. To remount it read-write, type:
* mount –n –o remount,rw /. When you exit the maintenance
* shell, the system will reboot automatically
Give root password for maintenance
At this point, I give the root password and enter the maintenance shell as root. I typed in “mount” and the first entry I got back is
/dev/sda6 on / type ext3 (rw)
This is exactly the root partition that the start up complains about. It is clearly there. I can see it, I can walk around it… it is clearly there. Why won’t it boot? Despite the message, the superblock is fine – it passes every test e2fsck can throw at it.
At this point, I did a “e2fsck /dev/hda6 (which is how RIPLinux would have passed it into Arch” and it says it is “clean”. I suspect that the Superblock message is because Arch sees root as sda6, while RIP passed it in as hda6...
Deciding to see what Arch would be seeing as it tried to set things up in the boot sequence, I tried the following next:
# mknod “/dev/root2” b 3 6
(“3” because RIPLinux refers to my hard drive as IDE, while Arch refers to it by major number “8”, which is SCSI. By the way, it IS an IDE drive – not sure why Arch insists on using the sdx nomenclature instead of hdx)
Then I entered “mount /dev/root2 /mnt/hda6” and “ls /mnt/hda6”
All was well. I can make the node, I can mount it, and I can see the contents. All is clearly well, but something is clearly wrong enough that Arch can’t boot.
I am totally out of ideas. I have tried every trick I know and am out of tricks. I would welcome any insights as to what I could try to get this venerable Arch installation back on its legs.
By the way, the key section of the /etc/lilo.conf file (lest anyone want to know) is:
image = /boot/vmlinuz26
root = /dev/sda6
label = ArchLinux-Duke
initrd = /boot/kernel26.img
read-only
I am stumped. Thanks in advance for any and all pointers you may be able to offer.
Last edited by mac57 (2014-06-02 17:42:21)

Folks, thanks for all your helpful comments, and I wanted to report back to you that I finally overcame the issue, and ArchLinux-Duke (2007) is once again executing flawlessly on my old Pentium Pro 200 system. I won't bother reporting here all the blind allies I went down as I tried to figure out what was wrong, but in the end, literally moments before I was about to give up and overwrite my Arch installation with a new Linux variant (antiX seemed well suited for such old and low power hardware), my attention was drawn to a note I had made in my files back in 2007 about a problem with similar symptoms. In that case, I had just deleted ZenWalk Linux from the hard drive (both Arch and Zen had been on the drive), and merged several partitions to make use of the newly free space. This had changed Arch's view of the drive lettering, and what had been its /dev/sddx root device was now /dev/sdcx. Arch failed to boot, throwing off the same errors I was seeing now. I wish I had recalled that note a month or so ago! It would have saved me a lot of work and a lot of frustration.
At any rate, as a last step, and testing the idea that maybe the drive lettering had changed for some reason, I repeatedly manually booted Arch, specifying root=/dev/sda6, then /dev/sdb6, then /dev/sdd6, and finally, /dev/sdc6. Eureka! Arch now considered itself to be on /dev/sdc6 whereas previously it had been on /dev/sda6. This got me part way there, but the boot failed at the filesystem check stage and threw me into root. I disabled the file system check in /etc/rc.sysinit and got farther. Then I cleaned up /etc/fstab to agree with the new sdc naming, and I was back on the air fully.
So, what had happened was that Arch had changed its view of the drive it was on from sda6 to sdc6. While I could not understand why this "sudden" change had occurred, at least I had a solution, and had Arch back up and running.
Trolling through the rest of my notes, I found the answer. In 2012, the Tekram SCSI card in the machine failed, and I ultimately replaced it with an Adaptec card. The Tekram card did not have a BIOS segment on it. The Adaptec card did. My guess is that this caused the two internal SCSI devices I have built into the system (Iomega ZIP and Jaz respectively) to be enumerated first, claiming the "sda" and "sdb". device names. That left "sdc" for the root device, and that is where Arch went next. This is my guess anyway.
I should have caught this issue back in 2012, at the time, but from my notes, I can see that I tested the new card thoroughly using the Windows NT 4.0 side of the machine, but never thought to bring up Arch as well. Hence, this problem lay dormant for two years, before I attempted to fire up Arch last month and blundered right into it.
It has not all been bad. I have learned more about the ext2 and ext3 file systems and superblocks in the intervening time than I will ever need to use. I have learned how to manually boot Linux on a machine whose BIOS is so old that it cannot address the disk cylinder that the kernel is on and I have completely refreshed the many general Linux skills that used to just flow from my finger tips. It has been a frustrating experience, but ultimately a successful and useful one.
Just wanted to let everyone know that this is now [SOLVED]. I would mark the post as such, but I don't see any obvious way to do that. Thanks again everyone.

Repair superblock? RAID5 volume crash

I have a fiber channel raid connected to my G5 Mac. Yesterday video and audio suddenly started dropping out on the volume. Audio was static and video would have all sorts of blocks and corruption.
This is the second time this has happened in the past few months. I am looking for advice on which component might be failing. It is RAID5 and the subsystem is reporting no disk errors. My thoughts are that the raids controller or maybe even the computers fiber channel card may be on its way out? The disk has since totally dropped off and can no longer be mounted.
I tried out a demo of data rescue to restore a few files and everything it returns is totally corrupt.
I will try out DiskWarrior next for rebuilding I suppose.
Any suggestions or advice would be appreciated.
Here's a bit of output from terminal:
edittheta$ /sbin/fsck_hfs -fdr /dev/rdisk3s2
** /dev/rdisk3s2
Using cacheBlockSize=32K cacheTotalBlock=1024 cacheSize=32768K.
Journal replay returned error = 6
** Checking Journaled HFS Plus volume.
** Checking Extents Overflow file.
** Checking Catalog file.
** Rebuilding Catalog B-tree.
hfsUNswapBTNode: invalid node height (1)
** Rechecking volume.
** Checking Journaled HFS Plus volume.
** Checking Extents Overflow file.
** Checking Catalog file.
Missing thread record (id = 32965)
Invalid extent entry (4, 832)
Incorrect block count for file A017C013_0805Q7001.R3D
(It should be 2097152 instead of 256)
Incorrect number of thread records
(4, 176)
CheckCatalogBTree: fileCount = 19939, fileThread = 19956
** Checking multi-linked files.
** Checking Catalog hierarchy.
Missing thread record (id = 38125)
Invalid volume file count
(It should be 19934 instead of 19939)
** Checking Extended Attributes file.
Overlapped extent allocation (file 3 Extents Overflow BTree)
extentType=0x0, startBlock=0x2da35, blockCount=0x1400, attrName=(null)
** Checking volume bitmap.
Volume Bit Map needs minor repair
** Checking volume information.
Invalid volume free block count
(It should be 573459245 instead of 1830097600)
invalid VHB nextCatalogID
invalid VHB attributesFile.clumpSize
Volume Header needs minor repair
(2, 0)
Verify Status: VIStat = 0xa800, ABTStat = 0x0000 EBTStat = 0x0000
CBTStat = 0x0800 CatStat = 0x00004230
** Repairing volume.
DoMinorRepair: Repair for type=-510 failed (err=32).
** The volume Colossus could not be repaired.
volume type is pure HFS+
primary MDB is at block 0 0x00
alternate MDB is at block 0 0x00
primary VHB is at block 2 0x02
alternate VHB is at block 14642907054 0x368c907ae
sector size = 512 0x200
VolumeObject flags = 0x07
total sectors for volume = 14642907056 0x368c907b0
total sectors for embedded volume = 0 0x00

Just to follow up... ended up using DiskWarrior to attempt to rebuild the disk. DiskWarrior was able to rebuild the directory structure and get the drive to mount. It errored at the very end with some sort of error code though.
I can copy all the files off now though most appear to have all sorts of digital gunk on images, videos, ect... very strange. Solution for now is to backup and reformat... will update if discover what caused this odd file corruption. Sad that 4TB of data is rendered basically useless with absolutely no sign of failure prior.

Cannot repair or erase external hard drive

I recently purchased a Transcend 1TB harddrive and partitioned it in two. One of those partitions can no longer be mounted. I cannot repair the disk or erase it. I would be happy if I could completely erase the whole hard drive and start from scratch. Can anyone offer any suggestions? The output from diskutil verifyVolume is
Started file system verification on disk4 James_TM
Checking storage system
Checking volume
disk3s2: Scan for Volume Headers
disk3s2: Scan for Disk Labels
Logical Volume Group 02004E72-5803-4B70-9E9C-63F6A68AEAA0 on 1 device
disk3s2: Scan for Metadata Volume
Logical Volume Group has a 16 MB Metadata Volume with double redundancy
Start scanning metadata for a valid checkpoint
Load and verify Segment Headers
Load and verify Checkpoint Payload
Load and verify Transaction Segment
Incorporate 0 newer non-checkpoint transactions
Load and verify Virtual Address Table
Load and verify Segment Usage Table
Load and verify Metadata Superblock
Load and verify Logical Volumes B-Trees
Logical Volume Group contains 1 Logical Volume
Load and verify 606252CC-9C2B-4006-BFE4-494D5CA8E592
Load and verify B379F48C-BD07-4702-AE92-D4E36BC031E7
Load and verify Freespace Summary
Load and verify Block Accounting
Load and verify Live Virtual Addresses
Newest transaction commit checkpoint is valid
Load and verify Segment Cleaning
The volume 02004E72-5803-4B70-9E9C-63F6A68AEAA0 appears to be OK
Checking file system
Error: -69845: File system verify or repair failed
Underlying error: 8: POSIX reports: Exec format error

]/dev/disk0
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *64.0 GB    disk0
   1:                        EFI EFI                     209.7 MB   disk0s1
   2:          Apple_CoreStorage                         63.2 GB    disk0s2
   3:                 Apple_Boot Recovery HD             650.0 MB   disk0s3
/dev/disk1
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *750.2 GB   disk1
   1:                        EFI EFI                     209.7 MB   disk1s1
   2:                  Apple_HFS Mac HD                  749.8 GB   disk1s2
/dev/disk2
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                  Apple_HFS Mac SSD                *62.8 GB    disk2
/dev/disk3
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *1.0 TB     disk3
   1:                        EFI EFI                     209.7 MB   disk3s1
   2:          Apple_CoreStorage                         667.0 GB   disk3s2
   3:                 Apple_Boot Boot OS X               134.2 MB   disk3s3
   4:          Apple_CoreStorage                         332.7 GB   disk3s4
   5:                 Apple_Boot Boot OS X               134.2 MB   disk3s5
/dev/disk4
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                  Apple_HFS Sonam_TM               *332.4 GB   disk4
/dev/disk5
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                  Apple_HFS James_TM               *666.7 GB   disk5

Can't repair Macintosh HD in Disk Utility (extended attributes)

Hi all,
I have a Retina Macbook Pro with one of them new fancy SSDs in it. I'm running 10.9.3 all up-to-date and am a bit computer-savvy, but I'm more than puzzled by what my Mac has been doing as of late.
When trying to install Windows via Bootcamp, I ran into an error message in the Partitioning step of the process. I hopped into Disk Utility, figuring I could simply partition from there (something in me trusts Disk Utility more than the Boot Camp Assistant). Partition failed!
I then executed the "Verify Disk" command in Disk Utility, only to be told I needed to restart from the Recovery Partition and use the "Repair Disk" function of Disk Utility then. Log of this whole event is at the end of this post, but the offending line seems to be
2014-06-12 20:59:30 -0400: Checking extended attributes file.
2014-06-12 20:59:30 -0400: (It should be 15783744 instead of 14437995)
I then restarted and followed these instructions. "Verify Disk" found no errors, nor did "Repair Disk." I rebooted, only to be met with the same problem!
Is there some sort of lower-level command I can use to repair my disk if I boot in Single User mode or something?
Thanks,
Nathan
2014-06-12 20:58:30 -0400: Disk Utility started.
2014-06-12 20:58:36 -0400: Verifying partition map for “APPLE SSD SD512E Media”
2014-06-12 20:58:36 -0400: Starting verification tool:
2014-06-12 20:58:36 -0400: Checking prerequisites
2014-06-12 20:58:36 -0400: Checking the partition list
2014-06-12 20:58:36 -0400: Checking for an EFI system partition
2014-06-12 20:58:36 -0400: Checking the EFI system partition’s size
2014-06-12 20:58:36 -0400: Checking the EFI system partition’s file system
2014-06-12 20:58:36 -0400: Checking all HFS data partition loader spaces
2014-06-12 20:58:36 -0400: Checking booter partitions
2014-06-12 20:58:36 -0400: Checking booter partition disk0s3
2014-06-12 20:58:36 -0400: Checking file system
2014-06-12 20:58:36 -0400: Checking Journaled HFS Plus volume.
2014-06-12 20:58:36 -0400: Checking extents overflow file.
2014-06-12 20:58:36 -0400: Checking catalog file.
2014-06-12 20:58:36 -0400: Checking multi-linked files.
2014-06-12 20:58:36 -0400: Checking catalog hierarchy.
2014-06-12 20:58:36 -0400: Checking extended attributes file.
2014-06-12 20:58:36 -0400: Checking volume bitmap.
2014-06-12 20:58:36 -0400: Checking volume information.
2014-06-12 20:58:36 -0400: The volume Recovery HD appears to be OK.
2014-06-12 20:58:36 -0400: Checking Core Storage Physical Volume partitions
2014-06-12 20:58:36 -0400: Checking storage system
2014-06-12 20:58:36 -0400: Checking volume
2014-06-12 20:58:36 -0400: disk0s2: Scan for Volume Headers
2014-06-12 20:58:36 -0400: disk0s2: Scan for Disk Labels
2014-06-12 20:58:36 -0400: Logical Volume Group D79A3F82-3153-4DCC-A58F-C9B3ADAD2F6E on 1 device
2014-06-12 20:58:36 -0400: disk0s2: Scan for Metadata Volume
2014-06-12 20:58:36 -0400: Logical Volume Group has a 16 MB Metadata Volume with double redundancy
2014-06-12 20:58:36 -0400: Start scanning metadata for a valid checkpoint
2014-06-12 20:58:36 -0400: Load and verify Segment Headers
2014-06-12 20:58:36 -0400: Load and verify Checkpoint Payload
2014-06-12 20:58:36 -0400: Load and verify Transaction Segment
2014-06-12 20:58:36 -0400: Incorporate 0 newer non-checkpoint transactions
2014-06-12 20:58:36 -0400: Load and verify Virtual Address Table
2014-06-12 20:58:36 -0400: Load and verify Segment Usage Table
2014-06-12 20:58:36 -0400: Load and verify Metadata Superblock
2014-06-12 20:58:36 -0400: Load and verify Logical Volumes B-Trees
2014-06-12 20:58:36 -0400: Logical Volume Group contains 1 Logical Volume
2014-06-12 20:58:36 -0400: Load and verify BDEE2B2F-6770-4707-AE0A-3862965E6414
2014-06-12 20:58:36 -0400: Load and verify B761A88F-B034-44A9-8F54-F7732861C825
2014-06-12 20:58:36 -0400: Load and verify Freespace Summary
2014-06-12 20:58:36 -0400: Load and verify Block Accounting
2014-06-12 20:58:36 -0400: Load and verify Live Virtual Addresses
2014-06-12 20:58:36 -0400: Newest transaction commit checkpoint is valid
2014-06-12 20:58:36 -0400: Load and verify Segment Cleaning
2014-06-12 20:58:36 -0400: The volume D79A3F82-3153-4DCC-A58F-C9B3ADAD2F6E appears to be OK
2014-06-12 20:58:36 -0400: The partition map appears to be OK
2014-06-12 20:58:36 -0400:
2014-06-12 20:58:36 -0400: Verifying volume “Macintosh HD”
2014-06-12 20:58:36 -0400: Starting verification tool:
2014-06-12 20:58:36 -0400: Checking storage system
2014-06-12 20:58:37 -0400: Checking volume
2014-06-12 20:58:37 -0400: disk0s2: Scan for Volume Headers
2014-06-12 20:58:37 -0400: disk0s2: Scan for Disk Labels
2014-06-12 20:58:37 -0400: Logical Volume Group D79A3F82-3153-4DCC-A58F-C9B3ADAD2F6E on 1 device
2014-06-12 20:58:37 -0400: disk0s2: Scan for Metadata Volume
2014-06-12 20:58:37 -0400: Logical Volume Group has a 16 MB Metadata Volume with double redundancy
2014-06-12 20:58:37 -0400: Start scanning metadata for a valid checkpoint
2014-06-12 20:58:37 -0400: Load and verify Segment Headers
2014-06-12 20:58:37 -0400: Load and verify Checkpoint Payload
2014-06-12 20:58:37 -0400: Load and verify Transaction Segment
2014-06-12 20:58:37 -0400: Incorporate 0 newer non-checkpoint transactions
2014-06-12 20:58:37 -0400: Load and verify Virtual Address Table
2014-06-12 20:58:37 -0400: Load and verify Segment Usage Table
2014-06-12 20:58:37 -0400: Load and verify Metadata Superblock
2014-06-12 20:58:37 -0400: Load and verify Logical Volumes B-Trees
2014-06-12 20:58:37 -0400: Logical Volume Group contains 1 Logical Volume
2014-06-12 20:58:37 -0400: Load and verify BDEE2B2F-6770-4707-AE0A-3862965E6414
2014-06-12 20:58:37 -0400: Load and verify B761A88F-B034-44A9-8F54-F7732861C825
2014-06-12 20:58:37 -0400: Load and verify Freespace Summary
2014-06-12 20:58:37 -0400: Load and verify Block Accounting
2014-06-12 20:58:37 -0400: Load and verify Live Virtual Addresses
2014-06-12 20:58:37 -0400: Newest transaction commit checkpoint is valid
2014-06-12 20:58:37 -0400: Load and verify Segment Cleaning
2014-06-12 20:58:37 -0400: The volume D79A3F82-3153-4DCC-A58F-C9B3ADAD2F6E appears to be OK
2014-06-12 20:58:37 -0400: Checking file system
2014-06-12 20:58:37 -0400: Performing live verification.
2014-06-12 20:58:37 -0400: Checking Journaled HFS Plus volume.
2014-06-12 20:58:37 -0400: Checking extents overflow file.
2014-06-12 20:58:37 -0400: Checking catalog file.
2014-06-12 20:58:59 -0400: Checking multi-linked files.
2014-06-12 20:59:30 -0400: Checking extended attributes file.
2014-06-12 20:59:30 -0400: (It should be 15783744 instead of 14437995)
2014-06-12 20:59:30 -0400: Error: This disk needs to be repaired using the Recovery HD. Restart your computer, holding down the Command key and the R key until you see the Apple logo. When the OS X Utilities window appears, choose Disk Utility.
2014-06-12 20:59:30 -0400:
2014-06-12 20:59:30 -0400: Disk Utility stopped verifying “Macintosh HD”: This disk needs to be repaired using the Recovery HD. Restart your computer, holding down the Command key and the R key until you see the Apple logo. When the OS X Utilities window appears, choose Disk Utility.
2014-06-12 20:59:30 -0400:

I'm having a similar problem with my G4 Desktop.
I have a 2nd internal hard drive and 2 FW Drives.
None of them are able to be verified or repaired using DU.
I get the following message: "Verify volume failed with error Could not unmount disk." And then some message about "make sure that all your files are closed."
I tried soft-booting by holding the shift-key down just as a trouble-shooting idea and I was able to verify and the drives were working well. However, when I restarted in normal mode I was not able to verify or repair.
What is my G4's problem? Why does it need to use that secondary drive in order to operate? What do I need to do to fix it?
Any suggestions?
G4 Dual 1.42 Mac OS X (10.4.6) 1 Gig Ram / 2 Internal Hard Drives

Superblock.. make my system unstable.

Yo, i tried a install in an old computer and superblock cause gnome to have serious issues and partition are almost broken..
i don't understand what to do with them..
Gparted before partioning : http://i.imgur.com/8L35M0A.png
Gparted when partionnated : http://i.imgur.com/y5RODDU.png
I get space used ,, when i clearly have nothing ..
I tried
dd if=/dev/zero of=/dev/sda
Not deleting the superblocks..
So i did :
mke2fs -n /dev/sda
/dev/sda is entire device, not just one partition!
Proceed anyway? (y,n) y
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
61054976 inodes, 244190646 blocks
12209532 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=0
7453 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
102400000, 214990848
i did :
e2fsck -b 32768 /dev/sda
e2fsck 1.42.8 (20-Jun-2013)
e2fsck: Bad magic number in super-block while trying to open /dev/sda
The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>
I wanna remove them from backing up in my partion, or repair them..
Edit : i think, i posted in a wrong section, 1000 sorry.
Last edited by localhostabc (2013-08-31 04:54:32)

i finaly found how to use e2fsck
I created a full ext4 partiition and run multiple command
e2fsck <SUPERBLOCK> /dev/sda1

[SOLVED] "The superblock could not be read..."

Good Evening.
In the beginning, I want to apologise if my English isn't as correct and comprehensible as I want it to be.
I am rather clueless Linux user with penchant for learning. I have used Slackware for some time, but I wanted to try out Arch because of it's superior package management, rolling release system and minimalism. I read through installation guides, and performed basic installation using 2009.08 CD without any problems. When I tried to boot into my new system I got following message:
:Mounting Root Read-only [DONE]
:Checking Filesystems [BUSY]
/dev/hda1:
and then
The superblock could not be read or does not describe a correct ext2 filesystem. If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock is corrupt and you might try running e2fsck with an alternate superblock:
e2fsck -b -8193 <device>
and finally
FILESYSTEM CHECK FAILED
Please repair manually and reboot. Note that the root file system is currently mounted read-only. To remount it read-write type:
mount -n -o remount,rw /
When you exit the maintenance shell the system will reboot automatically.
I tried to run fsck, of course, as well as e2fsck or remounting / read-write but I always got the second message "The superblock could not be read... etc.".
My partitioning scheme is kinda tricky, because I make no distinction beetween production and testing machine. What is interesting, when I wanted to look at it using cfdisk from my indispensable Knoppix DVD I got something like:
FATAL ERROR: Bad primary partition 0:
Partition ends in the final partial cylinder.
Press any key to exit cfdisk.
But when I tried with root privileges it worked, and my 80GB hard drive looks something like that:
hda1 Primary Linux ext3 (/)
hda2 Boot Primary NTFS
hda3 Primary Linux
hda5 Logical W95 FAT32
hda6 Logical BeOS fs
hda7 Logical Linux ext2 (boot)
hda8 Logical Linux ReiserFS (tmp)
hda9 Logical Linux ReiserFS (usr)
hda10 Logical Linux ReiserFS (var)
hda11 Logical Linux ext3 (home)
hda12 Logical Linux Swap/Solaris (swap)
Only hda1, hda7, hda8, hda9, hda10, hda11 and hda12 are part of my Arch installation. I'm currently booting Windows XP through GRUB from NTFS partition (hda2) too.
Does anyone know how to make my Arch working installation?
Last edited by Schirase (2010-07-14 13:14:03)

My bad, I actually didn't read Begginers' Guide very carefully. I didn't realize that setting this UUIDs in fstab is so important. Now my fstab looks something like that (mind that this is slightly different partitioning scheme):
# /etc/fstab: static file system information
# <file system> <dir> <type> <options> <dump> <pass>
devpts /dev/pts devpts defaults 0 0
shm /dev/shm tmpfs nodev,nosuid 0 0
/dev/cdrom /media/cd auto ro,user,noauto,unhide 0 0
/dev/dvd /media/dvd auto ro,user,noauto,unhide 0 0
#/dev/fd0 /media/fl auto user,noauto 0 0
UUID=7a6e9456-69d4-4346-bf4d-803e5f61f100 / ext3 defaults,noatime 0 1 #/dev/hda5
UUID=bf4e4d66-2658-4e39-b1f8-b84cc157ba72 /boot ext2 defaults 0 2 #/dev/hda6
UUID=d3a5e92f-454e-47f9-8bfa-86804a322e55 /tmp reiserfs defaults,notail 0 2 #/dev/hda7
UUID=5333292d-4f3d-45a9-aa44-9df8c930244b /usr reiserfs defaults,notail 0 2 #/dev/hda8
UUID=bb25bd08-eeaa-4732-93a6-87e238c06029 /var reiserfs defaults,notail 0 2 #/dev/hda9
UUID=38298476-ea3d-4d15-a5d2-8c221a20ebe8 swap swap defaults 0 0 #/dev/hda10
UUID=de1d9d94-09ef-4429-b63e-fddea5e81195 /home ext3 defaults,noatime 0 2 #/dev/hdb1
and I am happily using Arch right now. However, I have got strange non-critical issues with partitions and disks which I explained in http://bbs.archlinux.org/viewtopic.php? … 82#p791582.

Bad superblock on root slice

I booted up my machine yesterday, and got dumped out at the grub prompt. I booted from the CD, and after some investigation I found that the disk partition table was ok, and the Solaris VTOC appears to be fine as well. I was able to mount and access the /usr, /var, and /export file systems, but slice 0 with the root file system has a bad magic number in the superblock.
As I see it, I have a few options. newfs slice 0 and restore from the last dump, trust what newfs says about the alternate blocks and fsck away, or try to repair the superblock using fsdb. I figure that since the root file system is probably unrecoverable, I may as well try using fsdb. At best I might be able to recover the file system. At worst I learn about using fsdb before I newfs and restore.
Any ideas for things I may have missed, guides to using fsdb, estimates of my chances for success?

ewaller wrote:I believe that the abstraction provided by things like Microsoft Windows and KDE add to this confusion. Those systems create user interfaces that provide the illusion there is an underlying file system on Audio CDs. As long as you remember that it is an illusion, you might try "browsing" the Audio CDs with Dolphin and the Audio CD kioslave.
That is true. For end-users this is a convenient feature when using an OS because then they don't actually need to know the difference between Audio CD formats and CD-ROM formats - which in this case I was not aware of before now. Reading the wikipedia article on the Rainbow Books did clear things up.
karol wrote:Have you tried e.g. http://www.archlinux.org/packages/?name=cdfs ?
Thanks, I tried it and it froze my computer until I ejected my cd. I will try more of this later on.

[Solved] Filesystem check failed - manual repair too

Good Evening.
Recently my Arch box hang up and I had to reboot forcefully. I expected to get a filesysem scan. The messages on bootup say, that the filesystem check failed and I have to repair it manually. The exact error message is similar to http://bbs.archlinux.org/viewtopic.php?id=89394.
Then I log into the maintenance shell and try to run fsck -pck /dev/sdXX. But that doesn't work because it complains that the filesystem is no ext2-fs or the superblock is corrupt. I should try one of the backup superblocks. To figure out the backup superblocks, I tried mke2fs -n /dev/sdXX but that does not work either. Now it complains that /dev/sdXX does not exist! I looked in /dev and the partitions really don't show up. Where are they? I mean, the maintenance shell works on the / partition, or does it?
To cut a long story short, I can't check my partitions and I don't know any other way how to fix the problem. The next ArchLive CD is 500 km away.
I appreciate any help.
Greetz,
haunted
EDIT:
Ok, I solved the problem as I got my ArchLive CD. If it's to anybody's use, that's the procedure I went through:
I inserted the CD and booted from it. I ran the e2fsck several times. First I did an overall check (e2fsck -v /dev/sdaX) on my Arch partition which I had to do manually i.e. type "y" to every inconsisteny found, then updated the badblock list (e2fsck -vc /dev/sdaX) and checked the partition again.
I rebooted the system without the CD to look if I succeded repairing the hdd. Eventually I deleted the /sys mountpoint in the procedure and had to create it again via ArchLive CD. After the next reboot it complained that the superblock's timestap was written in the future. Rebooting with the CD again, checking again and rebooting without CD again.
It wasn´t of any use and Arch complained again. Then I simply rebooted the system (without CD) again and on start up it stopped complaining and did a normal check on the Arch partition, completed the check and went on loading as normal. System repaired.
Last edited by hauntergeist (2010-02-08 11:11:59)

It went ahead and fixed the filesystem, however some of the files (music files mostly) are corrupted and won't play. I have backups of those so it's no big lose, as long as the file system works now.

Disk Utiliy error on Disk Repair - Unable to bootstrap transaction group cksum mismatch

When I try to Repair my Hard Disk on Disk Utility (command+R recovery mode) it shows this error:
My hard disk is encrypted with filevault 2 and Disk Utility seems to be unable to decrypt it.
Can I do something with bash? Thank you.
Checking volume.
disk0s2: Scan for Volume Headers
disk0s2: Scan for Disk Labels
Invalid Disk Label @ 319200587776: cksum mismatch
Invalid Disk Label @ 319204782080: cksum mismatch
Logical Volume Group 573A27F3-05AE-45D8-8C36-C2190AA709A0 spans 1 device
Logical Volume Group has a 16 MB Metadata Volume with double redundancy
Start scanning metadata for a valid checkpoint
Load and verify Segment Headers
Load and verify Checkpoint Payload
Load and verify Transaction Segment
Incorporate 0 newer non-checkpoint transactions
Load and verify Virtual Address Table
Load and verify Segment Usage Table
Load and verify Metadata Superblock
Load and verify Logical Volumes B-Trees
Logical Volume Group contains 1 Logical Volumes
Load and verify EBE1F6D9-1560-4837-BFE4-A8C45CE0252A
Load and verify 1F61CB62-C529-4301-AF2E-B71933C040C3
Unable to bootstrap transaction group 2601: cksum mismatch
Continue scanning metadata for an older checkpoint
Load and verify Segment Headers
Load and verify Checkpoint Payload
Load and verify Transaction Segment
Incorporate 0 newer non-checkpoint transactions
Load and verify Virtual Address Table
Load and verify Segment Usage Table
Load and verify Metadata Superblock
Load and verify Logical Volumes B-Trees
Logical Volume Group contains 1 Logical Volumes
Load and verify EBE1F6D9-1560-4837-BFE4-A8C45CE0252A
Load and verify 1F61CB62-C529-4301-AF2E-B71933C040C3
Unable to bootstrap transaction group 2600: cksum mismatch
Continue scanning metadata for an older checkpoint
Load and verify Segment Headers
Load and verify Checkpoint Payload
Load and verify Transaction Segment
Incorporate 0 newer non-checkpoint transactions
Load and verify Virtual Address Table
Load and verify Segment Usage Table
Load and verify Metadata Superblock
Load and verify Logical Volumes B-Trees
Logical Volume Group contains 1 Logical Volumes
Load and verify EBE1F6D9-1560-4837-BFE4-A8C45CE0252A
Load and verify 1F61CB62-C529-4301-AF2E-B71933C040C3
Unable to bootstrap transaction group 2599: cksum mismatch
Continue scanning metadata for an older checkpoint
Load and verify Segment Headers
Load and verify Checkpoint Payload
Load and verify Transaction Segment
Incorporate 0 newer non-checkpoint transactions
Load and verify Virtual Address Table
Load and verify Segment Usage Table
Load and verify Metadata Superblock
Load and verify Logical Volumes B-Trees
Unable to bootstrap transaction group 2596: cksum mismatch
No valid commit checkpoint found
The volume 573A27F3-05AE-45D8-8C36-C2190AA709A0 was found corrupt and
needs to be repaired.

MRDJones wrote:
… I replaced hard drive …
That was sensible.
… I used a external enclosure on the failed hard drive but I get the same error when trying to use disk utility on it. … The drive will not mount.
Those symptoms are consistent with a failing or failed hard drive.
Related
Storage problems, Core Storage, Disk Utility, checksums, fsck_cs and cksum mismatches

Superblock issue

Looking for a little guidance from the gurus.
Unable to get our V480 to boot. Booted single user from cdrom. When I run fsck on the root file system I get a bad superblock error and am not able to repair it.
So I try to find alternate superblocks and get the following error:
# newfs -Nv /dev/rdsk/c0t0d0s0
mkfs -F ufs -o N /dev/rdsk/c0t0d0s0 640 640 1 8192 1024 16 10 5 2048 t 0 -1 8 16 n
mkfs: bad value for size: 640 must be between 1024 and 640
mkfs: size reset to default 640
Warning: inode blocks/cyl group (42) >= data blocks (42) in last cylinder group. This implies 640 sector(s) cannot be allocated.
/dev/rdsk/c0t0d0s0: 0 sectors in 0 cylinders of 1 tracks, 640 sectors 0.0MB in 0 cyl groups (16 c/g, 5.00MB/g, 2432 i/g)
super-block backups (for fsck) at:
<blank>
I am a bit stumped. Been looking all over the web, man pages and anything else I can find.
Any ideas would be greatly appreciated.

Hi,
Please try this, would help you......
#newfs -N /dev/rdsk/c0t0d0s7
it will generate the identical superblock.
then run.......
#fsck -o b=535952 /dev/rdsk/c0t0d0s7
all the best
Bhupal

[SOLVED] Superblock has invalid ext3 journal after change of VMSPLIT

I'm not sure if this is the appropriate forum for this, but here goes..
I recently recompiled a custom kernel (toofishes' Eee kernel) which had NOHIGHMEM=y and VMSPLIT2G=y, enabling highmem and changing the split back to VMSPLIT3G. However, when it came to booting it, my login manager never popped up and instead I got a tty. Logging in gave me this output:
/bin/ls: /lib/librt.so.1: unsupported version 372 of Verdef record
and when I try to start X:
xauth: creating new authority file /home/jickel/.serverauth.1892
/usr/bin/X: error while loading shared libraries: libm.so.6: ELF load command alignment not page-aligned
giving up.
xinit: Connection refused (errno 111): unable to connect to X server
xinit: No such process (errno 3): Server error.
Plus some segfaults when quitting. It seems I did not configure the new memory setting properly, though I did remember to change the CONFIG_PAGE_OFFSET_ VALUE at least.
Now when I try to boot using the default arch kernel to replace the faulty kernel, the file system check fails, and when I manually run fsck I get this question:
Superblock has an invalid ext3 journal (inode 8).
Clear<y>?
I'm still pretty new to Linux, but it seems the change of memory might have forced a change in the FS journal. No idea where to go from here though, and I that answering yes to the above might hose my FS. What do you suggest I do? I recently backed up my system, luckily.
Last edited by Jickel (2008-07-08 20:10:30)

I did it manually, I'll try doing it the other way later then. Thanks for the advice!
I guess those segfaults must have damaged the journals then. I'm still not sure how to repair this though.
UPDATE: Well I deleted the journal, had the file system repaired, and had a new journal created. The fsck command reports everything is fine now, but I still get the "FILE SYSTEM CHECK FAILED - Please repair manually and reboot" box-thingy when I try to reboot. Any idea how do progress from here? I need a working system to update the kernel back to a working one.
Oh, I found another thread where the OP has the same issue http://bbs.archlinux.org/viewtopic.php?pid=385792 . I'll go through the solutions suggested there and see if anything works. No word on results in that thread though.
Last edited by Jickel (2008-07-08 05:37:44)

Fsck.jfs superblock ?!?!?!

hi there
i wonder about this:
[root@hansa matto]# fsck.jfs /
fsck.jfs version 1.1.7, 22-Jul-2004
processing started: 9/9/2004 1.33.16
Using default parameter: -p
The current device is: /
Superblock is corrupt and cannot be repaired
since both primary and secondary copies are corrupt.
CANNOT CONTINUE.
[root@hansa matto]#
how do i repair my superblock??? btw :-) what is a superblock
and how important is it... my system runs very well i think.....
greetings matto

hi
i don´t really understand what fsck.jfs wants me to know
with fsck.jfs /dev/discs/disc1/part3 it says something that my filesystem is dirty but marked as clean ......
so i formated a small partition with jfs, mounted that as /temparch, copied ALL / into that, installed lilo into the new partitiion (i have done this before with help from this forum ;-) ) booted from there and the checked my "normal" root partition with
fsck.jfs /dev/discs/disc1/part3
but sadly i forgot the whole output ... but fsck.jfs says my filesystem is clean, like with every boot up
now i think the error was/is due to my mounted root.....
if i am wrong, please correct me!!!!!!!!
thank you
greetings matto

Is my HD beyond repair?

After installing Mountain Lion last week my MBP tarted to perform badly. Ocassionally Finder failed to respond, something that never happen before ; often, time machine was unable to finish the task of backing files, error received 'TM used by another application'; another USB drive I had crashed to the point I can't 'see' the volumen on the desk top.
I verified permissions for “Macintosh HD”, and got this:
2012-07-29 18:34:08 -0700: Repairing permissions for “Macintosh HD”
2012-07-29 18:36:56 -0700: Warning: SUID file “System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/MacOS/ARDAg ent” has been modified and will not be repaired.
2012-07-29 18:38:53 -0700:
2012-07-29 18:38:53 -0700: Permissions repair complete
I verified the Disk, and got this
2012-07-29 18:39:10 -0700: Verifying volume “Macintosh HD”
2012-07-29 18:39:10 -0700: Starting verification tool:
2012-07-29 18:39:12 -0700: Checking storage system2012-07-29 18:39:12 -0700: Checking volume.
2012-07-29 18:39:12 -0700: disk0s2: Scan for Volume Headers
2012-07-29 18:39:12 -0700: disk0s2: Scan for Disk Labels
2012-07-29 18:39:12 -0700: Logical Volume Group A52C8580-9D69-4878-99B3-D5FB1759D310 on 1 device
2012-07-29 18:39:12 -0700: disk0s2: Scan for Metadata Volume
2012-07-29 18:39:12 -0700: Logical Volume Group has a 16 MB Metadata Volume with double redundancy
2012-07-29 18:39:12 -0700: Start scanning metadata for a valid checkpoint
2012-07-29 18:39:12 -0700: Load and verify Segment Headers
2012-07-29 18:39:12 -0700: Load and verify Checkpoint Payload
2012-07-29 18:39:12 -0700: Load and verify Transaction Segment
2012-07-29 18:39:12 -0700: Load and verify Transaction Segment
2012-07-29 18:39:12 -0700: Incorporate 1 newer non-checkpoint transaction
2012-07-29 18:39:12 -0700: Load and verify Virtual Address Table
2012-07-29 18:39:12 -0700: Load and verify Segment Usage Table
2012-07-29 18:39:12 -0700: Load and verify Metadata Superblock
2012-07-29 18:39:12 -0700: Load and verify Logical Volumes B-Trees
2012-07-29 18:39:12 -0700: Logical Volume Group contains 1 Logical Volume
2012-07-29 18:39:12 -0700: Load and verify 711B2B50-E939-4396-8788-4BC7C9657F23
2012-07-29 18:39:12 -0700: Load and verify BC87FFF5-70D6-4E1C-B160-CEDFC0A9F5E6
2012-07-29 18:39:12 -0700: Load and verify Freespace Summary
2012-07-29 18:39:12 -0700: Load and verify Block Accounting
2012-07-29 18:39:12 -0700: Newest transaction commit checkpoint is valid
2012-07-29 18:39:12 -0700: Load and verify Segment Cleaning
2012-07-29 18:39:12 -0700: The volume A52C8580-9D69-4878-99B3-D5FB1759D310 appears to be OK.
2012-07-29 18:39:12 -0700: Checking file system2012-07-29 18:39:13 -0700: Performing live verification.
2012-07-29 18:39:13 -0700: Checking Journaled HFS Plus volume.
2012-07-29 18:39:13 -0700: Checking extents overflow file.
2012-07-29 18:40:34 -0700: Checking catalog file.
2012-07-29 18:40:34 -0700: Checking multi-linked files.
2012-07-29 18:40:34 -0700: Incorrect number of file hard links
2012-07-29 18:40:34 -0700: Checking catalog hierarchy.
2012-07-29 18:40:34 -0700: Checking extended attributes file.
2012-07-29 18:40:34 -0700: Checking volume bitmap.
2012-07-29 18:40:34 -0700: Checking volume information.
2012-07-29 18:40:34 -0700: The volume Macintosh HD was found corrupt and needs to be repaired.
2012-07-29 18:40:34 -0700: Error: This disk needs to be repaired using the Recovery HD. Restart your computer, holding down the Command key and the R key until you see the Apple logo. When the OS X Utilities window appears, choose Disk Utility.2012-07-29 18:40:34 -0700:
2012-07-29 18:40:34 -0700: Disk Utility stopped verifying “Macintosh HD”: This disk needs to be repaired using the Recovery HD. Restart your computer, holding down the Command key and the R key until you see the Apple logo. When the OS X Utilities window appears, choose Disk Utility.
2012-07-29 18:40:34 -0700:
Twice I used the disk utility in the recovery disk to perform disk repair as instructed. It never gave me a message confirming disk had, or had not, been repaired.
I then trien to re-install Mountain Lion, but was not able to pass to the next step after accepting the licensing req. - the forward arrow was grayed out and non responsive.
I understand in the past the 'incorrect number of file hard links' were caused by a bug in the system files of the recently launched OS (see https://discussions.apple.com/thread/1196001?start=0&tstart=0)
So, I wonder: is my HD drive damaged to the point that I need to replace or this could be something caused by a bug in Mountain Lion?
Thank you for any help, and I'm looking forward to reading your comments.
Model Name:          MacBook Pro
Model Identifier:          MacBookPro6,1
Processor Name:          Intel Core i7
Processor Speed:          2.66 GHz
Number of Processors:          1
Total Number of Cores:          2
L2 Cache (per Core):          256 KB
L3 Cache:          4 MB
Memory:          8 GB
Processor Interconnect Speed:          4.8 GT/s
Boot ROM Version:          MBP61.0057.B0F
SMC Version (system):          1.57f17

This sounds like a software issue, create a new user and login to it and see if your issue pursists. If it doesn't then it's not your hardware but something you've installed (possibly even ML)
I've heard of Cnet something or other doing this to Finder with ML.
if it pursists in the new user, reinstall ML after all of this to see if it won't fix anything (after repairing and verifying disks and permissions) in the recovery partition. To get to the recovery partition restart your computer, hold CMD+R down when you hear the boot up chime. Open Disk Utility first (verify your boot disk and repair if needed) and then close it and reinstall ML.

I was given the wrong macbook when I gave mine in for repair. I want to complain. Also, they wiped ALL my data off the hard drive. I want to complain to someone in authority. How?

I am extremely disappointed and angry with Apple service. I am a writer and booked three weeks in Spain so that I could finish my book. On the second day my laptop cut out on me asI was working on it, so I took it to Goldenmack in Cadiz. Not only was I given someone else's macbook when I went back to collect it, but then when I returned to the UK, the Apple shop in Brighton managed to delete ALL my data from the hard drive because I was unlucky enough to get a trainee on her first day. I have since learned she should not have deleted my data without even running a diagnostic. She told me she was going to 'restore' the drive. I took this to mean she was going to restore my work. But no! She erased the lot.
I complained and eventually was put in touch with a supervisor, who I was told had authority to resolve the issue. She said she would get the shop to phone me. That was ten days ago and I'm still waiting.
Ok so there's nothing I can do now to get back the three chapters of my book that I have lost and didn't back up, but the hard drive on this laptop is still faulty. I try to back up my work every time I use the machine but as soon as I attach an external drive, the whole thing shuts down. I can't use it any more as I can't risk losing any more work. This laptop is only just over a year old and this is just not acceptable, especially since I have really looked after it.
This is an appalling service I have encountered from Apple, and I am not going to ignore it. I have contacted the young chap whose laptop I was erroneously given, and the repair of which I paid for! (although I did eventually get a refund), to ask him if he had been given mine as well. He said he had been completely unaware that his laptop had been given to me and he is furious as he had loads of "sensitive material" on it." I have no idea in whose hands my laptop has been either, or indeed what damage it sustained while it was supposed to be in for repair.

Contact Apple Support:
http://www.apple.com/support/contact/
Apple - How to Contact Us:
http://www.apple.com/contact/
Be sure to refer to the repair ticket number.
Sounds like a terrible mixup.
Good luck & happy computing!

OracleVM3 poolfs superblock repair

Similar Messages

Maybe you are looking for