rEFInd update on SSD

Dieter · 2013-07-19 14:52:04

In my PC, a SSD is installed with 4 partitions.
Partition 1 contains Arch linux, partition 4 is /boot/efi with rEFInd bootloader.

As written in the wiki, I used the refind_name_patchv2 script for automatic updates of the refind stuff in /boot/efi on the SSD partition 4.

I realized now more than once that the automated copying of refind_x64.efi results in a corrupted file on the EFI partition. With the corrupted file, the system fails to boot with an empty black screen. The refind_x64.efi file on /boot/efi/EFI/refind is significantly smaller than source in /usr/lib/refind/.

What is the reason for the dammaged file? My SSD? Is it possible that copying by the script (via systemd) starts before the (via pacman) updated file is completely written to /usr/lib/refind/refind_x64.efi and so only a part of this file is copied?
Sometimes it works, sometimes not ...

Should I add a "sleep" before copying the files? Or any other suggestions?

srs5694 · 2013-07-19 15:54:12

One thought that occurs to me is that some users have had problems with FAT32 ESPs smaller than 512MiB, apparently because of EFI FAT driver problems. If you've got such a partition, you can try either increasing its size or converting it to FAT16. (The ESP is officially supposed to be FAT32, but in practice FAT16 usually works and avoids such problems. OTOH, the Windows installer barfs when it sees a FAT16 ESP, so if you're dual-booting or might want to do so in the future, it's better to enlarge the partition.)

Another point is that the latest rEFInd package includes the rEFInd install.sh script, renamed to something else (I think it's refind-install). Running this script on updates might be preferable to running a script that manually updates all the files. OTOH, this change is very new and may yet be buggy. I've not yet tested it myself.

WonderWoofy · 2013-07-19 19:00:09

Rod, I thought you might be interested to see what happens when I run "refind-install" on my machine (ESP mounted at /boot and and refind directory is /boot/EFI/refind).

%  sudo refind-install 
Installing rEFInd on Linux....
EspFilesystem is 'vfat'
ESP was found at /boot using vfat
Found rEFInd installation in /boot/EFI/refind; upgrading it.

CAUTION: Your computer appears to support Secure Boot, but you haven't
specified a valid shim.efi file source. If you've disabled Secure Boot and
intend to leave it disabled, this is fine; but if Secure Boot is active, the
resulting installation won't boot. You can read more about this topic at
http://www.rodsbooks.com/refind/secureboot.html.

Do you want to proceed with installation (Y/N)? y
OK; continuing with the installation...
Copied rEFInd binary files

Notice: Backed up existing icons directory as icons-backup.
cp: cannot create symbolic link ‘/boot//EFI/refind/icons’: Operation not permitted
Existing refind.conf file found; copying sample file as refind.conf-sample
to avoid overwriting your customizations.

An existing rEFInd boot entry exists, but isn't set as the default boot
manager. The boot order is being adjusted to make rEFInd the default boot
manager. If this is NOT what you want, you should use efibootmgr to
manually adjust your EFI's boot order.
Installing it!

ALERT:
Installation has completed, but problems were detected. Review the output for
error messages and take corrective measures as necessary. You may need to
re-run this script or install manually before rEFInd will work.

I should note that there is a mechanism in systemd that causes the ESP to be automounted when set at /boot. Because of this, the first time it registered as autofs, which resulted in this:

Installing rEFInd on Linux....
EspFilesystem is 'autofs
vfat'
//boot/efi doesn't seem to be on a VFAT filesystem. The ESP must be
mounted at //boot or //boot/efi and it must be VFAT! Aborting!

Anyway, it worked for the most part. I am curious if it actually copied the icons to the ESP since a symlink is not possible on VFAT (FAT32). I wonder if the script can be updated to appropriately handle symlinking vs copying if a FAT filesystem is detected.

srs5694 · 2013-07-19 22:57:19

It looks like the simple changes made to the script by the Arch maintainers are inadequate to the changes made by the Arch maintainers to the layout of files. Specifically, the Arch package splits rEFInd files across the /usr/lib/refind and /usr/share/refind directories, with some symbolic links thrown in at the former location pointing to the latter. The cp command used in the script to copy the icons directory is choking on the symbolic links, though, which is resulting in the icons directory not being copied (and perhaps some others, too).

As to the detection of the ESP filesystem, that could be remedied by changes to the script, but I need a copy of one of the /etc/mtab file from an affected system.

I've just requested that bug 36151 be re-opened, but I failed to mention the specifics or link to this thread because I assumed I'd be able to after entering the re-open request. I can't seem to do so, though. If somebody else knows of a way to do that, please do so.

Last edited by srs5694 (2013-07-19 23:04:12)

the.ridikulus.rat · 2013-07-19 23:10:34

srs5694 wrote:

It looks like the simple changes made to the script by the Arch maintainers are inadequate to the changes made by the Arch maintainers to the layout of files. Specifically, the Arch package splits rEFInd files across the /usr/lib/refind and /usr/share/refind directories, with some symbolic links thrown in at the former location pointing to the latter. The cp command used in the script to copy the icons directory is choking on the symbolic links, though, which is resulting in the icons directory not being copied (and perhaps some others, too).
As to the detection of the ESP filesystem, that could be remedied by changes to the script, but I need a copy of one of the /etc/mtab file from an affected system.
I've just requested that bug 36151 be re-opened, but I failed to mention the specifics or link to this thread because I assumed I'd be able to after entering the re-open request. I can't seem to do so, though. If somebody else knows of a way to do that, please do so.

Will "cp -r --dereference" in the refind-install script not work in such a case?

WonderWoofy · 2013-07-20 00:40:22

Well, until it does reopen, here is my mtab file (which, as systemd call for, is a symlink to /proc/self/mounts):

rootfs / rootfs rw 0 0
proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0
devtmpfs /dev devtmpfs rw,nosuid,size=4005988k,nr_inodes=1001497,mode=755 0 0
securityfs /sys/kernel/security securityfs rw,nosuid,nodev,noexec,relatime 0 0
tmpfs /dev/shm tmpfs rw,nosuid,nodev 0 0
devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
tmpfs /run tmpfs rw,nosuid,nodev,mode=755 0 0
tmpfs /sys/fs/cgroup tmpfs rw,nosuid,nodev,noexec,mode=755 0 0
cgroup /sys/fs/cgroup/systemd cgroup rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd 0 0
pstore /sys/fs/pstore pstore rw,nosuid,nodev,noexec,relatime 0 0
efivarfs /sys/firmware/efi/efivars efivarfs rw,nosuid,nodev,noexec,relatime 0 0
cgroup /sys/fs/cgroup/cpuset cgroup rw,nosuid,nodev,noexec,relatime,cpuset 0 0
cgroup /sys/fs/cgroup/cpu,cpuacct cgroup rw,nosuid,nodev,noexec,relatime,cpuacct,cpu 0 0
cgroup /sys/fs/cgroup/memory cgroup rw,nosuid,nodev,noexec,relatime,memory 0 0
cgroup /sys/fs/cgroup/devices cgroup rw,nosuid,nodev,noexec,relatime,devices 0 0
cgroup /sys/fs/cgroup/freezer cgroup rw,nosuid,nodev,noexec,relatime,freezer 0 0
cgroup /sys/fs/cgroup/net_cls cgroup rw,nosuid,nodev,noexec,relatime,net_cls 0 0
cgroup /sys/fs/cgroup/blkio cgroup rw,nosuid,nodev,noexec,relatime,blkio 0 0
/dev/sdb / btrfs rw,noatime,compress=lzo,ssd,space_cache,autodefrag 0 0
systemd-1 /proc/sys/fs/binfmt_misc autofs rw,relatime,fd=34,pgrp=1,timeout=300,minproto=5,maxproto=5,direct 0 0
systemd-1 /boot autofs rw,relatime,fd=37,pgrp=1,timeout=300,minproto=5,maxproto=5,direct 0 0
systemd-1 /var/opt/btrfs-tree autofs rw,relatime,fd=39,pgrp=1,timeout=300,minproto=5,maxproto=5,direct 0 0
systemd-1 /var/lib/mpd/music autofs rw,relatime,fd=40,pgrp=1,timeout=300,minproto=5,maxproto=5,direct 0 0
systemd-1 /var/cache/pacman/pkg autofs rw,relatime,fd=41,pgrp=1,timeout=300,minproto=5,maxproto=5,direct 0 0
hugetlbfs /dev/hugepages hugetlbfs rw,relatime 0 0
mqueue /dev/mqueue mqueue rw,relatime 0 0
tmpfs /tmp tmpfs rw 0 0
debugfs /sys/kernel/debug debugfs rw,relatime 0 0
configfs /sys/kernel/config configfs rw,relatime 0 0
/dev/sdb /home btrfs rw,noatime,compress=lzo,ssd,space_cache,autodefrag 0 0
/dev/sda1 /boot vfat rw,nosuid,nodev,noexec,noatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro 0 0

cfr · 2013-07-20 01:33:11

I could test, if you would like. I am guessing that since I use /boot/efi/EFI/arch_refind for rEFInd, the script should just ignore my existing installation and install to /boot/efi/EFI/refind. (That's what it looked like when I examined the script but I'd like to be sure though I do have copies of everything elsewhere.)

[I have not yet tried to use this for real. My attempted solution to the issue was to add the sleep command as WonderWoofy suggested but refind-efi has not been updated since to test. I think it looked to me as if the script was not going to be sensitive to my customisations (which is understandable) and since I couldn't figure out how it would avoid the timing issues without a sleep command anyway, I decided to just try the sleep variation for now and think about this later.]

WonderWoofy · 2013-07-20 01:40:15

It would be really cool if I could just run refind-install to get things updated real quick, and this would likely solve your problem cfr. Also there has been a flurry of activity in planning out pacman hooks. So in the near future, we may be able to just hook this script into the update and have it fully automated.

@srs5694, I appreciate you looking into this BTW.

cfr · 2013-07-20 02:42:35

I think the sleep command is more likely to solve the automation problem because I think that the service (whatever it does) is just running too soon. A pacman hook would work much better, I suspect, whatever you hooked into it. I'd probably be tempted to write my own script at that point, in fact...

Installing rEFInd on Linux....
EspFilesystem is 'vfat'
ESP was found at /boot/efi using vfat
Installing driver for ext4 (ext4_x64.efi)
Copied rEFInd binary files

cp: cannot create symbolic link ‘/boot/efi//EFI/refind/icons’: Operation not permitted
Copying sample configuration file as refind.conf; edit this file to configure
rEFInd.

Installing it!

ALERT:
Installation has completed, but problems were detected. Review the output for
error messages and take corrective measures as necessary. You may need to
re-run this script or install manually before rEFInd will work.

Personally, I think that the script should tell the user that it has added a boot menu entry and that it has set that new entry as default. Especially given that it doesn't think it has managed to install the boot manager correctly in the first place. (I actually think it should not set the entry as default in this case and that it should tell the user in all cases.)

BootCurrent: 000B
Timeout: 0 seconds
BootOrder: 000E,000B,000A,000C,000D,0007,0005,0008,0006
...
Boot000A* Arch Linux (GRUB2)    HD(1,800,200000,f28c8824-79f1-4f97-83c6-f6a551aa4e79)File(\EFI\arch_grub\grubx64.efi)
Boot000B* Arch Linux (rEFInd)   HD(1,800,200000,f28c8824-79f1-4f97-83c6-f6a551aa4e79)File(\EFI\arch_refind\refind_x64.efi)
...
Boot000E* rEFInd Boot Manager   HD(1,800,200000,f28c8824-79f1-4f97-83c6-f6a551aa4e79)File(\EFI\refind\refind_x64.efi)

I've removed the addition, obviously, as I don't actually want rEFInd doing this.

/boot/efi/EFI/refind/:
total 188
drwxr-xr-x 2 root root   4096 Gor  20 02:56 drivers_x64/
drwxr-xr-x 2 root root   4096 Gor  20 02:56 keys/
-rwxr-xr-x 1 root root  17911 Gor  20 02:56 refind.conf*
-rwxr-xr-x 1 root root 162112 Gor  20 02:56 refind_x64.efi*

/boot/efi/EFI/refind/drivers_x64:
total 32
-rwxr-xr-x 1 root root 32128 Gor  20 02:56 ext4_x64.efi*

/boot/efi/EFI/refind/keys:
total 24
-rwxr-xr-x 1 root root 1769 Gor  20 02:56 SLES-UEFI-CA-Certificate.cer*
-rwxr-xr-x 1 root root  767 Gor  20 02:56 altlinux.cer*
-rwxr-xr-x 1 root root 1080 Gor  20 02:56 canonical-uefi-ca.der*
-rwxr-xr-x 1 root root  876 Gor  20 02:56 fedora-ca.cer*
-rwxr-xr-x 1 root root 1656 Gor  20 02:56 openSUSE-UEFI-CA-Certificate.cer*
-rwxr-xr-x 1 root root  831 Gor  20 02:56 refind.cer*

Note that it doesn't mention that it could not copy the fonts directory etc. even though it clearly failed to copy those for the same reason as it failed to copy the icons over.

It also installed refind_linux.conf to /boot. Unfortunately, not only did it not mention this, but I can see that the configuration in the file would *not* boot my machine. More specifically, it would fail to find the root device. Also, it has added pcie_aspm=force for no apparent reason. I thought maybe it had just touched an old refind_linux.conf I'd forgotten to delete so I deleted and reran the install but I still get the same result: the command line would not boot my machine, the force option is added and I am not even encouraged to check the file for problems!

I would have thought the obvious thing to do here would be to parse /proc/cmdline but I guess that is not available on all systems.

"Boot with standard options" "ro root=/dev/mapper/vgroup--cfr-arch  quiet resume=/dev/disk/by-uuid/d37a7834-2947-4224-90dc-a2893c75324b pcie_aspm=force i915.i915_enable_rc6=1 i915.i915_enable_fbc=1 i915.lvds_downclock=1 i915.semaphores=1 "
"Boot to single-user mode"   "ro root=/dev/mapper/vgroup--cfr-arch  quiet resume=/dev/disk/by-uuid/d37a7834-2947-4224-90dc-a2893c75324b pcie_aspm=force i915.i915_enable_rc6=1 i915.i915_enable_fbc=1 i915.lvds_downclock=1 i915.semaphores=1 single"
"Boot with minimal options"  "ro root=/dev/mapper/vgroup--cfr-arch"

pcie_aspm=force is unnecessary and (so I'm told) a potential source of instability. I am not using it to boot. At least, it is not in my kernel command line. (It did used to be.) i915.i915_enable_rc6=1 is also a bad idea, I'm told, and is also not what I'm using. (I set this to -1 which just uses defaults.) Personally, I think setting resume and i915 options for single user mode is a bad idea and I don't do it but perhaps that's just my paranoia. (Does this even do anything with systemd? There's no single.target and I can't find it as an alias either.)

The reason not one of these options will boot is that none specify cryptdevice and root is in an encrypted LUKS container. (LVM on LUKS set up.) I'm ready to admit that I ought to know this and recognise the omission but I think if I was installing this for the first time and just told to check refind.conf that I would not necessarily realise I also needed to check a second configuration file on another partition.

Note that the script ignored the existence of /boot/efi/EFI/arch/refind_linux.conf. I believe this is expected since I did not point it to that directory. I think the script only looks for kernels at the root of the ESP and /boot, if that's different. Is that correct?

Note that I greatly appreciate your work on rEFInd even if I'm not that taken by its install script, and I did not intend this to sound like a litany of complaints when I started. Just when I looked at what it had actually done, I realised how far it was from doing something reasonable given my configuration where "something reasonable" might well consist of telling me to figure it out for myself.

Also, I realise it told me I might not be able to boot but I take it it did that only because it could not install the icons directory and that it would not have claimed that otherwise even though it would still have installed a refind_linux.conf which would not boot the machine.

OK. I just figured out why it did this. The script should definitely say that it is relying on /etc/default/grub for configuration information. I have not updated this for ages because I do not autogenerate grub.cfg. I hand edit it which is perfectly possible on Arch. The only reason refind_linux.conf got as close as it did is because I used to autogenerate it. Otherwise it would just have used the default version, I assume. I would never have thought that a completely different boot manager would rely on the configuration file of another without even mentioning this or checking it for any kind of sanity. Sorry but it was totally mysterious to me where the script got that config from and so it was totally unobvious how I could correct it. I just cannot believe it does not even mention doing any of this!

EDIT: I removed /etc/default/grub just to see if it would at least tell me to check refind_linux.conf but I guess not. This is what it produced:

"Boot with standard options" "ro root=/dev/mapper/vgroup--cfr-arch   "
"Boot to single-user mode"   "ro root=/dev/mapper/vgroup--cfr-arch   single"
"Boot with minimal options"  "ro root=/dev/mapper/vgroup--cfr-arch"

So, again, it produces an unbootable configuration and does not even recommend the user check it.

Last edited by cfr (2013-07-20 02:54:18)

srs5694 · 2013-07-20 04:01:03

WonderWoofy wrote:

Well, until it does reopen, here is my mtab file (which, as systemd call for, is a symlink to /proc/self/mounts):

Thanks for that. It gave me the information I needed to get install.sh to ignore the autofs entry. That's now in the git repository and will go out with the next revision.

cfr wrote:

Personally, I think that the script should tell the user that it has added a boot menu entry and that it has set that new entry as default.

The installation script is meant mainly for people with a skill level that would make such notifications confusing. People with your skill level are more likely to do it manually or to have the common sense to check such things.

Note that it doesn't mention that it could not copy the fonts directory etc. even though it clearly failed to copy those for the same reason as it failed to copy the icons over.

You're jumping to conclusions. The script makes no attempt to copy the fonts directory. Users who want to use alternate fonts can copy them from the rEFInd .zip file or wherever a packaging system drops them.

I would have thought the obvious thing to do here would be to parse /proc/cmdline but I guess that is not available on all systems.

It might also be inappropriate -- say, if you were installing from a live CD.

Note that I greatly appreciate your work on rEFInd even if I'm not that taken by its install script, and I did not intend this to sound like a litany of complaints when I started. Just when I looked at what it had actually done, I realised how far it was from doing something reasonable given my configuration where "something reasonable" might well consist of telling me to figure it out for myself.

Given your configuration, yes, "something reasonable" is to figure it out for yourself.

OK. I just figured out why it did this. The script should definitely say that it is relying on /etc/default/grub for configuration information.

I've added a notice about this.

I would never have thought that a completely different boot manager would rely on the configuration file of another without even mentioning this or checking it for any kind of sanity.

"Checking it for any kind of sanity" would be completely impossible. There are too many options that are too dependent upon too many hardware and software configurations. It would be a full-time job to maintain just that one piece of code -- and that code would quickly become something quite huge.

The reason the script draws default options from /etc/default/grub is because, as a practical matter, most systems on which rEFInd is installed also have working (or mostly-working) GRUB installations, so grabbing the default settings from the GRUB configuration file makes sense -- more sense than setting no extra options whatsoever or even extracting them from /proc/cmdline. Remember that a script, like a program, is stupid; it lacks common sense and human-level experience, which is what you seem to be complaining that the script lacks.

I just cannot believe it does not even mention doing any of this!

Once again, the installation script is intended for beginners to intermediate users. Such users would be scared away by too many technical messages, and as a practical matter, the script does seem to work for most users, so scaring them with too many warnings would be pointless.

WonderWoofy · 2013-07-20 04:20:07

I could certainly set something up to handle this update as well. But it would be nice to see a working version of the script included in the official Arch package.

As a side note, the new version is again not booting for me. Not the efistub, but refind itself actually won't start. It just gives me a distorted screen... I'll have to see if a downgrade helps. But that is a whole different matter.

srs5694 · 2013-07-20 15:15:06

WonderWoofy wrote:

As a side note, the new version is again not booting for me. Not the efistub, but refind itself actually won't start. It just gives me a distorted screen... I'll have to see if a downgrade helps. But that is a whole different matter.

If you're using any of the EFI drivers, try removing them or downgrading to the 0.6.12 version. Apparently some of the changes to the drivers with 0.7.0 are causing problems on some systems. I included some fixes in 0.7.1, but they might not have fixed everything.

WonderWoofy · 2013-07-20 18:26:23

Thanks srs5694, I'll give it a try.

cfr · 2013-07-20 22:11:36

srs5694 wrote:

cfr wrote:
Personally, I think that the script should tell the user that it has added a boot menu entry and that it has set that new entry as default.
The installation script is meant mainly for people with a skill level that would make such notifications confusing. People with your skill level are more likely to do it manually or to have the common sense to check such things.

I don't really see why "Setting rEFInd as default boot manager" would be more confusing than "ESP was found at /boot/efi using vfat" or "Installing driver for ext4 (ext4_x64.efi)", for example. In fact, that strikes me as rather less technical and more likely to reassure beginners than anything else. After all, that's actually the point of the whole exercise - to set up their boot manager. A message saying that's what's happened seems like a useful one to have. More advanced users might say, "Damn, I didn't want it to do that" and will know the implications and how to undo it if they want. Less advanced users would just read it as another success message. That is, the message doesn't need to be especially technical or erudite.

Note that it doesn't mention that it could not copy the fonts directory etc. even though it clearly failed to copy those for the same reason as it failed to copy the icons over.
You're jumping to conclusions. The script makes no attempt to copy the fonts directory. Users who want to use alternate fonts can copy them from the rEFInd .zip file or wherever a packaging system drops them.

Fair enough. I thought those were required just because pacman always tells me to copy the fonts directory as well as the icons one. If not, great.

Note that I greatly appreciate your work on rEFInd even if I'm not that taken by its install script, and I did not intend this to sound like a litany of complaints when I started. Just when I looked at what it had actually done, I realised how far it was from doing something reasonable given my configuration where "something reasonable" might well consist of telling me to figure it out for myself.
Given your configuration, yes, "something reasonable" is to figure it out for yourself.
OK. I just figured out why it did this. The script should definitely say that it is relying on /etc/default/grub for configuration information.
I've added a notice about this.

Thanks.

I would never have thought that a completely different boot manager would rely on the configuration file of another without even mentioning this or checking it for any kind of sanity.
"Checking it for any kind of sanity" would be completely impossible. There are too many options that are too dependent upon too many hardware and software configurations. It would be a full-time job to maintain just that one piece of code -- and that code would quickly become something quite huge.

Hence the disjunctive claim: it should either check it or mention it is relying on the grub config. But now it is going to do that, so the disjunction is satisfied . And this also effectively tells me to figure it out for myself which is also reasonable, so long as I know to do so.

There were only three things I thought it really should mention: one was that it uses grub's config (when it does so); one was that it installed itself as the default boot manager; and the other was that it should mention refind_linux.conf. I don't really see why doing these things should be especially intimidating since they can easily be couched as success messages. Moreover, inexperienced users are much more likely to want/need to edit refind_linux.conf than refind.conf so telling people that they should edit the latter to "configure rEFInd" but not even mentioning the former seems perverse.

Suppose I am not quite a beginner but not very advanced. I know that I want to add a particular option to my kernel command line because I need that to boot. I install rEFInd using the script and I carefully read the output. Let's assume it has succeeded. Let's also suppose that my system is not set up to use grub. So the script tells me where the configuration script is. Great! That's probably where I need to check it has added that option to my command line. So I try to find somewhere appropriate for it in refind.conf. That seems entirely logical to me. If I'm resourceful, I might look for other config files when I fail to find anything promising in refind.conf. But I could be excused for looking in the same directory on the same partition as the config file I've been directed to since everything pretty much seems to be there - certainly everything the script mentioned copying like the icons and the driver and so on.

Look, this really isn't a problem for me. Were I to use the script, I would check everything it did and I know where to look and what should be where. (Famous last words but still.) But I take it not everybody will be in that position. (I would quite like the reminder but that's all it would be and I can always leave a note for myself somewhere appropriate as I do for any number of other things.)

Also, users do sometimes need to alter their kernel command lines and so it would be helpful to tell them where they should do that. If rerunning the script will regenerate refind_linux.conf, maybe that should be grub's config file where that exists. Otherwise, they need to know about refind_linux.conf.

And users who don't need it will just see another success line - "Great the script autogenerated refind_linux.conf (whatever that is) so I don't have to worry about it".

Last edited by cfr (2013-07-20 22:15:45)

WonderWoofy · 2013-07-21 00:35:23

srs5694,
So I installed the.ridikulus.rat's refind-efi-git from the AUR, and I just tested the refind-install script since I noticed that everything in his new packaged moved the /usr/share/refind. These were the results:

$  sudo refind-install 
Installing rEFInd on Linux....
EspFilesystem is 'vfat'
ESP was found at /boot using vfat
Found rEFInd installation in /boot/EFI/refind; upgrading it.

CAUTION: Your computer appears to support Secure Boot, but you haven't
specified a valid shim.efi file source. If you've disabled Secure Boot and
intend to leave it disabled, this is fine; but if Secure Boot is active, the
resulting installation won't boot. You can read more about this topic at
http://www.rodsbooks.com/refind/secureboot.html.

Do you want to proceed with installation (Y/N)? y
OK; continuing with the installation...
Copied rEFInd binary files

Notice: Backed up existing icons directory as icons-backup.
Existing refind.conf file found; copying sample file as refind.conf-sample
to avoid overwriting your customizations.

An existing rEFInd boot entry exists, but isn't set as the default boot
manager. The boot order is being adjusted to make rEFInd the default boot
manager. If this is NOT what you want, you should use efibootmgr to
manually adjust your EFI's boot order.
Installing it!

ALERT: There were problems running the efibootmgr program! You may need to
rename the refind_x64.efi binary to the default name (EFI/boot/bootx64.efi
on x86-64 systems or EFI/boot/bootia32.efi on x86 systems) to have it run!

Existing //boot/refind_linux.conf found; not overwriting.
# Configuration file for the rEFInd boot menu

ALERT:
Installation has completed, but problems were detected. Review the output for
error messages and take corrective measures as necessary. You may need to
re-run this script or install manually before rEFInd will work.

Interestingly, the last time I tried this, the efibootmgr detected my existing rEFInd entry just fine, and just set it as the first boot entry. But this time it told me it had issues. Upon investigation... I no longer have a rEFInd entry. Odd...

srs5694 · 2013-07-21 18:59:58

cfr, you've made some good points, and I've added some additional information to the script's output.

WonderWoofy, my best guess is that you're running into some of the recent efibootmgr/kernel problems that have been rampant of late. It's far too easy to run into version mismatches that can cause efibootmgr to misbehave. OTOH, if you were able to get it to work by using efibootmgr manually, it's likely to be something else.

WonderWoofy · 2013-07-21 19:25:51

Yeah, I just added the entry back after it failed creating a "new" entry (while also removing the existing one). I was able to add it back no problem within the same boot and everything. Efivars was loaded at the time of running the refind-install script. I have never actually run into the efibootmgr/kernel problems others have discussed, but I am aware of their existence. I haven't had the time to run this again, or try to take a look at what is going on. But if I figure anything out, I'll let you know.

Arch Linux

#1 2013-07-19 14:52:04

rEFInd update on SSD

#2 2013-07-19 15:54:12

Re: rEFInd update on SSD

#3 2013-07-19 19:00:09

Re: rEFInd update on SSD

#4 2013-07-19 22:57:19

Re: rEFInd update on SSD

#5 2013-07-19 23:10:34

Re: rEFInd update on SSD

#6 2013-07-20 00:40:22

Re: rEFInd update on SSD

#7 2013-07-20 01:33:11

Re: rEFInd update on SSD

#8 2013-07-20 01:40:15

Re: rEFInd update on SSD

#9 2013-07-20 02:42:35

Re: rEFInd update on SSD

#10 2013-07-20 04:01:03

Re: rEFInd update on SSD

#11 2013-07-20 04:20:07

Re: rEFInd update on SSD

#12 2013-07-20 15:15:06

Re: rEFInd update on SSD

#13 2013-07-20 18:26:23

Re: rEFInd update on SSD

#14 2013-07-20 22:11:36

Re: rEFInd update on SSD

#15 2013-07-21 00:35:23

Re: rEFInd update on SSD

#16 2013-07-21 18:59:58

Re: rEFInd update on SSD

#17 2013-07-21 19:25:51

Re: rEFInd update on SSD

Board footer