Shirt Pocket Discussions

Shirt Pocket Discussions (http://www.shirt-pocket.com/forums/index.php)
-   General (http://www.shirt-pocket.com/forums/forumdisplay.php?f=6)
-   -   Disk Utility problem after cloning (http://www.shirt-pocket.com/forums/showthread.php?t=377)

macWish 05-16-2005 12:47 PM

Disk Utility problem after cloning
 
I have G4 1 Ghz iMac, 512 MB RAM. OS X 10.4

After installing Tiger on internal HD, everything seemed to work without any problems (but don't ask me about Spotlight!).
I then set up my External LaCie D2 Firewire 400 HD with three partitions:
1. Backup: a partition for backup of Documents and other User files using DataBackUp 2.0.5;
b. HD Clone: bootable 'Backup All Files" clone of internal HD created with SuperDuper! 1.5.5;
c. Startup Clone: bootable "Safety clone - shared users and applications" created with SuperDuper. I use this as my startup disk.

When I startup up on my Internal HD and launch Disk Utility to repair permissions and repair disk on the partitions on the External Firewire HD, no problems reported with any of the partitions

If I start up on the Startup Clone on external HD and run Disk Utility, I can perform the Repair Disk function on the other two partitions on the external hard drive. However, when I try to Repair Disk on the Internal HD, a task which always worked prior to installing Tiger, I get the error message: Unable to Unmount Volume - the first step of verifying and repairing a disk. The reason for this failure appears to be an open file/application on the hard drive.

The same problem occurs if I boot from the External HD Clone (i.e. the complete clone).

The same problem occurs if I boot from an eDrive created with TechToolPro 4.0.4 on its own partition on the external firewire drive. Disk Warrior on the eDrive also fails to unmount the internal HD.

However, it I boot from a bootable CD or DVD containing Disk Utility, then the latter functions without any problems and fails to find anything to repair on internal HD. Can also repair internal HD by launching it as single user and repairing internal HD with AppleJack.

There seems to be a problem with the cloning process with both SuperDuper! and TechToolPro such that Disk Utility (and Disk Warrior) act as if there is an open file/application on the internal hard drive when the startup disk is on a cloned drive on an external firewire drive.

The following did not correct the problem:
1. Disabling Spotlight via terminal use of mdutil and deleting .Spotlight index files from all drives;
2. Disabling Dashboard by quitting Dock.

Any suggestions?

dnanian 05-16-2005 01:52 PM

You should be able to see what file is actually 'open' on the volume using lsof. Try the following:

- Boot from the clone
- Open Terminal
- Use the command:

lsof | grep "internal-volume-name"

That should tell you who/what is holding the drive open...

macWish 05-16-2005 05:07 PM

No luck
 
1 Attachment(s)
Quote:

Originally Posted by dnanian
You should be able to see what file is actually 'open' on the volume using lsof. Try the following:

- Boot from the clone
- Open Terminal
- Use the command:

lsof | grep "internal-volume-name"

That should tell you who/what is holding the drive open...

It looks as if there are a lot of files on the internal hard drive that are open when I boot from the clone. I have attached the Terminal output text file of
lsof | grep "internal-volume-name". This seems to be a problem unique to Tiger as it never happened with the OS 10.3.9 and earlier versions.

dnanian 05-16-2005 05:11 PM

Given that, are you sure you're not running from a Safety Clone, as opposed to a full "Backup - all files" clone?

If not, try naming the backup the *same* as the internal drive, smart update it, and then boot from it. (I explain elsewhere on the forums about aliases resolving using the volume name...)

lstuff 05-16-2005 05:26 PM

which one do I use?
 
I am trying to use the super duper. Which pull down window do I use to use just the cloner part?

dnanian 05-16-2005 05:30 PM

Hi, lstuff.

Choose the source in the first pop-up, the destination in the 2nd, and "Backup - all files" in the 3rd.

(Let me suggest that you check out section 3 of the User's Guide, too. That has all the details.)

macWish 05-16-2005 05:46 PM

1 Attachment(s)
Quote:

Originally Posted by dnanian
Given that, are you sure you're not running from a Safety Clone, as opposed to a full "Backup - all files" clone?

If not, try naming the backup the *same* as the internal drive, smart update it, and then boot from it. (I explain elsewhere on the forums about aliases resolving using the volume name...)

My startup disk is a Safety clone. I also have a "Backup - all files" clone. WHen I startup from the full clone, I get the same error with Disk Utility and Disk Warrior run from the startup disk. Since Disk Utility is not aliased to the internal drive on either the Safety clone or the full clone, it should not be aliasing the DU on the internal drive. The same problem occurs with the eDrive cloned by Techtool Pro.

For reasons beyond me, only my internal drive shows up on the desktop. None of the partitions on the external fire drive show up on the desktop. I did not realize they were not there because I have Finder Preferences set not to show the disks on the desktop since I can access them via DragThing or via a Finder Folder where they all show up. The desktop appears to be only place I can try to rename the Safety Clone, short of recloning it with same name as internal drive, if SuperDuper allows that.

For what it is worth, I attached the output of open files when I booted from the Full Clone. It is much smaller.

dnanian 05-16-2005 05:52 PM

Well, the Safety Clone is always going to have a lot of files opened on the original drive, because those items are shared. So that's normal.

But, the "Full Clone" is likely doing this because it's not named the same as the original "Macintosh HD" -- try that, Smart Update it, and I think it'll be resolved.

Disk Utility/Disk Warrior aren't causing the problems as such -- these other items that have auto-started on you are... and those are starting from the original drive, due to the naming & aliases (these are internally stored aliases, not ones you create yourself).

I can't explain the eDrive because I don't know how exactly they do what they do... sorry.

macWish 05-16-2005 06:40 PM

But why did this problem appear with Tiger when it did not exist in Panther?

dnanian 05-16-2005 11:26 PM

I can't answer that: it should have happened and both, and does in our testing...

macWish 05-17-2005 07:31 AM

New Full Clone
 
I renamed a partition on external drive the same as the internal HD and did a full backup-all files. I then booted from the Full Clone. Disk Utility still unable to unmount the internal hd. Assuming that there are no other problems than this unmounting one, I will not try any other work arounds at the moment. When I do want to repair the disk on the internal hard drive, I'll do it in single user mode with AppleJack.

Now with OS X 10.4.1 released this morning, the process may start all over, all nothing in the news of the update mentions this problem and I have yet to hear back from my bug report to Apple.

dnanian 05-17-2005 09:26 AM

OK. This isn't something we've seen here, macWish, and it doesn't seem SuperDuper! specific, so it's hard for me to provide any other suggestions at present...

macWish 05-17-2005 10:46 AM

Problems with giving external clone same name as internal HD
 
I renamed by full clone on the external firewire drive, giving it the same name as the name of the internal HD. I made full clone - backup all files - and then booted the external full clone. No problem booting, but disk utility launched from the external drive still fails to be able to unmount the internal HD. Moreover by having two volumes with the same name, all of the aliases got very screwed up, i.e. an alias in drag strip to a folder on in Documents failed to open the proper folder and seemed not to know whether to use the internal or the external volume with same name.

Update to OS X 10.4.1 did not solve the problem with unmounting internal HD when booted from Safety Clone or from Full Clone or from eDrive on external firewire drive.

dnanian 05-17-2005 11:00 AM

The aliases got screwed up? That's strange, because they should go right to the internal drive: after all, they go by name.

Strange. I've tried to duplicate the problem here without luck... anyone else seeing this when the volumes are named identically?

macWish 05-17-2005 07:48 PM

Well this problem is certainly not unique to SuperDuper!. Other programs which clone the internal hard drive to my external firewire drive result in the same problem, namely TechTool Pro 4.0.4 (Tiger compatible) and Data Backup 2.0.5 (Tiger Compatible). None of them (and SuperDuper!) had any difficulty producing clones with Panther. With Tiger, all of them create clones which make Disk Utility unable to check the internal hard drive because of bug in unmounting the drive.

dnanian 05-17-2005 09:43 PM

I do wish I could reproduce this. I'd really suggest trying to stop all running processes that are user-based... there's clearly something weird being loaded from *somewhere* -- I just don't see how it's resolving to the wrong drive. Perhaps going the opposite way in your situation -- renaming the "original" drive to something other than "Macintosh HD" before booting from the clone -- would help to ensure things aren't doing something weird?

macWish 06-19-2005 03:03 PM

Quote:

Originally Posted by dnanian
I do wish I could reproduce this. I'd really suggest trying to stop all running processes that are user-based... there's clearly something weird being loaded from *somewhere* -- I just don't see how it's resolving to the wrong drive. Perhaps going the opposite way in your situation -- renaming the "original" drive to something other than "Macintosh HD" before booting from the clone -- would help to ensure things aren't doing something weird?

The cloning problem with Tiger is not unique to SuperDuper!. The exact same problem occurs when I clone with Disk Utility itself and with TechTool Pro (i.e. to create eDrive). The problem seems to be that, unlike Panther, when Tiger is cloned, a few files on the clone seemed to be linked back to the Internal Hard Drive. When I do safety boot of safety clone on external firewire drive into Maintenance User (which has no third party log in items) and then use "lsof" in terminal to list the open files, the following files which seem to be on Internal hard drive (MacIntosh HD) are open:

loginwind 156 maintenance cwd VDIR 14,2 476 117056
/Volumes/MacIntosh HD/Users/maintenance
Finder 188 maintenance 11r VDIR 14,2 136 117060
/Volumes/MacIntosh HD/Users/maintenance/Desktop
Finder 188 maintenance 13r VDIR 14,2 68 393078
/Volumes/MacIntosh HD/Users/maintenance/.Trash

All of the other open file listed by lsof are on safety clone.

If I boot into eDrive, then the only open file on internal hard drive is:

Finder 137 ronaldgold 11r VDIR 14,2 170 337370
/Volumes/MacIntosh HD/.Trashes/501

Apple Developer Bug reporter staff has not yet come up with an answer. Since I reported the bug one month ago, I am not to optimistic that they are dealing with it.

dnanian 06-19-2005 03:27 PM

Well, that would make sense, though, if it's a Safety Clone, because a Safety Clone *does* link the users back to the original volume.

macWish 06-19-2005 04:44 PM

Quote:

Originally Posted by dnanian
Well, that would make sense, though, if it's a Safety Clone, because a Safety Clone *does* link the users back to the original volume.

Yes but - this did not happen with OSX 10.3.9, but only with Tiger. And it also happens with Techtool Pro's eDrive (which is cloned by its own partition by TechTool Pro) and also when I make clone with Disk Utility and when I make complete clone with SuperDuper. Regardless of how I make the clone, with Tiger, but NOT with Panther, the cloning process creates some links back to the Source Volume for the Clone so that when I boot the clone, it opens the links. This makes it impossible to unmount the internal hard drive boot volume when unmounting is required by an application such as Disk Utility, Disk Warrior, or some parts of TechTool Pro. The only way I have found to get around this problem is to boot with the Disk Warrrior CD to check the Internal HD with Disk Warrior on the or with the Tiger Install DVD to check the Internal HD with Disk Utility. Given the very slow bootup times of CDs and DVDs, this is a pain.

dnanian 06-19-2005 04:47 PM

Yeah, that I don't understand, but I definitely understand why a Safety Clone would have a link back to the main volume.

Complete clones, not so much. But -- if you name things properly -- this shouldn't happen. I'm at a loss, macWish.

macWish 06-22-2005 08:39 AM

I installed Tiger on a partition on my external hard drive. When I boot from that partition, Disk Utility has no difficulty in checking all of the other volumes on both internal and external hard drives. HOWEVER, when I cloned the Tiger partition with SuperDuper to another partition on the external drive, Disk Utility can unmount everything EXCEPT the Tiger partition which was the source of the clone. As before, lsof indicates that two files are opened on the Tiger Partition when I boot from the Tiger clone:

loginwind 176 ronaldgold cwd VDIR 14,14 476 92106 /Volumes/OSX
Tiger/Users/ronaldgold
Finder 240 ronaldgold 11r VDIR 14,14 102 92117 /Volumes/OSX
Tiger/Users/ronaldgold/Desktop

These are the same two culprits that caused the original problem. Clearly not an issue with Firewire drives. Why this happens with my setup with Tiger, but not Panther is beyond me. Others have not had this problem (see http://www.techsurvivors.net/forums/...=ST&f=1&t=9508)

dnanian 06-22-2005 09:20 AM

The implication there is that the loginwindow process has that folder as the current working directory, and that you have it open as the desktop.

Have you messed with NetInfo at all?

macWish 06-22-2005 08:19 PM

No. I have never opened it. In Activity monitor, LoginWin is listed as being active with same process ID as listed by lsof. I don't have a clue as to why it is open on Internal Hard Drive. A bunch of my third party login items are also linked to Internal Hard Drive as would be expected on Safety Clone. Only LoginWin persists when I boot with no third party logins, along with Finder/desktop. Should I kill LoginWin via activity monitor as a test?

dnanian 06-22-2005 11:13 PM

Is the volume capitalized/spelled *exactly* the same as the original volume? That could account for this kind of thing, too.

macWish 06-23-2005 06:21 AM

My internal hard drive is "McIntosh HD"; shared clone on external hd is "myClone".

dnanian 06-23-2005 08:58 AM

Yeah, I see that I've suggested it previously in this thread, but I really think you should try to name the clone and the original *exactly* the same. Then, do the reboot and send me the same lsof output...

macWish 06-23-2005 02:42 PM

Quote:

Originally Posted by dnanian
Yeah, I see that I've suggested it previously in this thread, but I really think you should try to name the clone and the original *exactly* the same. Then, do the reboot and send me the same lsof output...

I renamed clone so that it matched internal hard drive exactly, and rebooted. No change in lsof output or in behaviour of Disk Utility. I have attached output to losf in a separate email to you.

dnanian 06-23-2005 02:52 PM

Weird, Ronald. Going by the lsof logs, the volumes don't seem to be named the same:

Finder 95 maintenance 11r VDIR 14,2 136 117060 /Volumes/MacIntosh HD/Users/maintenance/Desktop
Finder 95 maintenance 12r VDIR 14,12 68 170117 /.Trashes/502
Finder 95 maintenance 13r VDIR 14,2 68 408673 /Volumes/MacIntosh HD/Users/maintenance/.Trash
Finder 95 maintenance 14r VDIR 14,13 68 107408 /Volumes/OSX Tiger/.Trashes/502
Finder 95 maintenance 15r VDIR 14,14 68 35797 /Volumes/Backup/.Trashes/502
Finder 95 maintenance 16r VDIR 14,15 68 247416 /Volumes/HD Clone/.Trashes/502

Did something go wrong in the rename? Or are the "clone" volumes other, unrelated backups?

macWish 06-23-2005 04:12 PM

Quote:

Originally Posted by dnanian
Weird, Ronald. Going by the lsof logs, the volumes don't seem to be named the same:

Finder 95 maintenance 11r VDIR 14,2 136 117060 /Volumes/MacIntosh HD/Users/maintenance/Desktop
Finder 95 maintenance 12r VDIR 14,12 68 170117 /.Trashes/502
Finder 95 maintenance 13r VDIR 14,2 68 408673 /Volumes/MacIntosh HD/Users/maintenance/.Trash
Finder 95 maintenance 14r VDIR 14,13 68 107408 /Volumes/OSX Tiger/.Trashes/502
Finder 95 maintenance 15r VDIR 14,14 68 35797 /Volumes/Backup/.Trashes/502
Finder 95 maintenance 16r VDIR 14,15 68 247416 /Volumes/HD Clone/.Trashes/502

Did something go wrong in the rename? Or are the "clone" volumes other, unrelated backups?

The internal hard drive boot volume is "MacIntosh HD". On the external hard drive, my startup volume is a safety clone which I renamed "MacIntosh HD" by copying the name of the internal drive and pasting it in safety clone. I have three other partitions on the external firewire drive:
1. "Backup": a non-bootable partition to which I make nightly backups of my User files;
2. HD Clone: a complete copy clone of the internal hard drive which I do not use for startups;
3. OSX Tiger: a partition on which I installed Tiger directly from the Tiger DVD. If I boot from this partition, with OSX Tiger which is not a clone, there is no problem with Disk Utility.

macWish 06-24-2005 03:49 PM

Further mystification
 
Having learned on another forum that Carbon Copy Cloner can be used with Tiger by launching it via Pseudo in order to get root authentication, I used CCC to clone the partition on my external hard drive on which I had installed Tiger from the Tiger Install DVD (named "OSX Tiger". The clone creased with CCC booted without any problem and Disk Utility had no problem checking all of the bootable volumes on both the internal HD and external firewire hd. When I checked for open files with lsof, no files on OSX Tiger were open.

When I cloned this partition with SuperDuper! to a partition on the external fire wire drive and booted from the clone, I got the usual failure of Disk Utility and lsof indicated that the following files on "OSX Tiger" were open:

loginwind 143 maintenance cwd 3r VDIR 14,13 476 117056
/Volumes/MacIntosh HD/Users/maintenance
Finder 164 maintenance 11r VDIR 14,13 136 117060
/Volumes/MacIntosh HD/Users/maintenance/Desktop

Something changed with Tiger and SuperDuper! (and Disk Utility and TechTool Pro) so that it appears (to me) that a link to loginwin and Finder on the source volume are being created during the cloning process. This does not appear to occur with Carbon Copy Cloner (which is not officially Tiger-compatible but seems to work when launched via Pseudo).

dnanian 06-24-2005 05:32 PM

I honestly don't know what's going on here. I can't reproduce the problem at all, and it doesn't make much sense, especially since it happens with everything but CCC, including Disk Utility, and CCC pretty much just copies with "ditto".

We absolutely do not link files that weren't originally links on the main drive, unless specifically instructed to do so in the copy script. I'm positive that's not the issue...

Two things to check.

1. Go into Netinfo Manager. Navigate to the "users" entry, and then "maintenance". What does it say for the "home" entry under the maintenance user?

2. Try renaming the original volume before you reboot from the clone to something else ("original drive" or something). Does it still open files on that volume?

macWish 06-25-2005 07:27 AM

1. Netinfo manager: "/users/Maintenance"

2. If I rename the original source volume (i.e. the internal hard drive) and reboot from the clone, the startup process hangs on the Log In Window. If I select either of the two user options (Ronaldgold or Maintenance, the two user accounts), then I get an error dialog stating that that user cannot log in at this time.

In order to boot from the clone, I had to change name of source volume back to its original name. Then if I change the log in option to log in automatically to account Ronaldgold so that the log in screen does not appear, startup occurs uneventfully. However, if I check lsof, it still shows that the first login window file being accessed during startup is loginwn on MacIntosh HD, not on myClone.

It appears as if, for some unkown reason, during startup, the clone has to open the login window file on the source volume which leads to the subsequent problems with unmounting the source volume.

It also looks as if the clone opens a Finder file on the source volume related to Desktop.

loginwind 176 ronaldgold cwd VDIR 14,14 476 92106 /Volumes/MacIntosh HD/Users/ronaldgold
Finder 240 ronaldgold 11r VDIR 14,14 102 92117 /Volumes/MacIntosh HD/Users/ronaldgold/Desktop

dnanian 06-25-2005 07:38 AM

Well, you can see pretty clearly that Netinfo indicates that the home folder should be accessed from the root (/). That's what it should be (and what I expected).

At this point, I just don't know what's wrong. I've never seen this before and can't duplicate it... it's as maddening for me here as it must be for you there.

There must be something a bit unusual that's starting pretty early on your machine that's causing this to happen. Maybe it's a 3rd party something-or-other... so let's try one more thing.

Rename the original volume again to something else. Set the external to the boot drive, and shut all the way down. Hold down Shift and power on, keeping shift down until you see the "Safe Boot" indicator in the boot panel.

In "safe mode" can you log in?

macWish 06-25-2005 10:33 AM

After changing name of original volume, shutting down, and doing safe boot, I cannot log in. In order to log in, I have to have original name of the source volume even in safe boot.

After startup and logging in, I check Console. I don't know if the following has any significance in terms of the login issue, but the first line of the Console log is:

"Mac OS X Version 10.4.1 (Build 8B15)
2005-06-25 10:24:48 -0400
2005-06-25 10:24:51.161 loginwindow[107] FSResolveAliasWithMountFlags returned err = -43"

dnanian 06-25-2005 06:44 PM

OK. At this point, I'm really out of ideas, Ronald. Something very strange is going on here -- something I've never seen: for some reason, your system really wants to point to the internal drive. It's like there's a process attached to the login window that's forcing things to internal.

Could you send me a System Profiler report to the support email address? Maybe I'll see something in there that will help... make sure all the involved drives are attached.

macWish 09-30-2005 05:31 PM

Follow-up on Apple Development Response
 
Here, 3 months later, is response from Apple to my bug report:

Engineering has determined this issue behaves as intended based on the following information:

We replicated the issue using the 'Safety Clone' feature in SuperDuper. The Safety clone creates sym links back to the original volume, so there are open files. We were able to boot from the new volume and run disk util on the original.

Thank you for taking the time to submit this report.

Best Regards,

The Bug Reporting Team
Apple Developer Connection

No help at all at explaining the problem on my machine.

dnanian 09-30-2005 11:06 PM

Well, was it a Safety Clone? Perhaps they (or I) didn't understand...?

macWish 10-01-2005 01:06 PM

[QUOTE=macWish]Here, 3 months later, is response from Apple to my bug report:

Engineering has determined this issue behaves as intended based on the following information:

We replicated the issue using the 'Safety Clone' feature in SuperDuper. The Safety clone creates sym links back to the original volume, so there are open files. We were able to boot from the new volume and run disk util on the original.

Thank you for taking the time to submit this report.

Best Regards,

The Bug Reporting Team
Apple Developer Connection

------

I donít understand this either. I interpret it to mean that they created Safety Clone, booted from it and ran Disk Utility while booted from Safety Clone and had no problem running Disk Util on the original. I do't understand how they can do this if there indeed are open files on the original when they boot from the Safety Clone.

My work around avoids the issue without explaining it: I installed Tiger on the partition on my external hard drive in addition to the Safety Clone. I use the Safety Clone as my startup volume and the Tiger Partition for maintenance.

dnanian 10-01-2005 01:08 PM

Certainly, if you're booting from a Safety Clone, you can't unmount the original volume -- after all, your Home folder is hosted there, since the user files are shared.

But -- if you're booting from a "regular" copy (as I thought you were -- that is, "Backup - all files"), there's no reason for the main volume to be busy as long as the backup is named the same...


All times are GMT -4. The time now is 12:54 AM.

Powered by vBulletin® Version 3.8.9
Copyright ©2000 - 2017, vBulletin Solutions, Inc.