I've an USB stick with multiple partitions (from various OSes installation/LiveCD isos). Windows partitions use ntfs, Linux ones use ext2, and rEFInd is set in a fat32 one to handle UEFI boot (syslinux is used for legacy BIOS boot).
Starting with version 0.10.2, on one UEFI system rEFInd fails to load the configuration file and fallbacks to a text menu with minimum boot entries. The error is:
Load Error while (re)opening our installation volume
Media changed while scanning the efi\boot\drivers_x64 directory
(The second line may not exactly match, it is not displayed long enough for me to see it properly)
On another UEFI system, I don't have this issue.
rEFInd show the following info on the system where it fails:
Previous versions (up to 0.10.1) are OK on both systems.
Not having drivers to load prevents the issue, except rEFInd then obviously cannot access the efi file on the partition to boot (unless it is fat32).
What manually works is:
Rename the drivers folder to something not scanned.
Reboot to rEFInd.
Enter the EFI shell.
Load the necessary driver.
Execute the EFI file on the targeted partition.
To me it seems that after loading the drivers, drives map is refreshed and on the system that have the issue rEFInd does not find itself anymore where expected. e.g. after manually calling map -r I observed (at least once) that fs0 was not pointing to the boot partition anymore (where was rEFind), but apparently to my ESP (on SSD) partition instead.
Any idea what could be the cause, and if it can be fixed (as was working since 0.10.1) ?
Thanks
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Version 0.10.2 introduced a workaround for a driver-loading problem on some HP EFIs, so it looks like that change has had an unintended consequence on at least some other computers. Out of curiosity, what is the brand of the computer on which this is no longer working? Also, what does the partition table look like? (Showing the output of gdisk -l /dev/sda or parted /dev/sda print would be helpful -- and if there's more than one disk, showing that output for all of them would be helpful.) It's conceivable that re-ordering the partitions would work around the problem; but obviously a better fix is highly desirable.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The motherboard (this is an assembled computer) where it does not work is a Gigabyte GA-AX370-Gaming 5 (which is pretty recent). My previous computer did not have UEFI support.
The system where it still works is an Asus N76 laptop (~5 years old).
Oh right, I forgot to mention that - in order to work with legacy BIOSes - the USB stick uses a MBR partition table and not GPT.
This also limits the possibilities I had, e.g. Windows installation/repair tools (at least Windows 7/8, latest Windows 10 seems a little bit more flexible) don't like not being on the first primary partition.
So, the content of the USB stick:
# gdisk -l /dev/sdd
GPT fdisk (gdisk) version 1.0.1
Partition table scan:
MBR: MBR only
BSD: not present
APM: not present
GPT: not present
***************************************************************
Found invalid GPT and valid MBR; converting MBR to GPT format
in memory.
***************************************************************
Disk /dev/sdd: 64651264 sectors, 30.8 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 86DBDA47-354B-4D7E-B4BF-19FF0677B3D0
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 64651230
Partitions will be aligned on 2048-sector boundaries
Total free space is 13658461 sectors (6.5 GiB)
Number Start (sector) End (sector) Size Code Name
1 2048 6555647 3.1 GiB 0700 Microsoft basic data
2 6555648 14952447 4.0 GiB 0700 Microsoft basic data
3 14952448 24168447 4.4 GiB 0700 Microsoft basic data
5 24170496 26116095 950.0 MiB 0700 Microsoft basic data
6 26118144 26218079 48.8 MiB 8300 Linux filesystem
7 26220544 27039743 400.0 MiB 8300 Linux filesystem
8 27041792 28475391 700.0 MiB 8300 Linux filesystem
9 28477440 32573439 2.0 GiB 8300 Linux filesystem
10 32575488 36671487 2.0 GiB 8300 Linux filesystem
11 36673536 40769535 2.0 GiB 8300 Linux filesystem
12 40771584 42819583 1000.0 MiB 8300 Linux filesystem
13 42821632 51013631 3.9 GiB 8300 Linux filesystem
sdd[1-3] are Windows 7/8/10, sdd5 is syslinux+rEFInd, the other partitions are various Linux installation/LiveCD partitions.
My main SSD disk (recently converted from MBR to GPT):
# gdisk -l /dev/sda
GPT fdisk (gdisk) version 1.0.1
Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: present
Found valid GPT with protective MBR; using GPT.
Disk /dev/sda: 351651888 sectors, 167.7 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): CC5CFE21-DC5F-4F49-9DF6-A0730C83CC46
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 351651854
Partitions will be aligned on 2048-sector boundaries
Total free space is 15056877 sectors (7.2 GiB)
Number Start (sector) End (sector) Size Code Name
1 2048 526335 256.0 MiB EF00 EFI System
2 526336 1050623 256.0 MiB 0C01 Microsoft reserved
3 1050624 105908223 50.0 GiB 0700 Microsoft basic data
4 105908224 147851263 20.0 GiB 8300 Linux filesystem
5 147851264 231737343 40.0 GiB 0700 Microsoft basic data
6 231737344 336596991 50.0 GiB 8300 Linux filesystem
A data HDD disk:
# gdisk -l /dev/sdb
GPT fdisk (gdisk) version 1.0.1
Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: present
Found valid GPT with protective MBR; using GPT.
Disk /dev/sdb: 5860533168 sectors, 2.7 TiB
Logical sector size: 512 bytes
Disk identifier (GUID): 496CE51B-233E-4217-AE1E-44822A9D79ED
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 5860533134
Partitions will be aligned on 2048-sector boundaries
Total free space is 2925 sectors (1.4 MiB)
Number Start (sector) End (sector) Size Code Name
1 2048 209717247 100.0 GiB 0700
2 209717248 5860532223 2.6 TiB 0700
A backup data HDD disk:
# gdisk -l /dev/sdc
GPT fdisk (gdisk) version 1.0.1
Partition table scan:
MBR: MBR only
BSD: not present
APM: not present
GPT: not present
***************************************************************
Found invalid GPT and valid MBR; converting MBR to GPT format
in memory.
***************************************************************
Disk /dev/sdc: 2930277168 sectors, 1.4 TiB
Logical sector size: 512 bytes
Disk identifier (GUID): 1E240AC3-490D-4D7A-A55E-A64C1A14F8A3
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 2930277134
Partitions will be aligned on 2048-sector boundaries
Total free space is 4845 sectors (2.4 MiB)
Number Start (sector) End (sector) Size Code Name
1 2048 2930274303 1.4 TiB 0700 Microsoft basic data
While I am there, I was wondering if the "volume" token (used in my configuration OS stanza) can work with some kind of UUID related to MBR. For now I use the volume partition label to match a target partition to boot since there is no real GUID (which is related to GPT) for my USB stick partitions.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've an USB stick with multiple partitions (from various OSes installation/LiveCD isos). Windows partitions use ntfs, Linux ones use ext2, and rEFInd is set in a fat32 one to handle UEFI boot (syslinux is used for legacy BIOS boot).
Starting with version 0.10.2, on one UEFI system rEFInd fails to load the configuration file and fallbacks to a text menu with minimum boot entries. The error is:
(The second line may not exactly match, it is not displayed long enough for me to see it properly)
On another UEFI system, I don't have this issue.
rEFInd show the following info on the system where it fails:
The system where it works:
Previous versions (up to 0.10.1) are OK on both systems.
Not having drivers to load prevents the issue, except rEFInd then obviously cannot access the efi file on the partition to boot (unless it is fat32).
What manually works is:
Rename the drivers folder to something not scanned.
Reboot to rEFInd.
Enter the EFI shell.
Load the necessary driver.
Execute the EFI file on the targeted partition.
To me it seems that after loading the drivers, drives map is refreshed and on the system that have the issue rEFInd does not find itself anymore where expected. e.g. after manually calling
map -rI observed (at least once) that fs0 was not pointing to the boot partition anymore (where was rEFind), but apparently to my ESP (on SSD) partition instead.Any idea what could be the cause, and if it can be fixed (as was working since 0.10.1) ?
Thanks
Version 0.10.2 introduced a workaround for a driver-loading problem on some HP EFIs, so it looks like that change has had an unintended consequence on at least some other computers. Out of curiosity, what is the brand of the computer on which this is no longer working? Also, what does the partition table look like? (Showing the output of
gdisk -l /dev/sdaorparted /dev/sda printwould be helpful -- and if there's more than one disk, showing that output for all of them would be helpful.) It's conceivable that re-ordering the partitions would work around the problem; but obviously a better fix is highly desirable.The motherboard (this is an assembled computer) where it does not work is a Gigabyte GA-AX370-Gaming 5 (which is pretty recent). My previous computer did not have UEFI support.
The system where it still works is an Asus N76 laptop (~5 years old).
Oh right, I forgot to mention that - in order to work with legacy BIOSes - the USB stick uses a MBR partition table and not GPT.
This also limits the possibilities I had, e.g. Windows installation/repair tools (at least Windows 7/8, latest Windows 10 seems a little bit more flexible) don't like not being on the first primary partition.
So, the content of the USB stick:
sdd[1-3] are Windows 7/8/10, sdd5 is syslinux+rEFInd, the other partitions are various Linux installation/LiveCD partitions.
My main SSD disk (recently converted from MBR to GPT):
A data HDD disk:
A backup data HDD disk:
While I am there, I was wondering if the "volume" token (used in my configuration OS stanza) can work with some kind of UUID related to MBR. For now I use the volume partition label to match a target partition to boot since there is no real GUID (which is related to GPT) for my USB stick partitions.