You are not logged in.

#26 2013-03-15 12:07:29

s1ln7m4s7r
Member
Registered: 2013-02-22
Posts: 262

Re: refind blocks the stage boot

srs5694 wrote:
s1ln7m4s7r wrote:

I don't know if you already fixed the "refindx64.efi" bug entry in refind.

It appeared to me after an update, but i never had that efi file, so i guess its a bug in refind and it has nothing to do with arch.

No, that's a follow-on effect of a bug in the Arch package of rEFInd, not in the rEFInd binary itself. Since rEFInd's first release, I used a filename of refind_x64.efi for rEFInd on x86-64, but the Arch packagers decided to change this to refindx64.efi. I've been relying more and more on installation and other support scripts that assume the binary's name to be refind_x64.efi, though, so I asked the Arch packagers to change it. They did so, but apparently when updating the Arch package the old file isn't removed.

Also, rEFInd normally ignores all binaries in its home directory, so if you're seeing such a boot entry, that means it resides in a directory other than the one from which rEFInd is launching. Chances are this means that in your case, you installed an update in a directory other than the one you used originally. Deleting the old version of rEFInd is the appropriate action in this case.

That's not possible, because i retested it with a Virtualbox clean install yesterday and it apears all the same. The "refindx64.efi" entry is there too.

And there's also a really weird thing in the clean Virtualbox install, with auto-detect enabled (duplicated boot entries, but the duplicates have a UUID that i've never used and doesn't exist in the system)!

Last edited by s1ln7m4s7r (2013-03-15 12:10:24)

Offline

#27 2013-03-15 17:52:02

srs5694
Member
From: Woonsocket, RI
Registered: 2012-11-06
Posts: 719
Website

Re: refind blocks the stage boot

s1ln7m4s7r wrote:

That's not possible, because i retested it with a Virtualbox clean install yesterday and it apears all the same. The "refindx64.efi" entry is there too.

Without knowing precisely how your VirtualBox setup is configured (files on the ESP, refind.conf file, how you installed, etc.), I really can't comment on what's going on. I can assure you that rEFInd doesn't make up entries that don't exist (unless perhaps you've got manual entries that point to nothing), so if a fresh install shows an extra "refindx64.efi" loader, that means that whatever installation script or procedure you used is buggy. As rEFInd's developer, I'm responsible for the binaries that I release, but the Arch packagers are responsible for the binaries and instructions that they release, and my suspicion is that you're running into problems with the latter.

And there's also a really weird thing in the clean Virtualbox install, with auto-detect enabled (duplicated boot entries, but the duplicates have a UUID that i've never used and doesn't exist in the system)!

I don't know what you mean by this because rEFInd doesn't display UUIDs. Are you referring to UUIDs in efibootmgr output? If so, that's most likely a VirtualBox quirk/bug -- I've noticed that VirtualBox seems to create a number of useless entries (as displayed by efibootmgr), and changes made by efibootmgr are forgotten when you reboot the virtual machine. You can use bcfg in an EFI version 2 shell to change the VirtualBox "NVRAM" entries, though.

Offline

#28 2013-03-15 20:49:38

s1ln7m4s7r
Member
Registered: 2013-02-22
Posts: 262

Re: refind blocks the stage boot

srs5694 wrote:
s1ln7m4s7r wrote:

That's not possible, because i retested it with a Virtualbox clean install yesterday and it apears all the same. The "refindx64.efi" entry is there too.

Without knowing precisely how your VirtualBox setup is configured (files on the ESP, refind.conf file, how you installed, etc.), I really can't comment on what's going on. I can assure you that rEFInd doesn't make up entries that don't exist (unless perhaps you've got manual entries that point to nothing), so if a fresh install shows an extra "refindx64.efi" loader, that means that whatever installation script or procedure you used is buggy. As rEFInd's developer, I'm responsible for the binaries that I release, but the Arch packagers are responsible for the binaries and instructions that they release, and my suspicion is that you're running into problems with the latter.

I didn't use any script. I've done it all by hand.

pacstrap /mnt refind
arch-chroot /mnt
mkdir -p /boot/efi/EFI/refind/
mkdir -p /boot/efi/EFI/tools/drivers/
cp -r /usr/lib/refind/config/refind.conf /boot/efi/EFI/refind/
cp -r /usr/share/refind/icons /boot/efi/EFI/refind/
cp -r /usr/lib/refind/config/refind_linux.conf /boot/
cp -r /usr/lib/refind/refind_x64.efi /boot/efi/EFI/refind/
cp -r /usr/lib/refind/drivers_x64/* /boot/efi/EFI/tools/drivers/
sed -i "s/#textonly/textonly/" "/boot/efi/EFI/refind/refind.conf"
sed -i "s/#scan_driver_dirs EFI\/tools\/drivers,drivers/scan_driver_dirs EFI\/tools\/drivers/" "/boot/efi/EFI/refind/refind.conf"
sed -i "s/#scan_delay 5/scan_delay 5/" "/boot/efi/EFI/refind/refind.conf"
sed -i "s/codepage=cp437/codepage=437/" "/etc/fstab"
sed -i 's/root=PARTUUID=XXXXXXXX rootfstype=XXXX ro/root=UUID=$(blkid -s UUID -o value $(df -k /)) rootfstype=$(blkid -s TYPE -o value $(df -k /)) ro/' '/boot/refind_linux.conf'
sed -i "s/#dont_scan_dirs ESP:\/EFI\/boot,EFI\/Dell/dont_scan_dirs \/EFI\/boot/" "/boot/efi/EFI/refind/refind.conf"

I then rechecked /root/refind_linux.conf and /boot/efi/EFI/refind/refind.conf and everything is ok with the setup. (auto detection)

And there's also a really weird thing in the clean Virtualbox install, with auto-detect enabled (duplicated boot entries, but the duplicates have a UUID that i've never used and doesn't exist in the system)!

I don't know what you mean by this because rEFInd doesn't display UUIDs. Are you referring to UUIDs in efibootmgr output? If so, that's most likely a VirtualBox quirk/bug -- I've noticed that VirtualBox seems to create a number of useless entries (as displayed by efibootmgr), and changes made by efibootmgr are forgotten when you reboot the virtual machine. You can use bcfg in an EFI version 2 shell to change the VirtualBox "NVRAM" entries, though.

I'm really talking about refind boot entries under refind's boot manager window and not VirtualBox's "NVRAM" (anyway: it can't hold EFI boot entries after a full restart, so i use UEFI Shell or boot from file options).

In refind's boot manager window, i have 4 boot entries. If you press F2 key under any of those entries it gives us advanced options ("boot with defaults" and "boot to terminal"), if you press F2 again it allows to edit boot entry.

In my case 2 of those have in their boot entry a UUID (cause i use uuid instead of partuuid) that doesn't exists anywhere.

NOTE: It passed true my mind that it may be some kind of issue with raid devices (my /boot partition is a raid1 device, because of mirroring, it may be detecting the copy partition)? But i don't know.

Last edited by s1ln7m4s7r (2013-03-18 19:29:46)

Offline

#29 2013-03-15 22:28:27

s1ln7m4s7r
Member
Registered: 2013-02-22
Posts: 262

Re: refind blocks the stage boot

OK, i tested refind with many system layouts and my idea was right! Refind has a bug (or not) with auto-detection in systems with /root being a raid1 array, i don't know why but it detects both EFISTUB Kernels from the active /root partition and it's mirrors (reads files in all partitions belonging to the raid instead of reading only the active one), creating fake entries.

About the refindx64.efi bug, it is recurrent in all installs, and so, it has to be an arch package or refind's problem.

But i don't know how it can be a packaging issue, if there is no such file anywhere in the system with:

find / -name "refindx64.efi"

Last edited by s1ln7m4s7r (2013-03-15 23:33:12)

Offline

#30 2013-03-15 23:38:17

cfr
Member
From: Cymru
Registered: 2011-11-27
Posts: 7,131

Re: refind blocks the stage boot

srs5694 wrote:

It will also prevent rEFInd from finding bootable removable media, which rely on this fallback filename. You could, though, uncomment that line and change "ESP" to the filesystem's true name. (Highlight the entry in the rEFInd display to learn what this name is.) You can set it in GParted if it's not set and therefore shows up as something like "500 MiB FAT volume."

FWIW, a version or two ago I added a check to keep the fallback boot loader out of the boot menu if it's byte-for-byte identical with another boot loader. This is helpful because Windows, and increasingly some other OSes, are duplicating their own boot loaders in the fallback location as a way around EFI limitations.

Thanks for this info. I was using this option because I didn't want it to scan EFI/boot and find the fallback entry. I was also blocking EFI/arch for related reasons. I did not realise this would block detection of bootable removable media because the setting to scan for "external" was still there. I guess I don't understand this as well as I should. I'm assuming it has this effect because EFI/boot means EFI/boot on *any* available filesystem, is that correct?

Are the "true names" of the file systems which you mention those listed in /dev/disk/by-label/? Or something different? Because there is no guarantee those will be unique, is there? So how would specifying the file system that way prevent blocking bootable removable media?


CLI Paste | How To Ask Questions

Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L

Offline

#31 2013-03-18 18:53:56

srs5694
Member
From: Woonsocket, RI
Registered: 2012-11-06
Posts: 719
Website

Re: refind blocks the stage boot

s1ln7m4s7r wrote:
srs5694 wrote:

if a fresh install shows an extra "refindx64.efi" loader, that means that whatever installation script or procedure you used is buggy.

I didn't use any script. I've done it all by hand.

Then your procedure is buggy. I don't see any obvious problems in what you've quoted below, although I did notice that you copied the 32-bit version of rEFInd, which makes even less sense that it would be detecting "ghost" versions of refindx64.efi. You must have a stray copy of that file somewhere. Examining the path and volume label or description reported by rEFInd when you highlight the entry should enable you to find it. For instance, if you hightlight the entry and it reads "Boot EFI\refind\refindx64.efi from FOO", then you should look for the file EFI/refind/refindx64.efi on the partition whose filesystem has a filesystem name of "FOO".

Note that I have never used the filename of "refindx64.efi" in rEFInd; nor does it have any code that generates that name. Nobody else has reported this type of bug. The only conclusion I can come to is that you do have this file on your computer -- or at least, that your EFI is finding such a file. (It could be that you've got a damaged FAT filesystem with a file that the EFI detects but that Linux doesn't, for instance.) Also, be sure to check removable media; by default, rEFInd scans every filesystem it can read, which includes removable disks and other filesystems that might not be mounted by default in Linux.

If you still can't find this file, please post a screen shot of rEFInd with the entry in question highlighted. (You can generate a screen shot by pressing F10. That will save it to a file called screenshot.bmp on the ESP.) Also, post the output of "blkid" and "parted -l", both typed as root, once Linux has booted.

In refind's boot manager window, i have 4 boot entries. If you press F2 key under any of those entries it gives us advanced options ("boot with defaults" and "boot to terminal"), if you press F2 again it allows to edit boot entry.

In my case 2 of those have in their boot entry a UUID (cause i use uuid instead of partuuid) that doesn't exists anywhere.

Those values are taken from the refind_linux.conf file for a kernel, so I suggest you check there.

Refind has a bug (or not) with auto-detection in systems with /root being a raid1 array, i don't know why but it detects both EFISTUB Kernels from the active /root partition and it's mirrors (reads files in all partitions belonging to the raid instead of reading only the active one), creating fake entries.

I assume you mean "root (/)", not "/root", since you don't normally place /root (the root user's home directory) on a separate partition.

The EFI filesystem drivers upon which rEFInd relies know nothing about RAID setups, so if you're using Linux's software RAID 1, you will indeed see this behavior, because from the EFI and rEFInd perspective, there are two partitions with identical contents. If this bothers you, you can add a separate /boot partition to hold your kernels that's not RAIDed.

cfr wrote:

I was also blocking EFI/arch for related reasons. I did not realise this would block detection of bootable removable media because the setting to scan for "external" was still there. I guess I don't understand this as well as I should. I'm assuming it has this effect because EFI/boot means EFI/boot on *any* available filesystem, is that correct?

Correct; if you specify a pathname without a leading volume identifier (for instance, "EFI/arch", then the match applies to any volume. If you add a volume name (as in "SOMEVOL:/EFI/arch"), then that matches the directory on just the specified volume ("SOMEVOL" in this example).

cfr wrote:

Are the "true names" of the file systems which you mention those listed in /dev/disk/by-label/? Or something different?

They're the filesystem names encoded in the filesystem. I believe that the /dev/disk/by-label filenames should match them, but I generally check them with GParted or by using "blkid".

Offline

#32 2013-03-18 19:29:08

s1ln7m4s7r
Member
Registered: 2013-02-22
Posts: 262

Re: refind blocks the stage boot

srs5694 wrote:
s1ln7m4s7r wrote:
srs5694 wrote:

if a fresh install shows an extra "refindx64.efi" loader, that means that whatever installation script or procedure you used is buggy.

I didn't use any script. I've done it all by hand.


Then your procedure is buggy. I don't see any obvious problems in what you've quoted below, although I did notice that you copied the 32-bit version of rEFInd, which makes even less sense that it would be detecting "ghost" versions of refindx64.efi. You must have a stray copy of that file somewhere. Examining the path and volume label or description reported by rEFInd when you highlight the entry should enable you to find it. For instance, if you hightlight the entry and it reads "Boot EFI\refind\refindx64.efi from FOO", then you should look for the file EFI/refind/refindx64.efi on the partition whose filesystem has a filesystem name of "FOO".

Sorry i've just posted the wrong thing. This was for my x86 uefi virtualbox, that i have made for testing purposes, that actually has the same bug on it. I will correct those lines to:

cp -r /usr/lib/refind/refind_x64.efi /boot/efi/EFI/refind/
cp -r /usr/lib/refind/drivers_x64/* /boot/efi/EFI/tools/drivers/

EDIT: After reading your post i re-commented the "dont_scan_dirs" to test it again and WTH, the entry doesn't appear anymore. I'm completely stupefied!!! Did nothing, changed nothing.

NOTE: I gess to many nights on computer makes me see weird things. ;-)

NEW EDIT: After thinking for a while, i guess having /boot under RAID 1 was messing up refind.

In refind's boot manager window, i have 4 boot entries. If you press F2 key under any of those entries it gives us advanced options ("boot with defaults" and "boot to terminal"), if you press F2 again it allows to edit boot entry.

In my case 2 of those have in their boot entry a UUID (cause i use uuid instead of partuuid) that doesn't exists anywhere.

Those values are taken from the refind_linux.conf file for a kernel, so I suggest you check there.

Refind has a bug (or not) with auto-detection in systems with /root being a raid1 array, i don't know why but it detects both EFISTUB Kernels from the active /root partition and it's mirrors (reads files in all partitions belonging to the raid instead of reading only the active one), creating fake entries.

I assume you mean "root (/)", not "/root", since you don't normally place /root (the root user's home directory) on a separate partition.

Yes i do mean root (/).

The EFI filesystem drivers upon which rEFInd relies know nothing about RAID setups, so if you're using Linux's software RAID 1, you will indeed see this behavior, because from the EFI and rEFInd perspective, there are two partitions with identical contents. If this bothers you, you can add a separate /boot partition to hold your kernels that's not RAIDed.

Yes i already did it.

Last edited by s1ln7m4s7r (2013-03-18 19:51:08)

Offline

#33 2013-04-01 13:54:20

otto88
Member
Registered: 2012-12-16
Posts: 74

Re: refind blocks the stage boot

sorry but now what do i do to resolve ?
in case have you tried the kernel version 3.8 ?
is it work?

thanks

Offline

#34 2013-04-01 14:04:04

cfr
Member
From: Cymru
Registered: 2011-11-27
Posts: 7,131

Re: refind blocks the stage boot

otto88 wrote:

sorry but now what do i do to resolve ?
in case have you tried the kernel version 3.8 ?
is it work?

thanks

If you are being bitten by the bug, the only thing you can do is try it and see. For me, everything worked fine prior to 3.8 and nothing works post 3.8. But others have had the opposite experience.


CLI Paste | How To Ask Questions

Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L

Offline

Board footer

Powered by FluxBB