2

Time to ask my first-ever question here.

At some point in past, I used to have my kernel Just Work (TM) with GRUB2; it still does with GRUB Legacy, but I want [VBE] framebuffer graphics.

The first problem I noticed is that

grub-mkrescue -o cd.iso cdimg/

builds bogus, unbootable images. The latest version I've tried builds an okay text-mode image if I copy my kernel to the root of the image source directory and call it efi.img (otherwise, xorriso fails due to missing efi.img).

I suppose the real question here is if GRUB2 is even supposed to work with non-EFI systems? :( As far as I know, my framebuffer initialisation and filling the screen with white are the exact same code that used to work with some earlier version of GRUB2 before.

Thanks in advance,

Vendu

P.S. FWIW, the OS project is at https://github.com/vendu/OS-Zero/

P.P.S. I hope this isn't all too vague... :)

Vendu
  • 39
  • 1
  • 3

2 Answers2

1

i am the developer of xorriso (but not much involved in GRUB2).

the real question here is if GRUB2 is even supposed to work with non-EFI systems? :(

My own test system has AMD 64 bit with BIOS, not EFI. It boots grub-mkrescue images from CD/DVD and from USB stick.

Does yours boot with a grub-mkrescue image without payload ?

grub-mkrescue -o cd.iso

(you should get a GRUB2 boot prompt then)

A GRUB2 based GNU/Linux image which boots for me from CD/DVD is epidemic-4.1-b1-1-amd64.iso . (It fails to boot from USB stick because of a shortcomming in its initrd. This is not the fault of GRUB2.) Its GRUB2 is not the newest one, though.

builds bogus, unbootable images.

Can you post the outcome of

xorriso -indev cd.iso -toc

which should report about the El Torito boot info which is used by BIOS and UEFI when booting from CD and DVD. (Interesting are only images which do not boot properly, of course.)

If this looks good so far, then you should report the problem to your distro's maintainer (if you aren't in that role yourself) or to grub-devel mailing list.

P.P.S. I hope this isn't all too vague... :)

You will have to give at least an exact description of the refusal to boot: What BIOS do you have ? What version of GRUB2 did you use ? What messages do you see ? Does it happen on more than one machine ? ...any unusual circumstances ... ?

Have a nice day :)

Thomas

Thomas Schmitt
  • 259
  • 1
  • 3
  • Hey Thomas and thanks for your answer! :) I guess I forgot to mention that the scenario is not real hardware, but I'm trying to boot my custom (non-Linux) kernel on top of Qemu. :) I'll try to provide you with a bit more information... :) – Vendu Dec 14 '13 at 03:21
  • Oops, it looks like the comments are not multiline (stackoverflow n00b alert)... :) The problem with xorriso is that it seems to look for "/efi.img": xorriso : FAILURE : Cannot find path '/efi.img' in loaded ISO image xorriso : UPDATE : 598 files added in 1 seconds xorriso : aborting : -abort_on 'FAILURE' encountered 'FAILURE' - this seems to happen here regardless of whether I specify a source directory or not. – Vendu Dec 14 '13 at 03:31
  • Once I put my custom kernel as a second copy inside the source tree and call it efi.img, I get these two lines as output from the command you suggested: Boot image : '/boot/grub/i386-pc/eltorito.img' , boot_info_table=on , grub2_boot_info=on Boot image : '/efi.img' , platform_id=0xEF – Vendu Dec 14 '13 at 03:43
  • As the final words at the moment, by the way, thanks for xorriso; I'm willing to help you fix it, pretty much no matter what it would take, as I seriously need VBE framebuffer graphics for my kernel. :D – Vendu Dec 14 '13 at 04:01
  • 1
    The desire of xorriso for /efi.img probably comes from an option like "--efi-boot efi.img" given to xorriso by grub-mkrescue. Obviously that script wants an UEFI boot image. This is not supposed to be the kernel, but rather a FAT filesystem with some program and data. BIOS will try to boot via .../i386-pc/eltorito.img which is supposed to interpret a grub.conf file with instructions how to load the operating system. Contact me via scdbackup@gmx.net for further examination. – Thomas Schmitt Dec 14 '13 at 08:47
  • It looks like I got the building of boot images fixed; I think grub-mkrescue is keen on the efi.img and I'd rather not change that. I found a script for the combo grub-mkimage + genisoimage and read some manual pages to fix it for my use. :) In case you want to see it, the current build script I'm using is at https://github.com/vendu/OS-Zero/blob/master/kern/unit/ia32/mkcdimg2.sh :) – Vendu Dec 14 '13 at 15:26
  • 2
    I experienced the same issue with Grub 2.02~beta2 on Arch Linux. I compiled grub from the master branch of the Grub [git repo](http://savannah.gnu.org/git/?group=grub) and `grub-mkrescue` no longer expects `/efi.img`. – joe Oct 11 '14 at 21:06
1

Hit this one today on Debian Jessie. To fix the grub-mkrescue -o boot.iso failing with missing /efi.img just install mtools package. Grub depends on mtools (optionally) and fails silently if it doesn't exist.

On Debian apt-get install mtools solved this for me. Hope it helps.

variable
  • 59
  • 2
  • "Grub depends on mtools (optionally) and fails silently if it doesn't exist." What does that mean? "Depends" and "optional" seem like opposite sides of the same coin. – ILMostro_7 Oct 27 '15 at 12:32
  • Practically it means that Grub is installed and it works without the tools it "optionally" depends on. It is up to the user to install "xorriso" and "mtools". Without those grub will fail silently when dealing with ISO creation (dependency to xorriso) or efi images (dependency to mtools). Note: I have not gone to the packaging definitions, nor grub code - this comment is based on my experiences when creating "boot.iso"s to get VirtualBox boot a "real" linux installation from hard disk. – variable Oct 28 '15 at 12:58
  • If it **fails** then it's a **dependency**. If it's *optional*, it wouldn't fail! In any case, the problem was solved upstream without the use of `mtools`. – ILMostro_7 Oct 29 '15 at 00:15