Re: Grub-install documentation or override?

[mgreger]

---- Andrei Borzenkov <address@hidden> wrote: 
> В Fri, 26 Jun 2015 17:03:27 +0000
> <address@hidden> пишет:
> 
> > > > 
> > > > It does not appear libdevmapper is a part of LFS.
> > > 
> > > Then no kpartx would be possible at all. Where do you think /dev/mapper
> > > devices come from?
> > >
> > 
> > 
> > I think you misunderstood.
> > kpartx is run from the host Debian system. It has the mapper but does not 
> > have grub. The LFS system has grub, but does not have libdevmapper.
> 
> Then use host Debian system to install grub. Why do you insist on doing
> it in chroot?
> 
> But I find it really hard to believe that any Linux distribution would
> not include LVM.
> 

The host system does not have grub and will not.
I just verified LFS does not contain LVM.

Maybe it would help to explain what this is for:

LFS is a nearly minimal linux that users compile from scratch. It isn't exactly 
a distro.
http://www.linuxfromscratch.org/lfs/view/stable/

As it is compiled entirely from source, you need a host system to build it on.

I am automating the build with the following goals:

   1) Not to add any additional dependencies into the LFS system itself beyond 
what is standard, so the LFS system uses GRUB but does not have LVM.
   2) To have minimal impact on the host system, so installing grub to the host 
if they don't have it is not an option.
   3) It needs to be able to be installed to an actual drive or to a disk 
image, at the choice of the end user.

The only part of this causing me pain is grub-install at the very end of the 
build.


> > 
> > 
> > 
> > >  I could be wrong, but I don't see it anywhere.
> > > > 
> > > > I don't understand why grub-install needs to find the partition 
> > > > /dev/mapper/loop0p1 at all. Surely all it needs to do is install to the 
> > > > MBR of /dev/loop0 and the embedded space before the first partition. 
> > > > Why would it need anything other than the device name /dev/loop0 ?
> > > > 
> > > 
> > > Because it needs to know which drivers are requires to access $prefix;
> > > whether $prefix is on the same drive as primary boot sector; which
> > > partition $prefix is in; etc etc etc
> > > 
> > 
> > I'm not sure exactly what you are referring to with $prefix.
> 
> Which is exactly why grub-install exist - to make it unnecessary for
> users to know what $prefix is and how to access it.
> 
> > Is there no way to manually tell grub that information, rather than have it 
> > try (unsuccessfully) to auto-detect it?
> > There should always be a way to manually override any kind of 
> > auto-detection logic, IMHO.
> > 
> 
> There is - to the extent. It is possible to use grub-mkimage and
> grub-bios-setup directly. But that also means you will be duplicating
> grub-install logic and need to know all low level details.
> 
> 

I think that grub-mkimage and grub-bios-setup might get me past the problem. Is 
there a place you can direct me to that has detailed explanations of the 
arguments they accept?

Or maybe suggest some arguments likely to work given the setup I've described?
Assume a BIOS system with one hard drive. It has an MBR and one ext4 partition 
containing root filesystem and a boot directory. The "hard drive" is on 
/dev/loop0 - but only during the install process.  From the LFS system's point 
of view, when it boots it will be booting from /dev/sda and the root filesystem 
will be on /dev/sda1.

Thanks again




> > 
> > > > Assuming libdevmapper is not an option, how could I bypass 
> > > > grub-install, also assuming my /boot/grub directory is empty at start?
> > > 
> > > Try partitioned loop - losetup -P ...
> > 
> > 
> > I've never heard of that option. I will see if it works.
> >