Hide Forgot
Description of problem: See comment #104 in this BZ: https://bugzilla.redhat.com/show_bug.cgi?id=124246#c104 In a nutshell, on F17 x86_64, the default installation or updates thereof have resulted in a read-only /boot/efi, thus there is no way to boot into a newly installed kernel. The error is: Cleanup : kernel-headers-3.6.2-4.fc17.x86_64 53/64 Cleanup : kernel-3.5.3-1.fc17.x86_64 54/64 grubby fatal error: unable to find a suitable template grubby: error creating /boot/efi/EFI/redhat/grub.conf-: Read-only file system Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
While this is clearly a problem, it doesn't seem to have anything to do with grubby. Whatever is causing the filesystem to be mounted read-only is at fault. I think that's systemd, so I'm reassigning it there - but I could be wrong.
systemd currently has no code to mount EFI in any particular way. Maybe anaconda adds it to fstab? Benjamin, can you paste your fstab please?
Here is the fstab. Everything was working up util the kernel-3.5.3-1 update # # /etc/fstab # Created by anaconda on Wed Jun 13 23:29:45 2012 # # Accessible filesystems, by reference, are maintained under '/dev/disk' # See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info # /dev/mapper/coso-lv_root / ext4 defaults 1 1 UUID=defe8682-df18-426c-9e62-e67b373a9e43 /boot ext4 defaults 1 2 UUID=cb6411bc-3dde-306d-b394-7ef647b65940 /boot/efi hfsplus defaults 0 2 /dev/mapper/coso-lv_home /home ext4 defaults 1 2 /dev/mapper/coso-lv_swap swap swap defaults 0 0
Here is /boot/efi/EFI/redhat/grub.conf. # grub.conf generated by anaconda # Note that you do not have to rerun grub after making changes to this file. # NOTICE: You have a /boot partition. This means that all kernel and # initrd paths are relative to /boot, eg. # root (hd0,4) # kernel /vmlinuz-version ro root=/dev/sda6 # initrd /initrd-[generic-]version.img boot=/dev/sda5 device (hd0,5) HD(5,7231000,64000,71cd205b-1678-4146-b1ac-64da7e26716b) default=0 timeout=5 splashimage=(hd0,5)/grub/splash.xpm.gz hiddenmenu title Fedora (3.5.3-1.fc17.x86_64) root (hd0,5) kernel /vmlinuz-3.5.3-1.fc17.x86_64 rd.md=0 root=/dev/mapper/coso-lv_root KEYTABLE=us rd.lvm.lv=coso/lv_root SYSFONT=True rd.luks.uuid=luks-246d7283-2aea-4b0d-a577-07341d7511d6 LANG=en_US.UTF-8 ro rd.lvm.lv=coso/lv_swap rd.dm=0 rhgb quiet initrd /initramfs-3.5.3-1.fc17.x86_64.img title Fedora (3.5.2-3.fc17.x86_64) root (hd0,5) kernel /vmlinuz-3.5.2-3.fc17.x86_64 rd.md=0 root=/dev/mapper/coso-lv_root KEYTABLE=us rd.lvm.lv=coso/lv_root SYSFONT=True rd.luks.uuid=luks-246d7283-2aea-4b0d-a577-07341d7511d6 LANG=en_US.UTF-8 ro rd.lvm.lv=coso/lv_swap rd.dm=0 rhgb quiet initrd /initramfs-3.5.2-3.fc17.x86_64.img title Fedora (3.5.0-2.fc17.x86_64) root (hd0,5) kernel /vmlinuz-3.5.0-2.fc17.x86_64 rd.md=0 root=/dev/mapper/coso-lv_root KEYTABLE=us rd.lvm.lv=coso/lv_root SYSFONT=True rd.luks.uuid=luks-246d7283-2aea-4b0d-a577-07341d7511d6 LANG=en_US.UTF-8 ro rd.lvm.lv=coso/lv_swap rd.dm=0 rhgb quiet initrd /initramfs-3.5.0-2.fc17.x86_64.img title Fedora (3.4.6-2.fc17.x86_64) root (hd0,5) kernel /vmlinuz-3.4.6-2.fc17.x86_64 rd.md=0 root=/dev/mapper/coso-lv_root KEYTABLE=us rd.lvm.lv=coso/lv_root SYSFONT=True rd.luks.uuid=luks-246d7283-2aea-4b0d-a577-07341d7511d6 LANG=en_US.UTF-8 ro rd.lvm.lv=coso/lv_swap rd.dm=0 rhgb quiet initrd /initramfs-3.4.6-2.fc17.x86_64.img title Fedora (3.4.5-2.fc17.x86_64) root (hd0,5) kernel /vmlinuz-3.4.5-2.fc17.x86_64 rd.md=0 root=/dev/mapper/coso-lv_root KEYTABLE=us rd.lvm.lv=coso/lv_root SYSFONT=True rd.luks.uuid=luks-246d7283-2aea-4b0d-a577-07341d7511d6 LANG=en_US.UTF-8 ro rd.lvm.lv=coso/lv_swap rd.dm=0 rhgb quiet initrd /initramfs-3.4.5-2.fc17.x86_64.img
Oh, you're on a Mac. Kernel driver defaults to r/o for hfsplus, IIRC.
From a quick check of the grand wide internet, you either need to disable journaling on the MacOS side, or add 'force' to the mount options. I cannot speak myself as to the risks of either of those.
Can you please attach the output of dmesg?
Why is the EFI partition on the Mac hfs and not FAT? The Apple firmware can read hfs, sure, but the EFI partition is still FAT by default and this would just work fine. Why was it re-formatted?
Because it needs to be HFS+ to interoperate with OS X properly.
What? Why does Apple ship it by default as FAT then?
/boot/efi isn't the EFI System Partition on Macs.
And that's why? We install a second EFS?
Created attachment 636909 [details] dmesg output
The bootloader needs to be on HFS+ for seamless integration with the OS X startup preferences.
It's failing to mount read-write because it's been cleanly unmounted and hasn't been fscked. Do you have the hfsplus-tools package installed?
Yes. yum install -y hfsplus-tools Loaded plugins: langpacks, presto, refresh-packagekit Package hfsplus-tools-540.1.linux3-1.fc17.x86_64 already installed and latest version Nothing to do [bkoz@coso ~]# I guess the work around is boot into MacOS and turn off journaling as per #6
Turning off journaling on HFS+ volumes makes no difference, FYI Installing : kernel-3.6.5-1.fc17.x86_64 37/72 grubby fatal error: unable to find a suitable template
What does the following produce: umount /boot/efi fsck /boot/efi
[root@coso ~]# umount /boot/efi [root@coso ~]# fsck /boot/efi fsck from util-linux 2.21.2 ** /dev/sda5 Executing fsck_hfs (version 540.1-Linux). ** Checking non-journaled HFS Plus Volume. The volume name is untitled ** Checking extents overflow file. ** Checking catalog file. Keys out of order (4, 3) ** Rebuilding catalog B-tree. ** The volume untitled could not be repaired.
Ok. Your filesystem is corrupt, so it's unsurprising that it's not working.