MaverickCDBoot
|
Size: 2596
Comment:
|
Size: 7448
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| ## page was renamed from FoundationsTeam/Specs/MaverickCDBook | |
| Line 5: | Line 6: |
| * '''Contributors''': * '''Packages affected''': |
* '''Contributors''': ColinWatson, ScottJamesRemnant, LukeYelavich, ... * '''Packages affected''': `grub2`, `debian-installer`, `ubuntu-cdimage`, `usb-creator` |
| Line 10: | Line 11: |
| This should provide an overview of the issue/functionality/change proposed here. Focus here on what will actually be DONE, summarising that so that other people don't have to read the whole spec. See also CategorySpec for examples. | GRUB should now support booting from CDs reliably, and its new graphical menu system was designed partly with the aim of being able to implement our CD menus. If successful, this would be easier to maintain than gfxboot. |
| Line 14: | Line 15: |
| 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. |
Ubuntu CDs now use the GRUB 2 boot loader. The CD boot menu interface has been redesigned. |
| Line 20: | Line 19: |
| This should cover the _why_: why is this change being proposed, what justifies it, where we see this justified. | Current Ubuntu CDs use ISOLINUX, with the gfxboot extensions from SuSE implementing graphical menus. |
| Line 22: | Line 21: |
| == User stories == | This has proven to be rather difficult to maintain, with only one person in Ubuntu who understands the theming code involved (which is actually rather more than what one would normally expect from a theme: the underlying language only provides primitive operations, and the theme needs to implement everything from the widget layer on up). Since we are now using GRUB 2 everywhere else on x86, and since GRUB 2 recently had graphical menu support added to it upstream, moving to that has the potential to reduce our maintenance load. It seems likely that we will need to use GRUB 2 anyway in order to support EFI, and having to configure two different boot loaders on our CDs would be undesirable. |
| Line 24: | Line 23: |
| == Assumptions == | Using GRUB will also permit us to take advantage of UbuntuSpec:foundations-m-grub2-boot-framebuffer, using a better video mode and transitioning the display smoothly to Plymouth. |
| Line 28: | Line 27: |
| You can have subsections that better describe specific parts of the issue. | At the time of writing, we have an image created using `grub-mkrescue` with the addition of a [[http://www2.apebox.org/wordpress/linux/228/|theme produced by Jo Shields]]. Basic boot menu support is working. However, GRUB's gfxmenu code currently lacks support for the additional menus we use in our CD boot loader, and we also have a custom facility to display a splash screen before the main boot menu which bypasses the boot menu if a key is not pressed within a certain amount of time. |
| Line 30: | Line 29: |
| == Implementation == | Adding these facilities in gfxmenu will probably increase its size by a moderate amount; but gfxmenu is already a module, and is already too big to fit into the MBR embedding region, so the next plausible limit on its size will be bigger than we need to worry about. |
| Line 32: | Line 31: |
| This section should describe a plan of action (the "how") to implement the changes discussed. Could include subsections like: | === Splash screen === |
| Line 34: | Line 33: |
| === UI Changes === | It should be possible to hook a splash screen into the existing hidden-timeout code. |
| Line 36: | Line 35: |
| Should cover changes required to the UI, or specific UI that is required to implement this | === Menu structure === |
| Line 38: | Line 37: |
| === Code Changes === | In `gfxboot-theme-ubuntu`, the menus are typically as follows: |
| Line 40: | Line 39: |
| Code changes should include an overview of what needs to change, and in some cases even the specific details. | * F1: Help * F2: Language * F3: Keymap * F4: Modes * F5: Accessibility * F6: Other Options |
| Line 42: | Line 46: |
| === Migration === | We do not need to provide all these features in precisely the same form, so it's worth looking at the underlying requirements of each menu. |
| Line 44: | Line 48: |
| Include: * data migration, if any * redirects from old URLs to new ones, if any * how users will be pointed to the new way of doing things, if necessary. |
* F1: Help This is not a priority. Many of the text in the help system is quite outdated anyway, and our focus on working out of the box has meant that fewer and fewer people need to apply the workarounds suggested for certain situations there. If users need to read help to operate the boot loader at all, then we're Doing It Wrong. However, F1 is widely understood as a help key, so we will not reuse it for other purposes. * F2: Language The boot loader displays human-readable text, and there is no opportunity to configure the language beforehand in the CD case, so language selection is important. It needs to be possible to preset the language when building the CD. * F3: Keymap Text entry is possible in the boot loader (boot parameters) so keymap configuration is quite important, although secondary to language configuration in the event that we run low on time. * F4: Modes The Modes menu logically forms a submenu off each main boot menu item for things such as OEM mode, so it would probably be clearer to implement it as such rather than using a function-key menu. The list of modes available at any point depends on the selected main boot menu item. * F5: Accessibility Users of this menu often need to operate it without the benefit of sight, so it is important that it be present and keyboard-accessible. We will probably need to preserve the same general form and particularly the same keystrokes as are currently implemented in `gfxboot-theme-ubuntu`. Note that GRUB supports playing sounds, which we've never been able to make work in ISOLINUX/gfxboot. This should allow us to provide an audible indication that the boot menu is ready for input. * F6: Other Options This is a list of options with checkbox semantics, corresponding to entries that are appended to the boot parameters list. With a little work in GRUB, we could probably render it more attractively and clearly than we do in gfxboot at the moment. (Suggestion: set variables when options are selected, and then we could simply substitute a variable into the command line.) In gfxboot, F6 also provides the ability to edit the boot parameters directly; GRUB has other facilities for this already, so we do not need to associate the two. === New gfxmenu facilities === [Note that all of this is subject to discussion with upstream.] We will clearly need to be able to define a menu bar, with keys bound to particular menus. Rendering of each menu is up for discussion, although there are often more entries than will fit vertically on the screen (particularly in the case of the language menu), and so we will need either a scrolling menu or a grid; the latter may be easier to use. The menu entry names should of course be configurable. To implement the actions associated with each menu, the simplest approach would seem to be to bind a function to be called when an entry is selected. This could set variables for substitution into the boot parameters, as well as more sophisticated actions such as changing the keyboard map. The F6 menu will require checkbox widgets. === CD changes and other issues === We will need to run GRUB code as the images are built, which is likely to be tricky; we may have to fish the necessary pieces out of .debs in the archive, or, more plausibly, have the `debian-installer` build process build appropriate GRUB images for us. To start with, we will only tackle this for BIOS-based systems, as handling EFI as well will require care due to mutual conflicts between `grub-pc` and `grub-efi-*`. `usb-creator` will need to detect whether the ISO image it is copying to the USB stick contains GRUB or ISOLINUX, and install the appropriate boot loader to the stick. In order to support running `usb-creator` in non-Ubuntu environments where it is difficult to change the GRUB image in use, the GRUB image on the CD will need to contain the union of all modules necessary to boot from either CD or USB. We should review the BIOS workarounds present in ISOLINUX and GRUB, and check whether any additional hacks need to be ported over to GRUB. |
| Line 51: | Line 102: |
| 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. | We will prepare small test images for wide testing (including in our certification laboratory) before committing to this change. After that, everyone will be testing it! |
| Line 53: | Line 104: |
| This need not be added or completed until the specification is nearing beta. | == References == |
| Line 55: | Line 106: |
| == Unresolved issues == This should highlight any issues that should be addressed in further specifications, and not problems with the specification itself; since any specification with problems cannot be approved. == BoF agenda and discussion == Use this section to take notes during the BoF; if you keep it in the approved spec, use it for summarising what was discussed and note any options that were rejected. |
* [[http://grub.enbug.org/ThemeFormat|GRUB theme format documentation]] |
Launchpad Entry: foundations-m-cd-boot
Created: 3 May 2010
Contributors: ColinWatson, ScottJamesRemnant, LukeYelavich, ...
Packages affected: grub2, debian-installer, ubuntu-cdimage, usb-creator
Summary
GRUB should now support booting from CDs reliably, and its new graphical menu system was designed partly with the aim of being able to implement our CD menus. If successful, this would be easier to maintain than gfxboot.
Release Note
Ubuntu CDs now use the GRUB 2 boot loader. The CD boot menu interface has been redesigned.
Rationale
Current Ubuntu CDs use ISOLINUX, with the gfxboot extensions from SuSE implementing graphical menus.
This has proven to be rather difficult to maintain, with only one person in Ubuntu who understands the theming code involved (which is actually rather more than what one would normally expect from a theme: the underlying language only provides primitive operations, and the theme needs to implement everything from the widget layer on up). Since we are now using GRUB 2 everywhere else on x86, and since GRUB 2 recently had graphical menu support added to it upstream, moving to that has the potential to reduce our maintenance load. It seems likely that we will need to use GRUB 2 anyway in order to support EFI, and having to configure two different boot loaders on our CDs would be undesirable.
Using GRUB will also permit us to take advantage of foundations-m-grub2-boot-framebuffer, using a better video mode and transitioning the display smoothly to Plymouth.
Design
At the time of writing, we have an image created using grub-mkrescue with the addition of a theme produced by Jo Shields. Basic boot menu support is working. However, GRUB's gfxmenu code currently lacks support for the additional menus we use in our CD boot loader, and we also have a custom facility to display a splash screen before the main boot menu which bypasses the boot menu if a key is not pressed within a certain amount of time.
Adding these facilities in gfxmenu will probably increase its size by a moderate amount; but gfxmenu is already a module, and is already too big to fit into the MBR embedding region, so the next plausible limit on its size will be bigger than we need to worry about.
Splash screen
It should be possible to hook a splash screen into the existing hidden-timeout code.
Menu structure
In gfxboot-theme-ubuntu, the menus are typically as follows:
- F1: Help
- F2: Language
- F3: Keymap
- F4: Modes
- F5: Accessibility
- F6: Other Options
We do not need to provide all these features in precisely the same form, so it's worth looking at the underlying requirements of each menu.
- F1: Help
- This is not a priority. Many of the text in the help system is quite outdated anyway, and our focus on working out of the box has meant that fewer and fewer people need to apply the workarounds suggested for certain situations there. If users need to read help to operate the boot loader at all, then we're Doing It Wrong. However, F1 is widely understood as a help key, so we will not reuse it for other purposes.
- F2: Language
- The boot loader displays human-readable text, and there is no opportunity to configure the language beforehand in the CD case, so language selection is important. It needs to be possible to preset the language when building the CD.
- F3: Keymap
- Text entry is possible in the boot loader (boot parameters) so keymap configuration is quite important, although secondary to language configuration in the event that we run low on time.
- F4: Modes
- The Modes menu logically forms a submenu off each main boot menu item for things such as OEM mode, so it would probably be clearer to implement it as such rather than using a function-key menu. The list of modes available at any point depends on the selected main boot menu item.
- F5: Accessibility
Users of this menu often need to operate it without the benefit of sight, so it is important that it be present and keyboard-accessible. We will probably need to preserve the same general form and particularly the same keystrokes as are currently implemented in gfxboot-theme-ubuntu. Note that GRUB supports playing sounds, which we've never been able to make work in ISOLINUX/gfxboot. This should allow us to provide an audible indication that the boot menu is ready for input.
- F6: Other Options
- This is a list of options with checkbox semantics, corresponding to entries that are appended to the boot parameters list. With a little work in GRUB, we could probably render it more attractively and clearly than we do in gfxboot at the moment. (Suggestion: set variables when options are selected, and then we could simply substitute a variable into the command line.) In gfxboot, F6 also provides the ability to edit the boot parameters directly; GRUB has other facilities for this already, so we do not need to associate the two.
New gfxmenu facilities
[Note that all of this is subject to discussion with upstream.]
We will clearly need to be able to define a menu bar, with keys bound to particular menus. Rendering of each menu is up for discussion, although there are often more entries than will fit vertically on the screen (particularly in the case of the language menu), and so we will need either a scrolling menu or a grid; the latter may be easier to use. The menu entry names should of course be configurable.
To implement the actions associated with each menu, the simplest approach would seem to be to bind a function to be called when an entry is selected. This could set variables for substitution into the boot parameters, as well as more sophisticated actions such as changing the keyboard map.
The F6 menu will require checkbox widgets.
CD changes and other issues
We will need to run GRUB code as the images are built, which is likely to be tricky; we may have to fish the necessary pieces out of .debs in the archive, or, more plausibly, have the debian-installer build process build appropriate GRUB images for us. To start with, we will only tackle this for BIOS-based systems, as handling EFI as well will require care due to mutual conflicts between grub-pc and grub-efi-*.
usb-creator will need to detect whether the ISO image it is copying to the USB stick contains GRUB or ISOLINUX, and install the appropriate boot loader to the stick. In order to support running usb-creator in non-Ubuntu environments where it is difficult to change the GRUB image in use, the GRUB image on the CD will need to contain the union of all modules necessary to boot from either CD or USB.
We should review the BIOS workarounds present in ISOLINUX and GRUB, and check whether any additional hacks need to be ported over to GRUB.
Test/Demo Plan
We will prepare small test images for wide testing (including in our certification laboratory) before committing to this change. After that, everyone will be testing it!
References
FoundationsTeam/Specs/MaverickCDBoot (last edited 2010-09-29 17:13:42 by 99-156-85-10)