[Solved} USB boots to TC@BOX:~$ prompt, not Tiny Core Desktop

[killingtime]

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,

[coreplayer2]

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

[polikuo]

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

[killingtime]

Thank you for the commands.

https://pastebin.com/YExFr5qX

Regards.

[coreplayer2]

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

[killingtime]

That worked.

Thanks.

[techsuper]

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

[Rich]

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?

[techsuper]

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.


 

[NewUser]

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.

[PDP-8]

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.

[PDP-8]

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.

[PDP-8]

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.

[aus9]

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?

[PDP-8]

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.