Tiny Core Linux

Tiny Core Base => TCB Q&A Forum => Topic started by: killingtime on April 04, 2017, 11:03:53 AM

Title: [Solved} USB boots to TC@BOX:~$ prompt, not Tiny Core Desktop
Post by: killingtime on April 04, 2017, 11:03:53 AM
Hello,

I've loaded tinycore (CorePlus-current.iso) onto a USB flash drive using core2usb and am booting a thin client computer (Cyrix 686).

Selecting 'Core Plus w\default FLWM topside' from boot menu. I get as far as the  TC@BOX:~$ prompt but cannot get any further.

'Into The Core' pdf doesn't have anything on this but the issue has been reported already.

http://forum.tinycorelinux.net/index.php?topic=17829.0

I'm getting "-sh: xsetup: not found" and "-sh: startx: not found"

The last post in the above thread asks for dmesg.

How do I copy this file onto the usb flash drive?

Thanks,


Title: Re: USB boots to TC@BOX:~$ prompt, not Tiny Core Desktop
Post by: coreplayer2 on April 04, 2017, 11:12:00 AM
Hi killingtime

First be sure to check you have the bootcode " waitusb=10 " in your boot config file command line

Something like:
Code: [Select]
KERNEL /tce/boot/vmlinuz
APPEND initrd=/tce/boot/core.gz opt=sda1 home=sda1 waitusb=10
Title: Re: USB boots to TC@BOX:~$ prompt, not Tiny Core Desktop
Post by: polikuo on April 04, 2017, 11:13:19 AM
The last post in the above thread asks for dmesg.
How do I copy this file onto the usb flash drive?

1. Plug in the USB (preferably formatted to ext{2,3,4} or fat32)
2. sudo rebuildfstab
3. mount /mnt/sdXY ("X,Y" depends on your machine)
4. dmesg > /mnt/sdXY/dmesg_out.txt
5. sync (just being safe)
6. sudo umount /mnt/sdXY
7. remove your USB
Title: Re: USB boots to TC@BOX:~$ prompt, not Tiny Core Desktop
Post by: killingtime on April 04, 2017, 11:35:15 AM
Thank you for the commands.

https://pastebin.com/YExFr5qX

Regards.
Title: Re: USB boots to TC@BOX:~$ prompt, not Tiny Core Desktop
Post by: coreplayer2 on April 04, 2017, 12:43:34 PM
Hi Killingtime

The most common cause of being unable to boot into a desktop after installing to a USB is not having the waitusb=10 bootcode.  Besides that you are also using the cde bootcode which is wrong for a USB or hdd install. 
Your dmesg confirms this is the issue.
Code: [Select]
Kernel command line: initrd=/boot/core.gz loglevel=3 cde showapps desktop=flwm_topside BOOT_IMAGE=/boot/vmlinuz
Since none of your installed extensions are loading,
replace cde with waitusb=10 and you should have success

Oh and don't forget to remove the tinycore cd
Title: Re: USB boots to TC@BOX:~$ prompt, not Tiny Core Desktop
Post by: killingtime on April 05, 2017, 12:54:26 PM
That worked.

Thanks.
Title: Re: USB boots to TC@BOX:~$ prompt, not Tiny Core Desktop
Post by: techsuper on May 31, 2020, 07:33:38 AM
Hello,

I decided to re-install 11.1 32bit for a clean install.
I have previously installed 11.0 and 11.1 three or four times successfully from a USB drive.
Both booted and displayed the desktop as expected.

After downloading the iso twice, rewriting to 2 drives, writing with etcher or rufus, using hiren to clean the hdd first and
trying at least 10 times with 11.0 or 11.1, using tc-install or the tc-install gui.

EVERY TIME it stops at the tc@box:~$ prompt.

Oh and btw, Using the SAME hardware that I used before, with NO CHANGES to anything.

Web searches vary wildly and I shouldn't have to do the edit this file, dmesg this or rebuild that or initrd or .......
maybe a seance with a high priest might help?

TC documentation says to type Startx or Xsetup, but both yield the -sh: not found error message.
What could I possibly be missing?

thanks in advance.
brent
Title: Re: USB boots to TC@BOX:~$ prompt, not Tiny Core Desktop
Post by: Rich on May 31, 2020, 07:50:46 AM
Hi techsuper
One of the options presented by  tc-install gui  is  Install X  or  Install GUI  (I don't recall the wording). Did you remember to select
that option?
Title: Re: USB boots to TC@BOX:~$ prompt, not Tiny Core Desktop
Post by: techsuper on June 07, 2020, 06:52:54 AM
Thanks for that info Rich, but their isn't any choice for that option.
The only place that may present something like this, is in the Boot Options page.
(choices for xsetup and vga=7xx), but I've always left field blank.

The next prompt asks to Install Extensions from a TCE directory, which I thought I had always left blank.

But after a few more attempts, choosing a TCE/CDE directory on the usb stick during this prompt does
yield a Desktop GUI. Maybe I choose this option originally but totally spaced it out after fighting for
a month getting a printer to work. - sorry.

So does this mean that even though the description for TinyCore says: 
"includes the base Core system plus X/GUI extensions for a dynamic FLTK/FLWM graphical desktop environment".
 having a graphical desktop is still an extension to the command line only install?

Wow, guess I have to forget everything logical I've ever learned!

take care
brent

on to the next challenge.


 


Title: Re: USB boots to TC@BOX:~$ prompt, not Tiny Core Desktop
Post by: NewUser on June 07, 2020, 11:31:16 PM
The next tome you boot your USB, hit tab at the window manager menu. The cursor will show up at the bottom of the display. Enter waitusb=10 with a space before, then hit enter. That should get you to the GUI desktop.
Title: Re: USB boots to TC@BOX:~$ prompt, not Tiny Core Desktop
Post by: PDP-8 on July 30, 2020, 03:04:22 PM
Still relevant because one may run into this to this day.  Some hints:

The tc-install gui from CorePlus automatically picks up the embedded extensions inside itself without any user intervention to go wrong.  No problem.

But, if you use CorePlus and tc-install gui to make a bootable usb stick - also choosing to include the installer to make yet another one - there's a difference.

1) From the subsequent new stick, unless you download and load at least one application, the /tmp/tce/optional directory is not fully populated until you do.

Trying to burn another stick (say for a friend) using the tc-install-gui without the /tmp/tce/optional directory populated gets you to the $ shell prompt on subsequent reboot.  So it appears you need to download and install at least one tc-app.

OR, be sure you have set and tested persistence on another device.  That is, use tce-setdrive to set your persistence.  The objective here is when you are telling the gui where to pick up your tce/cde directory, you no longer point at /tmp/tce, but target the new location, say /dev/sda1/tce

For some strange reason (99% sure it's my own user error somewhere), this doesn't always result in success on the new stick you create.

I noticed that on ver 7.2 this works.  But not on 11.1.  In all cases, the extensions ARE there in my /dev/sda1/tce/optional, but I'm still working out why this is not seemingly consistent.

Somewhere I'm missing something, possibly due to fatigue, that might be a common mistake.

In the future, when mentioning an issue with TC-Install-GUI, be absolutely sure to inform us of whether it came from CorePlus (always works), or if it is from a subsequent burn, where picking up the embedded extensions seems a little weird.

I'm looking into it.
Title: Re: USB boots to TC@BOX:~$ prompt, not Tiny Core Desktop
Post by: PDP-8 on July 30, 2020, 05:02:23 PM
On the to-do list:

Target : blank formatted usb stick.  NOT MADE with CorePlus iself, but either subsequent sticks, or direct repo downloads of the installer.

Differences to test:  is there an inconsistency whether the operator choose between frugal, usb-hdd, or zip-disk?

What's the significance of the highlighted directory shown in the filepicker with a trailing slash, whereas the filename indicated below it does not include the trailing slash?  Does it matter - can we ignore it?

Once a TC installation has a persistent tce directory enabled on the root of the target filesystem, TC in my experience always picks up on that, even if cde is not removed from the boot config.

Is something missing when one does a tce-setdrive, and subsequently points the gui installer to the tce directory there (which is populated!), yet results in the shell regardless.

These are the variables I'm juggling with the NON-coreplus installation of the gui installer itself.  Whether made by the initial Coreplus installer to install-the-installer itself to a subsequent bootstick, or whether the operator simple uses a bootable iso, and immediately downloads the gui-installer from the repo and tries using that immediately.

Fortunately, these aren't the days of CDR's, so I won't burn through an entire spindle to find out what's up. :)
Title: Re: USB boots to TC@BOX:~$ prompt, not Tiny Core Desktop
Post by: PDP-8 on July 30, 2020, 07:32:11 PM
FOUND THE PROBLEM!

1) It all stems from the typical usb-stick(s) only environment and drive-ordering.

2) If this is wrong, the gui utils will still allow you to go through the motions thinking everything is ok, but it is NOT.

Setup:
A: You successfully burn a bootable stick from the iso.  No problem, it all looks nice.

B: Insert another stick to use for persistence. Run tce-setdrive and properly identify that new stick device name for use.

C: Make a small junk textfile as a test to prove persistence after reboot.  Reboot.

D: *** Depending on how your machine boots up the drive*** which it will, if you use the MOUNT-TOOL and hover over your devices and display labels, if you are lucky, they will match to the device name.  BUT, if your machine brings up these sticks in a different order, MOUNT-TOOL if you hover, will show that the LABELS are backwards!  Ie, the label does not match the device name , ie sdb1, sdc2 and so forth have the wrong labels.

E: The thing that can throw you is that the EXIT util, where it shows the device pathname it is going to save your mydata.tgz will ALSO be wrong, yet IT will still write to the proper device as initially set up in tce-setdrive!  This is the false sense of security - if you don't pay attention, you won't notice the disparity unless you put a magnifying glass sense of attention to the device path it wants to save to.

HACKER SOLUTION:
Before you do anything involving tce-setdrive, or using the TC-installer gui, use the MOUNT TOOL and hover to be sure your drives are labeled as what they say they are.  If not, change ports of the sticks until they do!

Then go ahead.

Ie, my machine boots the 3.1usb ports first, but when I initially burned my iso, I booted it from a random 2.0 port.  Which worked, but as I quickly found out upon reboot, with my persistence stick in use, the device assignments were totally jacked up.

Advanced users will quickly notice this by running blkid, which doesn't match the mounted device name.

And most troubling of all, is that the EXIT util, even though showing the wrong device pathname to save to, actually does save to the right device.

Ultimately, UUID's are the answer, in the cheatcodes or by manually editing your bootloader since we've seen that the mount-tool can get the labels backwards, depending on how your machine sees them first.

So there you go - advanced users use blkid and go to town.  Hackers, just change the order of your usb stick ports after creation, and hover with mount-tool to make sure the labels are correct before going any further.




Title: Re: USB boots to TC@BOX:~$ prompt, not Tiny Core Desktop
Post by: aus9 on July 30, 2020, 07:45:06 PM
seeking clarity please.

Are you suggesting that you have 2 USB devices at boot up?

Are you suggesing that one is bootable and the other is not?

Are you suggesting that the bootable one is currently using a tce=sdXn or tce=LABEL=label-name?
And you propose to only use tce=UUID=uuid-string

The one that is not bootable is your target tce dir?
Title: Re: USB boots to TC@BOX:~$ prompt, not Tiny Core Desktop
Post by: PDP-8 on July 30, 2020, 08:05:01 PM
Well, what I'm saying is that if your drive-ordering is not correct upon reboot, mysterious things like following the advice to *remove* cde from your boot cheatcode, or grub.cfg leave you at the shell prompt.  Just the opposite of what you'd expect from the forum help.  (no disrespect, they aren't sitting in front of your box!)

So everything is peachy for some.  For others, it's shell prompt time, even if they follow the book or recommendations here.

The project to find out why it seems so hit-n-miss, started from a 2-stick setup:

ISO-BOOT stick.
PERSISTENCE stick.

From those two components, I used TCE-SETDRIVE to properly set up a persistence stick that I can point the tc-install-gui to when it asks you to point to the TCE/CDE directory to nab the embedded tcz's from, rather than from /tmp/tce

Where things started to go pear-shaped was when I noticed that when I initially booted with BOTH sticks inserted, sure, boot went fine.  But then when I ran tce-setdrive, it put the tce directory into /dev/sdb and not /dev/sdb1 !  What's up with putting it into a device directly, and not the partition?

So then I booted the ISO-BOOT stick solo.  Inserted the PERSISTENCE stick after I had booted.  Now (after totally reformatting my persistence stick to start over) tce-setdrive put the tce directory into sdb1 like I expected.

So this got looking around noticing that mount-tool hovering was showing labels being backwards.  And the exit gui saving my persistence to the wrong device, although in reality, it DID save to the right device!

So I looked at my foot, and sure enough I had blown a hole in it by not having the right device drive ordering at the outset.

Ultimately, this is what confuses the tce-installer gui and operator alike - they *think* they are directing it to the right device pathnames, but they are not.

I mean, it's not a problem for me, I was just trying to think what the average or even medium-joe is struggling with when the device pathnames and labels are jacked due to how their system sees them in order.


Title: Re: USB boots to TC@BOX:~$ prompt, not Tiny Core Desktop
Post by: Rich on July 30, 2020, 08:13:27 PM
Hi PDP-8
From the FAQ (Emphasis mine):
Quote
Tiny Core supports UUID and LABELS.

 This is most helpful when using pendrives on different machines and you want to "anchor" your Tiny Core boot codes to a specific device.

 To find the UUID of a device use the command blkid
blkid -s UUID /dev/sda1

 You can mount devices by UUID with the mount command, e.g,
# mount -U 4773-DFE2

 The UUID tends to be long, so best to cut and paste into your menu.lst boot options.

 You can now specify the device to be used by UUID as follows:
tce=UUID=4773-DFE2 home=UUID=4773-DFE2 opt=UUID=4773-DFE2 restore=UUID=4773-DFE2

 Typically this is helpful when using pendrives, be sure to add the waitusb=5 option.

 Advanced users may add a specific device to wait for, with the time limit being the maximum time to wait:
waitusb=30:LABEL=tinycore
 waitusb=30:UUID=4773-DFE2




 You can now also use LABELS. This too is optional.

 To write a label on the partition of a pendrive, use the command tune2fs
# tune2fs -L tinycore /dev/sda1

 You can check your results with
blkid -s LABEL /dev/sda1

 Then you can specify devices by LABEL, e.g.
# mount -L tinycore

 For Tiny Core boot options use:
tce=LABEL=tinycore home=LABEL=tinycore opt=LABEL=tinycore restore=LABEL=tinycore
To me that says don't specify drives by /dev name.
Title: Re: USB boots to TC@BOX:~$ prompt, not Tiny Core Desktop
Post by: PDP-8 on July 30, 2020, 10:12:45 PM
Thanks Rich!  But here's the sad news in regards to uuid ..

With all that boot order business behind me, I proceeded to let the tc-install-gui install and test some more.

At all times, ended up at the $ prompt.  Details:

I did a blkid at the prompt, and the uuid it gives matches up exactly to what is contained in the syslinux.cfg file for both tce=[uuid] and waitusb:5=[uuid].  Actual numeric uuids.

I changed waitusb from the default of 5 to 15 just for good measure.

I proved that the line is actually being read by giving it another option, like multivt and checking.  It likes that.

Tried building it two way when prompted for the TCE/CDE directory:

1 - build itself by pointing to the CDE directory on the iso itself.  Shell prompt.

2) build by pointing to my persistent storage TCE directory.  Shell prompt with waitforx

Changing the filename of the CDE or TCE selection to include the trailing slash, made no difference.  Shell prompt.

Changed format from ext4 to ext2 and even vfat.  Not an issue, same shell result.

Checked to make sure that the stick actually populated the tce/optional directory in the target stick.  YES, in both cases.

Upon boot, you can see the wheel /-\-/-\ (wheelspin) as it loads the embedded extensions.  Shell prompt.

Ran tce-setup.  Shell on reboot.

I don't know - it can't seem to reproduce itself on a target stick when pointing to the CDE directory, nor when pointing to the TCE directory - even though by all appearances when the target stick is browsed, seems to contain all the necessary parts.

I do thank you for the help - certainly.  Something here is just nutty.  I'm trying again and seeing removing quotation marks from around the uuid's might help...

Title: Re: USB boots to TC@BOX:~$ prompt, not Tiny Core Desktop
Post by: PDP-8 on July 30, 2020, 10:37:01 PM
Maybe if I didn't write speeches .. :)

Instead of the statement "It just drops me into the shell"

a better diagnostic would be:

"Did it just drop to the shell like it would as if you were building a cli micro-core?

OR, does it do several seconds of wheel-spin indicating that it is indeed loading up the extensions, and THEN just dropping to the prompt?"

Mine is the latter.

Title: Re: USB boots to TC@BOX:~$ prompt, not Tiny Core Desktop
Post by: PDP-8 on July 31, 2020, 12:49:01 AM
Narrowing down - 32 bit and 64 bit act differently in TC 11.1

Objective : use the bootable iso to tc-install-gui itself to a target drive:

Results of test:

* 32bit TC iso boot.
* Immediately download and install the tc-install-gui with the apps gui.
* Run installer and point the extension directory when requested to the CDE directory to pick up the extensions.

Reboot to a successful writable clone of the iso boot stick.

64-bit:
Using the same procedures, after extension loading is seen while wheelspinning, you are dropped to shell prompt.

PERSISTANCE option:

When doing the above, but this time setting up a persistent tce-setdrive on another filesystem, and when prompted by the installer to choose a CDE/TCE directory in which to pick up the extension from, and of course this time using the TCE directory, the result for *both 32 and 64 bit*

A wheelspin attempting to load all the extensions, and then dump to shell prompt.

I don't know why the 64-bit version can't install itself to a target stick like the 32-bit version can when pointed to the CDE directory.

I can't explain why either one dumps to the shell after seemingly picking up the extensions (seen by the wheelspin), when using a user-defined TCE directory on another persistent filesystem.

Title: Re: USB boots to TC@BOX:~$ prompt, not Tiny Core Desktop
Post by: PDP-8 on July 31, 2020, 01:56:17 AM
Well, throwing in the towel for now.

Thanks to Rich for providing support and tips.  I'll explore further tomorrow and see if I can coax it.

Most importantly, thanks to the author for putting in some hard work to bring this to us in the first place.  At least I can bang out a writeable 32 bit clone of itself to a target disk.  Wish I had the dev-chops to find out what I'm doing wrong in 64 bit.

Although not a utility I'll use every day, it will remain in my wbar as a reminder of how important community contribution is in the first place!
Title: Re: USB boots to TC@BOX:~$ prompt, not Tiny Core Desktop
Post by: jazzbiker on July 31, 2020, 01:59:10 AM
Hi, Core guys!

I am not sure and can not check it right now (i'm on the 32-bit-only box), but tc-install.sh ( I don't know about tc-install of course) while making filesystems uses option -O ^64-bit. May this cause the trouble?
PDP-8, thanks for Your intentions and efforts to make TinyCore more acceptable for the newbies. I think, that the right way to trouble-shoot the "install-from-the-installed" issue is to modify tc-install to detect, that it is working not from the iso, and to look for extensions in the right place.

Regards!
Title: Re: USB boots to TC@BOX:~$ prompt, not Tiny Core Desktop
Post by: PDP-8 on July 31, 2020, 02:39:26 AM
Thanks jazzbiker - thing is I'm not trying to make it easier for noobs specifically - there are plenty of way to just burn-n-go like all the rest.  Even if it did work perfectly for me out of the box, most noobs would have trouble figuring out which mnt point to pick up the gz and extensions by navigating the filesystem like you would in midnight commander. :)

I don't mind it at all, but some might go nuts not seeing any icons with a click-here arrow. :)

Maybe the devs can try and duplicate my findings - not from their own fully-built and well-stocked system, but from a clean burn and see if what you are suggesting might be the case.

Anyway, I still want to make absolutely sure I've looked in all the corners as suggested by Rich to see if I can find a tweak that maybe I'm missing before contacting the author.

It's not a show-stopper.  I've got ways to achieve my goals be it making my own stick manually, to 3rd-party front ends, fromISOfile and other nifty cheats. 
Title: Re: USB boots to TC@BOX:~$ prompt, not Tiny Core Desktop
Post by: PDP-8 on July 31, 2020, 02:04:43 PM
Looking into other corners:

64 bit:  let tc-install gui simply build a text-only stick, and then add the minimal desktop with the usual tce-load -wi commands (substituting Xfbdev - no Xvesa of course).  No problem, does a very fine job of doing that.

Same result:  boot just fine.  Starts to load extensions and wheelspin indicator.  Dump to shell with waitforx.

Now I'm getting frustrated. :)  It's not a matter of making it work, but a matter of WHY it isn't working - well, working half-way.

I have to find out what's wrong, because otherwise, how many people are following the book and other docs, and getting the same result?

Otherwise, this utility, if I can't find out what's wrong, is doing more damage to the TC project overall, and I'm not speaking about click-here noobs, and should be removed from the repo and documentation.

Can anyone else duplicate my findings?

Title: Re: USB boots to TC@BOX:~$ prompt, not Tiny Core Desktop
Post by: Rich on July 31, 2020, 02:20:34 PM
Hi PDP-8
Without me rereading all of the posts, do I remember correctly you formatted a drive but did not create partitions? Create a partition
even if it occupies the entire device.
Title: Re: USB boots to TC@BOX:~$ prompt, not Tiny Core Desktop
Post by: PDP-8 on July 31, 2020, 03:09:56 PM
Hi Rich - thanks for hanging with me and my speeches.  I know I wouldn't. :)

I think I *may* have narrowed it down to a possible issue on 64 bit:

The gui tool will create a bootable 64 bit stick no problem.  Very nicely actually.  UUID's taken care of , partitioning and formatting handled automatically with your choice of filesystem, bootcode options prior to creation and so forth.

So I'm not a total ingrate. :)

The release iso itself boots to a minimal gui desktop, so I even substituted the CDE directory from the ISO (which works there) into the new stick, and renamed it tce of course.

But that failed too with the wheelspin and eventual drop to shell.  Drat.

So here are the steps:

1) Grab the TinyCorePure64.iso and burn it.  DD, whatever suits your fancy to get it to be part of the installation process, not necessarily a daily driver.

2) Boot the iso.  Insert a target stick.  Format doesn't matter since it's going to be rewritten anyway by the tc-install gui.

3) Download and install the tc-install-gui and run it

4) Navigate or allow the tool to download the 64 bit gz file.

5) Have the tool apply your choice of filesystem, cheat boot codes whatever to your liking to the target stick you select.

6) At your option, use the tool to hunt down where the extensions live on the original boot stick in the cde directory.  OR, simply allow the tool to make a text-only cli stick.

7) Pull the iso burnt stick, and allow your new stick created by the tool to boot.

It will successfully boot, BUT when it comes time to load the extensions, it will try to do so.  Indicated by several seconds of wheelspin at the command line.  At the end, instead of bringing up the minimal desktop, it just drops to the command line, sometimes seen with wait-for-x.

IF you allowed the tool to make just a text-only command line install to the new stick, it boots fine.  Nice job.  However, if you then proceed to manually install a minimal desktop with tce-load -wi [extensions], the system will dutifully place them in the optional directory.

But, after reboot, the same symptom exists as before - it *tries* to load the extensions, indicates it is doing so by wheelspinning characters, and then dumps to the shell.

So it's a total longshot, unless there are permission issues, that maybe that the new stick is using syslinux as the bootloader is conflicting with 64-bit somehow when it reaches the stage of activating the gui-extensions?

So thanks for looking into it - when you have time - TC is not a desk-job! :)
Title: Re: USB boots to TC@BOX:~$ prompt, not Tiny Core Desktop
Post by: PDP-8 on August 01, 2020, 03:38:57 AM
[SOLVED !!!]

Oh man, found it.  Now I feel foolish.

So what is it about the ISO installer stick that differs from the eventual writable one created by either tc-install or tc-install-gui ?

Take a gander at the grub.cfg in the ISO installer for it's kernel options:
/mnt/sdX/EFI/BOOT/grub/grub.cfg   (where X is YOUR device - no partition, since it emulates a cd, ie sda)

THIS should have been added to the bootcode option line in the stick that the tool makes to your new target stick:

Code: [Select]
vga=791 video=vesafb:ywrap,mtrr:3
If you are on your target device, sitting at the shell-prompt after it crashed trying to bring up video, THIS is why!

See your new syslinux bootloader options on your new stick at
/mnt/sdX1/syslinux.cfg

Add the above vga and video values to it.

RICH - you can clearly mark this as SOLVED !!!
Title: Re: USB boots to TC@BOX:~$ prompt, not Tiny Core Desktop
Post by: jazzbiker on August 01, 2020, 05:04:36 AM
Hi, PDP-8!

Congrats! And 32-bit works without those bootcodes?
Title: Re: USB boots to TC@BOX:~$ prompt, not Tiny Core Desktop
Post by: Juanito on August 01, 2020, 05:13:29 AM
32-bit uses Xvesa not Xfbdev
Title: Re: USB boots to TC@BOX:~$ prompt, not Tiny Core Desktop
Post by: jazzbiker on August 01, 2020, 06:13:24 AM
Ok, thanks!
But not so clear for me-the-noob... I was sure that without vga=XXX bootcode Xvesa will not start (excepts grub is used with gfxpayload=keep). Is this false statement? Do Xvesa really can run without vga=XXX bootcode?
Title: Re: [Solved} USB boots to TC@BOX:~$ prompt, not Tiny Core Desktop
Post by: Rich on August 01, 2020, 06:31:45 AM
Hi PDP-8
... RICH - you can clearly mark this as SOLVED !!!
Clearly marked as [Solved]
.
Title: Re: [Solved} USB boots to TC@BOX:~$ prompt, not Tiny Core Desktop
Post by: PDP-8 on August 01, 2020, 02:10:13 PM
Even though the problem is solved, there is a big caveat.

Strictly speaking, on *this* 64 bit machine, all I really needed was

Code: [Select]
vga=791
I didn't truly need the other option.  An advanced user would recognize this.  A noob-hacker type would merely see if the kernel options - whether they are obeyed or not - brings up the gui like the ones passed in the iso.

This is where it can get REAL sticky:

A 64-bit user, needs to know their video options in the first place.  The installer does a fine job, but that's not it's job to figure out if you do or not.  Hence, video options are left to you.

I should have recognized this right off the bat with the wheel-spinning picking up extensions, and not bringing up video.  Alas.

SO - this also depends on actually reaching the bootable stage and failing at the shell prompt in the first place!  Ie, I'm providing a weak hint to those that actually reach this stage.

The problem that you may encur before this even starts, might be wondering why the iso-release burned stick is even recognized and booted in the first place by your machine, but the subsequent tc-installer burnt stick is not recognized as a bootable device at all on another machine!

Never-mind dropping to a shell prompt - you can't boot something that's not recognized, and THAT is highly dependent on how your 64-bit machine is setup for legacy/csm/uefi options and if the target stick built with syslinux is formatted such to take all these additional variables that are not present on 32 bit environments.

I don't know how the devs deal with all that - I mentioned to Jason W that I'd probably end up stamp-collecting as a hobby. :)

Or just toss in the towel on all this variable nonsense, and run a cluster of raspberry-pi's using piCore where at least some sort of standard is not totally out of hand.

So long answer is that even as an end user these days, especially with 64 bit, you have to be on your toes with TC.  They gratefully provide some great tools to get around problems that might totally stump other distros.  There are solutions to be found, but depending on your skills or needs, what solves one problem, may not be the absolute best.

But in classic Unix tradition, given the environments the ops described, this seems to be the 90% solution.

Still, hat's off to TC, and the community helping to build tools to make it even possible in the first place.

So, still SOLVED. :)