WelcomeWelcome | FAQFAQ | DownloadsDownloads | WikiWiki

Author Topic: Yumi can't boot RH6.2 ?  (Read 1752 times)

Offline labeas

  • Sr. Member
  • ****
  • Posts: 266
Yumi can't boot RH6.2 ?
« on: April 21, 2020, 08:21:21 PM »
A writer here was advocating YUMI for UEFI problems.
-----------------
I decided to first try it to install OLD;RH6.2, to try to run
1990's:poplog. But boot & stepping to <RH6.2> shows
 <16bit version too old for 32b system>.
Probably the RH6.2 kernel was critcaly incompatible with YUMI ?!
Since the UEFI-problem-laptop CAN boot TC64 without Yumi, I'd like to
try Yumi on my other 32b-installed devices: Deb7, slax, Slackwr13.
All 8 <SanDisk/market-default> stiks, wear-away at PLASTIC plug!
10% more price gets Toshiba-stiks with METAL plugs.
With 2 laptops & 12 USBstiks: I don't find my Yumi-install-logs !
With CoVirus crisis, I've only got 1 4hr per week Wifi access!
Yumi-RH6.2stik has MASSIVE/intimidating DirTree compared to TC-booter.
How to add files for other intallations via existing Yumi-RH6.2-stik ?
==TIA.


Offline PDP-8

  • Hero Member
  • *****
  • Posts: 915
Re: Yumi can't boot RH6.2 ?
« Reply #1 on: June 26, 2020, 04:30:35 AM »
That would be me. :)

Normally I make my own TC64 uefi sticks with ext4 and an esp partition manually, but I still will use YUMI-UEFI on occasion to whip out a 64 bit stick that turns the iso9660 iso into a fat32 type that is writeable and boots.  I don't use it for it's intended purpose of multibooting, just a single boot for uefi when I'm lazy to construct one the right way.

Be sure you are using the UEFI version, which as of now is at 0.0.2.2

The massive tree can be tamed by concentrating on everything past
/multiboot/<your distro>

No need to go prior to that in the tree, unless you want to help the Yumi developer. :)

BUT understand that you are basically on your own for support from either development party, and it would be unfair to file bug reports from one to the other!

Example: in ver 0.0.2.2, I found that the EFI/boot/grub.cfg for TC64 has two errant lines that have faulty filepaths for vmlinuz and the gz file preventing boot.

But they were easy to spot and rectify, (basically a duplicate start of a filepath).
In addition, some of the gfxpayload and other variables may differ from the canonical values in TC proper.

In other words, if you are familiar with your own distro and can spot any errors that look out of place, it works fine - just don't ask the devs for help - not fair to either party.
That's a UNIX book! - cool  -- Garth