I am working around installing Rocky 9.5 on a “late 2014” Mac Mini. It is Intel i7 (3.0GHz), 16GB RAM with 2 internal drives (2TB SATA SSD and 1TB NVMe SSD).
I want to use the NVMe SSD (/dev/nvme0n1) as the boot device and the SATA 2TB (/dev/sda) as a data disk.
Right now, the Mac Mini only tries to boot from /dev/sda and can’t be made to try to boot from /dev/nvme0n1. Since /dev/sda is not configured as a boot disk, the boot up fails.
Even with the SATA cable disconnected from the logic board, the boot up on from the NVMe SSD still fails.
I don’t know if changing grub will help or hurt, and I could use some grub-guidance specific to the way Rocky makes changes to grub.
Details:
The work-around I found has installed Rocky 9.5 on the NVMe SSD, but it appears that the Installer “hard coded” all the boot-up details to /dev/sda in the process.
I think this is because the work-around to installing Rocky on the NVMe SSD used a USB attached NVMe external case, and that presented the NVMe SSD as /dev/sda on my Win10 host.
When the USB external case (with NMVe SSD still installed) is connected to the Mac Mini’s USB port, the system boots up perfectly.
But, the USB disk is /dev/sda and the SATA SSD is /dev/sdb
When the NVMe SSD is taken out of the external case and put into the Mac Mini’s internal NVMe slot, the system will not boot and stops at the dracut prompt.
The errors look like it stopped here because there are missing devices (rl_vbox-root, rl_vbox-swasp and rl_vbox-home).
If I reboot and select the Rocky Linux (0-rescue) from the grub loader, it boots all the way up with no errors.
And this is when lsblk shows sda is the 2TB SSD data disk and shows nvme0n1 is the 1TB boot disk.
In the past, I think I remember modifying the grub.cfg for the GRUB_DEFAULT= parameter to change the boot device from 0 to something else (in this case 1?). But I’ve never had to deal with cases where the new boot device has a different device label (nvme0n1 instead of sda).
RH uses the Boot Loader System (bls) environment to determine the boot kernel. The boot sequence first looks in /boot/efi/EFI/rocky/grub.cfg which is a stub file pointing to /boot where it then looks for the kernel definitions in /boot/loader/entries. Grub in this scenario is only providing a menu of choices for boot kernels it has no other influence on the boot process.
Device names such as sda or nvme are unknown to the boot process as devices are identified by their respective UUID’s unless this is deliberately overridden.
It would be good to compare the output of these commands to see where the boot process is looking while booted into the rescue kernel.
On (x86_64) “PC” (don’t know about Mac) the boot process starts from firmware on the motherboard. That firmware uses either “UEFI” or “legacy BIOS” procedure.
On legacy boot the firmware loads first stage of bootloader from first sector of a drive. That stage loads rest of bootloader from a filesystem (also referred to as “partition”) – usually /boot. Type of partition and filesystem are restricted by what the first stage of bootloader supports. One step of installation was to write the stages of bootloader (MS bootloader, LILO, or GRUB) to the first sector and to the filesystem. (This is probably what the “default = device 0” memories refer to.)
On UEFI boot the firmware has one (or many) “boot entry”. The entry points to bootloader file within filesystem on EFI System Partition (ESP). The firmware can search type ESP partition from partition table and supports FAT32 filesystem type. The firmware loads bootloader. If there are no custom entries, then UEFI seeks default filename (\EFI\BOOT\BOOTX64.EFI) from ESP. The efibootmgr -v lists the entries that firmware has. There is usually some key that shows the firmware entries to choose from, if pressed early on boot – before entry is automatically chosen.
If the Mac does load the GRUB bootloader – even if from “wrong drive”, then question is which “GRUB entry” (not same as “UEFI boot entry”) is loaded by default, and whether one can have an entry to choose (probably “chainload”) the OS X bootloader.
tlrd; It must the Mac firmware, where one sets where it seeks bootloader from.
Many years ago I installed Debian on an Mac mini using Boot Camp, but you may need to have macOS installed for that.
Also used rEFIt, seems to have been abandoned but rEFInd is a fork, The rEFInd Boot Manager. Can’t remember if you could set/change boot device with it, but there was a boot menu where you could select what to boot.
The only boot option is when you press and hold the key (on a Mac keyboard) and then power up.
The process will stop and show disk-icons for EFI bootable disks that were found.
You can then use the mouse to point at the one you want to boot from.
Boot Camp needs MacOS, and it needs to be a version that still has the Boot Camp setup app.
I didn’t check to see if Boot Camp is still an option in Monterey (that’s the last version of MacOS that runs on a “late 2014” Mac Mini).
It was mainly for running a dual-boot MacOS / Windows system (it included Windows drivers for the Mac hardware). I think Win7 was the last version that was supported.
Regardless, I don’t want a dual boot system. I was hoping to build a 100% Rocky system
Would the Rocky-9-5-boot.iso burned to a USB stick be the same as a LiveCD?
And, would booting into the 0-Rescue be the same (because it boots into the 0-rescue okay)
IIRC, there are partition UUIDs, not filesystem UUIDs. Command blkid does show those, if the lsblk does not have option to show them.
What the | grep rocky did hide from the output of efibootmgr are:
what is the default entry (first in boot order)
what other entries there are
Interesting that there is only one icon, even though efibootmgr did reveal at least two (unless one of them was for the USB stick)
Shows that the GRUB menu ought to have two entries for Rocky:
Regular entry with kernel version 5.14.0-503.33.1.el9_5
“Rescue” kernel, which is copy of a regular kernel, but has much more drivers in the “initramfs image” file (so it can do something more even when use of the normal install has issues)
Not quite.
All the “install” images start and run one application – the installer – not a more usable “OS”. They differ in how much RPM packages are in the image (and how many has to be downloaded from online repos by the installer)
The “live” images have the OS installed into the image, so one can boot to “run Rocky”.
One of the installed applications (icon on the desktop of the live session) is the installer of Rocky.
Both can start installer and both can do some forensics/rescue, but the LiveCD can also be used as (light) “workstation” without installing anything (to local drive).
Would the 0-rescue be good enough to show CPU compatibility?
I didn’t use the USB stick to install this.
I had a VBox guest on my Win10 PC and used the rocky-9-5-boot.iso file to boot the guest into the Installer.
The NVMe SSD was in an external USB NVMe case and I used a VBox USB Filter to map that device to the guest.
When the Installer got to the Localization screen, I picked the USB attached NVMe SSD as the target.
I think that’s when /dev/sda became “hard coded” as the “path” for all the directories and mount points for the boot process. When the NVMe is in the external case, it seems it shows up as a generic HD so it’s seen as /dev/sda.
When the NVMe SSD is installed internally to the Mac Mini, it changes to /dev/nvme0n1.
The existing /boot/efi/EFI/rocky/grub.cfg looks like this:
[root@localhost ~]# more /boot/efi/EFI/rocky/grub.cfg
search --no-floppy --fs-uuid --set=dev 77c510bd-4d6e-4bea-ade9-656beee38c67
set prefix=($dev)/grub2
export $prefix
configfile $prefix/grub.cfg
[root@localhost ~]#
It looks like grub.cfg is currently pointing to the 2nd partition on nvme0n1. That’s expected (right?) and shouldn’t be changed after the efibootmgr command.
I’ll read through the man page for efibootmgr before I pull the trigger.
I concur.
When you run the command to create the new boot entry it will be made the default and rocky’s boot menu should be presented on reboot. You should select the current kernel from the menu so that it gets marked as a successful boot otherwise the rescue kernel will become the default.
[root@localhost ~]# efibootmgr -d /dev/nvme0n1 -p 1 -c -L RL9 -l '\EFI\rocky\shimx64.efi'
BootCurrent: 0001
Timeout: 5 seconds
BootOrder: 0002,0001,0000,0080
Boot0000* rocky
Boot0001* rocky
Boot0080* Mac OS X
Boot0081* Mac OS X
Boot0082*
BootFFFF*
Boot0002* RL9
[root@localhost ~]#
It looks like it added a new line (Boot0002* RL9) and (maybe) changed the BootOrder to use 0002 first then 0001, 0000 and then fallback to MacOS 0080.
(after reboot)
[root@localhost ~]# efibootmgr
BootCurrent: 0002
Timeout: 5 seconds
BootOrder: 0002,0001,0000,0080
Boot0000* rocky
Boot0001* rocky
Boot0002* RL9
Boot0080* Mac OS X
Boot0081* Mac OS X
Boot0082*
BootFFFF*
[root@localhost ~]#
I guess I should delete the 2 MacOS options.
But nothing changed in terms of helping.
Stops at the same point, but will still boot using 0-rescue.
The real error message was probably before all those warnings. The rest is just consequences of the first error.
The “cannot find /dev/mapper/rl_box-root” reveals that kernel cannot find and thus not use that filesystem.
The /dev/nvme0n1p3 partition has Logical Volume Manager’s (LVM2) physical volume (PV).
This PV is used by LVM volume group (VG) named “rl_vbox”.
The “rl_vbox” has three logical volumes (LV): “root”, “swap”, and “home”.
Your firmware loads bootloader and bootloader loads kernel. The kernel should, with instructions on command-line ( ro crashkernel=1G-4G:192M,4G-64G:256M,64G-:512M resume=/dev/mapper/rl_vbox-swap rd.lvm.lv=rl_vbox/root rd.lvm.lv=rl_vbox/swap) and in initramfs, and with drivers in initramfs enable the LVM2 – logical volumes – and mount filesystem in “root” (where rest of OS files are).
That (start of LVM2) fails and blocks boot. (Or some earlier error blocks start of LVM2.)
Both regular and rescue kernels have identical “args”, so difference must be in the initramfs.
It should be possible, in the system that runs rescue kernel, to recreate initramfs for the regular kernel. With program dracut
The messages on the screen pause for about 2 minutes, then starts scrolling the endless warning messages for about 1 more minute, then stops at the "Starting Dracut Emergency Shell… " prompt.
This is the first 3 or 4 warnings after the first 2-minute pause. There doesn’t appear to be anything printed on-screen in the first two or three lines that seem significantly different.
But after modifying the efibootmgr boot order with the new entry, it still can’t find the correct drive.
I suspected all along that the Mac Mini firmware was somehow finding the correct efi boot device (nvme0n1), but when it was “handing off” to the disk for the rest of the boot, it lost its way (picked the wrong disk - sda).
How would that be “fixed” so it looks for the correct drive in the kernel?
Any suggestions for how to use dracut to get the kernel sorted?
At this point, I have nothing to lose.
If anyone wants to suggest a “fix” for this, I’m willing to try it - even if it corrupts things so badly I need to start over. There is nothing here that would stop me from rerunning the Rocky Installer and reformatting the two SSD.
Here I agree with jlehtone that the issue may be the initrd image. Read “man dracut” there you will find a few examples on what to do to update the initrd for a partitcular kernel or all. Once you’ve done that then draft up what you think the commandline should be to update your kernel initrd and post it here before you proceed. Then we can advise as to any corrections or confirm.
