Off-Topic > Off-Topic - Tiny Tux's Corner
a rant/discussion about grub bootloaders - MBR and EFI
PDP-8:
Wait - the current TC64 is bootable *as is* on UEFI-only machines? I'll try that like an ordinary newcomer would and see, rather than partition and format my own.
I have plenty of little 64 bit boxes from hybrid uefi/csm, to uefi-only and check it out again. They key issue is to actually HAVE a uefi-only machine, and not a hybrid, where the user can introduce settings that are problems.
Secure boot: not a problem. If enabled, simply turn it off. In fact, most of the small machines that make a GREAT environment for TC, like those little "hockey puck" sized boxes (typically 2gb ram, 32gb emmc, Atom cpus etc) even with Windows 10 on the emmc, come with secure-boot disabled.
To make it even easier, with uefi-only, there are NO other options for the user to worry about, like CSM etc. ! Its a uefi-only box, and secure boot is a different issue. Simply disable secure-boot and go to town.
BUT, that also means that you must have a usb stick properly formatted and partitioned (efi partition and all that) to work. And that is the stumbling block, NOT the easily defeated secure-boot.
We still have to remember that TC is more properly a *toolkit*, rather than a "distro", where if anything does not work, we already have the requisite skills to make it work, or build up into anything we desire, from simple cli only to a fully blown desktop - it's up to the user.
Note: time-warp back to the 1980's, and if TC was around, each forum message asking for assistance would be a $20 service charge. :)
So thanks to the devs for putting in all their time, not only to keep TC fresh, but also providing support on their own time.
PDP-8:
Emulating what a normal modern user would do for TinycorePure64 --- bzzzt. NOPE, not bootable *as is* on a uefi-only machine as a modern user would expect.
In a spirit of exploration, and NOT a mean-spirit of finger-pointing:
1) Secure boot has nothing to do with it. Just disable it if enabled. NOT a variable now.
2) If anyone knows how to make a usb-stick bootable, it would be the antiX / MX Linux guys. So let's use their tools for TC instead of they typical Ubuntu etc.
Nope. They, like other "usb burner" tools, only dd the iso. Just like Etcher. Just like Rufus unless told otherwise. YUMI-Uefi is the only odd man out since it DOES change the iso.
So let's count out Yumi since advanced users can recognize the mistake it makes. The point is, whether using other common Windows burners, or even linux "dd-based" burners, the TCpure64 iso won't boot as is on uefi only machines.
But again - it is NOT a problem with easily disabled secure boot. It is NOT a wild variety of csm-hybrid issues.
The problem is NOT with the usb-burner "dd" type tools. It is not a hardware issue since if one actually knows HOW, they "simply" format and partition the usb stick on their own with an efi partition properly set up in grub. Typically with the EFI partition last, not first - like most others.
Some might say that tc just simply does not follow convention, that's all. No shame or fingerpointing intended.
The point is, someone that might show an interest in TC is simply going to walk away and blame Tinycore since most everything else works with standardized "dd" type of burning. Others might wave the finger at "that damned secure boot - or uefi only conspiracy. Simply not the case.
At the end of the day, since we have proven that secure-boot, uefi, and even 3rd-party burners are NOT the problem:
1) Do you make your distributable iso follow common standards to allow these burners, or "dd"ers to work as expected in today's world and stop blaming them?
2) Or do you expect users to simply format and partition their sticks for uefi properly by themselves when they have never done so in a modern environment to simply burn and boot?
I'm not making a moral judgement here. I've done the burn and boot. Then again, I've done the DIY thing too to get TC to boot properly.
Just don't blame secure-boot, dd burners, or supposed uefi complexity. Those are not the real issue.
Rich:
Hi PDP-8
I only had to deal with UEFi once so far.
--- Quote from: PDP-8 on June 28, 2020, 06:16:24 PM --- ... (typically 2gb ram, 32gb emmc, Atom cpus etc) ...
--- End quote ---
Yeah, that's the one, a real basket case.
To make a bootable USB stick I had to:
1. Setup a GPT partition table.
Partition1: Filesystem=FAT32 Flags=msftdata
Partition2: Filesystem=EXT2 Flags=none
2. Install 32 bit grub2-multi bootloader. (64 bit processor running 32 bit UEFI firmware)
3. Install vmlinuz64. (32 bit kernel won't boot for some reason)
4. Install core64 (cat rootfs.gz modules64.gz > core64.gz) so I could run 32 bit programs. RAM is limited to 2 Gig and not
upgradeable, so no point in running 64 bit programs.
PDP-8:
Yup Rich, that kind of how I do it manually myself.
But that's 4 ways for a modern user to get it wrong. :)
Seems simple, but then again back in the day before cd iso-burner utilities were common, all we were pointed to was to grab all the stuff you needed from a repo, and simply use the mkisofs and cdrecord utils. Most users were blowing those commands, and the cd iso burner utils were a godsend when they arrived.
Time warp: "Dude, I don't need to make the iso bootable, just used mkisofs and cdrecord on the image and all will be fine."
<grin> :)
PDP-8:
MultiBootUSB project - tested and works. I only use it to boot a single instance of a TC iso however. Used the TinyCorePure64-11.1 iso.
Found a nice replacement for YUMI-Uefi. Intended for those experienced with TC and recognizing that this is outside the norms of support, not to ask devs questions about something they are not responsible for! YOU are.
Tried the latest MultiBootUSB burner ver 9.2.0 for both windows and Linux. Works great on all my 64 bit machines, including the very modern uefi-ONLY box.
Unlike simple dd'ers which just transfer the iso's to a stick, MultiBootUSB (like YUMI) makes big changes to the stick - most notably the use of other bootloader menus. Fortunately, the last menu is the standard TC menu, and allows you to change the kernel cheat-codes, and the usual TC grub.cfg is in control as usual.
And unlike the latest YUMI, it gets the filepaths correct!
Sure enough - all you have to pay attention to when you look at the stick it builds, is everything BEYOND
--- Code: ---/multiboot/TinyCorePure64-11.1
--- End code ---
for example and do the usual things. Rename cde to tce, adjust your grub.cfg to your likeing, etc. Hide your eyes to what lies before the /multiboot directory. :)
I actually always prefer just to move the entire cde directory to the root directory of the stick and rename that directory to tce in the process.
If you made the stick on Windows, you may want to clean up some dos ctrl-M line endings for grub.cfg seen with the less pager with a simple
--- Code: ---sudo dos2unix ./grub.cfg
--- End code ---
The gui interface in both windows and linux may seem to stall at first - but simply wait until you get the notification it is finished. At first it seems like the progress bar isn't moving and nothing is happening, but if your drive has an led on it, you'll see it is working. Just be patient.
Select drive.
Select iso.
Install Distro.
(don't shoot yourself in the foot with other options, unless you know what you are doing.)
That's it, other than being familiar with TC being very beneficial. Once I got some dependencies fixed for the Linux version (mtools, some python tools), I was glad to see the same interface.
So for now when I feel lazy, I think MultiBootUSB is now my 3rd party burner of choice. It seems to get everything right.
BUT - like all 3rd party stuff that the devs of TC have no control over, the next version may break so don't cry. :) Again, familiarity with how TC works in the first place is recommended.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version