X-Git-Url: https://code.delx.au/refind/blobdiff_plain/a8046e5f1429d856cfaa202e2271c7db5b6a106f..2eb4a9ca3c35a44bb35b7a0998ff036797a8580e:/NEWS.txt diff --git a/NEWS.txt b/NEWS.txt index 259b03e..6519380 100644 --- a/NEWS.txt +++ b/NEWS.txt @@ -1,10 +1,113 @@ -0.2.6 (?/??/2012): +0.3.1 (?/??/2012): +------------------ + +- Modified loader scanning code to sort boot loader entries within a + directory by modification time, so that the most recently-modified loader + is first among those in a given directory. Thus, if you specify a + directory name (or volume name, for loaders stored in the root directory + of a volume) as the default_selection, the most recent of those loaders + will be the default. This is intended to help with Linux kernel + maintenance when using the EFI stub loader; set up this way, the most + recent kernel copied to your kernel directory will be the default, + obviating the need to adjust the refind.conf file when adding a new + kernel. If you want to change the default among those in the default + directory, you can use "touch" to adjust the modification timestamp. + +- Tweaked code to find loader-specific .icns file so that it finds files + for Linux kernels without .efi extensions. In this case, files should be + named the same as the kernels they match, but with .icns extensions. For + instance, bzImage-3.3.2 should have an icon called bzImage-3.3.2.icns. + (The old code would have looked for an icon called bzImage-3.3.icns.) + +- Eliminated bogus OS loader tags for filenames that end in ".icns" when + the scan_all_linux_kernels option is set. + +0.3.0 (4/22/2012): +------------------ + +- I'm officially upgrading this project's status from "alpha" to "beta" and + giving it a bump from 0.2.x to 0.3.0. This doesn't reflect any major + milestone with this version; rather, it reflects my sense that rEFInd has + been "out there" for a while, and although I've gotten bug reports, + they've been minor and/or have been fixed. The program still has known + bugs, but my impression is that it is, overall, usable by ordinary users. + +- Added "resolution" option to refind.conf, which enables setting the video + resolution. To use it, pass two numeric values, as in "resolution 1024 + 768" to use a 1024x768 video mode. Note that not all modes are supported. + If you specify a non-supported video mode on a UEFI system, a message + appears listing the supported video modes and you must then press a key + to continue, using the default video mode (usually 800x600). + Unfortunately, I don't know the calls to get a list of supported video + modes on older EFI 1.x systems (including Macs), so on Macs setting an + incorrect video mode silently fails (you keep using the default mode). + This makes changing your video mode a hit-or-miss proposition on Macs. + CAUTION: It's possible to set a legal video mode that your monitor can't + handle, in which case you'll get a blank display until you boot an OS + that resets the video mode. + +- Fixed (maybe) a bug that caused rEFInd to crash when returning from an + EFI shell or other programs on Macs, particularly when rEFInd used + graphical mode. I'm not 100% sure this bug is squashed because I still + don't understand the cause and I only have one Mac for testing. See + comments in the ReinitRefitLib() function in refit/lib.c for more + details. + +- Added new refind.conf option: scan_all_linux_kernels, which causes Linux + kernels that lack ".efi" extensions to be included in scans for EFI boot + loaders. This may help integration with Linux distributions that don't + give their kernels such names by default. Beware, though: It can detect + unwanted files, such as older non-stub-loader kernels or .icns files used + to give kernels with .efi extensions custom icons. + +- Improved EFI boot loader detection on boards with Gigabyte's Hybrid EFI, + and perhaps other EFIs with a buggy StriCmp() function. Files with both + ".efi" and ".EFI" extensions should now be detected as boot loaders. + +- Fixed a bug that caused rEFInd to fail to scan for drivers if the + filesystem driver didn't set a volume name (that is, if the relevant + field was set to NULL rather than even an empty string). In such + situations, rEFInd now reports the volume name as "Unknown". + +0.2.7 (4/19/2012): +------------------ + +- After much trial and tribulation, I've overcome a GNU-EFI limitation and + enabled rEFInd to load EFI drivers. This feature was present in the + original build of rEFIt but was removed in the versions that could + compile under Linux, but now it's back -- and still being compiled under + Linux! To use it, you should place your drivers in a convenient directory + on the ESP (or whatever partition you use to launch rEFInd) and add a + "scan_driver_dirs" entry to refind.conf to tell rEFInd where to look. (As + always, you should specify the driver directory relative to the root of + the filesystem.) Note that you can't launch drivers from another + filesystem; they must be on the same volume that holds rEFInd. Those who + compile from source code should note that implementing this feature + necessitated using a more recent version of the GNU-EFI library. I'm + currently using version 3.0p, and version 3.0i does NOT work. I don't + know where the change occurred, but you may need to upgrade your GNU-EFI + installation. + +- Fixed bug that caused rEFInd to show up in its own menu sometimes. + +- Added new refind.conf token: also_scan_dirs. When scanning volumes for + EFI boot loaders, rEFInd always scans the root directory and every + subdirectory of the /EFI directory, but it doesn't recurse into these + directories. The also_scan_dirs token adds more directories to the scan + list. It defaults to "elilo,boot", but you can set it to any directory or + directories you like. + +0.2.6 (4/14/2012): ------------------ - Added "volume" keyword to configuration file's stanza options. This option changes the volume from which subsequent files (specified by "loader" and "icon") are loaded. You pass "volume" the name/label of the - FILESYSTEM you want to use (not the GPT partition name). + FILESYSTEM you want to use (not the GPT partition name), or a number + followed by a colon (e.g., "1:"). The former should reliably identify a + filesystem, assuming the name is unique. The latter assigns numbers based + on the order in which they're scanned, which may not be as reliable but + should work when a volume is unnamed. - Fixed bug in 0.2.5 that caused failure of Linux initial RAM disk mapping on some (but not all) systems. Affected computers include at