Release Engineering


FS#13277 - /sbin/grub-install hardcoded root-directory

Attached to Project: Release Engineering
Opened by Dieter Plaetinck (Dieter_be) - Saturday, 14 February 2009, 18:29 GMT
Last edited by Gerhard Brauer (GerBra) - Thursday, 23 July 2009, 10:04 GMT
Task Type Bug Report
Category AIF
Status Closed
Assigned To Aaron Griffin (phrakture)
Gerhard Brauer (GerBra)
Dieter Plaetinck (Dieter_be)
Architecture All
Severity Low
Priority Normal
Reported Version 2009.02-RC
Due in Version 2009.08-alpha
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


when /arch/setup was changed from /sbin/grub to /sbin/grub-install
(;a=commitdiff;h=4565577dbd2182dd49612f1e0b68288f5573bf7b )
You use --root-directory=$DESTDIR
in the code a bit higher (look for "# look for a separately-mounted /boot partition
" in;a=blob_plain;f=setup;hb=HEAD we do some effort to set $bootpart by looking for a mounted '/boot', using the root partition or just asking the user. In the old days we used that variable, but now we don't.

So, shouldn't we use --root-directory=$bootpart?

Edit: no wait.. $bootpart is a partition, they want a directory.
Maybe we *should* stick to --root-directory=$DESTDIR, but just drop the code related to $bootpart, there is no more need for the "try to detect where it is or just ask the user"-code, because we always know where it is ($DESTDIR), right?
This task depends upon

Closed by  Gerhard Brauer (GerBra)
Thursday, 23 July 2009, 10:04 GMT
Reason for closing:  Won't fix
Additional comments about closing:  We don't use arch-installer anymore. New grub related reports and infos are in the last comment.
Comment by Aaron Griffin (phrakture) - Saturday, 14 February 2009, 23:20 GMT
I was under the impression that --root-directory was used simply to look for the grub files in the system. If we ensure that $bootpart is mounted to $DESTDIR/boot then this isn't a problem, right?
Comment by Dieter Plaetinck (Dieter_be) - Saturday, 14 February 2009, 23:55 GMT
If we ensure that $bootpart is mounted to $DESTDIR/boot what's the point of this block of code? (eg, we can remove it imho)
# look for a separately-mounted /boot partition
bootpart=$(mount | grep $DESTDIR/boot | cut -d' ' -f 1)
if [ "$bootpart" = "" ]; then
if [ "$PART_ROOT" = "" ]; then
DIALOG --inputbox "Enter the full path to your root device" 8 65 "/dev/sda3" 2>$ANSWER || return 1
bootpart=$(cat $ANSWER)
And what about this one?
DIALOG --defaultno --yesno "Do you have your system installed on software raid?\nAnswer 'YES' to install grub to another hard disk." 0 0
if [ $? -eq 0 ]; then
DIALOG --menu "Please select the boot partition device, this cannot be autodetected!\nPlease redo grub installation for all partitions you need it!" 14 55 7 $DEVS 2>$ANSWER || return 1
bootpart=$(cat $ANSWER)

We don't do anything with $bootpart anymore, so all code to set and check it becomes unneeded.
Comment by Dieter Plaetinck (Dieter_be) - Sunday, 22 February 2009, 19:36 GMT
Gerhard/Aaron, can't we remove the 2 code blocks mentioned above then?
Comment by Aaron Griffin (phrakture) - Monday, 23 February 2009, 18:39 GMT
I'm not sure - the first looks redundant (assuming our autodetection of these things has gotten better over time), but the second one (RAID related) looks iffy.
Comment by Dieter Plaetinck (Dieter_be) - Monday, 23 February 2009, 20:37 GMT
Look at it this way: both clode blocks are only used to set $bootpart.
But $bootpart is not used anywhere anymore since;a=commitdiff;h=4565577dbd2182dd49612f1e0b68288f5573bf7b
Comment by Aaron Griffin (phrakture) - Tuesday, 24 February 2009, 21:02 GMT
Well then I vote for the removal :)
Comment by Gerhard Brauer (GerBra) - Thursday, 26 February 2009, 11:57 GMT
We should keep the possibility for raid users to install grub also on the other harddisks in the array (esp. for raid0/raid1 arrays).

Also we should recheck why the switch to grub-install was needed. I have done this change in 12/2008 (but with the same grub version as we use it now in core). With the old method (/sbin/grub instead of grub-install) i got reproducable boot errors on ext4 root/boot partitions. But grub-install is "only" a wrapper script for /sbin/grub. And after all i see no real difference on the parameters for /sbin/grub if we call it with grub-install. But grub-install work - /sbin/grub -foo- bar not.
grub-install writes a temp logfile which is removed after execution, this could be changed when edit the grub-install script.

So further we should check (when aif code is solid for grub): Do we still need with current software versions this way with grub-install (do we gain or loss features when using the wrapper script) or could/should we maybe switch back to /sbin/grub.
Comment by Dieter Plaetinck (Dieter_be) - Saturday, 28 February 2009, 21:12 GMT
Gerhard, is there a bug report or something for that problem? And what exactly is the problem? I found but it don't understand exactly..
Also i tried with AIF: ext4 / and ext2 /boot, and once with ext4 /boot and those work both fine (though I test in virtualbox, in the thread you seem to mention there is a difference between VM and real system?)
Comment by Gerhard Brauer (GerBra) - Sunday, 01 March 2009, 16:25 GMT
Dieter, the link you mentioned was testing with grub2, and so also my expierience that there is a difference between VMs and real hardware. This was all for grub2...

The problem with grub-0.97-15 was in 12/2008 (the date from the commit):
method /sbin/grub in installer code doesn't work. It gets installed but a ext4 / or /boot partition could not be bootet after finished installation in virtualbox.

But changing to /sbin/grub-install (the wrapper script, there is also another method install-grub <g>) solved it in 12/2008. Therefor the commit, and this code also make it's way to 2009.02. I have no plan why the wrapper methode works - and our old (using the grub shell directly) don't.
So i mean: If we writing the code piece for aif we should check: what methods for calling/installing grub works (or not) with our current versions of software (we have a new glibc for ex.). Maybe we don't have to stuck with grub-install...

And the raid part: Anyway which method of calling/installing the grub bootloader - it should be still possible to install the bootloader also on the other disks of an raid1 for example...
Comment by Dieter Plaetinck (Dieter_be) - Sunday, 01 March 2009, 16:51 GMT
Yes I agree we should always present the user the option to install grub on whichever device he chooses. But just note that since the "fix/workaround/patch" of 12/2008, we do not use the variable $bootpart anymore. Hence the two codeblocks I mentioned above are useless in their current state. We do pass $ROOTDEV to /sbin/grub-install, which is set at line 1060 (;a=blob;f=setup;h=b18c17f02cbc74e9e6523462574217bafaf1726b;hb=80ca34643e1c3db5ac5bbc856590ae44b559a6a1#l1060 )

In fact, both $bootpart and $ROOTDEV seem to basically be the same (it's one of $DEVS, see line 1060 and 1082) Since we already ask at line 1060, is there any reason we ask the same question again at line 1082 ?

As long as we keep the question at line 1060, that covers any case (including raid), right?

And for the reason we switched to /sbin/grub-install: I can only say that with aif (which still uses the old method) I tried an ext4 /boot and an ext4 / with ext2 /boot, and both cases worked fine for me (in virtualbox!)
How exactly could you reproduce the errors? Could you consistently reproduce the errors on a virtual machine (vbox?) I want to know this, so my tests are not "in the dark" :)

Comment by Gerhard Brauer (GerBra) - Sunday, 01 March 2009, 17:25 GMT
This part (grub installation) should be completely rewritten IMHO. I think the raid stuff is useless in the current version :-(

The error in old installer with "old methode" was: grub menu appears correctly but the ext4 system (neither /boot nor /) could not be booted. I don't remember the exact error, maybe it was something what we fixed later with ex. glibc. But in 12/2008 switching to grub-install works, so it was the solution for me that time. I agree to recheck "the old methode" again (you say it works for you), we have to look on what methode we benefit the most.
Comment by Dieter Plaetinck (Dieter_be) - Saturday, 11 July 2009, 15:28 GMT
we have to find out how much of this is still an issue for the new release (eg @grub softraid menu)
Comment by Gerhard Brauer (GerBra) - Thursday, 23 July 2009, 09:19 GMT
I will close this report soon, cause we don't use arch-installer anymore and aif handle grub install now with interacting with grub directly instead grub-install.
Nevertheless is will then open a new report mainly for the softraid part (i am working on that).
Comment by Gerhard Brauer (GerBra) - Thursday, 23 July 2009, 10:03 GMT
Ok, we have these 2 reports for grub related things in aif now:
 FS#13945  (long term refactor)
 FS#15652  (for special raid(1) setup)
Closing this report.