GRUB 2 Feature Requests
- 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.
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!
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
- 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.
- Mouse support for the user interface.
- NTFS File System support/capabilities (If so possible).
- 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)
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.
- 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.
- To support reiser4 filesystem
- gcc compiler to compile grub2 and reiser4 in AMD64 mode.
- 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)