GRUB 2 always starts in command line - can't proceed - EFI Boot

[jimmyjohn]

Every time I try to boot up, I get sent into a Grub 2 shell and am unable to move forward.  I am using Corepure 64 10.1 and am booting from a USB drive partitioned in GPT format.  I am using Rufus to burn the ISO to the drive, but have also tried with etcher.  I have tried manually booting with grub commands 'linux' and 'initrd', but even then I get an 'unknown filesystem' error.  I don't have the option to boot in legacy mode.

I am really excited to use Tiny Core Linux, but this stumbling block is quite annoying.  Does anyone know what might be going on and how to fix it?

[coreplayer2]

Hello

The path to kernel and initrd is incorrect

Perhaps there’s no grub.cfg file ?


Sent from my iPhone using Tapatalk

[jimmyjohn]

Well, there is a grub cfg file.  In fact, just now, I pulled the bootx64.efi from a different linux ditro (puppy linux), then i moved the grub.cfg file to the root directory on the usb drive and doing that has gotten it working.  However, despite the fact that it is working, that leads me to question if perhaps the most recent iso has a faulty bootx64.efi file.  Has anyone else tested it and found it to be fully functional?

[coreplayer2]

JimmyJohn

Glad you figured it out
Next time try installing manually without use of third party installers, like Rufus etc etc (Although YUMI EFI reportedly understands tinycore requirement).  Again, installing manually is quite easy if you check off the following list items & notes below

We're making many assumptions here;

• that you've Created a GPT Partition Table
• that you've Created at least one 100 to 200MB FAT32 Partition for boot manager, tinycore and Linux Kernel
• that Grub2 is installed from a 64bit operating system, with the following directory paths
•         sd(x)1/EFI/BOOT
•         sd(x)1/EFI/BOOT/GRUB
• Created grub config file
•         sd(x)1/EFI/BOOT/GRUBgrub.cfg
• Optional 2nd larger partition formatted with ext2 file system for " tce " (for persistent TCE, Home and OPT directories if required)
• that you've copied the ISO/CDE directory and all it's contents to
•         sd(x)2/tce
• that you've copied the kernel and initrd (eg: corepure64.gz) to
•         sd(x)2/linux/   (or as specified in the grub.cfg file)

Note 1: grub.cfg file contains at a minimum:
[/list]

Code: [Select]

loadfont unicode
insmod all_video
set gfxmode=auto
set gfxpayload=keep
set gfxterm_font=unicode
terminal_output gfxterm

search --no-floppy --fs-uuid --set=root "964B-11FB"

menuentry "Corepure64" {
linux /linux/vmlinuz64 loglevel=3 vga=871 waitusb=5
initrd /linux/corepure64.gz
}


Note 2: EFI Boot partition UUID code for grub.cfg --set=root "964B-11FB" command can be found at the linux terminal

Code: [Select]

tc@box:~$ blkid -s UUID /dev/sdc1
/dev/sdc1: UUID="964B-11FB"If unable you can temporarily comment that line out

Code: [Select]

# search --no-floppy --fs-uuid --set=root "964B-11FB"
Note 3: See this link for more
http://forum.tinycorelinux.net/index.php/topic,19364.msg119228.html#msg119228

[coreplayer2]

I pulled the bootx64.efi from a different linux ditro (puppy linux), then i moved the grub.cfg file to the root directory on the usb drive and doing that has gotten it working.  However, despite the fact that it is working, that leads me to question if perhaps the most recent iso has a faulty bootx64.efi file.  Has anyone else tested it and found it to be fully functional?

We always create a bootx64.efi boot loader for each scenario

Code: [Select]

sudo grub-install --target=x86_64-efi --boot-directory=/mnt/sdb1/EFI/BOOT --efi-directory=/mnt/sdb1 --removable

[jimmyjohn]

JimmyJohn

Glad you figured it out
Next time try installing manually without use of third party installers, like Rufus etc etc (Although YUMI EFI reportedly understands tinycore requirement).  Again, installing manually is quite easy if you check off the following list items & notes below

We're making many assumptions here;

• that you've Created a GPT Partition Table
• that you've Created at least one 100 to 200MB FAT32 Partition for boot manager, tinycore and Linux Kernel
• that Grub2 is installed from a 64bit operating system, with the following directory paths
•         sd(x)1/EFI/BOOT
•         sd(x)1/EFI/BOOT/GRUB
• Created grub config file
•         sd(x)1/EFI/BOOT/GRUBgrub.cfg
• X - Optional 2nd larger partition formatted with ext2 file system for " tce " (for persistent TCE, Home and OPT directories if required)
• X - that you've copied the ISO/CDE directory and all it's contents to
•         sd(x)2/tce
• that you've copied the kernel and initrd (eg: corepure64.gz) to
•         sd(x)2/linux/   (or as specified in the grub.cfg file)

Note 1: grub.cfg file contains at a minimum . . .

Thanks for the feedback and the checklist!  I can confirm that, other than those marked with an x, every condition above was met.  Also, after the first attempt failed using Etcher, I did a manual install with the same results before attempting using Rufus.

I am going to keep fiddling to see what all I can do.

On another note, is it possible to boot the standard 32bit tiny core via UEFI?[/list]

[coreplayer2]

On another note, is it possible to boot the standard 32bit tiny core via UEFI?[/list]

Absolutely you can.   

Know this; except in extremely rare cases, (eg antique 32bit MacBooks) you must install grub2 to your USB or HDD from a 64bit grub2 version

Your grub.cfg file can specify any number of Tinycore flavors

Good luck


Sent from my iPhone using Tapatalk

[coreplayer2]

• that you've copied the kernel and initrd (eg: corepure64.gz) to
•         sd(x)1/linux/   (or as specified in the grub.cfg file)

Ooops I made a typo

Partition number for core & linux files should be sd(x)1
While that’s obviously not exact, the ESP is typically the first partition.  It’s important that  drive number and path should be reflected in grub.cfg file

Sent from my iPhone using Tapatalk

[PDP-8]

Bummer - that simple trick of moving grub.cfg to the root of the drive did not work for both of my boxes.  Performed this operation in Linux, and not on windows, which surprise - didn't work either. 

(And yes, the notepad editor in an up to date win 10 box will properly read/write in the unix format.)

Somewhat frustrating because as we know, the ISO is not usable out of the box for those unix users thinking an isohybrid is going to work with "dd".  The only thing that results in is a virtual iso9660 cd format on a usb stick.

Some notes comparing the current iso to the minimal listing above:

Does it matter if the GRUB directory is NOT capitalized, but lower case in the iso?

The iso is also missing these elements:
insmod all_video
insmod efi.gop  <--- from earlier research on a good manual install

Search path:  Entirely missing from iso.
But I guess I understand as that has to be customized by the end user for each machine setup they intend to put it on.

Example: both of my uefi only boxes boot from mmcblk devices.  However, to boot from a usb stick, they are represented as /dev/sda, so the generic release to the repos is for /dev/sdb, assuming there is already an sda device onboard?

Welcome to UUID's.  Problem is catch 22 for those not already running a linux distro to get the blkid -s UUID tool. 

Not complaining, just trying to wrap my head around what might be an easter-egg hunt caused by uefi-only hardware.

Note: To be accurate, RUFUS is not a 3rd-party bootloader.  It does NOT modify or add anything additional beyond what the original iso creator released.  It's sole purpose is to burn the supplied iso.  Your only major choices are to burn in either mbr or gpt format.  gpt for us uefi-folk naturally.  Then, the only other choice is either iso or dd mode.  DD mode with tc results in a cd-on-a-stick, which we know won't boot a uefi-only mode machine, so iso mode is the one, and is seen properly in Gparted for example.

Yet it is still up to the user to modify his grub search path.  Thus the fail with Rufus.  It is not designed to "know" about a distro - if the necessary info isn't there, Rufus won't magically supply it.

YUMI-UEFI - this IS different.  It uses it's own bootloader to burn TinyCore initially, and then get it's necessary grub.cfg from the TinyCore iso itself.  This method does result in a "hands off" kind of user-built stick without having to know UUID's etc - provided that the user knows that the usual TC directories are now in slightly different places.  Of course you can do UUID's later if you want - but the point is, you WILL boot initially.

Just didn't want to start a finger-pointing war - TC rocks, but these burners and alternate bootloaders aren't stupid either.

[jimmyjohn]

For anyone else experiencing this issue, the only method I have found to work around the issue I posted, was to use a different EFI file.  I have included a link to the EFI file(s) I was able to get to work.  You need to do two things:

1)  Move the contents of the grub folder ( /efi/boot/grub) into the root directory.  This would be the fonts folder and grub.cfg

2) Replace the entire EFI folder with the one attached to this post.

Anyway, I tried a few different things and that is the only thing I could get to make it work.

Link:  http://s000.tinyupload.com/index.php?file_id=07415292769309112095

Good luck!

[PDP-8]

Jimmyjohn - That's a pretty neat hack.  I just tried it on my uefi-only Computestick and works like your Kangaroo.   Downloaded that EFI as a test, so thanks for that.

The really interesting thing is that after grub 2.03 menu comes up, finds the grub.cfg file you moved, TCpure64 boots up in full native resolution!

Normally I'd have to load kernel-<graphics> to get that to happen, but this now happens by default.  If I wanted lower, I'd just adjust my grub.cfg file.

I poured over the Rufus faq about just ending up in the grub commandline:

https://github.com/pbatard/rufus/wiki/FAQ#Using_an_UEFI_bootable_ISO_based_on_grub_all_I_get_is_the_grub_prompt

where a number of issues that may not be pertinent to TC, but an issue with others like Manjaro not using a fat-32 module, or Ubuntu not using a part-gpt module when running grub-mkimage etc etc.

Keeping track of all these variables is what makes my head spin - despite the EXCELLENT info provided by our heavyweight TC devs.  Heh, that's why I shamefully admit I'm a slacker and an image, rather than an iso, is in my wheelhouse these days.

[PDP-8]

Jimmy - you know what?  This is a much cleaner simpler hack than using YUMI-UEFI.

Since it comes up in full native resolution for me, I verified that I can turn the resolution down if I want by merely adding the standard

Code: [Select]

set gfxpayload=1024x768
at the end of my grub.cfg.

Not official, but since I use Rufus for duties other than iso / img burning, this is a nifty hack to keep in my back pocket.  Thanks!

[coreplayer2]

Jimmy - you know what?  This is a much cleaner simpler hack than using YUMI-UEFI.

Since it comes up in full native resolution for me, I verified that I can turn the resolution down if I want by merely adding the standard

Code: [Select]

set gfxpayload=1024x768
at the end of my grub.cfg.

Not official, but since I use Rufus for duties other than iso / img burning, this is a nifty hack to keep in my back pocket.  Thanks!

Hello
I'm wondering why this is called a hack?  I mean gfxpayload is an available grub2 option..

From my standard grub.cfg

Code: [Select]

insmod font
insmod gfxterm
loadfont unicode
set gfxterm_font=unicode
terminal_output gfxterm
set gfxmode=auto
set gfxpayload=auto


Code: [Select]

set gfxmode=autoWill select a platform default suitable for the terminal or you can specify width x height  (supported via VESA BIOS Extensions)

Code: [Select]

videoinfothis command at the grub terminal will list supported modes

Code: [Select]

set gfxmode=1920x1080x24
set gfxpayload=keepto pass the same screen resolution used at the terminal to the kernel

Or you can try

Code: [Select]

set gfxpayload=auto
Just saying that you have control over these variables
good luck

[PDP-8]

setting gfxpayload was just an operational test from replacing the EFI components as distributed in the tcpure64 iso and subsequent burn.  And I suppose too is moving and being able to find the grub.cfg file just an operational test.

The "hack" is replacing the EFI directory from another distro, and having that boot the standard iso without dropping to the grub prompt.  Performing an ls using grub, we find that no filesystems are recognized on any of the available partitions.

Inside the alternate EFI, we find two files:

bootx64.efi
bootia32.efi

These seem to be the key.  I note that tcpure64 iso omits the bootia32.efi.  Even though we are uefi-only 64 bit, does bootia32.efi need to be present to use a fat32 filesystem?

I'm not experienced enough to know if bootia32.efi is necessary, so I'll probably delete it and see by experimentation.

The other question is there some major difference in bootx64.efi between TC and the distro that this replacement came from?

I'm just doing layman type of investigations.  The other stuff such as finding grub.cfg and set gfxpayload are sideline operational issues.

I think part of the problem is those of us using uefi-only hardware discovering corner cases for TC64, as opposed to those using uefi hardware that has csm options available - even if those csm options are disabled.

[PDP-8]

Aha!  could this be an indication of devices using 32-bit uefi, rather than 64 bit?

Most of these smaller consumer level devices from 2015 onwards like Computesticks, Kangaroos and so forth come standard with 32-bit Windows 10.  Yet in their bios setups, one can change that to the 64-bit Linux / Ubuntu choices.

But does that mean the devices are still using a 32-bit uefi?

Is that why the replacement EFI from another distro boots up fine (once it finds grub.cfg, or you manually modify the grub).

Dunno' - the variables are making my head spin.