[Bug 185878] Re: GRUB installation fails if installing to certain non-ext3 filesystems

[Launchpad Bug Tracker]

** Branch linked: lp:ubuntu/grub

[Launchpad Bug Tracker]

** Branch linked: lp:ubuntu/hardy-updates/grub

[Steve Langasek]

I've gone ahead and applied this patch to the hardy grub and uploaded to
hardy-proposed. Waiting for SRU processing now.

** Changed in: grub (Ubuntu Hardy)
Status: Triaged => In Progress

** Changed in: grub (Ubuntu Hardy)
Assignee: Colin Watson (cjwatson) => Steve Langasek (vorlon)

[Martin Pitt]

Accepted grub into hardy-proposed, the package will build now and be
available in a few hours. Please test and give feedback here. See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to
enable and use -proposed. Thank you in advance!

** Changed in: grub (Ubuntu Hardy)
Status: In Progress => Fix Committed

** Tags added: verification-needed

[Launchpad Bug Tracker]

** Branch linked: lp:ubuntu/hardy-proposed/grub

[Bela Lubkin]

Martin & Colin,

I've analyzed a performance problem in `grub-probe` on my Karmic system,
in grub2, and found that it was caused by repeated BLKFLSBUF ioctls.
Each call takes about .5 second and the overall probe does the ioctl
dozens of times. Of course both of those factors will be different on
each system, but in general I would expect them to be worse -- this
system has 2.5GHz QC CPU, 4GiB memory, only one disk and only 2 OS
partitions -- it could be _much_ worse.

grub needs to close and reopen the disk device, or (more easily) use

the BLKFLSBUF ioctl.

In my grub2 `strace grub-probe` output, every single open() of a disk
device was followed by a close() of that device before any other disk
devices were accessed. In fact, it so happened that fd #4 was used
every for every single read from a whole-disk or partition device, so
clearly there was no overlap of open times.

Due to this problem, each OS update which changes anything to do with
grub (e.g. grub2 updates, but also kernel updates [which trigger a grub
rescan & initrd rebuild]) takes many minutes to complete. Karmic has
what appear to be dozens if not hundreds of duplicate bug reports about
grub install failing -- many with error codes indicating a user
interrupt. I take these to mean that the grub update is taking so long
that the user manually aborts it, then raises a bug about the abort!

I have not tested your grub1 PPA (or grub1 at all). I just wanted to
alert you to this: _if_, during the process of scanning, it ends up
doing a lot of BLKFLSBUF ioctls, it will have this problem. I suspect
that the alternative solution of always making sure one has closed
whole-disk devices before opening partition devices & vice-versa, won't
have this performance problem.

I'm going to email this same comment to the Debian 362028 tracker
(assuming it will receive email from a random email address...)

[Bela Lubkin]

Oh, I should also mention that when I [binary] patched the `grub-probe`
binary to skip the BLKFLSBUF ioctls, everything else was _MUCH_ faster.
Transcript:

# export TIME="%e real %U user %S sys"
# for what in fs fs_uuid drive device partmap; do

/usr/bin/time /usr/sbin/grub-probe --device /dev/sda3 --target=$what
done

ext2
9.19 real 0.00 user 0.15 sys
4f0c55b5-6bc6-40a4-b239-f0918b84d57c
10.89 real 0.00 user 0.21 sys
(hd0,3)
2.05 real 0.00 user 0.02 sys
/dev/sda3
2.18 real 0.00 user 0.01 sys
part_msdos
2.66 real 0.00 user 0.05 sys
# for what in fs fs_uuid drive device partmap; do

/usr/bin/time /tmp/grub-probe --device /dev/sda3 --target=$what
done

ext2
0.03 real 0.00 user 0.00 sys
4f0c55b5-6bc6-40a4-b239-f0918b84d57c
0.00 real 0.00 user 0.00 sys
(hd0,3)
0.00 real 0.00 user 0.00 sys
/dev/sda3
0.00 real 0.00 user 0.00 sys
part_msdos
0.00 real 0.00 user 0.00 sys
# mount | grep sda3
/dev/sda3 on / type ext4 (rw,errors=remount-ro)
# diff -up <(objdump -d /usr/sbin/grub-probe) <(objdump -d /tmp/grub-probe)
--- /dev/fd/63 2009-12-11 14:21:05.687644648 -0800
+++ /dev/fd/62 2009-12-11 14:21:05.696688380 -0800
@@ -1,5 +1,5 @@

-/usr/sbin/grub-probe: file format elf64-x86-64
+/tmp/grub-probe: file format elf64-x86-64


Disassembly of section .init:
@@ -1480,7 +1480,7 @@ Disassembly of section .text:
402807: 0f 88 5e 02 00 00 js 402a6b <fflush at plt+0x13c3>
40280d: 31 d2 xor %edx,%edx
40280f: 89 c7 mov %eax,%edi
- 402811: be 61 12 00 00 mov $0x1261,%esi
+ 402811: be 5e 12 00 00 mov $0x125e,%esi
402816: 31 c0 xor %eax,%eax
402818: e8 8b eb ff ff callq 4013a8 <ioctl at plt>
40281d: 85 db test %ebx,%ebx

# grep x12.9[47] /usr/src/linux-headers-`uname -r`/include/linux/fs.h
#define BLKROGET _IO(0x12,94) /* get read-only status (0 = read_write) */
#define BLKFLSBUF _IO(0x12,97) /* flush buffer cache */

[Steve Langasek]

I've posted a test case now that documents how to verify this fix for
8.04.4. Can someone please confirm that this fixes the problem?

Bela, I would suggest filing a separate bug report for the performance
regression you describe - which I don't think should block us from
including this update this in 8.04.4, since grub-probe's performance has
fairly little impact on the behavior of the running system.

** Description changed:

Just like Bug #14010 but not just for JFS.

GRUB will fail to install during setup when it is being installed to a
partition (as opposed to a boot sector) formatted as anything but
ext2/3fs, including JFS and ReiserFS.
+
+ TEST CASE:
+ 1. use the ubuntu 8.04.3 alternate installer in expert mode to configure your root filesystem as JFS
+ 2. tell grub to install to the root partition instead of to the disk.
+ 3. confirm that grub installation fails.
+ 4. use the ubuntu 8.04.4 alternate installer candidate in expert mode to configure your root filesystem as JFS
+ 5. tell grub to install to the root partition instead of to the disk.
+ 6. verify that grub installation succeeds.

** Description changed:

Just like Bug #14010 but not just for JFS.

GRUB will fail to install during setup when it is being installed to a
partition (as opposed to a boot sector) formatted as anything but
ext2/3fs, including JFS and ReiserFS.

TEST CASE:
1. use the ubuntu 8.04.3 alternate installer in expert mode to configure your root filesystem as JFS
2. tell grub to install to the root partition instead of to the disk.
3. confirm that grub installation fails.
- 4. use the ubuntu 8.04.4 alternate installer candidate in expert mode to configure your root filesystem as JFS
- 5. tell grub to install to the root partition instead of to the disk.
- 6. verify that grub installation succeeds.
+ 4. download the ubuntu 8.04.4 alternate installer candidate from http://cdimage.ubuntu.com/hardy/daily/current/
+ 5. use the 8.04.4 candidate in expert mode to configure your root filesystem as JFS
+ 6. tell grub to install to the root partition instead of to the disk.
+ 67. verify that grub installation succeeds.

[Dave Morley]

Colin fix failed.

On 20100121.2 the cd still fails to install grub. Syslog attached

** Attachment added: "syslog"
http://launchpadlibrarian.net/38189663/syslog

[Dave Morley]

** Attachment added: "partman"
http://launchpadlibrarian.net/38189674/partman

[Steve Langasek]

Dave,

The above syslog doesn't match the test case. It shows a grub install
to the disk instead of the partition ("(hd0)"), and says that /boot is
XFS - please test with JFS.

[Colin Watson]

XFS is a special case, known to be broken in hardy for other and more
complicated reasons, but fixed in jaunty. See bug 8058.

[Dave Morley]

** Attachment added: "syslog"
http://launchpadlibrarian.net/38191210/syslog

[Dave Morley]

** Attachment added: "partman"
http://launchpadlibrarian.net/38191213/partman

[Colin Watson]

Dave's previous attempt (comments 34/35) broke because he had / on
/dev/sda6 but was attempting to install to the nonexistent (hd0,0)
(a.k.a. /dev/sda1). I then had an attempt that failed due to the
problem fixed in http://bazaar.launchpad.net/~ubuntu-core-dev/grub-
installer/ubuntu/revision/833 (not a regression; but note that you need
to explicitly mark a partition as bootable in the partitioner when
performing this test). Dave then had an attempt that failed because he
had a former installation on the same disk which of course
(intentionally) didn't have its boot loader removed from the MBR.

Once we got past all those roadblocks, though, both of us appear to have
working installations now.

[Dave Morley]

Just a confirmation on the above I have a booting system and all
hardware has been recognised and is functioning as expected :)

[Colin Watson]

** Tags added: verification-done
** Tags removed: verification-needed

[Launchpad Bug Tracker]

This bug was fixed in the package grub - 0.97-29ubuntu21.2

---------------
grub (0.97-29ubuntu21.2) hardy-proposed; urgency=low

[ Colin Watson ]
* cache_coherency.diff: Flush buffer cache on disk devices after writing
to any partition devices they contain, otherwise we may read old data
back (LP: #185878).
-- Steve Langasek <steve.langasek at ubuntu.com> Wed, 09 Dec 2009 19:13:19 -0800

** Changed in: grub (Ubuntu Hardy)
Status: Fix Committed => Fix Released

[Neil Plucknett]

Trying to install on my PC - that is already running Win-7. I added a 160 Gb drive to take Ubuntu ("Bionic Beaver) and elected to install the software here - /dev/sdd - and the boot partition is the existing 750 Gb boot drive for Windows 7 - /dev/sda - as I want a dual boot system for the time being at least.
Installer failed on the last step saying grub could not be installed to the / filesystem.
--
You received this bug notification because you are a member of Kubuntu
Bugs, which is subscribed to a duplicate bug report (20914).
https://bugs.launchpad.net/bugs/185878

Title:
GRUB installation fails if installing to certain non-ext3 filesystems

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/grub/+bug/185878/+subscriptions

[peter b]

- I have on sda winXP AND on sdb WIN10 and 16.04
- 18.04 sits/installed on sdf

- did you try/change in BIOS your sdd to be the FIRST BOOT DEVICE/HDD?

- my system/described above boots/works flawlessly - grub sees and boots
all 4 OS's.

- pls take a look at

https://askubuntu.com/questions/226061/how-to-install-the-boot-repair-tool-in-an-ubuntu-live-disc
https://www.howtogeek.com/114884/how-to-repair-grub2-when-ubuntu-wont-boot/
--
You received this bug notification because you are a member of Kubuntu
Bugs, which is subscribed to a duplicate bug report (20914).
https://bugs.launchpad.net/bugs/185878

Title:
GRUB installation fails if installing to certain non-ext3 filesystems

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/grub/+bug/185878/+subscriptions