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

[PDP-8]

Thanks again for the help coreplayer2 - really, this will come in handy when creating your own grub bootloader.

Unfortunately, all attempts to boot with directives above result in "Unknown Filesystem".

Interestingly, when attempting

boot EFI

It says you have to load the kernel first.  But then when you try to do so, it errors up with unknown-filesystem.

This is interesting stuff, but for now I'll go out on a limb and say that *on certain machines*, like my Computesticks or Kangaroos, just build your own bootloader, or rely upon other bootloaders and shoe-horn it in.

Heh, TC is made nicely to do that in the first place, so I'm not sweating it.

I'm taking a break from it for now, but certainly you've schooled me quite a bit, which will come in handy later.

[PDP-8]

Ok, enough break.  Time for a thought-experiment:

(and shouldn't have X-Files playing in the background)

Is it possible that when the iso image was made for TinyCorePure64, that the grub-mkimage simply did not contain filesystem support for fat32?

Aha - most burners from windows burn fat32 only.  But the emphasis we see here is to NOT use fat32, but a real linux fs like ext2 for sticks.  DD is unusable on my machines since they won't show up in the bios as a bootable device, so the image is burned iso9660.

Yeah, sure, grub will *launch* itself from fat32, but that also needs to be specified when doing the grub-mkimage procedure.

Tinfoil hat time:
If in fact fat32 was not used during the grub-mkimage, despite loading the modules, is this an oversight, or just a way to dissuade us from using fat32 filesystems on our sticks?  Or nudge us to burn our own doing so? 

"Scully, I'm telling you something's going on here when grub crashes"
"Oh Mulder, you need to get out more often"
"Scully - something's a foot, the man is trying to make fat32 go away!"
Suddenly the smell of stale cigarette-smoke appears as the smoking man draws back the curtains.....

[PDP-8]

Want to be "fat-free" with uefi boot?  Simply don't use fat32 at all.

Despite warnings about "mandating" the use of fat32 for uefi-boot, all it really says that if you are to call yourself "uefi compatible", you should demonstrate that you can do so with fat32.  Not that you *HAVE* to.

For instance, I just burned TinyCorePure64 iso with gpt mode, but this time chose NTFS as the filesystem.  To get the ntfs filesystem support, I had to hack in the efi file from Puppy, and move the original grub.cfg as talked about earlier.

Guess what ?  It boots all the way to the commandline.  It tries to load the extensions and leaves me in the ash prompt.

I can fix it, but I'm not going to spend my time using NTFS as a boot filesystem with TC.

Just a proof for those making their own bootloaders, and if you want to be fat-free or whatever, you can use ext2 or whatever you like.  Laugh at the online references about "mandating" fat32 for uefi.

[coreplayer2]

[emoji85]


Sent from my iPhone using Tapatalk

[PDP-8]

Yeah, I'll take a break from being OT and long winded.

I just find it interesting that using fat32 for the uefi partition is not actually mandatory - one can use any filesystem they want as long as it is driven properly.  But this seems to have been repeated so often that it is taken for truth.

Wait - what?  My entire stick can be ext2, or xfs or whatever I like - including the efi partition?  Truth.

[coreplayer2]

I just find it interesting that using fat32 for the uefi partition is not actually mandatory - one can use any filesystem they want as long as it is driven properly.  But this seems to have been repeated so often that it is taken for truth.

Wait - what?  My entire stick can be ext2, or xfs or whatever I like - including the efi partition?  Truth.

Not exactly true,  firmware capacity has traditionally been limited.  Therefore manufacturers will likely provide support only for intended Operating Systems.

For compatibility FAT support on all machines is provided for sure, NTFS is often provided to support Windows installs on drives without an ESP.   

Apple products support FAT and AppleFS on recent mac’s

I could be wrong here but even with recent increases of bios/firmware memory only pc’s destined for linux or sold without an OS might  provide support for ext

Maybe one day, Right?


Sent from my iPhone using Tapatalk

[nick65go]

grub-mkimage is the key central for grub to build all other stuffs when needed.
For example, grub-[install,mkstandalone,mkrescue] all refer to the use of grub-mkimage, so once grub-mkimage is understood, everything looks easy to do.
grub-mkimage has 2 ways to "attach" a config file to its image :
    option -c,--config=File (embed FILE as an early config)
    option -m,--memdisk=file (embed FILE as a memdisk containing eventually config file)

Example of an embedded configuration for a UEFI boot from "ISO-type" inside:

Code: [Select]

set pager=1
root=(cd)
configfile (cd)/boot/grub/grub.cfgThe memdisk is a virtual disk device viewed by grub, having a tarfs filesystem; the various modules sitting there are "ready for use", meaning they can be loaded by insmod directly. But they are not directly call-abled as "preloaded modules" as those in the options --modules="blah blah...:" (the last ones are similar to drivers loaded in initramfs in Linux OS)
sample Optional miniHDD GrubBIOS

Code: [Select]

grub-mkimage.exe -v -o grubBIOS-core.img --format=i386-pc --prefix="(hd0,msdos1)/boot/grub" biosdisk iso9660 part_msdos fator the equivalent for UEFI64:

Code: [Select]

grub-mkimage.exe -v -o grub_x64.efi --format=x86_64-efi --prefix="(hd0,gpt1)/boot/grub" part_gpt fat EDIT: FYI, my UEFI-HDD bootloader [1grubx64-gpt.efi] has 118 KB (121,344 bytes) 

 EDIT2: my BIOS boot (for Virtual machine) with almost all modules included (grub202-i386-cdrom.core) has 376 KB (385,024 bytes).
These are to prove that we DO NOT necesary need the folders i386-pc, neither the x86_64-efi; we need just the main bootloader and eventualy a configuration file (grub.cfg), and even the configutarion file can have an arbitrary name, because we will ask for it using grub-directive "configfile bla-bla-file".

[PDP-8]

Ah, interesting!

Leaning forward from my rocking chair and shaking my fists, I'll go OT for a sec and stop.

This is all great stuff - but I think loses many, even the TC diehards, if the uefi-only stuff doesn't boot straight away and you have to mess around with custom grubs.

Two analogies - in the old days, one just popped their DSL cd into the machine, booted and went to town for the most part.

Prior to that, one used kermit to download binaries, and used an ms-dos utility, RAWRITE.EXE to create boot/root/userland floppies.

But they didn't have to get their dos C-compiler out, and create rawrite.exe on their own.

Ok, bad analogy perhaps, so I'll duck out for awhile...

[labeas]

The forum statistics confirm the wave of <anti-M$-lockout> needs.
My recent attempt, based on the 2015 article:
 "Howto make a legacy bios/uefi dual boot usb stick with grub2"
worked for the TC64 grub-entry, but not for the <core32bit>.

While searching for the Wifi hardware/firmware I destroyed one
partition, and before reinstalling, I need to install Ver10.x
on this laptop, currently runing Ver7.2.
This: in order to better fetch the Ver10.x files for the.
<uefi laptop>.

I can't remember how I initially installed Ver7.2 TC64 ?

The online "Installation" instructions are confusing !!.

> "The guide assumes you've either booted the CorePlus CD, or have
> installed the tc-install extension (tc-install.tcz)"

No! No CD hardware available.
How can tc-install.tcz be used *BEFORE* TC is installed & running ?!

It was quiet a problem to get Wifi working on the TC64:Ver7.2.
If I have the URLs:
 then ver7.2 can fetch the required files for installing Ver10.1.

Perhaps I used YUMI...rufus...to install vers7.2 ?

Please advise howto:
1. install current TC64.
2. are instructions of <2015 article> still valid?

PS..
I appreciate the <tabulated, instead of chatty-format: instruction-list>
 given earlier in this thread.

[PDP-8]

labeas - I really think you are a candidate for using YUMI-UEFI multiboot for your project.  There is the original YUMI, and the more recent YUMI-UEFI.  I would choose the newer version for your Aptio.

You've already paid your Microsoft-tax, perhaps many times over your lifetime like all of us purchasing computers with dos or windows pre-installed.  What better way to get back some of your investment by using a GPL'ed windows tool to get your troublesome setup going.

I've gone into depth about it here:

http://forum.tinycorelinux.net/index.php/topic,23010.msg143982.html#msg143982

But if you want the checklist approach, here it is.

1) Download the Tinycore iso(s) you want to boot from the Windows box.
2) Use YUMI-UEFI to burn the iso(s) to your usb stick.
3) Copy and paste the cde directory to the root directory of your usb stick.
4) Rename this cde directory in the root, to tce.
5) Find the grub.cfg file in the TinyCorepure64 directory.  Don't mess with other grub files earlier in the path, as they pertain to YUMI itself.

It can be found here:
/mnt/sdaX/multiboot/TinyCorePure64-10.1/EFI/BOOT/grub/grub.cfg

6) Change the reference in the TC and TCW subsections from "cde" to
tce=LABEL=MULTIBOOT

This should serve as a guideline if you want to run the 32 bit version, although I have not done so.

Note that I don't use the multiboot feature.  But if you do, you may not want to share a tce directory.  In the case you are multibooting say 64 bit and 32 bit, you might want to have tce64 and tce32 directories in the root.  Change your grub.cfg to point to those accordingly.

Of course, the stick is fat32.  NOT exFAT, but fat32.  Maybe you are ok with that.  If not, then you'll have to dig harder with a manual install.

Maybe this will relieve some of the problems.  And don't forget - back in 1992, I had already purchased MS-DOS many times over retail, and used RAWRITE.EXE inside dos to create the boot/root/userland floppies for Slackware.  Trying to remember if I paid for mbasic-80 on my CP/M machine or if it was part of the "tax" even back then.

So I'm not defending Microsoft and their actions, but I am merely saying, you like most of us, have already paid $$$ in ms taxes.  Maybe make use of it with a clearer conciousness with YUMI?

[Juanito]

Please advise howto:
1. install current TC64.

* Download the latest corepure64.gz and vmlinuz64
* Rename the above to corepure64.gz_tc10 and vmlinuz_tc10
* Copy corepure64.gz_tc10 and vmlinuz_tc10 to the same place as your current files
* Edit your boot loader config and create a new menu entry referencing corepure64.gz_tc10 and vmlinuz_tc10
* Edit the new boot loader config menu entry and name the tce folder tce64_tc10
* Boot the new menu entry and load extensions from scratch

[labeas]

 I haven't studies the replies. Just want to get this report off
 before my memory of the events fades. Using USBstiks on laptops.
 By <trying something> I lost the ext:Patn1 of the <Grub2UEFI>.
 Since I'd already put info on the FAT:Partn2, I kept that.
 AFAIR the TC64 grub entry had been somewhat usable, before
 being lost.
 Now with the new attempt, the "core" entry of <grub.cfg> is
 usable. `uname -a` and `less /proc/cpuinfo` don't show me if
 I'm running 32 or 64 bit.
 
 On the older/less problematic laptop: finally: version == 7.2
 does tell something.
 I've installed V10.0, but the Wifi is problematic.
 Perhaps the book explains the different: "core", "base" ?
 
Observations:
  It's natural to try to INSTRUCT as if the reader was a PC;
ie. "doA ; doB ; ... doN"
Much better, for complex tasks is like prof <Wurz of Pascal>:
 "A causes Ai ; B causes Bi ; ... N causes Ni"
From this the user can CONFIRM the chain/pipe of Ni effects,
to much easierly find the faulty-stage.
What also helped me was the reminder how powerfull GRUB2 is:
 can single-step and examine details of the system, eg.
 devices UUID and size ...etc.
 to confirm what /device/partn/dir/file GRUB2 *CAN* access.
The 2019 July published script <How2 eg. fetch-for-installing
*.tcz for coreVer10.0 using TC64Ver7.2's Wifi facility> was
very valuable.
 
Let me now go to the new/problematic laptop to use the running
TC, to see the <grub.cfg word/s which I deleted from the
recommended entry, which has allowed TC to boot & run.

From: menuentry "core" - to give me "coreB" ,
 I've deleted: "quiet text tce=UUID=....."
 
PS. I've installed gpm & mc & LinuxNativeOberon gives a Frame-
Buffer-based GUI/text application.
12 times: `sudo openvt` gives 12 root-terminals, until `startx`
runs. And links is a killer-app; and links2 even does grafics
by FrameBuffer. Let's try that script to fetch it/them !!

[Rich]

Hi labeas

  ... `uname -a` and `less /proc/cpuinfo` don't show me if I'm running 32 or 64 bit. ...

If  uname  says  VERSION-tinycore  it's 32 bit. if it says  VERSION-tinycore64  it's 64 bit.

[PDP-8]

Another quickie way I found was that 32 bit runs with topside for the titlebar, and 64-bit defaults to the titlebars on the side.

Of course adding topside to 64 bit makes this a little less "visual" quickie.

But yeah, just run "uname" if you lose track like I do.

[labeas]

Use sequential/piping method, starting from working Model,
  to find STAGE/s of failure of Grub2Multi:UEFI project.
============ Working grub.cfg Entry ==
linux /boot/vmlinuz waitusb=10:UUID="bfe6116c-473a-4ee9-bbac-3638039dc9ad"
initrd /boot/rootfs.gz /boot/modules.gz
============= Failed grub.cfg Entry ==
linux /boot64/vmlinuzBigr waitusb=10:UUID="bfe6116c-473a-4ee9-bbac-3638039dc9ad"
initrd /boot64/rootfs64.gz /boot64/modules64.gz
=== Confirm SingleStepping working Model's parameters; using <manually boot> text.
-------------> the following is manually copied: <may have errors> !!
grub> deliberateError == can't find cmnd
grub> ls / == boot/ .... <no EFI ?!>
grub> ls /boot == ... vmlinuz  rootfs.gz  modules.gz
grub> linux /boot/vmlinuz == no Reply
grub> initrd /boot/rootfs.gz /boot/modules.gz == slight delay ? Action?
grub> boot == Thankyou ! = Usable TC.               $ version == 10.0
=== test SingleStepping failed entry's parameters; using <manually boot> text.
grub> ls / == boot/ .... <no EFI ?!>
grub> ls /boot64 == ... rootfs64.gz  vmlinuzBigr  modules64.gz
grub> linux /boot64/vmlinuzBigr ==  no Reply
grub> initrd /boot64/rootfs64.gz /boot64/modules64.gz == slight delay ? Action?
grub> boot == TC Logo, shows "modprobe...modprobe...modprobe
<"busy with 50 thread for more than 5 sec now... Failed to executeb /init>
      "Rebooting in 60 seconds"

---- previous post re. <manually boot> :
    Online coreplayer2
     * Quote
   To manually boot the kernel

   Code: [Select]          >   OWN results
   grub> ls /
   boot EFI                > boot/tce/ Set1 boot64/ MountSDcard
   grub> linux /boot/vmlinuz64 quiet
   grub> initrd /boot/corepure64.gz
   grub> boot
   Or

   Code: [Select]
   grub> linux (hd0,msdos1)/boot/vmlinuz64 quiet
   grub> initrd (hd0,msdos1)/boot/corepure64.gz
   grub> boot
=====
?! best not use "quiet" and WASTE all valuable debug info ?
TC's idea of building from an updating repository, causes the
MOVING TARGET PROBLEM. For serious work I must use my ver 7.2.
Q: are these sizes correct/compatible:
  vmlinuzBigr   4106416
  rootfs64.gz   3595754
  modules64.gz  6826959

AFAIR there was some inconsistency in the repository IMO.

==TIA