This thread is a split of Is my bios uefi?, the reason being that the thread was likely to go off on a tangent (if it hadn't already!) and so the subject of rEFInd is continuted here.

srs5694 wrote:

khayyam wrote:

I have rEFInd installed but the ext2 driver doesn't work for me (macbook 1,1)

The versions of the drivers I've released to date don't work on Macs. You can use the drivers that came with rEFIt instead. I've fixed the problem, and the fix is available in source code form from rEFInd's git repository. I expect to be making a new release of rEFInd in the next day or two, and the fix will be included with it.

OK, that's good to here, I'm probably likely to continue booting with the kernel's 'efi stub' method, but there are some features of rEFInd (like searching accross ext{2,3}, reiserfs, disks) that might make me switch. For whatever reason when I use a bootmanager, or Apple's 'EFI Boot' (via alt/option) my fan goes into overdrive, and this has been the primary reason I've avoided bootmanagers. It seems that its a 'feature', the fan goes on probably as a safety measure (there being no capacity to monitor the temperature at that stage of operation). If I boot from efi into grub2 then the fan isn't engaged. I assume its to make sure that if the machine is still cooled if having been rebooted, and that it's something particular to the macbook 1,1 as it occured after the (infamous) firmware update.

I've been assuming that 'BootFFFF' is related to having the 'alt/option' key provide 'Boot EFI' volumes, the other I have no idea, are they simply leftover remnants of some 'Software Update' procedure or what-have-you, are they required?

The BootFFFF (EFI/boot/bootia32.efi) entry is a default boot name for IA-32 (x86, 32-bit) Intel CPUs. It's not normally included in the NVRAM entries, but it does sometimes show up. Your Boot0000 (EFI/refind/refind_ia32.efi) entry is obviously for rEFInd. The Boot0001 entry looks like an attempt to boot the kernel directly. The Boot0082 entry I'm less sure about. It might be an entry to boot an optical disc, or a sort of "generic" entry for a hard disk. You can probably safely delete it, and anything else you're not using. In a worst-case scenario, the firmware should regenerate what it needs to boot OS X when you reboot, or you can add new entries to boot Linux.

I can report that BootFFFF is created when booting something via 'alt/option' ("EFI Boot"), I deleted the entry, rebooted, held the 'alt/option' and booted a USB key drive (with grub2 as the \efi\boot\bootia32.efi), the entry was recreated from that sequence. The Boot0082 entry may have been created by rEFIt, which I tested via their CD, or perhaps the MacOS Install Disk, I've since deleted it and it has yet to be re-created, so I assume its just leftovers from some boot or other. Boot0001 is my current method of booting (EFI stub), and points to the 3.4.3 kernel, and 0000 is, as you say, rEFInd.

srs5694 wrote:

All that said, on a Mac, it's generally best to use the "bless" utility in OS X to install boot programs. The Mac's EFI implementation is a bit weird, and efibootmgr in Linux doesn't always work. That said, if you don't have OS X installed and/or if efibootmgr has been doing the job for you, you might as well keep using it.

I have the compete opposite experience, "bless" would often not work, at least as I'd expect it. For instance, when I was creating my initial boot USB stick (a modified sysrescuecd using grub2.efi) I'd created an ESP (vfat) placed grub2 in the standard location (\efi\boot\bootia32.efi), blessed it, etc, but it would not be recognised as 'EFI Boot'. Reformating without an ESP but with a HFS partion and blessed it is recognised however. The same operation on the hardisk, create ESP, \efi\boot\bootia32.efi (grub2), blessed, boots. I assume from all this that the firmware has been instructed to be arbitrarily selective about what's 'blessed' and what is not.

Besides the fact of not having, or wanting, OSX, I'd need it if I wanted to re-install (or re-bless), so efibootmgr has been able to provide a method of severing that last tie with Apple. I have not had the slightest problem with it, and though Apple's "post efi v.1, pre efi v.2", breakage is without doubt shambolic, most of the efi v.2 features implimented I'm not likely to need to interface with (that is if my understanding of Apple's efi is correct). It may be that some of the issues people have experienced with efibootmgr were related to efivars, or happened during the early days of efibootmgr's release, but I would say that currently it works flawlessly, at least for what I require it to do.

So, using Redhat's 'bless' I can bless USB bootsticks (assuming they are HFS formated), and with efibootmgr I can similarly set which particular efi executable is loaded at boot ... so there is no need to have any further "booting OSX to bless ..." business, something I object to mostly becuase it seems Apple has gone out of its way to make the method of booting difficult for those who might 'think otherwise'.

I'm probably likely to continue booting with the kernel's 'efi stub' method, but there are some features of rEFInd (like searching accross ext{2,3}, reiserfs, disks) that might make me switch.

The drivers are implemented independently of rEFInd itself, so in theory, you could boot an EFI stub-enabled kernel by creating a suitable EFI boot variable entry in the NVRAM. The trick would be in getting the drivers to load beforehand, since creating that NVRAM entry might be difficult. In practice, it might be easier to bypass that and use an EFI shell script; however, that just turns the shell into a boot loader. In theory, you could load a driver by creating a Driver#### NVRAM entry (equivalent to the Boot#### entries used for boot loaders). In practice, I don't know of a way to do this on a Mac. Linux's efibootmgr can't do it, and neither can the Mac's built-in firmware options (AFAIK). Some EFI shells can do it via the bcfg command, but the only shells I've seen that have this feature are 2.x shells, which don't work on the Mac's EFI 1.x. Perhaps you could track down a suitable shell and create an entry.

Quote:

For whatever reason when I use a bootmanager, or Apple's 'EFI Boot' (via alt/option) my fan goes into overdrive, and this has been the primary reason I've avoided bootmanagers. It seems that its a 'feature', the fan goes on probably as a safety measure (there being no capacity to monitor the temperature at that stage of operation).

Does this happen only for the time when the boot manager is running, or does it continue after the system boots? If the former, I wouldn't worry about it. As you say, the firmware's designers may have just been "playing it safe" on the fan speed; and even if they weren't, the boot process is quick enough that you're unlikely to do any damage to the system for that brief period. OTOH, if the fan speed continues to run high after the OS has booted, that could be more of an annoyance -- but at least you can monitor the CPU temperature and whatnot, to get an idea of whether the fan speed is running high for some real reason.

Quote:

If I boot from efi into grub2 then the fan isn't engaged. I assume its to make sure that if the machine is still cooled if having been rebooted, and that it's something particular to the macbook 1,1 as it occured after the (infamous) firmware update.

It's conceivable that GRUB 2 has code to control the fan speed; I haven't checked it. Unless there's something I've overlooked lurking from rEFIt, rEFInd doesn't do anything about this, so the fan is presumably doing whatever the firmware last told it to do.

Quote:

"bless" would often not work, at least as I'd expect it. For instance, when I was creating my initial boot USB stick (a modified sysrescuecd using grub2.efi) I'd created an ESP (vfat) placed grub2 in the standard location (\efi\boot\bootia32.efi), blessed it, etc, but it would not be recognised as 'EFI Boot'. Reformating without an ESP but with a HFS partion and blessed it is recognised however. The same operation on the hardisk, create ESP, \efi\boot\bootia32.efi (grub2), blessed, boots.

Apple's "bless" utility is undeniably finicky. In your situation, I can't criticize your choice to use efibootmgr; but the impression I get from various forums is that efibootmgr is less reliable than bless on a typical Linux/OS X dual-boot system.

[...] Some EFI shells can do it via the bcfg command, but the only shells I've seen that have this feature are 2.x shells, which don't work on the Mac's EFI 1.x. Perhaps you could track down a suitable shell and create an entry.

Part of the problem (at least for those with Apple hardware) is the dearth of information, when I first installed this machine I could find next to nothing re efi booting, unless if was of the kind "install rEFIt .. run gptsync, etc". It all assumed that MacOS was available and that one was using hybrid GPT/MBR's. Even the install guides presented Hybrid MBR, rEFIT, etc, as the 'supported method', and native GPT and EFI booting are rarely mentioned, or worse, advised against. As I wanted the whole disk available for Linux, and didn't want to have to have OSX installed, or hybrid GPT/MBR, I had to pretty much figure it out via trial and error. The process wasn't helped by the fact that quite often grub2 (from bzr) will fail to build, and by no one seemingly using it for booting a macbook 1,1 (probably as a result of being advised to use rEFIt).

Anyhow, I've no idea if there are efi shells that will work .. and probably the only method of finding out is to try (there being probably no one who's attempted to do so), but its not really that important, I could continue to have ESP as /boot and use efibootmgr to switch between entrys, its quick and, as long as I keep a fallback, painless. I can if need be boot my USB stick and fix any problem.

srs5694 wrote:

Quote:

For whatever reason when I use a bootmanager, or Apple's 'EFI Boot' (via alt/option) my fan goes into overdrive [...]

Does this happen only for the time when the boot manager is running, or does it continue after the system boots?

It only happens if lingering in the bootmanager or "EFI Boot", there is about a 3 or 4 seconds grace period, if I make a selection and boot quickly the fan doesn't power up. Once powered it'll take somewhere in the region of 30 or 40 seconds to spin down again, but it'll run at full tilt for that time span. In case you weren't aware, the macbook 1,1 fan sounds like a vacuum cleaner ... its caused some odd looks when booting at the library .. hehe. WRT grub2, it doesn't linger at the EFI stage, its the bootloader that EFI hands off to, so the fan is never engaged once grub has loaded. As I said, I think this is a 'feature' of the macbook 1,1 firmware update, Apple refused to recognise that the machine had an overheating problem and this was their backdoor 'fix'. In 2010 they finially agreed to take on users grevencies and had a brief service extention and hardrive replacement program (the HD were effectively destroyed by overheating)

Incidentally, the fan powers up with anything over 10% cpu load (Apple's 'soltution' to the overheating, provided with the infamous firmware upgrade), when running OSX if you (foolishly) try to watch a video on youtube (yes, even low quality 320p), the CPU/GPU (a GMA950 intergrated graphics stupidity) can't handle the throughput and the fan goes into vacuum cleaner mode, you effectively loose complete control of the machine because the scheduling prioritises the display, it takes a minute or so to kill the process. The machine is basically a major design catastrophy, which, of course, Apple would never admit, as the cost of replacing them would bite into profit margin.

srs5694 wrote:

Quote:

If I boot from efi into grub2 then the fan isn't engaged. I assume its to make sure that if the machine is still cooled if having been rebooted, and that it's something particular to the macbook 1,1 as it occured after the (infamous) firmware update.

It's conceivable that GRUB 2 has code to control the fan speed; I haven't checked it. Unless there's something I've overlooked lurking from rEFIt, rEFInd doesn't do anything about this, so the fan is presumably doing whatever the firmware last told it to do.

I don't think so, no. I think its simply due to efi having been exited, once its handed off to the bootloader it assumes the machine is booting.

srs5694 wrote:

Apple's "bless" utility is undeniably finicky. In your situation, I can't criticize your choice to use efibootmgr; but the impression I get from various forums is that efibootmgr is less reliable than bless on a typical Linux/OS X dual-boot system.

I think its a "lock out" feature, Apple simply doesn't want people booting whatever they so choose via efi. The fact that 'bless' is so inconsistant about what it'll boot is based on the logic that if its external than it has to be HFS (and so be an OSX disk, and so allow users to boot from USB, etc), or if internal then ESP selection is allowed (even though Apple doesn't use the ESP, its bootloader is located on the OSX system disk). The latter is probably only allowed as its the only method to get hybrid GPT/MBR efi boot for OSX/Windows dual boots. I happen to think this is "by design" rather than a qwerk.

Again, I've not had any problems with efibootmgr, but I think its also somewhat of a chicken & egg loop ... there are probably so few people actually using this method that any reliability issues (bugs or what-have-you) stand out, and there is little in terms of success stories to counter-point. I might be wrong ITR, but I can only report my own experiences.

Part of the problem (at least for those with Apple hardware) is the dearth of information, when I first installed this machine I could find next to nothing re efi booting, unless if was of the kind "install rEFIt .. run gptsync, etc". It all assumed that MacOS was available and that one was using hybrid GPT/MBR's.

I understand completely. I've got a Mac Mini of that generation, purchased used well after I'd written GPT fdisk and discovered all the problems with hybrid MBRs. (Actually, I shouldn't use the word "all" -- I keep finding new problems!) I knew enough about EFI booting to be able to get Ubuntu Linux to boot under EFI in that way, and I wrote up my experiences. I've since updated that page with the benefit of additional experience. Gentoo has the advantage of a less scripted installation procedure, so there's less need to work around the things the installer does wrong for what's intended. (I'm not running Gentoo on that particular system, though.)

You know, I never made the connection, so your also the author of gdisk. I'd read various parts of your extensive documentation but I'd never connected gdisk with rEFInd, of course it seems obvious now. Well, thanks are in order ..

I seem to remember there was a recent Ubuntu release the installer of which destroyed the ESP on Apple machines, I think it fomatted it without checking to see if it was in use. I don't remember the precise details as its not something that passed by my desk, but I do remember there being alot of unhappy Ubuntu users.

I used to provide support on ubuntuforums but stopped after running foul of their "community standards", something which in practice is little more than a tool to prevent the development of "community". As I'm not an Ubuntu user (but have had to support quite a number installs) I just didn't see the point in continuing to provide them with my time and energy. I've developed somewhat of an aversion to the subject ... so I'll leave it at that.

You know, I never made the connection, so your also the author of gdisk. I'd read various parts of your extensive documentation but I'd never connected gdisk with rEFInd, of course it seems obvious now. Well, thanks are in order ..

You're welcome! In both cases, I started by just fiddling with something that bugged me and it turned into a new project -- the "scratching an itch" model of open source development.

Quote:

I seem to remember there was a recent Ubuntu release the installer of which destroyed the ESP on Apple machines, I think it fomatted it without checking to see if it was in use. I don't remember the precise details as its not something that passed by my desk, but I do remember there being alot of unhappy Ubuntu users.

Yes. all versions that supported EFI installation prior to 12.04 suffered from this bug. A bug report was filed around the time 11.04 was released, but it existed prior to that. The Ubuntu developers didn't bother to fix it until sometime in the 12.04 alpha or beta series. Thankfully, the bug is now fixed, so we won't have Ubuntu 12.04 LTS users complaining about this in a year....

Quote:

I used to provide support on ubuntuforums but stopped after running foul of their "community standards", something which in practice is little more than a tool to prevent the development of "community". As I'm not an Ubuntu user (but have had to support quite a number installs) I just didn't see the point in continuing to provide them with my time and energy. I've developed somewhat of an aversion to the subject ... so I'll leave it at that.

You too, eh? I ran into problems with a particular user who drove me away with his arguments whenever I corrected his bad advice. I've heard they've lost other competent people in similar ways. Perhaps that's the price for being such a popular Web forum....

Quote:

Any word on the rEFInd release?

Yes, version 0.4.3 is now available. It includes the fix for the drivers that enables them to work on Macs, and a few other tweaks. The main rEFInd binary can also now build using either GNU-EFI (which I've used for all previous builds) and TianoCore EDK2. There may be some subtle (or even not-so-subtle) differences between the two build methods, so I've built it both ways and have provided download links for both types of binaries. I suppose it's conceivable that the TianoCore build would behave differently with respect to the fan issue you noted earlier, but I wouldn't count on it. As I said, I know of nothing in the rEFInd code that explicitly controls the fan.

Yes, version 0.4.3 is now available. It includes the fix for the drivers that enables them to work on Macs, and a few other tweaks. The main rEFInd binary can also now build using either GNU-EFI (which I've used for all previous builds) and TianoCore EDK2. There may be some subtle (or even not-so-subtle) differences between the two build methods, so I've built it both ways and have provided download links for both types of binaries.

OK, I haven't had much time to mess arround with it, but I've booted with both the GNU-EFI and TianoCore using the ext2_ia32 driver only and both detected kernels located on an ext2 filesystem. The only issue I noticed is that the menu entry I created doesn't show up, it may simply be a syntax error on my part, or an ill defined 'volume'

I'll probably fiddle with it later this afternoon, and may even try the resiser driver.

srs5694 wrote:

I suppose it's conceivable that the TianoCore build would behave differently with respect to the fan issue you noted earlier, but I wouldn't count on it. As I said, I know of nothing in the rEFInd code that explicitly controls the fan.

Sadly that's not the case, the fan powers up with both the TianoCore and GNU-EFI ...

OK, I haven't had much time to mess arround with it, but I've booted with both the GNU-EFI and TianoCore using the ext2_ia32 driver only and both detected kernels located on an ext2 filesystem. The only issue I noticed is that the menu entry I created doesn't show up, it may simply be a syntax error on my part, or an ill defined 'volume'

Have you added "manual" to the "scanfor" option earlier in the configuration file? It's disabled by default. (I've gotten reports from others who haven't made this necessary change, so I'm thinking of changing the default.)

Have you added "manual" to the "scanfor" option earlier in the configuration file? It's disabled by default. (I've gotten reports from others who haven't made this necessary change, so I'm thinking of changing the default.)

No, I hadn't, infact I'd obviously omited to read that section of the config completely. I haven't had any further chance to mess with it today, but I'll look at it tommorow ... 'til then

Sorry for not getting back sooner, I wanted to make sure everything was working as expected, and as I run into a problem I wanted to get some idea of why before reporting it as a bug.

Firstly, yes, defining 'manual' in 'scanfor' does indeed produce the menu items. I just hadn't read the comments fully.

Most everything does seem to be working, the only driver I haven't tested is the reiserfs_ia32.efi, I did run into two issues, the first of which may infact be a 'bug' of sorts, the second I'm simply not so sure about. So, the first: I couldn't figure out why my my USB stick (HFS with \efi\boot\bootia32.efi) wasn't recognised. It turned out to be due to having set 'dont_scan_dirs efi/boot' which from the description in refind.conf-sample seemed to suggest this was for blacklisting directories within the ESP, and not, in addition, those on external devices. I took me quite a number of reboots to realise this confuguration was global as I was focused on the idea that the hfs_ia32.efi wasn't loading and so tried swithcing to TianoCore from GNU-EFI, removing all other drivers, etc. I'm not sure this is something your aware of, but perhaps a warning in the config that blacklisting directories is global would be in order.

The second possible bug: the option 'use_graphics_for' or using 'graphics' with a menuentry still produces 'text mode'. I tried various methods, including 'use_graphics_for' defined but empty, but each time I would still see 'text mode'.

Also, when you define 'scanfor manual,internal,etc' items you have defined manaully are also replicated (as presumably they are discovered by the internal search), idealy they should be excluded, as otherwise the menu is cluttered with duplicate entries.

I tested both TianoCore and GNU-EFI versions with the ext2_ia32, hfs_ia32, and iso9660_ia32 drivers, I was probably more through with the later and may have missed booting a CD with the former, but on all counts the efi were found on internal and external, and optical, devices.

I had one question re the iso9660 driver can this be used in a similar manner to grub's 'loopback', for booting iso images?

I couldn't figure out why my my USB stick (HFS with \efi\boot\bootia32.efi) wasn't recognised. It turned out to be due to having set 'dont_scan_dirs efi/boot' which from the description in refind.conf-sample seemed to suggest this was for blacklisting directories within the ESP, and not, in addition, those on external devices.

That's the way it's supposed to work, at least for now. Doing otherwise would require specifying a partition as part of the filename, which of course is possible but would require more code and raise more possible failure modes. I have added a clarification to the documentation, though, which will go out with the next release.

Quote:

The second possible bug: the option 'use_graphics_for' or using 'graphics' with a menuentry still produces 'text mode'. I tried various methods, including 'use_graphics_for' defined but empty, but each time I would still see 'text mode'.

This could have a number of causes. Three that come to mind are:

rEFInd version bug -- The "use_graphics_for" option was broken in version 0.4.3 (the version in which it was introduced), but I've fixed it in 0.4.4. (Basically, my test cases happened to work with some broken code, so I didn't realize it was broken until after I released it.) If you were using 0.4.3, please try 0.4.4. This issue shouldn't affect the "graphics" item in manual boot stanzas, though.

Misunderstanding of what it does -- For most boot loaders, the rEFInd boot mode will have an effect that lasts just a fraction of a second, since the boot loader itself will set up its own display mode. The effect can be a bit longer (typically a couple of seconds) with something like the Linux kernel's EFI stub loader because it's so big and it therefore takes longer to load the kernel and its initial RAM disk.

A bug that's unknown to me -- It could be that it's just plain not working on your system because of something system-specific that rEFInd should be handling, some option you're using that's interacting with "use_graphics_for", or some other reason that qualifies as a new bug.

The main reason I added the "use_graphics_for" option is that I've received reports of what I believe to be an implementation-specific EFI bug, or possibly a kernel stub loader bug, that caused the system to hang if graphics mode was not used with the Linux kernel. Enabling graphics mode is therefore a useful workaround for this bug. A secondary reason to add this is to minimize distracting screen mode changes when launching an OS. Such screen-mode changes vary depending on the boot loader in use. In my experience, most Linux boot loaders set up text mode, so setting Linux to use graphics mode will have little noticeable effect -- blink and you'll miss it. OS X, though, launches in graphics mode, so using text mode causes a brief flicker of text mode that might be objectionable. Hence the default of using graphics mode for OS X but not for Linux.

If you still think there's a bug here, please elaborate on precisely what you're seeing and what you think you should be seeing, and I'll look into it further. (Feel free to send me an e-mail about this, if you like; these details might not be of broad interest.)

Quote:

Also, when you define 'scanfor manual,internal,etc' items you have defined manaully are also replicated (as presumably they are discovered by the internal search), idealy they should be excluded, as otherwise the menu is cluttered with duplicate entries.

In the short term, if you're seeing duplicates like this, you should either disable the relevant manual setups or use the "dont_scan_dirs" option to exclude the automatic detection. In the long term, I've thought of this myself, but it's been low on my priority list because it's easy to work around in these two ways and implementing it reliably would be a bit tricky. (Basically, I'd need to compare existing entries when adding new ones, and that comparison could produce misses because of trivial differences in pathname specifications of the boot loader files between what a user enters and what the auto-detection finds.)

Quote:

I had one question re the iso9660 driver can this be used in a similar manner to grub's 'loopback', for booting iso images?

No -- at least, not as far as I'm aware. (I didn't write the driver; I just compiled it.) You could look into the "map" command in an EFI shell, though. A quick perusal of its help options doesn't suggest it can do the job, but I may have missed something, or there may be an undocumented feature that would enable you to do it. If you investigate and find a way to do this with an EFI shell, please tell me -- I may be able to replicate it within rEFInd and provide an option for it.

It turned out to be due to having set 'dont_scan_dirs efi/boot' which from the description in refind.conf-sample seemed to suggest this was for blacklisting directories within the ESP, and not, in addition, those on external devices.

That's the way it's supposed to work, at least for now. Doing otherwise would require specifying a partition as part of the filename, which of course is possible but would require more code and raise more possible failure modes. I have added a clarification to the documentation, though, which will go out with the next release.

I imagined this was the case, but wouldn't rEFInd have some idea of the ESP it was run from and so a value with which the blacklist could apply? Its not really a feature that I can see anyone really needing but as in my case you may think that your blacklisting the ESP and end up blacklisting these standard directories on other media, anyhow, the clarification should at least make this less likely.

srs5694 wrote:

Quote:

The second possible bug: the option 'use_graphics_for' or using 'graphics' with a menuentry still produces 'text mode'. I tried various methods, including 'use_graphics_for' defined but empty, but each time I would still see 'text mode'.

This could have a number of causes. Three that come to mind are:

rEFInd version bug -- The "use_graphics_for" option was broken in version 0.4.3 (the version in which it was introduced), but I've fixed it in 0.4.4. (Basically, my test cases happened to work with some broken code, so I didn't realize it was broken until after I released it.) If you were using 0.4.3, please try 0.4.4. This issue shouldn't affect the "graphics" item in manual boot stanzas, though.

With 0.4.4 is does now seem to work, I have both 'use_graphics_for linux' and 'graphics' in the boot stanzas, I haven't tryed removing the former to see if the later works as expected.

As I understood it with 'graphics' mode you won't see the blue box with the text 'rEFInd booting' (or similar ... as you say its only on screen for a fraction of a second) ... hopefully I understood this correctly.

srs5694 wrote:

The main reason I added the "use_graphics_for" option is that I've received reports of what I believe to be an implementation-specific EFI bug, or possibly a kernel stub loader bug, that caused the system to hang if graphics mode was not used with the Linux kernel. Enabling graphics mode is therefore a useful workaround for this bug. A secondary reason to add this is to minimize distracting screen mode changes when launching an OS. Such screen-mode changes vary depending on the boot loader in use. In my experience, most Linux boot loaders set up text mode, so setting Linux to use graphics mode will have little noticeable effect -- blink and you'll miss it. OS X, though, launches in graphics mode, so using text mode causes a brief flicker of text mode that might be objectionable. Hence the default of using graphics mode for OS X but not for Linux.

I see ... in my case I don't have this hang in 'text' mode using efi stub, but I'd prefer a more seemless transition. During the first second of the kernel loading when the video device is initialised there are already video artifacts (this happens with or without rEFInd and is not a bug), it would be better if it were seamless as it makes the boot look like some terrible event. I believe Apple blanks the screen so that these remants aren't displayed, and a more seamless transition occurs. I recently removed the efifb driver to see if this would have any effect but wasn't suprised when it didn't, when the framebuffer is initialised there are a some fireworks to celebrate the event.

Incidentally, I have a report from one user that if their kernel is built without efifb enabled grub will error "no suitable modes", any idea why?

srs5694 wrote:

Quote:

Also, when you define 'scanfor manual,internal,etc' items you have defined manaully are also replicated (as presumably they are discovered by the internal search), idealy they should be excluded, as otherwise the menu is cluttered with duplicate entries.

In the short term, if you're seeing duplicates like this, you should either disable the relevant manual setups or use the "dont_scan_dirs" option to exclude the automatic detection. In the long term, I've thought of this myself, but it's been low on my priority list because it's easy to work around in these two ways and implementing it reliably would be a bit tricky. (Basically, I'd need to compare existing entries when adding new ones, and that comparison could produce misses because of trivial differences in pathname specifications of the boot loader files between what a user enters and what the auto-detection finds.)

The problem is I use the ESP as /boot so all the kernels are there, and I'd assumed blacklisting "/" might cause problems. I don't really think its an issue, as you say I can disable manual stanzas or have those kernels I don't want listed in some blacklisted location, however it might be something you want to impliment at some point (low priority).

srs5694 wrote:

Quote:

I had one question re the iso9660 driver can this be used in a similar manner to grub's 'loopback', for booting iso images?

No -- at least, not as far as I'm aware. (I didn't write the driver; I just compiled it.) You could look into the "map" command in an EFI shell, though. A quick perusal of its help options doesn't suggest it can do the job, but I may have missed something, or there may be an undocumented feature that would enable you to do it. If you investigate and find a way to do this with an EFI shell, please tell me -- I may be able to replicate it within rEFInd and provide an option for it.

OK ... I may look into it at some point ... a typical grub stanza would look like the following:

... most of this is simply what's passed as kernel args, but its the 'loopback' and '(loop)/path' which may be difficult to replicate. I've not looked to see how grub does this, it may be trivial, but given rEFInd has a iso9660 driver the contents on the iso should be readable and so booting from it possible. I'll pass on any information I gleen if/when I get time to try it out.

but wouldn't rEFInd have some idea of the ESP it was run from and so a value with which the blacklist could apply? Its not really a feature that I can see anyone really needing but as in my case you may think that your blacklisting the ESP and end up blacklisting these standard directories on other media, anyhow, the clarification should at least make this less likely.

Yes, rEFInd can determine its own boot volume; however, there's at least a potential need to blacklist directories on non-ESP volumes. Clearly, without a volume specification there are drawbacks either way.

Quote:

srs5694 wrote:

Quote:

The second possible bug: the option 'use_graphics_for' or using 'graphics' with a menuentry still produces 'text mode'.

With 0.4.4 is does now seem to work, I have both 'use_graphics_for linux' and 'graphics' in the boot stanzas, I haven't tryed removing the former to see if the later works as expected.

That's good to hear.

Quote:

As I understood it with 'graphics' mode you won't see the blue box with the text 'rEFInd booting' (or similar ... as you say its only on screen for a fraction of a second) ... hopefully I understood this correctly.

Correct.

Quote:

in my case I don't have this hang in 'text' mode using efi stub, but I'd prefer a more seemless transition. During the first second of the kernel loading when the video device is initialised there are already video artifacts (this happens with or without rEFInd and is not a bug), it would be better if it were seamless as it makes the boot look like some terrible event.

Interesting. This isn't an issue on any of my systems. No doubt it's specific to your video controller, firmware implementation, or some other system-specific issue. I take it that this problem goes away when you use the graphics-mode boot in rEFInd?

Quote:

Incidentally, I have a report from one user that if their kernel is built without efifb enabled grub will error "no suitable modes", any idea why?

No, and that's very peculiar -- GRUB shouldn't be complaining about features that are or are not in the kernel, AFAIK, except maybe for something like the compression method used.

Quote:

The problem is I use the ESP as /boot so all the kernels are there, and I'd assumed blacklisting "/" might cause problems.

I don't recall testing it myself, but you should be able to blacklist "/" and have it work. (OTOH, there is some "/"-specific code in rEFInd to deal with assorted bugs and quirks, so it might not work. If so, that's a rEFInd bug.)

Quote:

given rEFInd has a iso9660 driver the contents on the iso should be readable and so booting from it possible. I'll pass on any information I gleen if/when I get time to try it out.

rEFInd relies on the EFI for all filesystem support. I do include an ISO-9660 driver with rEFInd, but the driver is an EFI driver. rEFInd can tell the EFI to load and use it, but then rEFInd relies on the EFI (including any loaded drivers) for filesystem access. Thus, getting loopback support working in rEFInd really means getting loopback support working for EFI (and perhaps finding a way to trigger that within rEFInd). This is different from GRUB, which was designed with BIOS in mind, and so all the filesystem drivers are GRUB drivers, not BIOS or EFI drivers.

but wouldn't rEFInd have some idea of the ESP it was run from and so a value with which the blacklist could apply? Its not really a feature that I can see anyone really needing but as in my case you may think that your blacklisting the ESP and end up blacklisting these standard directories on other media, anyhow, the clarification should at least make this less likely.

Yes, rEFInd can determine its own boot volume; however, there's at least a potential need to blacklist directories on non-ESP volumes. Clearly, without a volume specification there are drawbacks either way.

I hadn't thought of that, a need to blacklist external volumes that is, but wouldn't this be solvable in a similar manner to how internal/external/optical is currently handled?

srs5694 wrote:

Quote:

in my case I don't have this hang in 'text' mode using efi stub, but I'd prefer a more seemless transition. During the first second of the kernel loading when the video device is initialised there are already video artifacts (this happens with or without rEFInd and is not a bug), it would be better if it were seamless as it makes the boot look like some terrible event.

Interesting. This isn't an issue on any of my systems. No doubt it's specific to your video controller, firmware implementation, or some other system-specific issue. I take it that this problem goes away when you use the graphics-mode boot in rEFInd?

No, but I don't think rEFInd, or grub for that matter, has anything to do with it, it's the kernel initialising the card. Perhaps I shouldn't have used the term "fireworks", it more like "static".

srs5694 wrote:

Quote:

Incidentally, I have a report from one user that if their kernel is built without efifb enabled grub will error "no suitable modes", any idea why?

No, and that's very peculiar -- GRUB shouldn't be complaining about features that are or are not in the kernel, AFAIK, except maybe for something like the compression method used.

Yes, this was my thought exactly ... I didn't seem right, I think maybe the reporter just wasn't paying attention.

srs5694 wrote:

Quote:

given rEFInd has a iso9660 driver the contents on the iso should be readable and so booting from it possible. I'll pass on any information I gleen if/when I get time to try it out.

rEFInd relies on the EFI for all filesystem support. I do include an ISO-9660 driver with rEFInd, but the driver is an EFI driver. rEFInd can tell the EFI to load and use it, but then rEFInd relies on the EFI (including any loaded drivers) for filesystem access. Thus, getting loopback support working in rEFInd really means getting loopback support working for EFI (and perhaps finding a way to trigger that within rEFInd). This is different from GRUB, which was designed with BIOS in mind, and so all the filesystem drivers are GRUB drivers, not BIOS or EFI drivers.

I see ... OK, well, thanks for the additional information. I can't see myself looking at anytime soon, but I'll keep the above in mind.

Yes, rEFInd can determine its own boot volume; however, there's at least a potential need to blacklist directories on non-ESP volumes. Clearly, without a volume specification there are drawbacks either way.

I hadn't thought of that, a need to blacklist external volumes that is, but wouldn't this be solvable in a similar manner to how internal/external/optical is currently handled?

No, or at least, that wouldn't gain you anything over specifying a filesystem more precisely. In either case, it's an extra user interface element and code to match the user-specified filesystem or class of devices against what's found to actually exist. Since the internal/external/optical distinction is fairly crude but would be about as difficult to implement as a volume specification (using volume names or device numbers, similar to what the "volume" token in a manual stanza does), I don't see any point to doing it that way.