I don't see any holes in your plot either. Only a bs of 32k seems a bit small to me. It slows down transfer. 10M looks as a better value. But that's all

UUID's etc are stored in the disk partition so they should be copied.

jlinkels

Well, it worked! It took me a little trial and error to get gparted to create a new sda3 of precisely the right size, but after that I overwrote it with dd and it was all happy. I use the bs=32256 just because it's what a JustLinux (formerly LinuxNewbie) sticky how-to showed. I've used it ever since, and keep using the same bs just to ensure I don't accidentally confuse myself with bs*count math.

One thing changed, though. There must be some flag in the partition table which had made sda3 hidden in OSX. That meant that it didn't show up in OSX Disk Utility (the Apple bootloader always saw it as a boot option).

But now, sda3 shows up in OSX Disk Utility. I don't mind this.

I don't know if my experience and convoluted resolution method will be helpful for anyone else. Maybe the real useful advice is to think long and hard before shrinking any OSX partitions to make way for dual boot. USB or network boot options may be a better idea long term.

It expires a fully functional copy after the 30 days so the trial does everything the paid program will do or that is my understanding. I am not certain of that though as my copy never got the chance to expire, in my near ten years of use it has never failed me.

My experience has been considerably different I started when Leopard came out going on ten years ago. Luckily at the time I had just switched over to Intel Core processor family from AMD and some wonderful people had figured out how to fool the OSX operating system into thinking it was running on mac hardware. Now I have to tell you the difference is night and day between OSX and any Linux desktop I had used in the previous decade or so of full time Linux usage. Still to this day it beats it hands down as I have over the years installed a few test systems to see how it has progressed and to be frank not much has really changed. Now for a server I use nothing but Linux but as the systemd infestation continues I am about to jump to the BSD realm I do believe. BTW the cheapest SSD you can find will go into that machine and make it feel like a new extremely fast beast.

Nothing to it download the .dmg or .pkg file run and in the case of the .dmg drag and drop the program to the Application Folder. Pacifist is a program that will show the contents of either of them formats for installation showing where everything will be installed so you could remove manually or download the AppCleaner.app to do it graphically. iTunes never use it really and have never put any credit card info in there and the programs I use don't seem to mind. Now I run mainly open source software on my install only having purchased the already mentioned Carbon Copy Cloner, Pacifist, Default folder X and PathFinder.

No clue where it gets it but the first time it offered to do it for me was on an install that had no recovery partition at all ever on it. As I am still on my install done in early March 2008 using the retail install method for a hackintosh from the Leopard DVD I bought after having played around with what was called a distro which you just restored to a hard drive an image that someone had made from the November previous. This install has survived all these years over many different OS upgrades, machines and hard drives it is like the Energizer bunny it just keeps going and going.

I use to store my Time Machine backups on a zfs file system container formatted HFS+ on a Debian server now whether that will show up on the network for the mini to be able to access and restore from it no clue as I have never done it.

Looks like everything needed is still there the EFI, OS and enough size in the remaining for a Recovery partition. Rest of the plan OSX tools should be used as I have mentioned already.

Apple in its wisdom made it risky and difficult to try and replace the hard drive on these unibody Mac Minis. You have to destructively remove internal components and carefully remove (and later replace) a heat sink/heat pipe in order to get at the hard drive. Believe me, I would have done it years ago if I weren't wary of how much force I was putting on the components while trying to remove them. I'd rather put that 500GB hard drive in a battery powered media playback laptop for when the power goes out (or for use on a road trip). I've long had a suitable 30GB SSD to swap in after shrinking/moving/cloning the OSX drive.

Of course, Debian isn't crippled by the slow hard drive. I use NFS-RAMBOOT to load up the / filesystem into RAM (tmpfs). Much faster than any SATA SSD. What's crazy is that the initial boot time is still much faster than OSX even though it's transferring the entire (compressed) OS partition over gigabit ethernet.

I assume the .dmg file needs to be downloaded, though? I'm sure I could have figured that part out, but then my instinct would have been to double-click on the downloaded file rather than to drag it to the Application Folder (which I do now know how to get to). Good to know for later. Thanks!

Okay, CCC and Pacifist. I'll make note of them for later potential use.

Well, I have fixed up things now, and I have dd backup images for later use if necessary. For example, if that 500GB internal hard drive dies, then I may have another go at trying to replace the internal drive. With a 30GB SSD, of course, if I'm going to do it.

BTW, After updating my credit card info in iTunes, the App Store is now downloading a free upgrade to OSX Sierra (10.12). It currently has OSX Yosemite (10.10). The last time I did this OSX upgrade was when I first acquired this Mac Mini. It had been collecting dust at my parent's place (a gift from my brother, who also set up a ton of software on it).

Things didn't go so well that first time because the Mac Mini had its stock 2GB of RAM in it. Going to OSX Yosemite (10.10) took FOREVER and the result was stupendously sluggish because 2GB just wasn't enough. It was thrashing like crazy. Had I really thought about this possibility, I could have avoided grief simply by swapping in more RAM beforehand. I have plenty of laptops with DDR3 RAM. At the time, though, I thought 2GB was plenty of RAM for any reasonable OS.

Not a big problem, though. After the struggling Mac finally finished booting up and shutting down, I swapped in more RAM.

This time, the Mac Mini has 8GB of RAM. Surely that's plenty of RAM for OSX Sierra.

The max speed of gigabit ethernet is 120MB/s any modern SSD will blow that out of the water and what you are seeing is the transfer of the initrd and kernel to load not the entire operating system I would think. Compressed or not (binary files compress very little) the few GBs of data would take some amount of time to transfer let alone load into that ram disk that would be needed for its storage. Looking at my rather minimalist install of Debian it takes 3.3GB. A test copy of a 2.3GB file here just took little over minute at ~65MB/s between it and my OSX install.


Yes needs to be downloaded and in both instances doubled clicked for a .dmg you will get a finder window with most times an image of the App with arrow pointing to an Application folder which you drag and drop it too, .pkg just pops up dialog asking if you want to install.



30 is a little tight especially since you mentioned iOS app development so you will need Xcode probably better of with 120 minimum it is a space hog.

Uh, no. NFS-RAMBOOT loads the entire OS onto a local tmpfs ram drive. Then it completes the boot process with "/" on a local ram drive. It never accesses the network at all after that for OS files. The bandwidth available for DDR3 RAM is orders of magnitude faster than a SATA interface. No SATA SSD can compete with RAMBOOT for sheer speed.

Anyway, the slow 2.5" spinning hard drive in this Mac Mini can't even get 80MB/s, so there's really no point in me using it to store the OS tarball. Loading the OS tarball over gigabit ethernet is faster, and it also allows me to leave the OSX install untouched. And it also lets me perform various maintenance tasks on the file server, including compression of the tarball. I use rsync to only do incremental saves of the current "/" state. This is really fast and efficient. And then I run the tarball compression on the file server. This is great for a lot of reasons. I can do that tarball compression at the same time as rebooting the Mac Mini into OSX or whatever. By the time I'm ready to reboot back into Debian, that tarball compression has already been finished.

What you consider rather minimalist is very different from what I consider rather minimalist. When I do a minimal Debian 9 install and add XFCE4 and various little things I standardly use, it takes up about 1.5GB. Tarball compression on this roughly halves the size. As such, it roughly halves the amount of time NFS-RAMBOOT takes to boot (the other steps are ludicrously fast due to the insane speed of tmpfs RAM disk and the boot time efficiency of systemd).

That said, the NFS-RAMBOOT setup on this Mac Mini is not minimalist. I have it loaded up with all sorts of development software and multiple web browsers and such. It's my main computer. As such, its "/" is bloated up to 3.6GB in size, and the compressed tarball is bloated up to 1.5GB in size. So, the NFS-RAMBOOT setup transfers the 1.5GB tarball when booting, which takes about 2 minutes. Thus, it takes about 2 minutes for Debian NFS-RAMBOOT to boot up. This is still far less time than OSX takes to boot up thanks to the sluggish hard drive.

I see. I guess I'll invest in a new SSD then, if the internal hard drive ever fails. I'm not going through the risk/effort of tearing out the 500GB hard drive just to replace it with another spinning hard drive.

One last little update - the upgrade to OSX Sierra (10.12) created another little recovery partition - sda3; shifting the previous recovery partition (10.10) from sda3 to sda4.

So, all my worries were really over nothing. The recovery partition I was so keen on saving would have been outmoded by the Sierra upgrade anyway. But I learned a lot and vastly boosted my confidence in working with OSX partitions and OSX Disk Utility (albeit the UI for 10.12 Disk Utility is very different from 10.10 Disk Utility).

heloo

I have the same problem. I want to resize my original OS X partition after I reduced the size of a dual boot Linux partition. It's not possible with gparted or disk utility inside the running system. I did not yet try your approach but I wanted to say it helped to read the detailed description and the probably working solution. So thanks!

You're welcome!

In the two years since then, I have ended up using OSX a grand total of zero times. I have no need to remove OSX, though, since I'm not installing Debian on that slow spinning hard drive anyway.

I have modified my Debian setup, though. That Mac Mini is no longer my main computer, since I have a number of faster computers. I even removed some RAM from it so I could have more RAM in a couple faster laptops.

So, I no longer use RAMBOOT with the Mac Mini. It's just booting with NFS root. It's not as zippy as RAMBOOT, but I hardly notice the difference especially since I don't actually use it so heavily. In fact, the main thing I do with it is use it as a network sound output for a faster desktop computer with a ton more RAM (16GB). That computer does RAMBOOT.

I had this problem on a Macbook Air. I run several multi-boot Macs with Linux, Windows and OS X. Or I used to at least. Lubuntu was my favorite Linux but they changed it with 18.10 so I am not liking it that much any more. Also, Windows got better. But I still use my Macbooks and iMacs with OS X, even upgraded to macOS. I used rEFInd as boot manager: https://www.rodsbooks.com/refind/

Also, I just found another solution to resize the partition on the live system: https://flarn2006.blogspot.com/2010/...x-without.html

I checked if I could find the recovery partition that you mentioned but no command found it in terminal. Resize via the diskutil tool did not work anyway and gparted also could not do it. But I just did it with the command line.