Launchpad Entry: grub2-by-default
Packages affected: grub, grub2, grub-installer
Make GRUB2 available as an option in the installer, to enable us to get hard data about whether GRUB2 is suitable for use as a default in a later release.
This section should include a paragraph describing the end-user impact of this change. It is meant to be included in the release notes of the first release in which it is implemented. (Not all of these will actually be included in the release notes, at the release manager's discretion; but writing them is a useful exercise.)
It is mandatory.
There is no longer any upstream for GRUB1, and we're carrying a significant set of patches against this package. There are also a number of feature enhancements that are unlikely to ever be implemented with the current code base, but that we get for free by switching to GRUB2:
- menu.lst has inherent problems that we've hedged on using ucf, but we can't solve without a switch to a new syntax - GRUB2 provides that
- grub2 has l10n support, required by some OEMs in a number of markets
The kernel team has expressed concern that there is no good information about the hardware compatibility of GRUB2. We should therefore make it available as a (non-default) option in the installer for jaunty and solicit feedback from users, in order to be able to make an informed decision about using this as the default bootloader in a future release.
- GRUB upstream will move towards a "1.0" release of grub2, which will serve as the reference point for future use as a default bootloader.
- there will be no major architecture changes for GRUB2 between now and the 1.0 release.
- the configuration file format is stable and should not change, as asserted by upstream.
- GRUB2 will not be included on any CD images for jaunty, due to space considerations; it will only be available for installation to users who can download it from the network.
- grub2 is 1.3M+96K (.deb sizes). grub-common will be needed on the CDs anyway for jaunty to support XFS, but the grub-pc package probably won't fit.
- GRUB2 will be made available as a non-default bootloader option (either via preseeding or a lower debconf priority) for testing in the jaunty release.
- GRUB2 will not be shipped on the CDs themselves, but instead downloaded from the network on request.
- In order to gain confidence about GRUB2's hardware support, information will be gathered via the Ubuntu HW db.
- The HW db will be extended to report the boot loader (grub1 or 2) so that we can measure how many systems are running it
- HW enablement lab will be used for GRUB2 testing
UDS participants could all install GRUB2 next UDS
grub-installer must be verified to make GRUB2 available as an option while by default not prompting the user for this
- GRUB2 compatibility with the current patches for UUID handling in GRUB1 must be ascertained.
kernel upgrades call update-grub to update the list of kernels, which is provided by both the grub and the grub-pc packages. As a result, grub-pc conflicts with grub, so the two bootloader packages are not co-installable. The grub-pc package also has support for calling a copy of the legacy update-grub, but it grabs this from the Debian svn tree so this won't work on Ubuntu; this should be replaced with an updated copy from Ubuntu, or grub-pc should use diversions instead.
- there's a later upstream snapshot in Debian experimental which we may want to update to; however, this is not a requirement for this spec.
While grub-pc provides a script that can be used to migrate the active bootloader from GRUB1 to GRUB2, it fails to capture any of the configuration settings users may have specified in their existing menu.lst. For this reason, we do not recommend migration of existing systems as part of this spec, only new installs.
It's important that we are able to test new features, and demonstrate them to users. Use this section to describe a short plan that anybody can follow that demonstrates the feature is working. This can then be used during testing, and to show off after release. Please add an entry to http://testcases.qa.ubuntu.com/Coverage/NewFeatures for tracking test coverage.
This need not be added or completed until the specification is nearing beta.
- It is currently unknown whether GRUB2 provides feature parity with GRUB1, or what the upstream resources are for bringing feature parity where it is absent.
- GRUB1 may be getting a patch for "fast resume", to allow resume from hibernate bypassing the initramfs. This patch would need to be ported separately to GRUB2.
- are LVM and RAID supported upstream in GRUB2 right now, and what is upstream's committment to implementing them if not?
- password support?
- GRUB2 should eventually also be used by default on EFI systems. These systems are not handled by GRUB1 today, so this is out of scope for the present spec.
- We need to set the threshold where we consider GRUB2 acceptable for deployment as the default.