Installing recent CentOS versions on Macs is not as straight forward as I wish it to be. I repeatedly had issues even getting the installation media to boot. In this snippet I gather my findings and present a way to successfully install CentOS on a Mac.
Tested using CentOS Stream 8 on a Late 2014 Mac Mini.
When using the usual methods of creating a bootable USB drive (e.g. by using balenaEtcher) I was greeted by a black screen. In order to successfully get to the CentOS installer I did the following things:
- Format the USB drive
- Copy the ISO onto the USB drive
- Replace the EFI boot file
- Edit
grub.cfg
- Copy
repair-grub.sh
andmount-lvm.sh
to the USB drive
This step is mainly necessary in order to be able to modify files on the USB drive in macOS. By default the system wasn't able to read the filesystem of the CentOS ISO or the drive created by Etcher. If you are using a Linux machine you can probably skip steps 1.1 and 1.2 and instead copy the contents of the ISO to the USB drive using dd
.
On a Mac however I erased the USB drive using Disk Utility:
- Choose a name for the volume. This name will be important later. This name will be referred to as
<USB>
. - Format the volume with a FAT filesystem
- Use the GUID partition table (apparently some macs are especially picky about this setting).
Edit the create-ush.sh
script with your <USB>
name and the location of the CentOS ISO file. Then run the script. The script will perform the following actions in a docker container:
- Mount the ISO
- Copy its contents to the installation media
- Create a EFI boot image that does not result in a black screen but actually gets you into grub.
- Fix the
grub.cfg
file to use your<USB>
name. By default it expects a certain name for the volume, depending on the ISO you used.
Copy the contents of repair-grub.sh
and mount-lvm.sh
onto the installation media. We will use them in step 3. Alternatively you type the commands in the script manually in step 3.
Remember to adjust the values in mount-lvm.sh
to your environment.
Installing CentOS is relatively straight forward. However we have to do some custom partitioning. Here are the relevant steps, slightly adjusted:
- Select your disk
- At the bottom, click the "Full disk summary and boot loader" text
- Click on the disk in the list
- Click "Do not install boot loader"
- Close
- Select "Custom" (I didn't try automatic, but it probably would not create the EFI partition)
- Done in the top left to get to the partitioning screen
- Delete existing partitions if needed
- Click +
- Create /foo mountpoint, 600M, Standard partition, then edit the partition to be on /boot/efi and change the file system to 'EFI System Partition'.
- Click + repeatedly to create the rest of the partitions as usual (
/boot
,/swap
,/home
, etc.). - Done
In my case the package installation from install media was not possible. Instead I used a package repository URL as the installation source, more specifically http://mirror.centos.org/centos/8/BaseOS/x86_64/os/
.
When starting the installation there will be an error about a missing mactel-boot
package. Ignore the error and continue the installation.
When the installation finishes the system is not quite usable yet. We need to fix two things:
- Reinstall grub (to avoid the booting-to-black-screen problem)
- Create a
grub.cfg
.
To do this, boot from the installation media again and enter the rescue mode.
- Choose 1 to mount the system on
/mnt/sysimage
. If you chose to use a LVM root partition there may be an error that no linux filesystem could be found. Runbash /mnt/install/repo/mount-lvm.sh
to fix this issue. This is themount-lvm.sh
script copied in step 1.5. Alternatively you can type the commands from the script manually. - Run
bash /mnt/install/repo/repair-grub.sh
. This is therepair-grub.sh
script from step 1.5. Alternatively you can type the commands from the script manually. - Exit the rescue mode and reboot the machine. It should reboot once after SELinux relabelling and then boot into CentOS.
Hey @jameshskoh, glad my notes helped you so far. Unfortunately I'm not an expert on this as well and I don't currently have a Mac that I can test this with. But here are my thoughts:
IIRC the rescue system uses the filesystem on the install disk (the 120GB SSD in your case) as a read-only base image and overlays a
tmpfs
read-write layer on top. I think/dev/mapper/live-rw
is the resulting overlay filesystem. Essentially this means that the usable disk space of the rescue system is limited by the amount of memory rather than disk space (which I guess is at least 8GB in your case). I don't think the rescue system uses swap.I am no expert with
yum
/dnf
but I have found other sources reporting similar errors although enough disk space should be available. I guess this could be the case if the 60MB is only the required space for one package but there are multiple packages being installed. Or maybeyum
tries to keep at least some percentage of disk space available. Anyway I think that the amount of available disk space (read: memory) might actually be the source of the problem.Although I'm wondering why this happened (as I did my original tests on a machine with 8GB of memory as well) I have found some ideas how to circumvent this problem:
yum clean all
might clean up leftover package data giving enough available space for thegrub2-efi-x64-modules
package.tmpfs
filesystem with more storage using the commandmount -o remount,size=<new_size> /path/to/tmpfs
. You could maybe find the path of the mount point by runningdf -h
ormount
./etc/fstab
of the rescue system to increase the size of thetmpfs
overlay. But you would have to do that on the persistent part on the install disk before booting the rescue system.diskspacecheck=0
to/etc/yum.conf
(or rather/etc/dnf/dnf.conf
). This is probably a bad idea on any system that is actually being used but since we are using a temporary recovery system at this point I don't think there's any harm in trying. Only thegrub2-install ...
commands and thechroot ... grub2-mkconfig ...
actually change any persistent data. All the other steps in the rescue system should be gone after a reboot.I hope this helps.