iMac with OS X Lion (10.7) had failed to boot, showing only the Apple Logo and a grey progress bar below the spinning wheel. After a few seconds, the iMac shuts itself down. The system will not boot up at all.
The grey progress bar is fsck trying to analyze and or repair a possible disk error.
In my case it was a disk full error and invalid sibling links (footnote 1). There was no more space left on the disk for OS X to allocate for write cache and other essential temporary files for it to boot up.
I obtained the analysis by first booting into "Startup Manager" and then selecting the "Recovery Disk" to boot into. From the "Recovery Disk", I started the "Disk Utility" application to verify the issue with the regular startup disk. "Disk Utility" reported that the disk had "invalid sibling links" and that I should attempt to repair the disk.
While attempting to repair the disk, the error message about the disk being full and "Disk Utility" being unable to repair the disk due to having no space left popped up in the log. The suggestion from "Disk Utility" was to back up all important files, reformat the disk, and then restore from backup.
However, I wasn't about to give in so easily. If it was a matter of not having enough free space for the disk repair to proceed, all I had to do was free up some disk space.
Here are the following steps I took to remedy this situation.
1. Boot into "Single User" mode. You will be presented with a command line interface. Startup Keys
2. Change the mounted disk mode to writeable, by issuing the following command...
mount -uw /
3. Using unix commands, navigate through the directory structure and identify non-essential files that can be safely removed. i.e. files in .Trash, or unnecessary files in Downloads, etc...
Be VERY CAREFUL when doing so. Attempt at your own risk, because in "Single User" mode and with write-mode on, you are able to delete any file or directory on the system. This means a careless "rm -fr ./" while in the wrong directory could permanently render your OS X install completely dead!
I will not go into a tutorial of how to use unix commands in this post. Feel free to google and read up on the countless tutorials online for basic unix commands. I'm not trying to be elitist, but just trying to keep the size of this post manageable; please do not use the "rm" command without experienced prior knowledge. A accidental "rm" can really ruin a person's day.
4. Back to the problem at hand, once I had cleared off all the unnecessary files, I had about 9 Gigs free.
You can use "df -h" to see how much free space you have.
5. Issue the command "reboot" on the command line to reboot the system.
6. Press "Option" key while booting up to enter into "Startup Manager" mode and select the "Disk Utility" again.
7. Repair the regular startup disk. If you had cleared up enough free space, you should not encounter the "disk full error" message in the repair log. Let "Disk Utility" repair run its course and fix whatever problems it finds.
8. Quit from the "Recovery Disk" and boot up in the regular Startup Disk. You don't have to press any keys this time.
9. Barring any unforeseen issues, OS X should be back to normal. The only task left is to start moving some of those files off the Startup Disk and onto an external drive, so that this issue doesn't repeat itself again.
Also, I can't stress the importance of using Time Machine anymore than; please use it regularly, because one of these days it will really save your bacon, when you need it most.
Footnotes :-
1. "invalid sibling link" - reference url. Please read the explanation by "MicroMat Tech3".
Monday, June 24, 2013
Friday, January 27, 2012
Reverse the mouse scroll direction in Windows 7
Anybody familiar with iOS and OS X Lion will know that the mouse scrolling direction now mimics the action of "pushing" or "pulling" the page on the screen, rather than controlling the window's scroll tab. In other words, it is reversed from earlier convention.
In OS X Lion, scrolling the mouse wheel up, would be as if you were "nudging" the page up. While scrolling the mouse wheel down, would be as if you were "nudging" the page down. This is the behaviour in iOS as well. In some ways, it is more intuitive. However, some would argue that it is actually more frustrating. This topic is highly subjective in my opinion, and I won't be debating in this post about which way is better and which way is worse.
What I will be discussing, is how to make Windows 7 mouse scroll behave like iOS and OS X Lion.
I find that I get a little disorientated with mouse scroll when switching from using the iPad and MacBook Pro, to a Windows 7 machine. Particularly so, when it is "crunch time" and I really need to get things done fast. Enough was enough, so I decided I would try to find a way to make Windows 7 "reverse" the default mouse scroll direction. Here is what I dug up from the web, and worked for me. I cannot take credit for this little tip, as I did not come up with it.
Steps :-
1. In Windows 7 Control Panel, open up the "Mouse Properties" dialogue windows, and click on the "Hardware" tab.
2. Open the device properties window by clicking on the "Properties" button at the bottom right corner, just above the "Apply" and "Help" buttons.
3. In the device properties dialogue window, click on the "Details" tab and select "Hardwire Ids" from the "Property" drop-down list. You should see a list of entries starting with "HID...". Write down the values that start with "HID\VID_???...".
4. Close device properties by clicking "Cancel".
5. Close "Mouse Properties" by clicking "Cancel".
6. Find and open the application "regedt32.exe" as an administrator, if you are not already logged in as one.
7. Navigate to "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\HID", and look for an entry that resembles the "VID_???..." number that you wrote down earlier in step 3.
8. Open each child entry under your specified "VID_???..." key, and open the "Device Parameters" key. In my case, there were two child entries with a long "serial number"-like alphanumeric text string.
9. There should be a key named "FlipFlopWheel" under each of the "Device Parameters" key. Reverse the entry value for the "FlipFlopWheel". i.e. if default is "0" (zero) change it to "1", and vice-versa.
10. Do the same step 9, for each alphanumeric text string key entry, and their "Device Parameters", "FlipFlopWheel".
11. Close "regedt32.exe".
12. Unplug your USB mouse, and listen or watch for Windows 7's acknowledgement and confirmation that it has recognized the event of the mouse being unplugged. In my case, it was simply a "USB device unplugged" system sound. Re-connect the mouse and the new settings should have taken effect. If not, simply shutdown and restart Windows 7.
Done.
References :-
http://superuser.com/questions/310681/inverting-direction-of-mouse-scroll-wheel
http://neosmart.net/forums/showthread.php?t=1373
In OS X Lion, scrolling the mouse wheel up, would be as if you were "nudging" the page up. While scrolling the mouse wheel down, would be as if you were "nudging" the page down. This is the behaviour in iOS as well. In some ways, it is more intuitive. However, some would argue that it is actually more frustrating. This topic is highly subjective in my opinion, and I won't be debating in this post about which way is better and which way is worse.
What I will be discussing, is how to make Windows 7 mouse scroll behave like iOS and OS X Lion.
I find that I get a little disorientated with mouse scroll when switching from using the iPad and MacBook Pro, to a Windows 7 machine. Particularly so, when it is "crunch time" and I really need to get things done fast. Enough was enough, so I decided I would try to find a way to make Windows 7 "reverse" the default mouse scroll direction. Here is what I dug up from the web, and worked for me. I cannot take credit for this little tip, as I did not come up with it.
Steps :-
1. In Windows 7 Control Panel, open up the "Mouse Properties" dialogue windows, and click on the "Hardware" tab.
2. Open the device properties window by clicking on the "Properties" button at the bottom right corner, just above the "Apply" and "Help" buttons.
3. In the device properties dialogue window, click on the "Details" tab and select "Hardwire Ids" from the "Property" drop-down list. You should see a list of entries starting with "HID...". Write down the values that start with "HID\VID_???...".
4. Close device properties by clicking "Cancel".
5. Close "Mouse Properties" by clicking "Cancel".
6. Find and open the application "regedt32.exe" as an administrator, if you are not already logged in as one.
7. Navigate to "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\HID", and look for an entry that resembles the "VID_???..." number that you wrote down earlier in step 3.
8. Open each child entry under your specified "VID_???..." key, and open the "Device Parameters" key. In my case, there were two child entries with a long "serial number"-like alphanumeric text string.
9. There should be a key named "FlipFlopWheel" under each of the "Device Parameters" key. Reverse the entry value for the "FlipFlopWheel". i.e. if default is "0" (zero) change it to "1", and vice-versa.
10. Do the same step 9, for each alphanumeric text string key entry, and their "Device Parameters", "FlipFlopWheel".
11. Close "regedt32.exe".
12. Unplug your USB mouse, and listen or watch for Windows 7's acknowledgement and confirmation that it has recognized the event of the mouse being unplugged. In my case, it was simply a "USB device unplugged" system sound. Re-connect the mouse and the new settings should have taken effect. If not, simply shutdown and restart Windows 7.
Done.
References :-
http://superuser.com/questions/310681/inverting-direction-of-mouse-scroll-wheel
http://neosmart.net/forums/showthread.php?t=1373
Saturday, October 15, 2011
OS X Firewire External "self-eject" issue and possible fix
A possible work-around to the OS X Firewire External Hard drive and "self-eject" issue.
I have a small business that is almost entirely Mac and OS X, the only exceptions are the one MS Windows PC box sitting in the corner of my basement storeroom that runs some vendor software that must be on Windows and 3 VMs for a present client.
I have been experiencing this "self-eject" issue ever since I started using MacBook Pro laptops (unibody models). I cannot exactly pin-point the precise parameters as I've used several laptops and external firewire drives over the last 3 years (2009 to present 2011). As would anybody else, I started researching online about this particular "self-eject" issue.
With a Firewire External HDD connected to a unibody MBPro running on bus-power, with the MBPro on power-supply or battery, the "self-eject" issue occurs. I have been able to replicate this behaviour countless times, with different Firewire External HDD, and different MBPro, and with Snow Leopard and Lion.
I've used many different Firewire cables in the process as well, with no observable differences. The version of OS X may be a factor, but I cannot observe any significant differences or events either. I've had Finder becoming "non-responsive" during some extended read-write operations, but I cannot definitively attribute it to Firewire "self-ejects", as the Firewire units were still connected and responsive.
What I have observed with my particular hardware set, and I don't think it is related entirely to the version of OS X, is that the power source for the Firewire External HDD unit is a significant factor in whether it "self-ejects" or not. I have arrived at the opinion that the Firewire external drive hardware and power supply appears to be more relevant to the "self-eject" issue. I could be wrong, but at least I can share what "configurations" have been working for me so far.
Configuration One
- iMac (late-2009 model)
- OS X Snow Leopard
- Iomega 500Gb Firewire External HDD
- Firewire bus-powered, no independent power-supply
- Time Machine on external Firewire HDD
- No issues 7 months (approx) continuous
Configuration Two
- MacBook Pro 15 (mid-2010 model)
- OS X Snow Leopard
- G-Tech 2Tb Firewire External HDD
- Independent power-supply
- Time Machine on external Firewire HDD
- No issues 5 months (approx)
- No issues "non-consecutive", as laptop has been moving in and out of the office.
Configuration Three
- MacBook Pro 15 (mid-2010 model)
- OS X Lion
- G-Tech 2Tb Firewire External HDD
- Independent power-supply
- Time Machine on external Firewire HDD
- No issues 1 month (approx)
- No issues "non-consecutive", as laptop has been moving in and out of the office.
Configuration Four
- MacBook Pro 15 (mid-2010 model)
- OS X Lion
- G-Tech 2Tb Firewire External HDD
- G-Tech 750Gb Firewire External HDD (daisy chained on 2Tb unit)
- Independent power-supply on 2Tb unit (powering 750Gb unit as well)
- No issues, read-write operation between both units (
722 hours consecutive) *edited*
Configuration Five
- MacBook Pro 15 (mid-2010 model)
- OS X Lion
- G-Tech 750Gb Firewire External HDD ()
- Independent power-supply on 750Gb unit
- No issues 3 days (approx)
- No issues "non-consecutive", as laptop has been moving in and out of the office.
"Self-eject" manifestations
Any time I use the Firewire External HDDs on a MacBook Pro on bus-power. I get the "self-eject" problem showing up, regardless of OS X version, Snow Leopard or Lion.
I cannot attest to Tiger nor Leopard, since I was using them on a 2008 Aluminium MacBook Pro. All I can say is that, I did not experience any "self-eject" issues with the aluminium non-unibody MBPros with any of my previous Firewire External HDDs (Iomega and Seagate) with Tiger and Leopard. This Iomega unit is the exact same one that is connected to the iMac listed in "Configuration One". However, when this same Iomega unit is attached to either one the two unibody MBPros, on bus-power, the "self-eject" issue crops up. The Seagate Firewire unit crashed with an internal hardware failure, prior to my using the unibody MBPros, so I was not able to test them together. The Seagate unit hardware failure is totally un-related to "self-ejecting" consequences (it stopped working completely after it fell off a filing cabinet).
Take my observations for what you will, but I hope it helps someone else figure out their Firewire "self-eject" issues.
If you have comments, please leave constructive feedback or suggestions that are helpful to others. As a forewarning, "flaming", "trolling", etc... comments will be moderated.
Subscribe to:
Posts (Atom)