LinuxQuestions.org
Welcome to the most active Linux Forum on the web.
Go Back   LinuxQuestions.org > Forums > Other *NIX Forums > Other *NIX
User Name
Password
Other *NIX This forum is for the discussion of any UNIX platform that does not have its own forum. Examples would include HP-UX, IRIX, Darwin, Tru64 and OS X.

Notices


Reply
  Search this Thread
Old 08-17-2017, 07:04 PM   #16
jlinkels
LQ Guru
 
Registered: Oct 2003
Location: Bonaire, Leeuwarden
Distribution: Debian /Jessie/Stretch/Sid, Linux Mint DE
Posts: 5,191

Rep: Reputation: 1039Reputation: 1039Reputation: 1039Reputation: 1039Reputation: 1039Reputation: 1039Reputation: 1039Reputation: 1039

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
 
Old 08-17-2017, 08:07 PM   #17
IsaacKuo
Senior Member
 
Registered: Apr 2004
Location: Baton Rouge, Louisiana, USA
Distribution: Debian 9 Stretch
Posts: 2,354

Original Poster
Blog Entries: 8

Rep: Reputation: 384Reputation: 384Reputation: 384Reputation: 384
Quote:
Originally Posted by jlinkels View Post
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.
 
Old 08-17-2017, 09:21 PM   #18
HappyTux
Senior Member
 
Registered: Mar 2003
Location: Nova Scotia, Canada
Distribution: Debian AMD64
Posts: 3,747

Rep: Reputation: 131Reputation: 131
Quote:
Originally Posted by IsaacKuo View Post
Okay, I have had various struggles and successes, but basically I have determined that the OSX recovery partition can't resize the main OSX partition (it always fails saying it can't unmount partition) and that the main OSX partition always wipes out the recovery partition when resizing itself - even when it only resizes itself just a little bit bigger (with hundreds of GB of unallocated empty space between itself and the recovery partition).

I may give Carbon Copy Cloner a go, but I have some reservations:

1) At their web site, it seems that the download is for a "30 Day Trial". This makes it sound like the software will not work after 30 days. I'm okay with paying for software if I'm paying for capabilities that I'll use and are worth the money, but chances are good I'll only even boot into OSX maybe once or twice a year for whatever the heck may work better with the iPhone than Windows 10. I'm sure CCC has great capabilities for people who have a need for its capabilities. But I just want to restore this Mac Mini to the state it was before I shrunk its main partition.
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.

Quote:
What I have experienced with OSX so far in my lifetime does not inspire me to have any desire to use it more than the barest of bare minimums. Honestly, the only reason I'm keeping this Mac Mini up is in case I want to get into iOS native app development. Besides, OSX on this 2011 Mac Mini is crippled by the slow hard drive.
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.

Quote:
2) Honestly, I don't know how to download or install OSX software, much less remove it cleanly afterward--which I'll definitely want to do to avoid cluttering up this computer with non-functioning junk after the trial period. Various things on this OSX thing seem to complain about my expired iTunes account and/or expired Credit Card info on it.
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.

Quote:
3) The current recovery partition includes a base OSX image. I don't see how CCC could possibly replicate that image after the partition it's on has been wiped out.
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.

Quote:
BTW, I have no large USB thumbdrives, so options for where to save a partition or partition image are extremely limited for me while in OSX. In contrast, when booted up to Debian I've got huge drives on the network via NFS shares (and also samba).
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.

Quote:
So right now, I have made a new much smaller "dd" image (saved to my main file server), and I think my next step will be to try and "dd" an image of just /dev/sda3 and try to restore it afterward. My plan is:

Code:
1) image OSX Recovery partition sda3 with

dd if=/dev/sda3 of=/mnt/nfsshare/transfer/OSXsda3.img bs=32256

2) Reboot into main OSX (sda2), and use Disk Utility to expand itself

currently it is 27.4G:

/dev/sda1         40    409639   409600  200M EFI System
/dev/sda2     409640  57755647 57346008 27.4G Apple HFS/HFS+
/dev/sda3  975503360 976773119  1269760  620M Apple boot

My plan is to expand it to the maximum size minus 700M. This will leave enough space for the original sda3.

3) Reboot into Debian NFS-RAMBOOT; use gparted to create a new sda3 (1269760*512 bytes in size).

I think the file system I choose won't matter, so I'll just make it FAT.

4) restore from image with

dd if=/mnt/nfsshare/transfer/OSXsda3.img of=/dev/sda3 bs=32256

I think this will restore all relevant aspects of sda3 such as label, UUID, whatever.
It's not an elegant plan, but hopefully it will work.
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.

Code:
$ diskutil list

/dev/disk1 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *120.0 GB   disk1
   1:                        EFI EFI                     209.7 MB   disk1s1
   2:                  Apple_HFS EL_SSD                  39.3 GB    disk1s2
   3:                 Apple_Boot Recovery HD             650.0 MB   disk1s3
   4:                  Apple_HFS iMac_TM                 79.6 GB    disk1s4
 
Old 08-18-2017, 12:13 AM   #19
IsaacKuo
Senior Member
 
Registered: Apr 2004
Location: Baton Rouge, Louisiana, USA
Distribution: Debian 9 Stretch
Posts: 2,354

Original Poster
Blog Entries: 8

Rep: Reputation: 384Reputation: 384Reputation: 384Reputation: 384
Quote:
Originally Posted by HappyTux View Post
BTW the cheapest SSD you can find will go into that machine and make it feel like a new extremely fast beast.
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.

Quote:
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.
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!

Quote:
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.
Okay, CCC and Pacifist. I'll make note of them for later potential use.

Quote:
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.

Code:
$ diskutil list

/dev/disk1 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *120.0 GB   disk1
   1:                        EFI EFI                     209.7 MB   disk1s1
   2:                  Apple_HFS EL_SSD                  39.3 GB    disk1s2
   3:                 Apple_Boot Recovery HD             650.0 MB   disk1s3
   4:                  Apple_HFS iMac_TM                 79.6 GB    disk1s4
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.
 
Old 08-18-2017, 08:57 AM   #20
IsaacKuo
Senior Member
 
Registered: Apr 2004
Location: Baton Rouge, Louisiana, USA
Distribution: Debian 9 Stretch
Posts: 2,354

Original Poster
Blog Entries: 8

Rep: Reputation: 384Reputation: 384Reputation: 384Reputation: 384
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.
 
Old 08-18-2017, 10:01 AM   #21
HappyTux
Senior Member
 
Registered: Mar 2003
Location: Nova Scotia, Canada
Distribution: Debian AMD64
Posts: 3,747

Rep: Reputation: 131Reputation: 131
Quote:
Originally Posted by IsaacKuo View Post
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.
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.

Code:
$ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda5        32G  3.3G   27G  12% /
udev             10M     0   10M   0% /dev
tmpfs           599M  1.2M  598M   1% /run
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs           2.3G     0  2.3G   0% /run/shm

Quote:
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!
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.



Quote:
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.
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.
 
Old 08-18-2017, 10:45 AM   #22
IsaacKuo
Senior Member
 
Registered: Apr 2004
Location: Baton Rouge, Louisiana, USA
Distribution: Debian 9 Stretch
Posts: 2,354

Original Poster
Blog Entries: 8

Rep: Reputation: 384Reputation: 384Reputation: 384Reputation: 384
Quote:
Originally Posted by HappyTux View Post
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.
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.

Quote:
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.
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.

Quote:
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.
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.
 
Old 08-19-2017, 12:45 AM   #23
IsaacKuo
Senior Member
 
Registered: Apr 2004
Location: Baton Rouge, Louisiana, USA
Distribution: Debian 9 Stretch
Posts: 2,354

Original Poster
Blog Entries: 8

Rep: Reputation: 384Reputation: 384Reputation: 384Reputation: 384
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.

Code:
Device         Start       End   Sectors   Size Type
/dev/sda1         40    409639    409600   200M EFI System
/dev/sda2     409640 974233823 973824184 464.4G Apple HFS/HFS+
/dev/sda3  974233824 975503359   1269536 619.9M Apple boot
/dev/sda4  975503360 976773119   1269760   620M Apple HFS/HFS+
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).
 
Old 09-16-2017, 02:02 AM   #24
friv2
LQ Newbie
 
Registered: Sep 2017
Posts: 1

Rep: Reputation: 0
heloo
 
Old 01-01-2020, 10:48 AM   #25
bvrulez
LQ Newbie
 
Registered: Mar 2015
Posts: 3

Rep: Reputation: Disabled
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!
 
Old 01-01-2020, 12:42 PM   #26
IsaacKuo
Senior Member
 
Registered: Apr 2004
Location: Baton Rouge, Louisiana, USA
Distribution: Debian 9 Stretch
Posts: 2,354

Original Poster
Blog Entries: 8

Rep: Reputation: 384Reputation: 384Reputation: 384Reputation: 384
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.
 
Old 01-01-2020, 01:25 PM   #27
bvrulez
LQ Newbie
 
Registered: Mar 2015
Posts: 3

Rep: Reputation: Disabled
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.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
zypper update makes /var/lib/rpm/Packages grow and grow and grow... Earl3 Linux - General 3 06-27-2011 02:07 PM
LXer: Linux desktops grow and grow and grow LXer Syndicated Linux News 0 11-23-2007 01:00 PM
Recovering a filesystem (do you know something about NTFS or HFS?) mapquest Linux - General 2 04-25-2007 10:26 PM
hfs: unable to find HFS+ superblock VFS: Can't find ext3 filesystem on dev sdb. macroron Linux - Hardware 3 11-20-2006 09:50 PM
Error mounting HFS+ volume: unable to find HFS+ superblock applewax Linux - General 3 05-31-2006 08:45 AM

LinuxQuestions.org > Forums > Other *NIX Forums > Other *NIX

All times are GMT -5. The time now is 12:11 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration