• Falling Time Mac Os Catalina
• Falling Time Mac Os X
• Falling Time Mac Os Catalina
• Mac Os Catalina

The first release of the new OS — Mac OS X Server 1.0 — used a modified version of the Mac OS GUI, but all client versions starting with Mac OS X Developer Preview 3 used a new theme known as Aqua. Aqua was a substantial departure from the Mac OS 9 interface, which had evolved with little change from that of the original Macintosh operating. Mac OS 8.1 was the first system to have a Universal Disk Format (UDF) driver, allowing for DVD support on the Mac for the first time. It also shipped with the new Java runtime (JDK 1.13). Mac OS 8.1 also included an enhanced version of PC Exchange, allowing Macintosh users to see the long file names (up to 255 characters) on files that were.

Running Mac OS X as a QEMU/KVM Guest

Gabriel L. Somlo

Last updated: Mon. Sep. 05, 2016
Feedback to: somlo at cmu dot edu

0. I Just Want It Working, Right Now !

OK, here's what you'll need (or skip to the technical details instead):

• Development Tools: git, gcc[-c++], [auto]make, iasl, kernel-devel, etc. On Fedora,should take care of it. But, if following the rest of the directions below, you get weird build failures and other unexplained errors, consider the possibility that you're missing something in this category, possibly something I didn't think of listing explicitly above...
• KVM: As of kernel version 3.15, all necessary functionality is already integrated upstream. Right now, I have 3.15.3-200.fc20.x86_64 on my Fedora 20 machine, and everything works out of the box.For older kernels, it may be possible to build KVM kernel modules using the kvm-kmod 'wrapper', by following these instructions.Then, as root, while still in the kvm-kmod directory (substitute kvm_amd for kvm_intel, depending on your CPU):
• QEMU: Download QEMU 2.1.0 or later. This contains and installs an appropriately patched SeaBIOS binary as well, so there's no longer a need to download, build, and install a separate instance of SeaBIOS. Configure and build QEMU using something like:
• Chameleon: an additional bootloader is currently needed to bridge the gap between SeaBIOS and the Apple EFI BIOS expected by Mac OS X. Source is available from the project's SVN repo, but since it requires Mac OS X and Xcode to build, I've uploaded a binary image which you may use until you're ready to build your own.

Once the above components are in place, you'll need a HDD image for your Mac OS X guest:As of Yosemite (OS X 10.10), on kernels older than 4.7, we need to tell KVM to ignore unhandled MSR accesses (During boot, Yosemite attempts to read from MSR 0x199, which is related to CPU frequency scaling, and is clearly not applicable to a VM guest):To start your Mac OS X guest in QEMU, use the following command line:Optionally, to start an SMP guest, one could use something like:When running the OS X guest for the first time, you'll need to install the operating system to the HDD image, so you'll need to add (and boot from) an install DVD image on the command line.SnowLeopard (10.6) was the last OS X version released in DVD format. Starting with Lion (10.7), an install DVD (.iso) image may be generated on an OS X machine by following the steps below (Thanks Dick Marinus for pointing out the Yosemite-specific updates!):There are still a few remaining issues to be worked out:

• You will need to supply the correct 64-character string as the argument of the osk='...' command line parameter above. This string is the concatenated result of two 32-bit keys, OSK0 and OSK1, which can be read from the AppleSMC chip shipping on genuine Apple machines. I wrote a small userspace program based on the Linux kernel applesmc driver, SmcDumpKey.c, which can be used (on a Mac running Linux) to query the SMC for various key values. For the full details, please see here.
• SnowLeopard (10.6), Lion (10.7), MountainLion (10.8) and Mavericks (10.9) can all be booted, with the following caveats:
  • 10.6 and 10.7 require the 'idlehalt=0' kernel argument to be passed in (e.g., at the Chameleon 'boot:' prompt) to avoid using the unsupported MONITOR and MWAIT CPU instructions.
  • 10.6 and early versions of 10.7 (somewhere prior to 10.7.5) will crash with a 'HPET not found' panic on a PIIX + SMP guest. This can be fixed with this patch, but since the problem only occurs on relatively early versions of OS X on the 'secondary' platform (PIIX, as opposed to the 'primary' Q35), I've decided to hold off on trying to upstream it for now.
  • Early 10.8 (definitely 10.8.0) will hang during boot for unknown reasons. Using 10.8.5 boot media (DVD iso or installed HDD image) works fine.
  • 10.9 'firstboot' (i.e., booting from a freshly installed HDD image for the first time) only works with SMP, for currently unknown reasons. Once the initial setup is complete, the HDD image can be booted on either SMP or uniprocessor guests.
• The main goal of this work is to get Mac OS X working with upstream KVM/QEMU/etc., so I'm mainly targeting these projects' git master branches. The patches I refer to may work against recently released versions, but please consider that as nothing more than a happy coincidence :)

Legal Disclaimer: I am not a lawyer, and this is not legal advice. Taking into account that OS X is now officially supported on commercial virtualization solutions such as VMWare Fusion and Parallels, and after a careful reading of Apple's OS X EULA (which states that '[...] you are granted a [...] license to install, use and run one (1) copy of the Apple Software on a single Apple-Branded computer at any one time'), it is my belief that it's OK to run Mac OS X as a QEMU guest, provided the host hardware is a genuine, Apple-manufactured Mac computer, running an arbitrary (e.g. Linux) host OS. This happens to be how I'm using it, but YMMV.Please read on for a detailed overview of all the issues involved !

1. Intro, Motivation, and Overview

This work started out as my OS Practicum project during the Fall of 2012, where I picked Mac OS X on QEMU/KVM as my topic. I'm a 'native' Linux user, but my IT department supports quite a few Mac OS X users, and I decided I could be much faster and more productive if I could access a Mac as a VM guest rather than dual-boot or cold-start an additional machine each time it was needed.The original work to enable OS X to run under QEMU/KVM was done by Alexander Graf. Additional kernel and userspace patches were contributed by René Rebe. Previously available patches and documentation I reviewed include:

• René's patches at T2
• The by now really out of date Wiki instructions at
  http://d4wiki.goddamm.it/index.php?title=Howto:_Mac_OSX_on_KVM

Several different components must successfully interact with each other to facilitate running Mac OS X as a QEMU/KVM guest. Each component is listed below, with a link to its dedicated section covering relevant aspects and outstanding issues related to Mac OS X guest support:

• KVM Kernel Module: at the lowest level, this component provides an in-kernel hardware assisted virtualization infrastructure.
• QEMU: userspace emulator which takes advantage of the hardware virtualization facilities provided by KVM to run a guest at nearly native hardware performance.
• SeaBIOS: default BIOS used with QEMU.
• Chameleon: a bootloader used to bridge the gap between SeaBIOS and the EFI-compatible BIOS shipping with Apple hardware.

2. KVM Kernel Module

KVM is the component located at the lowest level, providing an interface to the virtualization support offered by (among a few others) the x86_64 hardware architecture. Let's begin with a brief list of upstream resources:

• Master git repo: git://git.kernel.org/pub/scm/virt/kvm/kvm.git
  This is actually a full clone of the mainline kernel git repo, with KVM-specific commits added on top. Therefore, it is slightly less convenient to work with, although any attempts at commiting changes upstream must apply cleanly (and work correctly) against it.
• Kmod 'wrapper': git://git.kiszka.org/kvm-kmod.git
  This allows building KVM kernel modules against (and loadable into) a distro kernel (such as what ships on e.g., F18), as shown here.

Earlier OS X versions (up to 10.7 a.k.a. Lion) indiscriminately use MONITOR and MWAIT instructions, which are not currently supported by KVM and which result in an 'invalid opcode' fault when a guest attempts to execute them. A thorough explanation is given here. Beginning with 10.8 (MountainLion), the OS X kernel follows the recommended practice of checking CPUID for MONITOR/MWAIT support, and will not attempt to use them if not supported. To run 10.7 or earlier versions of OS X, either apply this additional KVM patch, or, on an already installed HDD image, run:to prevent OS X from attempting to use the unsupported instructions.The last KVM patch required to boot OS X (already applied upstream) is a misleadingly simple-looking one liner, which removes a single line from virt/kvm/ioapic.c (or x86/ioapic.c in the kvm-kmod version):Without removing this line, a Mac OS X guest hangs during boot with an error message that reads: 'still waiting for root device

Falling Time Mac Os Catalina

'.Modern x86 system design includes Intel's IOAPIC (interrupt controller) chip, which receives interrupts from peripheral devices and forwards them to the appropriate CPU's local interrupt controller (LAPIC). The IOAPIC can be programmed to handle both level and edge triggered interrupts. Historically, with the IOAPIC's predecessor (the 8259 PIC), level triggered interrupts were considered 'active' (or 'asserted') when the line went 'high', and 'inactive' when the line remained 'low', from an electrical standpoint. In other words, the 'logical' state of an interrupt line coincided with its 'physical' state. With the IOAPIC, it is possible to configure each individual input (interrupt line) to use the 'classic' interpretation of 'active' vs. 'inactive', now referred to as 'ActiveHigh', or to reverse it by setting a per-input-line 'polarity bit', so that interrupts are considered asserted when the line drops to 'low' from a default inactive 'high' voltage state. This mode is known as 'ActiveLow'. With 'ActiveLow', the physical state of the line is the exact opposite of its logical state.ACPI-compliant operating systems are expected to query the firmware for an indication of which polarity type (ActiveLow or ActiveHigh) to use for any devices with level-triggered interrupts, and to configure the IOAPIC registers accordingly. Both QEMU and KVM have accumulated a significant number of optimizations based on the assumption that guest operating systems use ActiveHigh polarity, and are coded to assume that 'physical' and 'logical' IRQ line states are in sync. Even when a misbehaving guest OS (you guessed it, OS X does this) ignores the ACPI polarity hint (which in QEMU/KVM is ActiveLow, i.e. 'physical'logical') and configures the virtual IOAPIC with the wrong polarity bit values, both QEMU and KVM will mostly use 'logical' IRQ line levels.The referenced patch removes the last place where KVM attempted to care about the value of the polarity bit placed into the IOAPIC register by the guest OS. Because logical levels were assumed everywhere else, looking at the polarity bit could result in flipping the given 'logical' line state at the wrong time, resulting in level triggered interrupts being ignored instead of handled. Once we stop paying attention to the polarity bit values, things work fine. Logical IRQ levels are passed into KVM from userspace by QEMU, and whatever the guest OS does when it programs its IOAPIC polarity bits doesn't matter. Thus, when OS X wrongfully ignores QEMU's ACPI and proceeds with a hard-coded ActiveLow polarity, things just work in spite of that.

3. QEMU

QEMU is a multi-architecture emulator running in user-space. For certain architectures (such as x86_64), QEMU is able to take advantage of hardware virtualization features offered through e.g. KVM, which allow it to run guests at near-native performance levels. Here is roughly how QEMU and KVM work together to implement a guest VM:

• QEMU starts as a user-mode process, launching one thread for each VCPU that will be part of the guest VM. The guest system's 'physical' memory is allocated as part of the virtual address space of the QEMU process, and various handlers for the emulated virtual hardware of the guest systems are prepared.
• Each QEMU VCPU thread makes an ioctl() call into the kernel (where it will be serviced by KVM), requesting that the VCPU be scheduled on a pyhsical core. This ioctl() call will only return to userspace if/when KVM encounters a VM exit it can't handle itself. This typically involves a need for userspace emulation of specific guest hardware. Normally, when the userspace emulation is complete, the QEMU VCPU thread loops back to the spot where it calls into the kernel via the ioctl().
• KVM handles the kernel-side of the ioctl() call made by each QEMU VCPU thread. Normally, it causes the physical core on which the thread is scheduled to enter VM guest mode (a.k.a. L>1). Whenever a VM exit (back to host mode) occurs, KVM attempts to handle the exit cause itself, and immediately re-enters VM guest mode if successful. Otherwise, the VM exit reason is passed back to userspace by falling out of the ioctl() call, at which point QEMU must handle it as described above, before calling back into KVM again via the ioctl().

A quick list of QEMU upstream resources might include:

• Master git repo: git://git.qemu.org/qemu.git

There are four relevant topics regarding support for Mac OS X guests: QEMU's recent inclusion of support for the Q35/ICH9 based architecture; emulation of Apple's System Management Controller (a.k.a. AppleSMC), including automatically advertising its presence via ACPI; and, finally, a few issues related to QEMU's emulation of the e1000 network controller.

3.1. The Q35/ICH9 architecture

Support for the Q35 architecture was recently (Dec. 2012) merged into QEMU mainline. Q35 replaces the old I440FX (a.k.a. PIIX) with Intel's more modern ICH9 chipset, which also happens to be used on most Intel-based Apple hardware. Among other hardware, ICH9 includes an integrated AHCI disk controller, which had to be added explicitly prior to the Q35 QEMU command line:As Q35 is slated to become the new default 'machine type' in QEMU in the near future, the bulk of the effort (development, debugging, and testing) to get Mac OS X supported under QEMU will be focused on this platform.

3.1.1. Ethernet Link negotiation issues with e1000 on PIIX

Starting with MountainLion (OS X 10.8), the proprietary e1000 network driver built into OSX (AppleIntel8254XEthernet.kext) fails to detect network link unless special care is taken to move the network card to a separate hardware IRQ line from the AHCI/SATA controller. By default with the above command line (i.e. without using ',bus=pci.0,addr=5'), the network card will be placed in PCI slot 4, and will share IRQ11 with a bunch of other devices (e.g. AHCI/SATA, USB, etc). Moving it to PCI slot 5 causes it to use IRQ10 by itself, which is a sufficient workaround for the problem, at least for now.After some reverse engineering, it appears that the AppleIntel8254XEthernet.kext reads the e1000 ICR (Interrupt Cause Register) each time a PCI interrupt is detected. However, until e1000 initialization is complete, including the final configuration of the e1000 IMR (Interrupt Mask Register), any e1000 interrupts, including LSC (link state change) are ignored. The driver 'knows' it hasn't unmasked the interrupt yet, so while it reads the self-clearing ICR on hardware interrupt, it simply ignores the contents, which is then lost due to the register's reset-on-read behavior.Normally, the driver has enough time to finish setting up the mask register before a PCI interrupt is generated by the hardware when link autonegotiation is completed. However, by sharing a hardware IRQ line with the 'noisy' SATA controller, the hardware interrupt handler portion of the e1000 driver (which reads the ICR) is invoked early and often, before the mask setup is completed, leading to the asserted link state change interrupt being discarded before it can be acted upon.Moving the e1000 card to a new hardware IRQ line away from SATA (by forcing it into a custom PCI 'slot') solves the problem by not invoking the e1000 hardware interrupt handler before setup is complete. Another workaround (suggested by Alex Graf) is to delay reporting the LSC interrupt to the guest until the IMR (mask register) was configured. However, as pointed later in that thread, this patch may be problematic for guests wishing to poll the ICR without relying on hardware interrupts (by setting up a mask). Although mostly a theoretical issue at this point, this patch would significantly differ from expected hardware behavior.

3.2. The AppleSMC emulator

The AppleSMC (or System Management Controller) is a chip specific to Intel-based computers manufactured by Apple. Its main purpose is to control (and report on) fan speeds, temperature sensors, screen and keyboard light intensity levels, and miscellaneous other power management features.From the point of view of the operating system driver, interaction with the SMC happens via port-based I/O: The name of a 4-character key is written to a control port, and the key's numeric or ASCII value is then read from (or written to) a data port. Keys typically represent fan speeds, light intensity levels, or temperatures.A pair of already upstreamed patches advertises the presence of the SMC in QEMU's ACPI/DSDT table, conditionally, based on whether or not it was specified on the QEMU command line.There are currently two outstanding issues with QEMU's AppleSMC emulation which could improve Mac OS X guest support, outlined below.

3.2.1. Automatic OSK 'pass-through' on Apple hardware

The AppleSMC is also used to store a 64-byte ASCII string copyrighted by Apple, spread across two 32-byte key values, named OSK0 and OSK1. This string is used by Mac OS X to determine whether it's being booted on genuine Apple hardware. QEMU does not set up AppleSMC emulation by default (since only OS X guests require it at this time). To set it up, the following QEMU command line snippet is required:The user must supply the correct value of the 64-byte OSK string as an argument, and is responsible for honoring Apple's OS X EULA (which states that '[...] you are granted a [...] license to instal, use and run one (1) copy of the Apple Software on a single Apple-Branded computer at any one time').I wrote a small C program, SmcDumpKey.c, which can be used to read various SMC key values (including OSK0 and OSK1) from an Intel Mac running Linux. However, a significant improvement in usability and ease of compliance with the OS X EULA could be accomplished by allowing QEMU's AppleSMC emulator to automatically acquire the OSK strings from the underlying (Apple) host hardware.Currently, the drivers/hwmon/applesmc.c Linux driver populates a Sysfs directory (/sys/devices/platform/applesmc.768/) which offers access to most SMC key values. Unfortunately, that does not include OSK0 and OSK1. I submitted this patch against the applesmc.c Linux driver, but encountered two main objections (also see the various other replies in the referenced thread):

• /sys/devices/platform/applesmc.768/ is (or should be) reserved for hardware-monitoring related keys and values only; This point seems to be contradicted by Documentation/sysfs-rules.txt in the Linux kernel sources, which states that each device should get its own node (directory) in a device tree, and does not recommend spreading any device's entries into separate spots across Sysfs by any sort of 'category'.
• The OSK values are constant, so it makes no sense to query the hardware if we know ahead of time what the returned value will be. My counter argument to that is that it makes perfect sense to query the hardware each time, precisely because Apple claims copyright on the returned string, which can therefore never be legally hardcoded (and distributed) in any open source project such as QEMU.

I'm planning to follow up with the Linux maintainer of applesmc.c again in the near future to reiterate these points, but in the mean time I could really use some advice and feedback from anyone with successful patch submission experience to the Linux kernel :)

3.2.2. OS X fails to write a key value to the emulated SMC

During boot, Mac OS X will log a few non-fatal SMC-related errors:It appears that emulating a few extra SMC keys, as well as allowing the OS X guest to

Falling Time Mac Os X

write (as opposed to just read) some of the supported keys might make these errors go away.

3.3. The virtio-net virtual network card

A great alternative to using the default e1000 virtual network card (albeit one that requires post-install 'surgery' on the guest) appears to be using virtio-net instead (thanks George Yunaev and Warren Togami for pointing this out!). Start the guest with the following additional command line arguments:and install the 'aftermarket' virtio-net driver by Phil Jordan on the guest side. Since our guest does not have a network connection, download the driver on the host like so:and then start your guest with an additional FAT 'drive' mapped to the '

Falling Time Mac Os Catalina

./VirtIoNetDrv/' download directory:Once the guest is up, install the driver via the usual method, and restart. A new Ethernet interface should become available, and should work from that point on with minimum fuss. Tested and confirmed working on OS X 10.8.5 and 10.9.*.

Mac Os Catalina

3.4. Boot OS X on QEMU without KVM hardware assistance

This now works (albeit very slowly, too slowly to be useful in practice), with the following (already upstreamed) patches:

• OS X requires a software-emulated LAPIC version of 0x14 or higher;
• The software-emulated IOAPIC must ignore polarity bits set by the guest, matching the hardware-accelerated behavior of the KVM IOAPIC.

4. SeaBIOS

SeaBIOS is the default BIOS for QEMU/KVM. The QEMU source tree includes a sufficiently up-to-date snapshot of SeaBIOS (in pre-built, binary form).For reference only at this point, upstream resources include:

• Master git repo: git://git.seabios.org/seabios.git

SeaBIOS has been patched to accept SMBIOS tables generated by QEMU. At this point, all SMBIOS tables will be v2.8 compliant (a version newer than 2.4 is required to support 'About This Mac' without crashing Finder), and the user may specify the inclusion of a Type 2 (Baseboard) entry, required for booting [Mountain]Lion, on the qemu command line:

5. Chameleon

Chameleon is a Darwin/XNU boot loader based on Apple's boot-132. It is currently used to boot OS X on systems which do not contain Apple's EFI BIOS as expected. Project resources include:

• Project home page: http://chameleon.osx86.hu/
• SVN repository: http://forge.voodooprojects.org/svn/chameleon

Chameleon boots the OS X kernel (XNU) in three stages. We are interested mainly in the last stage (known as 'stage 2', counting from 0). The project is designed to be built under OS X itself, and also depends on Xcode. Xcode v5.0.2 (free/beer download via the AppStore) on OS X 10.8 or later can build the latest Chameleon trunk (SVN 2360 at the time of this writing). Once these prerequisites are met, simply running 'make' in the appropriate SVN subdirectory will build the entire project.The Chameleon stage-2 bootloader will be built as './sym/i386/boot'. On QEMU, we bypass all earlier stages by loading this binary as the default 'kernel' (via the '-kernel chameleon_svn2783_boot' command line argument). On a (U)EFI compliant machine, in theory, (U)EFI would find a file named '/System/Library/CoreServices/boot.efi' on the OS X partition and use it directly. Chameleon's stage-2 'boot' file is a roughly equivalent replacement for that.Chameleon offers a range of additional 'bells and whistles', such as the ability to load alternative and/or additional .kext modules (OS X kernel drivers), and replace the system's default ACPI DSDT, mostly intended for 'hackintosh' systems. On QEMU, however, the idea is to offer a DSDT and virtualized 'hardware' that's close enough for OS X to run on, without needing that type of 'assistance' from the bootloader.An example Chameleon configuration (create a new file under /Extra/org.chameleon.boot.plist) is shown below. The example configures Chameleon to automatically enter the first encountered OS X partition after a 5-second wait. It also forces the guest video settings to 1280x1024 pixels, 32-bit color depth (which is something that currently can't be done from *within* the guest's display settings, for reasons I'm still investigating). Thanks to Andrei Ostanin, Christian Simon, and Warren Togami!In the long term, it might be possible to use a QEMU-compatible UEFI BIOS instead of SeaBIOS, and have it boot into OS X using the original /System/Library/CoreServices/boot.efi Apple-provided bootloader.

6. Conclusion and Future Work

My ultimate goal is to upstream whatever changes are needed to KVM/QEMU/SeaBIOS/Chameleon/etc., to allow installing and running OS X from unadulterated, standard images. I plan to keep this document updated with the current list of outstanding issues. Eventually, the idea is for this document to 'melt away' as all these issues are addressed, and all patches are accepted into their respective upstream projects.I appreciate any ideas, comments, and feedback. Please email me at somlo at cmu dot edu with any questions, comments, and suggestions.

Table of Contents

• 2 Instructions on how to restore Mac OS to the previous date
  • 2.1 Step 1. Configure a Time Capsule

There’s nothing more annoying than a slow or crashing computer.^[1] It doesn’t matter if you use Windows or Apple device, you still want it to boot quickly and work fast. However, during the time, computers might become sluggish, and you might find yourself daydreaming about a new device. Though, new Mac might not be the priority in your shopping list. Fortunately, you start fresh without spending the money. It’s enough to restore Mac to the earlier date to make it faster or get rid of annoying errors.

Restoring Mac to the earlier date helps to speed up the computer.

Windows computer users have System Restore^[2] feature that allows reverting computer to the previous date. Thus, they can travel back in computer’s time before the error, ransomware attack or other problem has occurred.

However, Mac OS X users can take advantage of this feature as well. It’s not hard to restore Mac to the previous date. Thus, if you want to speed up your beloved PC, read further to learn more how to perform this task.

Reasons why computers become sluggish

Often Mac or Windows computers become sluggish due to various cyber infections:

• you might accidentally install potentially unwanted program (PUP) during freeware installation;
• you might download illegal content that brought spyware or cryptocurrency miner^[4] to the computer;
• you may have incorrectly uninstalled or deleted applications and corrupted program-related files that caused system errors;
• ransomware attack;
• etc.

However, not only viruses or malicious programs can cause system slowdowns. Even if you are responsible computer users, everyday tasks still diminish Mac performance. Thus, system restore can help to start fresh and enjoy your PC like the first day you got it from the Apple store.

Instructions on how to restore Mac OS to the previous date

Mac restore requires setting up a Time Capsule and using Time Machine. It’s a built-in backup software in macOS. It allows creating data backups and restoring them. However, it’s not an offline storage utility.^[3] Thus if you are afraid of losing your files or want to backup all your life and keep it safe and sound, you should use external storage device or look up for other Mac backup solution.^[5]

Step 1. Configure a Time Capsule

You won’t be able to restore Mac until you set up a Time Capsule. You can perform this task either manually or automatically. However, you will need to use an external drive and connect it to your computer.

However, if you cannot perform this task due to some computer-related problems or virus infection, you will need to repair the hard disk or reinstall the operating system. However, we hope that you won’t need these methods.

Automatic Time Capsule set up

Once you connect your external storage device to the computer, you should receive a prompt saying:

“Do you want to use the drive to back up with the Time Machine?”

You should choose Use a Backup Disk option to start the process. After a while, your Time Capsule will be configured, and you will be able to restore Mac.

Manual Time Capsule configuration

However, in some cases, Mac does not deliver previously mentioned pop-up. For this reason, you cannot set up Time Capsule automatically. For this reason, you have to do it manually by following these steps:

1. Open Apple menu.
2. Access System Preferences and choose Time Machine.
3. Click Select Backup Disk option.
   
4. Now you have to choose your external storage device from the available disks list. Then click Use Disk button.

If you want to ensure that your files are protected and cannot be accessed by third-parties, you should hit “Encrypt Backup Disk” option and create a strong password.

Wait until backup process is over. Indeed, it might take some time if your Mac is full of documents, video files, image and other data. Thus, you have to be patient!

Step 2. Use Time Machine to backup your data

Time Capsule creates backups every single day. Thus, once you set it up, it automatically creates backups for the previous 24 hours. Additionally, it also creates daily backups of the previous month. However, you can speed up this process; you can create a backup immediately after setting up a Time Capsule.

All you have to do is to choose Backup Up Now option from the Time Machine’s menu. Wait until it finishes the task and proceed to the third step.

Step 3. Restore Mac to the earlier date

When preparatory work is done (previous two steps), you can start the main task – computer restore with OS X Recovery Tool. Follow these steps:

1. During the system startup, hold down the command key + R to open the recovery tool.
2. Choose Restore From Time Machine Backup option.
   

   Choose “Restore From Time Machine Backup” option from the macOS Utilities window.

3. If you have few backups, choose the one that was created before particular Mac error or around the date you have noticed system slowdowns or other problems.

Then, you have to wait until Mac restore is finished. One it’s done, you can enjoy your PC’s performance again!