This mail is an automated notification from the bugs tracker
of the project: GNU GRUB.
/**************************************************************************/
[bugs #8539] Latest Modifications:
Changes by:
Yoshinori K. Okuji <[EMAIL PROTECTED]>
'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: [EMAIL PROTECTED]
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&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/
_______________________________________________
Bug-grub mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-grub
