refind find vmlinuz but not initramfs-linux.img

[Fabio Sasso]

I'm using Archlinux and trying to boot the standard kernel by using the EFISTUB.

if I choose "vmlinuz" refind says:

Starting vmlinuz
Using load options 'initrd=\initramfs-linux.img'
Failed to open file: initramfs-linux.img

the kernel and the initramfs are in the $EFI/ partition, system mount that as /boot/

[Roderick W. Smith]

Are you dual-booting with Windows 8 or later? If so, have you disabled the Windows "Fast Startup" feature? If not, do so, as described here, among other places. This feature turns a "shutdown" operation into a suspend-to-disk operation. The result, when dual-booting, is filesystem corruption that can cause any number of problems, including the symptom you're seeing. After disabling this feature, you may need to run dosfsck on the partition in Linux, and perhaps re-write the file(s).

Another possible cause is if your ESP is smaller than 512MiB. (Note that's MiB, not MB.) Some EFIs have problems with FAT32 filesystems smaller than that value; and others have problems with FAT16 ESPs. (Linux's mkdosfs utility defaults to FAT16 below something like 530MiB, but I don't recall the exact value; I generally recommend making the ESP 550MiB, to keep the value both easy to remember and above common problem points.)

[Fabio Sasso]

first of all thanks for the very impressive fast response, availabilty and clarity.
sorry for not being much clear about my particoular situation, but I'm running refind on an old macbook1,1 that support maximum "snow leopard" as OsX operating system.
the EFI is 32bit
the partition (verified with parted), created by OsX, is 210Mb fat32 with flags 'boot' and 'esp' so it could be less than 512Mib?
how can I resize that partition safety (in arch)?

[Roderick W. Smith]

I've never encountered problems with Apple's EFI reading either FAT16 or FAT32 ESPs, so that's not likely to be your problem.

Are you using rEFInd's auto-detection or a manual boot stanza? The latter can be tricky; any tiny typo or other error in specifying the initrd value can produce a failure.

You might also try launching an EFI shell and verifying that the file is visible. You can also try launching the kernel manually from the shell, including the exact initrd= option you're passing via rEFInd. If that produces an error, you can play with the format a bit more easily than you could in rEFInd.

[Fabio Sasso]

I use autodetection.
Ok now I've tried to use manual boot stanza with:

menuentry "Arch Linux" {
icon /EFI/refind/icons/os_arch.png
volume Boot
loader /vmlinuz-linux
initrd /EFI/initramfs-linux.img
options "root=/dev/sda3 rootfstype=ext4 ro"
}

but still cannot find initramfs-linux.img
right now I use my own compiled kernel without initrd line and it boots successfully.
I remember again that my efi fat32 partition in 200Mib

how can I use an EFI Shell?

ps; the correct booting manual stanza of compiled kernel is:

menuentry "Arch Linux" {
icon /EFI/refind/icons/os_arch.png
volume Boot
loader /vmlinuz
options "root=/dev/sda3 rootfstype=ext4 ro"
}

the autodeteced version instead doesn't boot because refind still try to append an initrd file that doesn't exist. I don't have a refind_linux.conf file.

[Roderick W. Smith]

To use an EFI shell, you must install an EFI shell binary, as documented on the Arch wiki:

https://wiki.archlinux.org/index.php/Unified_Extensible_Firmware_Interface#Obtaining_UEFI_Shell

Because Macs use EFI 1.x, you'll need the older v1 EFI shell.

Given your new information, my current suspicion is that your ESP may have filesystem damage. You wouldn't happen to be triple-booting with Windows 8 or later, would you? If so, be sure to disable the Windows Fast Startup feature, as documented here:

http://www.eightforums.com/tutorials/6320-fast-startup-turn-off-windows-8-a.html

Whether or not you're using Windows, you might consider backing up the files on the ESP, unmounting it, creating a fresh filesystem on it, re-mounting it, and restoring all the files. This will guarantee that any filesystem damage is repaired. I am not, however, anywhere close to 100% sure that this is the cause of your problems. It's worth trying this approach, but only if you're comfortable doing such things -- if you're not familiar with this type of operation, it's possible that a mistake will cause some OSes to become unbootable.

[Fabio Sasso]

I don't know how to disable UEFI fast startup since I don't have windows here on my macbook but only archlinux and snow leopard. the only version of windows that I had was win7 but now is gone from this computer.

I don't want to try AGAIN to touch ESP since in my last trying to resize it from 200Mib to something bigger I get into a buggy Gparted that seem to not very good at handling FAT32 partition and says to me that can't resize partition to that size.
You can check on google how Gparted sucks at resizing fat32 partitions
(http://ubuntuforums.org/showthread.php?t=2225043)

If there is something I prefer to check my partition instead of recreating it "just to be sure"

But I don't get the point of that "smaller that 512Mb/ damaged" are correlated to the fact that it find the linux image but can't load the appropriate initramfs.
with Syslinux it boots correctly the image and the initramfs. I just would like to use efistub feature.

thanks.

[Fabio Sasso]

maybe it's just a problem of putting file in the wrong directory? kernel and initramfs are in the same directory (the / of the ESP), kernel is seen initramfs no.

[Roderick W. Smith]

If you're no longer running Windows, then the Windows Fast Startup feature is not to blame, and you can forget it. (For future reference, though, that's a Windows feature that turns a shutdown into a suspend-to-disk operation. The result is filesystems in an inconsistent state, which can cause all manner of problems in a dual-boot configuration. Many EFIs have a feature with a similar name that bypasses some hardware initialization steps. The Windows and EFI features are unrelated, but many people get them confused. Macs have no EFI fast-startup feature per se, AFAIK.)

One problem with the ESP is that it must be read by at least two drivers: the FAT driver in the ESP and the FAT driver in your OS. If you dual-boot, then it's three drivers; and so on for every additional OS. Thus, a bug or limitation in just one of these drivers may interact in strange ways with the others. EFI is newer than many of the OSes it runs, and the FAT driver in many EFIs is a bit finicky. (Note that different EFIs can have different FAT drivers, which makes it even harder to figure out what's going on, since one computer can respond very differently from another one.) One observation that I've seen on various forums, and that I've confirmed myself, is that some EFIs behave strangely when fed a FAT32 ESP that's smaller than 512MiB. In particular, they refuse to open random files. In rEFInd, one symptom of this problem is that some icons are randomly replaced by an ugly black-and-yellow pattern. I've never heard of this particular problem on a Mac, but I can't rule out the possibility that this is what's happening to you. I've heard of (and seen) similar problems when the ESP uses FAT16 rather than FAT32, but that problem seems rarer.

I think it's more likely that your ESP's FAT filesystem is subtly damaged. Repairing it with dosfsck in Linux or the equivalent in OS X may fix it; but in some cases, backing up, creating a new filesystem, and restoring may be required. Note that this is not the same as resizing the partition; it's starting with a fresh set of filesystem data structures, freshly populated with the files you want. This operation is not painful if you're familiar with such things, but I admit it can be scary if you've never done it before. Since you mention you ran into trouble when resizing your filesystem with GParted, this cause may be even more likely, depending on what you did to recover from the problem. If you did anything less than this sort of starting-fresh solution, then there may be problems lurking on the filesystem that are invisible to OS X and Linux.

Your problem is not simply that the file is in the wrong directory. If the rEFInd auto-detection mechanism has found the initrd file, then that file must be in the same directory as the kernel, since rEFInd searches only the kernel's own directory for that file. You can specify an initrd file in another directory via a manual boot stanza, but not with auto-detection.

Getting back to an earlier suggestion: If you can launch an EFI shell, you can try to access the initrd file (by copying it or even by launching the kernel manually and passing it the correct initrd= option). You may learn something in this attempt -- for instance, if the copy operation fails, the EFI shell will probably give you an error message that might contain some vital clue.

[mirh]

https://bbs.archlinux.org/viewtopic.php?id=199871
It would be interesting to know your motherboard model/vendor.