Menu ▾ ▴

Can't seem to get rEFInd to launch on my Mac Mini 5,1

General Discussion
Paul
2023-03-02
2023-03-07

  • Paul

    Paul - 2023-03-02

    Hi,

    For some reason I can't seem to get rEFInd to load on my Mac Mini 5,1.

    It has two hard drives, one running MacOS High Sierra the other Ubuntu, but despite what I do I only ever see the mac boot menu.

    rEFInd says its inatalled fine, I disabled SIP, and never get any errors, just nothing shows. So I wonder if its loading onto the wrong disk?

    What info do you need to help me get this working? rEFInd isn't showing in the Startup disk section of System preferences.

    Many thanks
    Paul

     

    Last edit: Paul 2023-03-02

  • Roderick W. Smith

    Roderick W. Smith - 2023-03-02

    Can you boot into Ubuntu in some other way (via GRUB, for instance)? If so, then the output of sudo efibootmgr -v might be helpful.

    You might also try booting rEFInd via a USB drive; there's a USB image linked on the rEFInd downloads page that you can write to a USB flash drive; you should then be able to boot it by holding down the Option/Alt key as you power up the Mac. That's not a good long-term workaround, but it should at least get you into Ubuntu if you can't currently boot in any other way. Also, the rEFInd USB image has an installation option that might get it working from your hard disk.

     

  • Paul

    Paul - 2023-03-02

    I can boot into both Mac and Ubuntu through the Apple boot manager, just want the extra flexibility from rEFInd.

    The output from sudo efibootmgr -v is

    paul@paul:~$ sudo efibootmgr -v
BootCurrent: 0000
Timeout: 5 seconds
BootOrder: 0000,0080,0001
Boot0000* ubuntu HD(1,GPT,6ebdddd5-56c6-4ad6-b3d1-c0e5fecc37c9,0x28,0x64000)/File(\EFI\ubuntu\shimx64.efi)
Boot0001* OpenCore PciRoot(0x0)/Pci(0x1f,0x2)/Sata(0,0,0)/HD(1,GPT,7993bf1a-4f1c-4ab4-90cc-644acfc46e4f,0x28,0x64000)/File(EFI\OC\OpenCore.efi)
Boot0080* Mac OS X HD(1,GPT,6ebdddd5-56c6-4ad6-b3d1-c0e5fecc37c9,0x28,0x64000)/File(\EFI\refind\refind_x64.efi)
Boot0081* Mac OS X PciRoot(0x0)/Pci(0x1f,0x2)/Sata(0,0,0)/HD(2,GPT,5352de37-7ac9-44d9-be9d-44b95b73d85b,0x64028,0x7456ce40)
BootFFFF* PciRoot(0x0)/Pci(0x1f,0x2)/Sata(0,0,0)/HD(2,GPT,000054e0-2e94-0000-e07f-0000354a0000,0x64028,0x3a1ec0c0)/File(\System\Library\CoreServices\boot.efi)
     

  • Paul

    Paul - 2023-03-02

    Thats wierd, I am not using Opencore at the moment, I had it installed previously but thought I had completely removed it before re-installing macOS and Ubuntu!

     

    • dakanji

      dakanji - 2023-03-02

      You must have used the OCLP to install OpenCore as it sets things up for a permanent OpenCore Boot Coup every time you boot. You are not seeing this because you do not have an OpenCore instance present but it will kick in the moment you add OpenCore.

      Most OCLP users actually want this but it can be a nuisance if you don't. You will want to remove that entry from Linux or do a deep NVRAM reset (Hold the keys down until you hear about 4 chimes) to get rid of it.

       

  • Paul

    Paul - 2023-03-02

    Ok so after you told me that I looked into efibootmgr and discovered re-ordering.

    So, I entered sudo bootmanager -o 0080,0081,0000
    But it made no difference!

    I tried the option from Refind (from a USB) to install refind to disk, but it still boots into the Mac boot selection menu

     

    Last edit: Paul 2023-03-02

  • Paul

    Paul - 2023-03-02

    Also, weirdly I dont need to hold option when booting, it automatically goes into the Mac boot manager.

     

  • Paul

    Paul - 2023-03-02

    OK think I have solved it. I had sudo nvram manufacturing-enter-picker=true set which forced the Mac boot menu. With that set for False, I now see the rEFInd boot menu, now to customise it!

    Have an issue that when I now boot into MacOS it sees the Linux drive and says its unreadable, Initialise, Ignore which I would like to get rid of, but I guess thats a question for somewhere else!

     

  • Roderick W. Smith

    Roderick W. Smith - 2023-03-02

    I'm glad you got the boot order issue sorted out!

    As to macOS seeing the Ubuntu partition(s) as unreadable macOS partitions, that's most likely an issue with the partition type codes. You can change those with gdisk in Ubuntu (or in macOS, if you install it in macOS). For instance:

    $ sudo gdisk /dev/sda
GPT fdisk (gdisk) version 1.0.8

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.

Command (? for help): p
Disk /dev/sda: 488397168 sectors, 232.9 GiB
Model: Samsung SSD 840 
Sector size (logical/physical): 512/512 bytes
Disk identifier (GUID): 1794758F-535A-460D-B30E-3CCFC5767370
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 488397134
Partitions will be aligned on 1024-sector boundaries
Total free space is 3695 sectors (1.8 MiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            3072         1121279   546.0 MiB   EF00  EFI System
   2         1121280         2147327   501.0 MiB   8300  Ubuntu boot
   3         2147328         3172718   500.7 MiB   8300  LXD boot
   4         3173376         4606975   700.0 MiB   8300  Test boot
   5         4606976         6040575   700.0 MiB   AF00  Apple HFS/HFS+
   6         6040576       110898175   50.0 GiB    8E00  Linux LVM
   7       110898176       278670335   80.0 GiB    8E00  Linux LVM
   8       278670336       488397134   100.0 GiB   8E00  Linux LVM

Command (? for help): t
Partition number (1-8): 5
Current type is AF00 (Apple HFS/HFS+)
Hex code or GUID (L to show codes, Enter = AF00): 8300
Changed type of partition to 'Linux filesystem'

Command (? for help): p
Disk /dev/sda: 488397168 sectors, 232.9 GiB
Model: Samsung SSD 840 
Sector size (logical/physical): 512/512 bytes
Disk identifier (GUID): 1794758F-535A-460D-B30E-3CCFC5767370
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 488397134
Partitions will be aligned on 1024-sector boundaries
Total free space is 3695 sectors (1.8 MiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            3072         1121279   546.0 MiB   EF00  EFI System
   2         1121280         2147327   501.0 MiB   8300  Ubuntu boot
   3         2147328         3172718   500.7 MiB   8300  LXD boot
   4         3173376         4606975   700.0 MiB   8300  Test boot
   5         4606976         6040575   700.0 MiB   8300  Linux filesystem
   6         6040576       110898175   50.0 GiB    8E00  Linux LVM
   7       110898176       278670335   80.0 GiB    8E00  Linux LVM
   8       278670336       488397134   100.0 GiB   8E00  Linux LVM

Command (? for help): w

Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING
PARTITIONS!!

Do you want to proceed? (Y/N): y
OK; writing new GUID partition table (GPT) to /dev/sda.
Warning: The kernel is still using the old partition table.
The new table will be used at the next reboot or after you
run partprobe(8) or kpartx(8)
The operation has completed successfully.

    In this example, I changed partition #5 from AF00 (Apple HFS/HFS+) to 8300 (Linux filesystem). You'd do something similar; however, you should be sure to change only the Linux partition(s)' type code(s). If you change the macOS partition(s)' type code(s), or those of partitions like the ESP, then you may lose the ability to boot macOS. You can use df to find what partition(s) you're using in Ubuntu. (This example was taken on a non-Apple computer; I just adjusted it beforehand to show one "fake" type-AF00 partition to be changed. You might see some other type code, too, like 0700 or AF0A. If you don't understand what you're seeing, don't change things randomly; figure it out first!)

     

  • Paul

    Paul - 2023-03-03

    So, Roderick, if I do gdisk I get this:

    GPT fdisk (gdisk) version 1.0.8

    Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.

Command (? for help): p
Disk /dev/sda: 1953525168 sectors, 931.5 GiB
Model: ST1000LM014-1EJ1
Sector size (logical/physical): 512/4096 bytes
Disk identifier (GUID): 2C125D29-8937-431B-900C-5A8BE9989C1E
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 1953525134
Partitions will be aligned on 8-sector boundaries
Total free space is 13 sectors (6.5 KiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1              40          409639   200.0 MiB   EF00  EFI System Partition
   2          409640      1953525127   931.3 GiB   AF0A  Untitled

Command (? for help):

    Its not showing the mac partition ,so I guess i'm safe to alter the type of partition 2? Should I set it to type 8300?

    Thanks
    Paul

     

  • Paul

    Paul - 2023-03-03

    Ah, think I got that wrong, first I need to work out the disk to change, I think/dev/sda is my Mac disk.

     

    Last edit: Paul 2023-03-03

  • Roderick W. Smith

    Roderick W. Smith - 2023-03-04

    Yeah, there's no way you've got both macOS and Ubuntu installed on that one disk. You can probably figure out where Ubuntu is with df, as in:

    $ df /
Filesystem     1K-blocks     Used Available Use% Mounted on
/dev/sda2       36937728 10000696  26771048  28% /

    This example shows that Linux is on /dev/sda2.

    There are exceptions to this rule, though. If you used LVM for your setup, then you won't see a raw disk device filename; instead, you'd see something like /dev/mapper/ubuntu-root, which isn't very informative by itself.

    Another approach is to use blkid. If used with no options, it'll show filesystem and other information for all your partitions, as in:

    $ sudo blkid
[sudo] password for rodsmith: 
/dev/sda2: UUID="90bfea45-eaa2-41a5-b0e7-348fbf0ad979" UUID_SUB="68474609-7f00-4dfc-8255-4ac582823cc9" BLOCK_SIZE="4096" TYPE="btrfs" PARTLABEL="Ubuntu 22.04.2" PARTUUID="bd771d1f-730e-419e-a58f-07de3486a5e9"
/dev/sda1: UUID="BF0F-18A4" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="EFI System Partition" PARTUUID="939beaa7-76a5-4aac-a89f-536cae263fba"
/dev/loop1: TYPE="squashfs"
/dev/loop8: TYPE="squashfs"
/dev/loop6: TYPE="squashfs"
/dev/loop4: TYPE="squashfs"
/dev/loop2: TYPE="squashfs"
/dev/loop0: TYPE="squashfs"
/dev/loop7: TYPE="squashfs"
/dev/loop5: TYPE="squashfs"
/dev/loop3: TYPE="squashfs"

    You can ignore all those squashfs devices; instead, focus on the /dev/sd* entries (and /dev/nvme*, if you have NVMe devices). Each line (which is long enough to wrap) lists the filesystem (TYPE=) and other identifying information, some of which includes clues about what the partition/filesystem is. Note that you need to run blkid as root or using sudo, just like gdisk.

     

  • Paul

    Paul - 2023-03-06

    So I'm sorry but I'm still confused. rEFInd is working fine, but I still get the disk error in MacOS.

    I installed gdisk on MacOS, and am 95% sure i have found the correct partition, but its identifying as 8300, a linux partition. Isn't that what its supposed to be? Also below, results from df and diskutil list. Also, at the end df and blkid from Ubuntu.

    I'm sure that Linux is /dev/sdb1 (linux) or /dev/disk0 (mac)

    Any suggestions?

    bash-3.2# gdisk /dev/disk0s1
GPT fdisk (gdisk) version 1.0.9

Partition table scan:
  MBR: not present
  BSD: not present
  APM: not present
  GPT: not present

Creating new GPT entries in memory.

Command (? for help): p
Disk /dev/disk0s1: 1953521664 sectors, 931.5 GiB
Sector size (logical): 512 bytes
Disk identifier (GUID): 462C6B45-B85F-44A3-A90F-21C009A1A52B
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 1953521630
Partitions will be aligned on 2048-sector boundaries
Total free space is 1953521597 sectors (931.5 GiB)

Number  Start (sector)    End (sector)  Size       Code  Name

Command (? for help): t
No partitions

Command (? for help): q
bash-3.2# gdisk /dev/disk0
GPT fdisk (gdisk) version 1.0.9

Partition table scan:
  MBR: hybrid
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with hybrid MBR; using GPT.

Command (? for help): t
Using 1
Current type is 8300 (Linux filesystem)
Hex code or GUID (L to show codes, Enter = 8300):


bash-3.2# diskutil list
/dev/disk0 (internal, physical):

 #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *1.0 TB     disk0
   1:           Linux Filesystem                         1.0 TB     disk0s1

/dev/disk1 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *1.0 TB     disk1
   1:                        EFI EFI                     209.7 MB   disk1s1
   2:                 Apple_APFS Container disk2         1000.0 GB  disk1s2

/dev/disk2 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +1000.0 GB  disk2
                                 Physical Store disk1s2
   1:                APFS Volume Macintosh               26.2 GB    disk2s1
   2:                APFS Volume Preboot                 21.6 MB    disk2s2
   3:                APFS Volume Recovery                516.2 MB   disk2s3
   4:                APFS Volume VM                      20.5 KB    disk2s4

bash-3.2#



bash-3.2# df
Filesystem    512-blocks     Used  Available Capacity iused               ifree %iused  Mounted on
/dev/disk2s1  1953115488 51239528 1900419704     3%  549834 9223372036854225973    0%   /
devfs                372      372          0   100%     645                   0  100%   /dev
/dev/disk2s4  1953115488       40 1900419704     1%       2 9223372036854775805    0%   /private/var/vm
map -hosts             0        0          0   100%       0                   0  100%   /net
map auto_home          0        0          0   100%       0                   0  100%   /home
bash-3.2# gdisk /dev/disk2
GPT fdisk (gdisk) version 1.0.9


root@paul:/home/paul# df
Filesystem     1K-blocks     Used Available Use% Mounted on
tmpfs             805052     1896    803156   1% /run
/dev/sdb1      960302096 11142304 900305368   2% /
tmpfs            4025240        0   4025240   0% /dev/shm
tmpfs               5120        4      5116   1% /run/lock
/dev/sda1         201633    24752    176881  13% /boot/efi
tmpfs             805048     4716    800332   1% /run/user/1000
root@paul:/home/paul# blkid
/dev/sdb1: UUID="544e50e0-aea9-4e4b-afa6-9aec59207f80" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="d01bea74-dc8d-47b8-912c-b430b40786d9"
/dev/loop1: TYPE="squashfs"
/dev/loop8: TYPE="squashfs"
/dev/loop6: TYPE="squashfs"
/dev/loop4: TYPE="squashfs"
/dev/loop2: TYPE="squashfs"
/dev/loop0: TYPE="squashfs"
/dev/loop7: TYPE="squashfs"
/dev/sda2: UUID="d90b7739-d45f-45d9-8701-54ae495ab68e" BLOCK_SIZE="4096" TYPE="apfs" PARTLABEL="Untitled" PARTUUID="f00c5010-e0e1-4b4b-b132-940404480eff"
/dev/sda1: LABEL_FATBOOT="EFI" LABEL="EFI" UUID="70D6-1701" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="EFI System Partition" PARTUUID="6ebdddd5-56c6-4ad6-b3d1-c0e5fecc37c9"
/dev/loop5: TYPE="squashfs"
/dev/loop3: TYPE="squashfs"
     

    Last edit: Paul 2023-03-06

  • Roderick W. Smith

    Roderick W. Smith - 2023-03-06

    You launch gdisk against the whole disk (e.g., /dev/sda in Ubuntu or /dev/disk0 is macOS), NOT against an individual partition (e.g., /dev/sda1 in Ubuntu or /dev/disk0s1 in macOS). You did the latter, so gdisk gave no useful output.

    If Ubuntu is installed on your /dev/disk0 (in macOS), then the diskutil output makes it look like it's correctly marked, but I'm less familiar with what diskutil works, so I can't be sure of that; I'd still like to see confirmation from gdisk.

    Another possibility is that you've installed a driver in macOS to make it read one or more Linux filesystems, but it's not working as you'd hoped. Even if you later uninstalled the driver, it might have left some remnants behind -- namely, leaving macOS trying to read the contents of the Linux partition and failing.

    One workaround that occurs to me is that you can change the type code of the Ubuntu partition from 8300 to 8304, or even to something completely unrelated (say, A000). Neither the Linux kernel nor most other tools in Ubuntu care about the partition type code, so you can change it with some impunity; but if I'm right that macOS is seeing the Linux filesystem type code (shown as 8300 in gdisk) and interpreting that as license to try to read the partition, then something else might work around that problem. The gdisk code of 8304 is an obscure code for the root (/) Linux filesystem on an x86-64 computer, so it might not be in whatever list macOS is using, but it would still be valid; and A000 is the code for an Android bootloader, which is completely wrong but even less likely to be on the list of approved partition type codes in macOS. Be sure, though, to operate on the whole disk, not an individual partition, as you did before! Trying to write GPT data to an individual partition will damage the contents of that partition!

    Another possibility is that macOS is no longer filtering partitions based on their type codes, and it's seeing some leftover data from HFS+, APFS, or some other filesystem that macOS understands on the Ubuntu partition. If this is what's happening, it would be more difficult to overcome, since you'd need a way to remove whatever leftover HFS+/etc. filesystem data is on the partition without damaging the ext4fs (or whatever filesystem you're using) data it really contains. I don't know of a tool that would do this, offhand. Backing it all up on the file level, wiping it clean (writing "0" values to the whole partition), and restoring it would do the trick, but that's a tedious and error-prone process. I wouldn't want to try this without being reasonably certain that the cause is actually macOS parsing the partition's data incorrectly.

    Beyond that, you might want to ask about the problem of a Linux partition showing up as damaged in macOS on a Mac forum. Although I occasionally run macOS, I'm not an expert on that OS, and this problem isn't really a rEFInd issue, although it is of course related to a multi-boot configuration.

     

    • Paul

      Paul - 2023-03-07

      Roderick,

      No matter what I tried, MacOS complained, so I gave in and hit the
      Initialise button, assuming it would kill my Ubuntu drive and force a
      re-install, but it stopped the error and everything seems to still work!

      I really appreciate your efforts and explanations, rEFInd is a great
      solution.

      cheers
      Paul

      On Mon, 6 Mar 2023 at 13:59, Roderick W. Smith srs5694@users.sourceforge.net wrote:

      You launch gdisk against the whole disk (e.g., /dev/sda in Ubuntu or
      /dev/disk0 is macOS), NOT against an individual partition (e.g.,
      /dev/sda1 in Ubuntu or /dev/disk0s1 in macOS). You did the latter, so
      gdisk gave no useful output.

      If Ubuntu is installed on your /dev/disk0 (in macOS), then the diskutil
      output makes it look like it's correctly marked, but I'm less familiar with
      what diskutil works, so I can't be sure of that; I'd still like to see
      confirmation from gdisk.

      Another possibility is that you've installed a driver in macOS to make it
      read one or more Linux filesystems, but it's not working as you'd hoped.
      Even if you later uninstalled the driver, it might have left some remnants
      behind -- namely, leaving macOS trying to read the contents of the Linux
      partition and failing.

      One workaround that occurs to me is that you can change the type code of
      the Ubuntu partition from 8300 to 8304, or even to something completely
      unrelated (say, A000). Neither the Linux kernel nor most other tools in
      Ubuntu care about the partition type code, so you can change it with some
      impunity; but if I'm right that macOS is seeing the Linux filesystem type
      code (shown as 8300 in gdisk) and interpreting that as license to try to
      read the partition, then something else might work around that problem. The
      gdisk code of 8304 is an obscure code for the root (/) Linux filesystem
      on an x86-64 computer, so it might not be in whatever list macOS is using,
      but it would still be valid; and A000 is the code for an Android
      bootloader, which is completely wrong but even less likely to be on the
      list of approved partition type codes in macOS. Be sure, though, to operate
      on the whole disk, not an individual partition, as you did before!
      Trying to write GPT data to an individual partition will damage the
      contents of that partition!

      Another possibility is that macOS is no longer filtering partitions based
      on their type codes, and it's seeing some leftover data from HFS+, APFS, or
      some other filesystem that macOS understands on the Ubuntu partition. If
      this is what's happening, it would be more difficult to overcome, since
      you'd need a way to remove whatever leftover HFS+/etc. filesystem data is
      on the partition without damaging the ext4fs (or whatever filesystem you're
      using) data it really contains. I don't know of a tool that would do this,
      offhand. Backing it all up on the file level, wiping it clean (writing "0"
      values to the whole partition), and restoring it would do the trick, but
      that's a tedious and error-prone process. I wouldn't want to try this
      without being reasonably certain that the cause is actually macOS parsing
      the partition's data incorrectly.

      Beyond that, you might want to ask about the problem of a Linux partition
      showing up as damaged in macOS on a Mac forum. Although I occasionally run
      macOS, I'm not an expert on that OS, and this problem isn't really a rEFInd
      issue, although it is of course related to a multi-boot configuration.

      Can't seem to get rEFInd to launch on my Mac Mini 5,1
      https://sourceforge.net/p/refind/discussion/general/thread/fb5fce9072/?limit=25#453a

      Sent from sourceforge.net because you indicated interest in
      https://sourceforge.net/p/refind/discussion/general/

      To unsubscribe from further messages, please visit
      https://sourceforge.net/auth/subscriptions/

      --
      Paul Butterworth
      +44 7768 252250

       
      alternate

      • Paul

        Paul - 2023-03-07

        I spoke too soon! its complaining again. I'll hunt out a Mac forum to try
        to identify!

        On Tue, 7 Mar 2023 at 11:33, Paul pbutterworth@users.sourceforge.net
        wrote:

        Roderick,

        No matter what I tried, MacOS complained, so I gave in and hit the
        Initialise button, assuming it would kill my Ubuntu drive and force a
        re-install, but it stopped the error and everything seems to still work!

        I really appreciate your efforts and explanations, rEFInd is a great
        solution.

        cheers
        Paul

        On Mon, 6 Mar 2023 at 13:59, Roderick W. Smith
        srs5694@users.sourceforge.net %0Dsrs5694@users.sourceforge.net wrote:

        You launch gdisk against the whole disk (e.g., /dev/sda in Ubuntu or
        /dev/disk0 is macOS), NOT against an individual partition (e.g.,
        /dev/sda1 in Ubuntu or /dev/disk0s1 in macOS). You did the latter, so
        gdisk gave no useful output.

        If Ubuntu is installed on your /dev/disk0 (in macOS), then the diskutil
        output makes it look like it's correctly marked, but I'm less familiar with
        what diskutil works, so I can't be sure of that; I'd still like to see
        confirmation from gdisk.

        Another possibility is that you've installed a driver in macOS to make it
        read one or more Linux filesystems, but it's not working as you'd hoped.
        Even if you later uninstalled the driver, it might have left some remnants
        behind -- namely, leaving macOS trying to read the contents of the Linux
        partition and failing.

        One workaround that occurs to me is that you can change the type code of
        the Ubuntu partition from 8300 to 8304, or even to something completely
        unrelated (say, A000). Neither the Linux kernel nor most other tools in
        Ubuntu care about the partition type code, so you can change it with some
        impunity; but if I'm right that macOS is seeing the Linux filesystem type
        code (shown as 8300 in gdisk) and interpreting that as license to try to
        read the partition, then something else might work around that problem. The
        gdisk code of 8304 is an obscure code for the root (/) Linux filesystem
        on an x86-64 computer, so it might not be in whatever list macOS is using,
        but it would still be valid; and A000 is the code for an Android
        bootloader, which is completely wrong but even less likely to be on the
        list of approved partition type codes in macOS. Be sure, though, to operate
        on the whole disk, not an individual partition, as you did before!
        Trying to write GPT data to an individual partition will damage the
        contents of that partition!

        Another possibility is that macOS is no longer filtering partitions based
        on their type codes, and it's seeing some leftover data from HFS+, APFS, or
        some other filesystem that macOS understands on the Ubuntu partition. If
        this is what's happening, it would be more difficult to overcome, since
        you'd need a way to remove whatever leftover HFS+/etc. filesystem data is
        on the partition without damaging the ext4fs (or whatever filesystem you're
        using) data it really contains. I don't know of a tool that would do this,
        offhand. Backing it all up on the file level, wiping it clean (writing "0"
        values to the whole partition), and restoring it would do the trick, but
        that's a tedious and error-prone process. I wouldn't want to try this
        without being reasonably certain that the cause is actually macOS parsing
        the partition's data incorrectly.

        Beyond that, you might want to ask about the problem of a Linux partition
        showing up as damaged in macOS on a Mac forum. Although I occasionally run
        macOS, I'm not an expert on that OS, and this problem isn't really a rEFInd
        issue, although it is of course related to a multi-boot configuration.

        Can't seem to get rEFInd to launch on my Mac Mini 5,1

        https://sourceforge.net/p/refind/discussion/general/thread/fb5fce9072/?limit=25#453a

        Sent from sourceforge.net because you indicated interest in
        https://sourceforge.net/p/refind/discussion/general/

        To unsubscribe from further messages, please visit
        https://sourceforge.net/auth/subscriptions/

        --
        Paul Butterworth
        +44 7768 252250

        Can't seem to get rEFInd to launch on my Mac Mini 5,1
        https://sourceforge.net/p/refind/discussion/general/thread/fb5fce9072/?limit=25#453a/cea5

        Sent from sourceforge.net because you indicated interest in
        https://sourceforge.net/p/refind/discussion/general/

        To unsubscribe from further messages, please visit
        https://sourceforge.net/auth/subscriptions/

        --
        Paul Butterworth
        +44 7768 252250

         
        alternate

Log in to post a comment.

Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.