I'm incorporating my recent learning about linux and efi. I've found it quite important to have efivarfs mounted when doing something with the boot process. To keep from forgetting to mount it when i need it, I wanted to put it in /etc/fstab. Having it mounted doesn't seem to do anything to the system, but it's there if I need it.
I put it in my script to enter chroot this way: mount -vt efivarfs efivarfs $LFS/sys/firmware/efi/efivars And when I issue 'mount' with no options, one of the reports is: efivarfs on /sys/firmware/efi/efivars type efivarfs (rw,relatime) The kernel documentation says to mount it this way: mount -t efivarfs none /sys/firmware/efi/efivars I may have missed it, but I didn't see anything about the use of "none" in the mount man-page. I wonder if it's just the kernel document's author's way of saying "no options." If that's true, then I know that 'mount' will use the kernel defaults for mounting filesystems. In this case it appears to be "rw,relatime." There's no mention of the use of "none" in the /etc/fstab man page. But I've never seen an /etc/fstab entry without options. This is what I'm thinking would work for an /etc/fstab entry: efivarfs /sys/firmware/efi/efivars efivarfs rw, relatime 0 0 Comments? Approval? Musings? In trying to find an example /etc/fstab entry I ran across something really interesting that made me think of my work with grub and efi. There is a package for OpenSuse, Fedora, Debian and Ubuntu called efitools. The latest version is 1.4 and it's web page says "efitools-1.4 with linux key manipulation utilities released." Further reading indicates that this package will manipulate efi variables and further > mount -o efivarfs none /mnt (or some other useful mount point) > > As long as this is successful, you can now use the efi- tools to read > and write the secure variables. In order to write the variables in > User Mode, you must have the private part of the Platform and Key > Exchange Keys available. So, assuming your private part of the > platform key is PK.key, you can add your own KEK with > > efi-updatevar -a -c KEK.crt -k PK.key KEK > > And then add your own signature database key with > > efi-updatevar -a -c DB.crt -k KEK.key db > > Where KEK.crt and DB.crt are X509 certificates. > Of course, I don't understand the specifics of what's written, but I'm wondering if the reason I couldn't get my compiled version of grub to work in efi was that I couldn't read and write the secure variables. Gonna have to find out what an X509 certificate is. This is the link if anyone is interested: http://www.tuicool.com/articles/MR7zae Dan -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
