[bugs #8539] Allow use of grub-install in chrooted environment

[Yoshinori K. Okuji]

This mail is an automated notification from the bugs tracker
 of the project: GNU GRUB.

/**************************************************************************/
[bugs #8539] Latest Modifications:

Changes by: 
                Yoshinori K. Okuji <address@hidden>
'Date: 
                Thu 04/29/04 at 11:29 (GMT)

------------------ Additional Follow-up Comments ----------------------------
No, you are right. Your solution would be perfect, as
long as /etc/mtab is up-to-date.

But I still think the way in GRUB 2 is better, since it does not depend on 
/etc/mtab at all. So I will implement this feature in the grub shell and call 
it from grub-install instead of using df.

The only problem is that my time is too limited. I wish someone else would like 
to do this instead of me...

Okuji






/**************************************************************************/
[bugs #8539] Full Item Snapshot:

URL: <http://savannah.gnu.org/bugs/?func=detailitem&item_id=8539>
Project: GNU GRUB
Submitted by: 0
On: Sun 04/11/04 at 12:13

Category:  Installation
Severity:  Major
Priority:  5 - Normal
Item Group:  Feature Request
Resolution:  Works for me
Assigned to:  None
Originator Name:  Sven Vermeulen
Originator Email:  address@hidden
Status:  Open
Release:  0.94
Reproducibility:  Every Time
Planned Release:  


Summary:  Allow use of grub-install in chrooted environment

Original Submission:  Is it possible to allow grub-install to be used inside a 
chrooted environment? The main issue here is that grub-install requires a 
correct /etc/mtab which, in a chrooted environment, isn't 100% accurate. 

A possibility would be to have a --root-device=/dev/hda1 option (instead or 
supplementary to --root-directory). This way there is no need for querying 
/etc/mtab and can grub-install be safely used in a chrooted environment.

Follow-up Comments
------------------


-------------------------------------------------------
Date: Thu 04/29/04 at 11:29         By: okuji
No, you are right. Your solution would be perfect, as
long as /etc/mtab is up-to-date.

But I still think the way in GRUB 2 is better, since it does not depend on 
/etc/mtab at all. So I will implement this feature in the grub shell and call 
it from grub-install instead of using df.

The only problem is that my time is too limited. I wish someone else would like 
to do this instead of me...

Okuji

-------------------------------------------------------
Date: Wed 04/28/04 at 17:55         By: chjones
It certainly doesn't solve all problems, but I think it works as well as df 
alone, and better in some cases.  In the case you mentioned, find_device 
returns whatever device /dev/root links to for /boot, /boot/grub, and /;  df 
/{,boot{,/grub}} returns rootfs.  /dev/root is a symlink (on my machine, 
linking to /dev/ide/host0/bus0/target0/lun0/part2, which is handled by 
convert() ), but rootfs simply throws an error.

If you're worried about the returns of 'none' for subdirs of /dev, that throws 
an error in convert also;  since grub-install runs find_device on directories, 
not devices, this is not a problem.

Did I miss the problem?  If so, I apologize.  I agree this is far from an ideal 
solution, and that the code from GRUB2 seems pretty much perfect.  However, I 
was trying to avoid adding any requirements to grub-install;  if I'd used 
`cut', for instance, the patch would have been more readable---`mount' would 
have saved all the problems, but is far from portable.

-------------------------------------------------------
Date: Wed 04/28/04 at 11:36         By: okuji
Unfortunately, your patch does not work with Mandrake Linux 9.2, because df -P 
returns this:

Filesystem         1024-blocks      Used Available Capacity Mounted on
rootfs                38456308  30093524   6409284      83% /
/dev/root             38456308  30093524   6409284      83% /
none                  38456308  30093524   6409284      83% /dev
none                  38456308  30093524   6409284      83% /dev/pts

So, we need a different solution for this. I think the best way is to backport 
device detection code from GRUB 2. The algorithm is like this:

dev = getUnderlyingDevice(dir)
for file in getAllFiles('/dev')
  rdev = getDeviceNumber(file)
  if dev == rdev
    return file
error

This is wrriten in C in GRUB 2, but I think it is easy to implement this in a 
shell if we can use Perl or stat.

Okuji

-------------------------------------------------------
Date: Wed 04/28/04 at 08:08         By: chjones
Okay, so GNU df has some problems.  They've (just) been submitted as bugs to 
the coreutils developers.  Specifically, df <file> doesn't actually return the 
device <file> is on, it returns the first device that looks like it might be 
right.  Since grub-install uses df <dir> to determine what devices the root and 
boot directories are on, this can be a problem.  Though it here became apparent 
because you were chrooted, it would also have been a problem if, say, you'd 
mounted something at /mnt and then something else also at /mnt;  you'll see the 
second one, but df sees the first.

I've attached a patch for grub-install.  It's rather big and ugly, so feel free 
to not apply it to the tree.  (I won't be offended ;-) ).  It works, however, 
it's posix compliant, and, since it seems that df is the only utility that 
talks about mounted filesystems at all in the single unix specification, it's 
the only way of doing things I can come up with that should be portable.

(Sven, I should note that if you mount proc into a directory in the chroot, 
like /mnt/gentoo/proc, then chroot /mnt/gentoo, then copy---or even better, 
link---to /etc/mtab, you shouldn't have the problem with "real root 
paths"---the kernel and the proc filesystem have some sort of magic to fix 
that.  However, it *does* still show the actual / *first*, so that is what df 
reads and what causes problems.  Try it---it's kind of strange, twisted, and 
interesting.)

-------------------------------------------------------
Date: Wed 04/28/04 at 03:53         By: chjones
I think I may have tracked down (a big part of) the problem.  Could you run a 
quick test, if you have a usable system in which you can chroot?  Try this (the 
order is important)---
mkdir -p /mnt/gentoo
mount <gentoo chroot device> /mnt/gentoo
mkdir -p /mnt/gentoo/proc
mount proc /mnt/gentoo/proc -t proc
chroot /mnt/gentoo
cp /proc/mounts /etc/mtab
df /
Is the answer the <gentoo chroot device> above?  (My guess is no.  Is it 
'rootfs' or your main root device?)

-------------------------------------------------------
Date: Tue 04/27/04 at 21:17         By: okuji
Hmm, it sounds really difficult. What tool can you use in the chroot 
environment? Can you use Perl or stat, for example?

Okuji

-------------------------------------------------------
Date: Sun 04/25/04 at 18:01         By: None
Sadly, no. /proc/mounts uses the paths from the real root, not the chroot. For 
instance, if the boot partition is mounted under /mnt/gentoo/boot, then 
/proc/mounts contains /mnt/gentoo/boot, wheras /etc/mtab should read "/boot" 
(because we're chrooted inside /mnt/gentoo).

Wkr,
  Sven Vermeulen

-------------------------------------------------------
Date: Wed 04/21/04 at 11:13         By: okuji
Copying /proc/mounts to /etc/mtab suffices. Don't you agree?

Okuji

-------------------------------------------------------
Date: Sun 04/18/04 at 12:52         By: None
That's just how the installation for Gentoo itself is done, and I believe the 
same goes for LFS. Without chroot, running grub-install fails because it 
requires /sbin/grub. Users are not able to symlink /mnt/gentoo/sbin/grub to 
/sbin/grub as "/" is read-only (LiveCD) (and I don't know if this'll work 
anyway).

When writing my own /etc/mtab with a correct line for the /boot partition, 
running grub-install from within the chroot works. That's why I think it would 
be most beneficial to add this feature to grub-install so that others can use 
this too. Afaik, but this is of course an outsiders opinion, this doesn't 
affect the functionality of grub-install at all for the existing users.

My main motivation for having this as a feature request instead of just 
implementing a work-around for Gentoo is because I believe this feature can be 
used by others as well.

-------------------------------------------------------
Date: Mon 04/12/04 at 17:58         By: okuji
You haven't answered my question: why do you need to chroot?

Okuji






File Attachments
-------------------

-------------------------------------------------------
Date: Wed 04/28/04 at 08:08  Name: grub-install-dffix.patch  Size: 2KB   By: 
chjones
Patch to workaround problems with GNU df
http://savannah.gnu.org/bugs/download.php?item_id=8539&amp;item_file_id=1247






For detailed info, follow this link:
<http://savannah.gnu.org/bugs/?func=detailitem&item_id=8539>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/