grub menu contains "combinatorial expansion" of existing installations

Created an attachment (id=5018)
This is the result of the installer's work on the grub menu.

Hi,
Thank you for reporting this issue.

Does this problem still occur with the Dapper Beta installer?

I haven't looked at the Dapper betas, I'm afraid. Is there no official test system that could be used to check this?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

 subscribe

This bug affects me too and is present in dapper and in knot-1.
In the extreme case affecting me it causes the generation of a
350Kby menu.lst file containing >1k entries, which grub cannot boot.

This is a separate bug, Malone 54041, but it would probably be eaiser
to fix it here.

Ian.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFEx3qD8jyP9GfyNQARAtFYAJ9ayjAmHE6l/YyE9dEuWegAUE3hbwCfTBmO
571pG9motDMA74JpExyHYzY=
=Icg3
-----END PGP SIGNATURE-----

Come to think of it, can this bug cause existing installations to
become unbootable after a while ? Consider a machine with only two
installs, each of which runs update-grub occasionally.

Each time update-grub is run in install A, A's menu.list is made to be
twice the size of B's, and vice versa. So after running update-grub
five times in each install, in alternation, the menu.list will have
O(1000) entries (x the original three or so). We don't know when bug
54041 triggers.

Perhaps this bug should be `High' ?

Ian.

No, this bug isn't in update-grub, it's in the installer component that generates the initial menu.lst. update-grub only looks at kernels in its own installation.

Note that all the "(on /dev/blah)" entries are outside the "AUTOMAGIC KERNELS LIST" section, so update-grub considers them to be manually-maintained.

Colin Watson writes ("[Bug 26031] Re: grub menu contains "combinatorial expansion" of existing installations"):
> No, this bug isn't in update-grub, it's in the installer component that
> generates the initial menu.lst. update-grub only looks at kernels in its
> own installation.
>
> Note that all the "(on /dev/blah)" entries are outside the "AUTOMAGIC
> KERNELS LIST" section, so update-grub considers them to be manually-
> maintained.

So they are.

If we hadn't been in the habit of installing grub in the mbr then this
would be a much easier problem to solve: we could chain to the grub in
the other partition.

Ian.

Well, as for the importance of this bug, I suppose that people "expert" enough to want to have multiple installations probably should know how to edit grub menus, but I'm a bit disappointed that there have been two releases since Hoary without fixes for this. Had I had time, I would have attempted a Dapper install by now and would have seen this again, but surely this kind of testing shouldn't fall upon random end-users to test, especially since a review of the code would probably have revealed the cause. The big question is and was this: have we (or do we) test our installs alongside existing ones? If the answer is no, the testing process should be improved, because it's a pretty big omission, really.

Paul, we certainly do test this. I'm sorry you got bothered earlier with the question of whether this bug still existed in Dapper; I was certainly aware that it still existed and there was no need to ask you again about it. The reason I haven't considered it a high priority to fix is that it really only badly affects users who do lots and lots of consecutive installations in different partitions on the same machine; that's not to say I don't consider it a bug, just that I have many more urgent things to do. I will try to get to it at some point.

No problem, Colin! I just thought it was a bit embarrassing for Ubuntu, really.

I worked around this in os-prober recently. (Chaining to the other installations rather than copying their boot menu items, as Ian suggests, would still ultimately be better, but is more work to arrange.)

os-prober (1.20) unstable; urgency=low

  * Skip grub-installer's "(on /dev/blah)" entries detected in GRUB
    configuration files, as if they're useful they will probably be found by
    another probe, and detecting them can result in exponential growth of
    menu.lst files if you do repeated test installs on multiple partitions.
  * Use readlink -f in mapdevfs shim so that os-prober runs outside d-i
    handle mount-by-UUID correctly.
  * Use mktemp -d rather than /tmp, to make use outside d-i safer.
  * Merge from Ubuntu:
    - Try to install fs-core-modules and fs-secondary-modules udebs. These
      are specific to the Ubuntu kernel udeb layout, but it's fairly cheap
      to check for them as well and saves on divergence here.
    - Add os-probes/mounted/sparc/80solaris to recognize Solaris/SPARC
      (Fabio M. Di Nitto).
    - Add linux-boot-probes/mounted/sparc/50silo support (Fabio M. Di
      Nitto).
    - Try to load ufs module, for Solaris support (Fabio M. Di Nitto).
    - Tighten check for whether we're running in d-i; anna-install isn't
      quite enough because if you're running d-i code outside d-i it's
      sometimes reasonable to install a shim for anna-install.
  * Don't probe partitions mounted on /target/boot.
  * Teach linux-boot-prober to deal with mounted partitions correctly,
    unless they're mounted on /, /target, or /target/boot (LP: #14780). This
    should largely obsolete the --mounted option.
  * Only use /target/bin/mount if it exists, in order to work better outside
    d-i.

 -- Colin Watson <email address hidden> Thu, 26 Jul 2007 12:33:31 +0100