GRUB 2 Feature Requests
- I'd like to see the GRUB 2 menu simplified. GRUB 2 will often be people's first impression of Linux and things like "/dev/sda6/" and "memtest86+" will freak them out. What I'd like to see:
- By default, no "memtest86+" or recovery items
- But add an option to press e.g. "F" at startup for full menus with recovery, memtest, partition, etc.
- By default, don't report the partition,just the OS, release, and kernel. For example "Ubuntu 10.04 (kernel 2.6.32-23)", "Microsoft Windows XP Professional".
Modifying the menu this way is doable, using the instructions at http://ubuntuforums.org/showthread.php?t=1287602 and https://help.ubuntu.com/community/Grub2, but it's complicated and requires some understanding of shell scripting. It could be simplified by adding options to /etc/default/grub. Just as you can now hide the recovery option, you should be able to hide memtests from /etc/default/grub. Options could be added to set menus to minimal ("Ubuntu 10.04"), basic ("Ubuntu 10.04 (kernel 2.6.32-23)" and full "Ubuntu 10.04 with 2.6.32-23-generic on /dev/sda6". If just /etc/default/grub is the only file that needs to be edited in order to set the most important options, it would be a lot easier for inexperienced users to do so. It would also make it easier to update startup manager to provide a gui to set these options
- Add support to install GRUB 2 MBR portion to loop-mounted disk-files to support offline upgrade/installation of GRUB 2. While one can utilize mount and chroot to drive the installation of GRUB 2 into the /boot/grub of a given disk-file, the grub-setup command currently only wants to work with BIOS-detected devices in /dev. One can currently install/upgrade the MBR portion of the original GRUB in an offline fashion by using "device (hd0) /dev/loop#" with "setup (hd0)".
- Option to check signatures of the bootchain upto the cryptsetup/luksOpen: MBR, grub partition, kernel, initramfs. (Usefull option for a rescue boot medium (possibly a read only CDR) to check the HDD bootchain.) If signatures are to complex, just save some copies to compare and repair with.
- Distribute with a grub menu option to create/setup a floppy or USB Stick etc. as a alternate (rescue/checksum checking) boot device.
- If the MBR or bootchain is corrupted (i.e. MBR gets altered or overwritten): It would be nice to be able to boot grub core.img, as well as chainload into the grub partition (always install to partition, too, since most other bootmanagers support chainloading another partition) and have a grub menu options to simply reinstall the bootchain's MBR, partition bootsector, etc. (No need to boot a full emergency system, mount, chroot, grub-install etc.) Can be a scripted menu entry.
Add support for harddisks with Windows encrypted with TrueCrypt.
Filesystem creation support grub-mkfs rationale
- Booting ISO 9660 filesystem images from within supported partition types. // Sorry, as far I noticed this should be possible to do with loopback command. If so, please delete this request. Thanks.
- Yes, this is possible with a loopback. This is, however, a kind of FAQ. The bottleneck is not GRUB but the OS. You must think how to specify a root filesystem to the kernel. So this kind of request should be sent to, say, the Linux kernel developers rather than to us.
what about the suggested solution inhere? It works independently from the requested OS and thus more GRUB way, doesn't it? And the advantages become quite obvious once in use: you can have a few ISO files hanging around and boot them w/o having to burn them on CD, just selecting them at boot time from the menu. So many liveCDs out there to be tested or even used without messing with the partitions'setting. Just the good sides from both worlds : flexibility of the liveDistros and speed of the installed ones... plus here: the choice.
- Though I know about the Qemu like emulators (and use quite a lot indeed) they do not let you run the whole PC. With such a solution as ISO-from-GRUB the entire PC power is for the booted OS.
Hence, once implemented into Grub, no extra tricky tweaks (like loopbacks or isoemu) to get things running, extended possibilities (the ISO files could be on any accessible fs -why not within another ISO?-) from the GRUB start. -> Raise your hands!
- This proposition assumes that OS uses BIOS to access CD. This assumptions is false except for OSes like DOS
The ability to boot an El Torito CD by skipping the BIOS and using a standalone El Torito stack directly with GRUB. There is a solution to this problem (see the link below), but it's messy and smart boot manager is no longer being worked on. http://www.lrz-muenchen.de/~bernhard/grub-chain-cd.html
- Mouse support for the user interface.
- extensive online help - GRUB could remember the location of extensive online help files
- simple html browser as loadable module (for reading the extensive online help files)
- IMO PDF parser is easier to implement and is more useful
- compile grub2 in AMD64 mode.
- ultra flexible
- bootable from any media
- booting any media
media can be IDE, (e)SATA, Network, USB, FireWire, CD, Floppy, etc.
- booting _from_ any operating system (such as Windows, Linux, DOS)
have a look at grub4dos
- it can be booted from DOS (grub.exe), Linux (kexec), Windows (bootmenu)
- Can chainload DOS, Win9x, WinNT directly(!). Directly means chainloading the operating system specific system files such as ntldr, kernel.sys, io.sys, bootmgr. (Grub legacy has only indirect chainloading, chainloading of the master/volume boot record.)
- can boot CD-ROM even if the BIOS has no support to boot CD-ROM
- can emulate floppy images or iso images as a floppy or CD-ROM right at boot time and boot the virtual device
- frequently releases
Able to read/write GPIO lines in embedded devices [UseCases/GPIO]
- Enable user to configure and use alternate keyboard keys. Some computers/devices (such as Tablet PCs) have additional keyboard buttons that user may want to use to control boot menu. In case of Tablet PC, the user may want to use both standard keyboard buttons (arrows/enter) and alternate keys (such as bezel buttons) at the same time.
- NT Kernel Driver for virtual CD-ROM's created by GRUB
mr: Same as for "Linux Kernel Driver for virtual CD-ROM's created by GRUB", but for NT-based operating systems.
- This is very, very simple but should add to the experience: Allow booting of default item instantly without outputting any text, almost like NTLDR was booting something (At least I think NTLDR doesn't output anything)
- Make it possible to easily set in GRUB configuration file not to ignore the hidden menu in case of detecting multiple operating systems
Completed and invalid GRUB 2 Feature Requests
- The implementation of the "map" command from GRUB Legacy, or an adequate replacement for booting OSes which cannot be told that their HD is no longer the first (i.e. Windows XP)
- done by Javier MartÃn
Telnet access to the console - Access the grub menu remotely via TCP/IP. Grub would grab an IP using DHCP as it does now when using the --enable-<netcardname> option or the IP could be setup using the ifconfig option. You could then telnet to it and interace with it as if you were at the console.
- duplicate
- To support reiser4 filesystem
- duplicate
- Encrypted filesystem support!
- With it, the tedious "need to have the kernel unencrypted on a separate partition when doing crypto-root" problem goes away.
- Plus, it's much more secure to have the kernel on the crypted partition as well! For example, on a multi-boot system, a trojan
- on Windows could install itself into a Linux kernel on the unencrypted partition and monitor all the encrypted data the next time Linux runs. This wouldn't be possible if the kernel was encrypted as well.
- It just needs to be merged
- Linux Kernel Driver for virtual devices (harddisks, CD-ROM's or floppy) created by GRUB
mr: grub2 and grub4dos may load an iso and boot it, the initial booting phase in real mode will work just well, that's why all DOS-based iso's work perfect. But after the kernel is switching in protected mode and trying to find the correct driver he will fail. That's the big shame that initial booting is working but later stopping.
mr: In order to fix this you could program an a Linux Kernel Driver to fix this issue. After that's done any linux-based iso could be booted without problems.
mr: If you are not willing to do this please don't tell users to ask for this on the kernel developers mailing list. (I've posted it once but due to high traffic this message got spammed out.) This issue is _very hard_ to explain to someone who wasn't aware of the possibility to boot iso's directly. I would be glad if some more technical guy could ask for it in a way the idea is getting understood.
mr: I don't expect the kernel developers to create such a driver, if there is no action from grub2 developers I guess it will never happen.
VladimirSerbinenko: You don't need such a driver. Just add loopback mounting to your script. Look at e.g. wubi
mr: It's pretty unlikely that developers of linux distros implement loopback support because of the again this issue is to hard to explain.
mr: Using the original GRUB boot device and loopback would require the Linux Kernel to have a working driver for the original GRUB boot device. The Linux Kernel Driver for virtual devices would be a generic solution. It does no longer matter if the BIOS-supported boot device is also supported by the Linux Kernel or not because it just needs to overtake the ramdisk no matter which the original GRUB boot device was.
VladimirSerbinenko:if all you want is ramdisk then what's wrong with not unmounting initrd? If you want redirecting to grub_read then you may suffer performance hit. If you want to continue this discussion use mailing list
- A command tool (grub-set-temp) for 'one-time only' boot entry change, for new kernel testing reason on a remote server.
- grub.conf we has this line: default 0
- and run: grub-set-temp 1
- and reboot, grub should boot with entry 1 insteaded of the default value 0.
- But no matter boot entry 1 crash or succeed, when the machine reboot/reset(for crash case, almost remote reset), grub should choose boot entry 0 as grub.conf recorded later.
- This feature is very useful because there are too much Linux server that need recompile kernel source, and test if that work fine. When server hung, remote reboot is easy, but a boot time keyboard action will bother IDC guy, and maybe come with charge.
- Already doable in scripts with loadenv/saveenv
- a useful command to display what GRUB knows about the world
- A frustrating experience it was after an upgrade to Fedora 5 upon first boot to be dumped into the GRUB command line. This had never been used before and the help command just revealed commands to do something, not to show anything, so one could decide which commands to use. Searching the net on another PC, just revealed a lot of happy hackers showing exotic commands to do exotic things, but did not help much in solving the actual problem: to boot the server which for years had booted without problems without GRUB. Problem still not solved, but /boot/grub/menu.lst was set up correctly. displaymem and displayapm are useless.
- "ls" already does what is asked here
get rid of the stages.
Please elaborate. GRUB 2 already do not feature similar stage1 and stage2 system as is within GRUB Legacy. - The whole thing with stage1 and stage2 is completely unnecessary. Look at grub4dos. It has simply the bootcode either in Master Boot Record or in Volume Boot Record(only needed when getting chainloaded) and grldr on any partition with an supported filesystem.
- Ability to read the BIOS date and time in Grub prior to presenting the boot selection menu. Together with scripting support this would allow to decide on the boot options based on the date (e.g., boot linux on weekends and windows Monday through Friday).
This should be already possible with the combination of Hiddenmenu and echo date before the sleep command.
Setting default variable based on date/time is possible with datehook.mod. This should maybe documented.