From: srs5694 Date: Sun, 29 Apr 2012 20:13:57 +0000 (-0400) Subject: Improved BIOS-bootable detection code X-Git-Url: https://code.delx.au/refind/commitdiff_plain/b7734df2ccc0b0e943a8ce2c1f6d25e76e78e6f8 Improved BIOS-bootable detection code --- diff --git a/BUILDING.txt b/BUILDING.txt index 1c48099..3dcad8d 100644 --- a/BUILDING.txt +++ b/BUILDING.txt @@ -103,6 +103,17 @@ remove "local" from those paths, and perhaps change references to "lib" to out-of-date GNU-EFI implementations that will not work with rEFInd 0.2.7 and later. +When I tried to compile rEFInd under Ubuntu 12.04 (i386), even with a +locally-compiled GNU-EFI 3.0p, I got errors like this: + +main.o: In function `StartLegacy.isra.0': +main.c:(.text+0x8b1): undefined reference to `__stack_chk_fail_local' +lib.o: In function `ScanVolumeBootcode.part.3': +lib.c:(.text+0xf2f): undefined reference to `__stack_chk_fail_local' +lib.o: In function `ScanExtendedPartition.isra.4': + +The solution was to recompile GNU-EFI 3.0p with the -fno-stack-protector +GCC flag. In GNU-EFI, this can be added to the CFLAGS line in Make.common. Installing rEFInd ================= diff --git a/Make.common b/Make.common index 3f6f85f..edfe460 100644 --- a/Make.common +++ b/Make.common @@ -15,7 +15,7 @@ CPPFLAGS = -I$(EFIINC) -I$(EFIINC)/$(ARCH) -I$(EFIINC)/protocol -DCONFIG_ OPTIMFLAGS = -O2 -fno-strict-aliasing DEBUGFLAGS = -Wall -CFLAGS = $(ARCH3264) $(OPTIMFLAGS) -fpic -fshort-wchar $(DEBUGFLAGS) +CFLAGS = $(ARCH3264) $(OPTIMFLAGS) -fno-stack-protector -fpic -fshort-wchar $(DEBUGFLAGS) ASFLAGS = $(ARCH3264) LDFLAGS = -nostdlib -znocombreloc diff --git a/NEWS.txt b/NEWS.txt index 8805b75..173d904 100644 --- a/NEWS.txt +++ b/NEWS.txt @@ -1,3 +1,13 @@ +0.3.2 (?/??/2012): +------------------ + +- Added detection "recipe" for GRUB 2's BIOS Boot Partition. + +- Fixed bogus detection of ESPs created by Linux's mkdosfs utility or + Windows as bootable partitions when "scanfor" includes BIOS scanning + options. + + 0.3.1 (4/27/2012): ------------------ diff --git a/docs/refind/drivers.html b/docs/refind/drivers.html index 6d1a4be..40ee0e5 100644 --- a/docs/refind/drivers.html +++ b/docs/refind/drivers.html @@ -112,7 +112,7 @@ href="mailto:rodsmith@rodsbooks.com">rodsmith@rodsbooks.com

To the best of my knowledge, the best reason to want EFI driver support in rEFInd is to provide access to filesystems. Although EFI filesystem driver choices are currently limited, those that are available can help to improve your installation and configuration options, particularly if you've found yourself "boxed in" by awkward installation or bugs, such as the dinky ESP that Ubuntu creates by default or the bug that prevents a Linux kernel with EFI stub loader support from booting from the ESP of at least some Macs.

-

As a side note, using the ISO-9660 driver might help you keep the size of a custom Linux boot CD/DVD down to a reasonable value. This is because EFI systems normally boot from optical discs by reading a FAT image file in El Torito format and treating that file as an ESP. If you need to store the kernel both in that file and directly in the ISO-9660 filesystem (to maintain bootability on BIOS systems), that can represent an unwanted extra space requirement. Placing rEFInd and an ISO-9660 driver in the FAT image file should enable you to store the kernel on the disc only once. Note, however, that this is theoretical; I've not yet tried creating a bootable disc in this way. Also, some EFI implementations include ISO-9660 drivers, so you might not need a separate ISO-9660 driver if you're building a disc for a particular computer.

+

As a side note, using an ISO-9660 driver can theoretically help you keep the size of a custom Linux boot CD/DVD down to a reasonable value. This is because EFI systems normally boot from optical discs by reading a FAT image file in El Torito format and treating that file as an ESP. If you need to store the kernel both in that file and directly in the ISO-9660 filesystem (to maintain bootability on BIOS systems), that can represent an unwanted extra space requirement. Placing rEFInd and an ISO-9660 driver in the FAT image file should enable you to store the kernel on the disc only once. Unfortunately, my attempts to get this to work have failed to date. When the ISO-9660 driver is loaded from the El Torito image, my test systems seem to allow only one of the two filesystems (the El Torito image's FAT filesystem or the optical disc's ISO-9660 filesystem) to be active; load one and the other goes away. Also, some EFI implementations include ISO-9660 drivers, so you might not need a separate ISO-9660 driver if you're building a disc for a particular computer.

Finding and Installing EFI Drivers

@@ -122,7 +122,7 @@ href="mailto:rodsmith@rodsbooks.com">rodsmith@rodsbooks.com

  • rEFIt's ext2fs and ReiserFS drivers—You can gain read-only access to ext2fs, ext3fs, and ReiserFS volumes with these drivers. You can use the binaries in the refit-bin-0.14/efi/tools/drivers directory of the binary package directly on a Mac. On a UEFI-based PC, though, you'll need to break the Mac-style "fat" binary into its 32- and 64-bit components. You can use my thin program for this job.
    • -
  • Clover EFI's ISO-9660, ext2fs, and HFS+ drivers—This project is an offshoot of TianoCore, the main UEFI project. It's primarily a Hackintosh boot loader, but it includes drivers for ISO-9660, ext2fs, and HFS+; however, building them requires a fair amount of expertise. You can find a compile script for the ISO-9660 driver here, and a compiled ISO-9660 binary here. I haven't yet tested the compiled binary, much less tried to compile the source code.
    • +
  • Clover EFI's ISO-9660, ext2fs, and HFS+ drivers—This project is an offshoot of TianoCore, the main UEFI project. It's primarily a Hackintosh boot loader, but it includes drivers for ISO-9660, ext2fs, and HFS+; however, building them requires a fair amount of expertise. You can find a compile script for the ISO-9660 driver here, and a compiled ISO-9660 binary here. The compiled binary has worked in a brief test; however, it didn't give access to the ISO-9660 filesystem when it was loaded from an El Torito image the ISO-9660 filesystem held.
  • Clover's EFI Tools package—This osx86.net thread includes links to a package called EFI_Tools_Clover_v2_r384_EFI_x32_x64_EN.zip, which holds an OS X application (a directory with a .app extension, as seen from other platforms) with a number of drivers in the Contents/Resources/EFI/drivers64 directory (and an equivalent for 32-bit binaries). Some of these, such as keyboard drivers, are unlikely to be useful unless your system is badly broken as delivered. Three that caught my eye, however, are VBoxExt2-64.efi, NTFS-64.efi, and VBoxIso9600-64.efi.
    • @@ -132,7 +132,7 @@ href="mailto:rodsmith@rodsbooks.com">rodsmith@rodsbooks.com

    Most of these cross-project drivers appear to be related. For instance, the ISO-9660 drivers are both based on code written by Christoph Phisterer for rEFIt (although he doesn't seem to have finished and released it in binary form himself).

    -

    As you can see, pickings are rather slim. Nonetheless, they are useful for certain purposes. The options could increase in the future, too. Source code to a wide variety of filesystems is available in GRUB Legacy, GRUB 2, Linux, various BSD kernels, and in other projects. Sooner or later somebody's likely to begin porting those drivers to EFI. If you do so, or if you know of additional EFI drivers, please tell me about it, so I can share the information here. Likewise if you know of a source for other EFI drivers—say, for a video card or disk controller card.

    +

    As you can see, pickings are rather slim. Nonetheless, the drivers that exist are useful for certain purposes. The options could increase in the future, too. Source code to a wide variety of filesystems is available in GRUB Legacy, GRUB 2, Linux, various BSD kernels, and in other projects. Sooner or later somebody's likely to begin porting those drivers to EFI. If you do so, or if you know of additional EFI drivers, please tell me about it, so I can share the information here. Likewise if you know of a source for other EFI drivers—say, for a video card or disk controller card.

    Warning: Do not place EFI program files in your driver directories! Unfortunately, EFI uses the same .efi filename extension to identify both EFI program files and EFI drivers. Therefore, rEFInd can't distinguish between the two prior to loading them, and if you place program files in a drivers directory, rEFInd will run the EFI program file when it does its driver scan.

    diff --git a/refind/lib.c b/refind/lib.c index fde385f..c7c5734 100644 --- a/refind/lib.c +++ b/refind/lib.c @@ -366,6 +366,14 @@ static VOID ScanVolumeBootcode(IN OUT REFIT_VOLUME *Volume, OUT BOOLEAN *Bootabl Volume->OSIconName = L"grub,linux"; Volume->OSName = L"Linux"; + // GRUB in BIOS boot partition: + } else if (FindMem(SectorBuffer, 512, "Geom\0Read\0 Error", 16) >= 0) { + Volume->HasBootCode = TRUE; + Volume->OSIconName = L"grub,linux"; + Volume->OSName = L"Linux"; + Volume->VolName = L"BIOS Boot Partition"; + *Bootable = TRUE; + } else if ((*((UINT32 *)(SectorBuffer + 502)) == 0 && *((UINT32 *)(SectorBuffer + 506)) == 50000 && *((UINT16 *)(SectorBuffer + 510)) == 0xaa55) || @@ -435,7 +443,16 @@ static VOID ScanVolumeBootcode(IN OUT REFIT_VOLUME *Volume, OUT BOOLEAN *Bootabl Volume->OSName, Volume->OSIconName); #endif - if (FindMem(SectorBuffer, 512, "Non-system disk", 15) >= 0) // dummy FAT boot sector + // dummy FAT boot sector (created by OS X's newfs_msdos) + if (FindMem(SectorBuffer, 512, "Non-system disk", 15) >= 0) + Volume->HasBootCode = FALSE; + + // dummy FAT boot sector (created by Linux's mkdosfs) + if (FindMem(SectorBuffer, 512, "This is not a bootable disk", 27) >= 0) + Volume->HasBootCode = FALSE; + + // dummy FAT boot sector (created by Windows) + if (FindMem(SectorBuffer, 512, "Press any key to restart", 24) >= 0) Volume->HasBootCode = FALSE; // check for MBR partition table @@ -461,7 +478,7 @@ static VOID ScanVolumeBootcode(IN OUT REFIT_VOLUME *Volume, OUT BOOLEAN *Bootabl } } -// default volume icon based on disk kind +// default volume badge icon based on disk kind static VOID ScanVolumeDefaultIcon(IN OUT REFIT_VOLUME *Volume) { switch (Volume->DiskKind) { diff --git a/refind/main.c b/refind/main.c index 572f36a..6bdc3a1 100644 --- a/refind/main.c +++ b/refind/main.c @@ -104,7 +104,7 @@ static VOID AboutrEFInd(VOID) { if (AboutMenu.EntryCount == 0) { AboutMenu.TitleImage = BuiltinIcon(BUILTIN_ICON_FUNC_ABOUT); - AddMenuInfoLine(&AboutMenu, L"rEFInd Version 0.3.1"); + AddMenuInfoLine(&AboutMenu, L"rEFInd Version 0.3.1.2"); AddMenuInfoLine(&AboutMenu, L""); AddMenuInfoLine(&AboutMenu, L"Copyright (c) 2006-2010 Christoph Pfisterer"); AddMenuInfoLine(&AboutMenu, L"Copyright (c) 2012 Roderick W. Smith"); @@ -1110,7 +1110,7 @@ static VOID ScanLegacyVolume(REFIT_VOLUME *Volume, UINTN VolumeIndex) { Volume->BlockIOOffset == 0 && Volume->OSName == NULL) // this is a whole disk (MBR) entry; hide if we have entries for partitions - HideIfOthersFound = TRUE; + HideIfOthersFound = TRUE; } if (HideIfOthersFound) { // check for other bootable entries on the same disk