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

[Rich]

Hi PDP-8
From the FAQ (Emphasis mine):

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.

[PDP-8]

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...

[PDP-8]

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.

[PDP-8]

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.

[PDP-8]

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!

[jazzbiker]

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!

[PDP-8]

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. 

[PDP-8]

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?

[Rich]

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.

[PDP-8]

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!

[PDP-8]

[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 !!!

[jazzbiker]

Hi, PDP-8!

Congrats! And 32-bit works without those bootcodes?

[Juanito]

32-bit uses Xvesa not Xfbdev

[jazzbiker]

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?

[Rich]

Hi PDP-8

... RICH - you can clearly mark this as SOLVED !!!

Clearly marked as [Solved]
.