Dan McGhee wrote:
> I'm in the final stages of building and installing GRUB so that it works
> in an EFI environment. It's been quite interesting and I'm looking
> forward to sharing what I have done on this list. However, before I do
> that, I need to say that I'm not "quite" done yet. I still have not yet
> gotten my LFS build to boot, but am honing in on the solution.
>
> I have learned from my reading that some of the "problems" people
> encounter in trying to do this may be hardware related. Therefore, it's
> a distinct possibility that my experience and procedure may need to be
> modified when someone else wants to do the same thing. With that caveat,
> let me describe what I can and can't do and then pose my current questions.
>
> I can boot anything I want in "EFI Mode", except LFS-7.4, directly from
> booting or from a grub.cfg for a different linux system. What I haven't
> been able to do is boot something through what we may look at as GRUB's
> way--from the grub.cfg with entries as:
>
> set root='hdX, gptY'
> echo "Booting LFS-7.4......."
> linux /boot/vimluz*-lfs-7.4 ro
>
> To boot Ubuntu from the grub.cfg that I use for LFS-7.4, and vice versa,
> I must "chainload" it. This is the part that I do not know whether it's
> determined by firmware or my level of knowledge. If it's the latter,
> I'll get it figured out sooner or later. And just for the record, I
> have not as yet gotten a kernel to boot using its efi-stubs--but it was
> my LFS-7.4 kernel which may not be bootable. Now I'd like comments on my
> understanding of the boot process.
>
> GRUB starts and looks for it's config file. It executes video and font
> commands and loads the kernel. The kernel then mounts the file system
> as "read only" and runs fsck. Then it mounts the file system in
> "read,write" and goes through its sequence then hands off to the rc.init
> functions. Is this correct so far?
Let me take it one step at a time:
> GRUB starts and looks for it's config file.
Yes
> It executes video and font commands
This are optional
> and loads the kernel.
Yes and optionally initrd
> The kernel then mounts the file system as "read only" and runs fsck.
I'm not sure about the fsck. It really doesn't do any good if it's read
only. Normally we umount completely to do fsck and it checks the
device, not the mount point.
We do specify ro on the kernel command line, so I think
the default is to mount / as rw.
> Then it mounts the file system in "read,write"
This isn't done in LFS until running S40mountfs in the boot sequence.
> and goes through its sequence then hands off to the rc.init
> functions.
The kernel normally just executes /sbin/init unless something else is
specified on the command line and init takes it from there. See the
kernel code at init/main.c around line 844:
if (!run_init_process("/sbin/init") ||
!run_init_process("/etc/init") ||
!run_init_process("/bin/init") ||
!run_init_process("/bin/sh"))
...
> If this is correct, shouldn't I see something from the kernel almost
> immediately after I see "Booting LFS-7.4....."
Yes, kernel messages.
> When I start getting
> those pretty green "OK's," or the Ubuntu splash screen, then I know that
> SysVinit has taken over.
I don't know about the Ubuntu splash screen. I think it uses upstart
and that is yet another boot process, but the kernel process starts with
initializing data structures, critical system devices (clock, memory
controller, etc) and the drivers needed for disk and console IO. Read
/etc/rc.d/init.d/rc to see how the other init scripts are called. It's
really not very difficult to understand.
> What has happened in trying to go from the LFS-menu to boot Ubuntu or
> Ubuntu-menu to boot LFS, using GRUB's way, I get a blank screen and must
> do a "hard reset." This happens when grub.cfg is in /boot/grub or on
> the EFI partition at EFI/lfs-7.4/grub. Thinking that since this is
> "before" the filesystem gets mounted, GRUB doesn't have the geometry to
> know where /boot/grub/grub.cfg is, I made a grub image that looked for
> its config file in same directory as the image and used this as
> grub.cfg--this is the way Ubuntu does it:
>
> search.fs_uuid [UUID for /dev/sda6] root hd0,gpt6
> set prefix=($root)/boot/grub
> configfile $prefix/grub.cfg
This is where I don't know how GRUB handles efi. For it to find the
kernel it want to load, you should be able to drop to the GRUB command
line and type
ls (hd0,gpt6)/boot
> When this booted, I got the grub shell. I entered what I thought were
> appropriate commands and got the message: No suitable video mode found,
> booting in blind mode--and then nothing else. Then I went to bed.
The only thing that should be needed from the command line is:
linux (hd0,gpt6)/boot/linux-version root=/dev/sda6 ro
boot
> Since I got that message, I'm guessing that GRUB hadn't found
> /dev/sda6/boot/grub/grub.cfg yet. When I ran <ls> in the grub shell, I
> got listing for the top level of my partition. I still don't know if
> my kernel is bootable, but, since I can't "get in to or out of" the LFS
> partition with /boot/grub/grub.cfg for either Ubuntu or LFS, I'm
> wondering if there's a problem with my partition.
I suspect it's OK.
> The other thing I
> have discovered is that in an EFI environment efivarfs must be mounted
> to manipultate the efi variables. I don't think I built grub before I
> learned that. So rebuilding it is my next step.
>
> But in the meantime, here's the command I used to make the image:
>
> grub-mkimage -O x86_64-efi -o grubx64.efi -p "" part_gpt fat ext2 normal
> chain boot configfile linux multiboot
I'm not sure why you want --prefix=''. I think you want /efi/boot.
Have you seen http://wiki.osdev.org/GRUB#Grub_for_EFI ?
> Does anyone see any more modules that I need?
From the above, I think grubx64.efi is not significantly space limited
and you can add all modules to the image.
-- Bruce
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
